S’il y a une discipline de la gestion de projet qui connaît une effervescence exceptionnelle depuis plusieurs années c’est bien celle du développement logiciel. Scrum, Extreme Programming, Agile, RAD, plusieurs nouvelles méthodologies ont fait leur apparition et une littérature abondante existe sur le sujet.
Il est donc surprenant de constater que, dans le domaine du développement de produit électronique, où la constituante logicielle est en général très significative, ces nouvelles techniques soient encore si peu utilisées par les PME québécoises. Ce manque d’enthousiasme est probablement dû au fait que les décideurs sont souvent issus de la branche hardware et, moins sensibilisés aux spécificités du développement logiciel, ils ont naturellement tendance à promouvoir des méthodes plus conventionnelles du genre waterfall et concurrent.
Cela dit, j’ai plusieurs fois assisté à la mise en place spontanée de pratiques similaires sous la pression des circonstances, par exemple l’utilisation de cycles rapides de publication incrémentale (XP) et la tenue de courtes réunions d’équipes quotidiennes (Scrum). Mais je crois que les entreprises auraient avantage à utiliser plus formellement ce genre de méthodologies pour leurs développements logiciel, et ce, dès le début du projet. Pour reprendre l’exemple des réunions d’équipes quotidiennes, une telle stratégie peut rapidement tourner à la perte de temps si elle n’est pas combinée avec la discipline qu’impose la méthodologie Scrum.
Comme toujours, Google et Wikipedia sont vos meilleurs amis si vous voulez en apprendre davantage sur ces méthodologies de développement logiciel.
Pierre Marsan
Les numéros de pièce significatifs semblent avoir la vie dure dans la PME manufacturière québécoise. Même dans des entreprises fraîchement établies on retrouve encore souvent ce genre de système, et ce, malgré la quasi-unanimité des voix expertes qui découragent le procédé.
À mon tour d’en rajouter. Selon mon expérience, les numéros de pièces significatifs, ça ne marche pas longtemps, ça ne sert pas à grand-chose et ça finit par coûter cher.
Cela dit, l’un des arguments les plus convaincants en faveur d’un système intelligent est sa capacité d’effectuer des recherches basées sur les catégories définies par le numéro. Effectivement. Le processus d’assignation d’un numéro significatif oblige une rigueur qui facilite beaucoup les recherches de composantes (quand le système fonctionne parfaitement, ce qui est rarement le cas).
Mais, pourquoi utiliser le numéro de pièce pour ça?
On peut tout aussi bien utiliser le même type de processus et imposer la même rigueur pour définir par exemple, le champ description de la pièce, ou tout autre champ spécifiquement créé à cette fin. Ça répond aux mêmes besoins (si le système permet d’effectuer des recherches intelligentes sur le champ choisi) et c’est beaucoup moins contraignant (lorsqu’un changement à la codification devient nécessaire, il est généralement infiniment plus difficile de modifier le numéro de pièce que tout autre champ).
En tout cas.
Il y a plusieurs années, j’avais développé une macro Excel Visual Basic permettant de construire des descriptions de pièces normalisées basées sur des tables de codifications. Pensant qu’elle pouvait être utile à quelqu’un, je l’ai remise au goût du jour et elle peut être téléchargée ici. Son utilisation est relativement simple et des notes expliquent son mode d’opération. N’hésitez pas à me laisser un commentaire si vous l’utilisez.
En passant, cette macro peut également être utilisée pour générer des numéros de pièce…significatifs.
Pierre Marsan
