Pousser la programmation à l'extrême

Mansour Raad avait un gros problème. Sa start-up, DiscoverCast, développait un logiciel de détection de collision pour l'industrie du transport aérien. Des erreurs dans le code pourraient coûter des vies. Mais l'argent s'est tari après un premier tour de financement, et l'embauche de programmeurs supplémentaires pour terminer une version à l'épreuve des bogues était hors de question.

Raad a donc lancé une discipline de codage relativement nouvelle appelée programmation extrême. Au lieu de travailler seuls sur des missions individuelles, les programmeurs se sont associés, l'un écrivant du code tandis que l'autre regardait et critiquait, fournissant à la fois un œil critique et une sauvegarde d'une importance critique. [Ma femme] a eu un bébé, mais le projet devait continuer, dit Raad. Parce que je le montrais aux autres, quelqu'un pouvait me mettre à ma place. L'entreprise a respecté les délais sans augmentation des erreurs en raison de la communication.

La plupart des programmeurs ne sont pas plus satisfaits de la qualité du logiciel que leurs clients. Aujourd'hui, de plus en plus de personnes essaient de trouver des moyens de créer des logiciels solides sur un marché qui attend de nouveaux produits et améliorations et qui les souhaite rapidement. De plus en plus, les éditeurs de logiciels se tournent vers des stratégies de développement avec des noms tels que le développement agile et des slogans chargés d'adrénaline et de programmation extrême bien adaptés à l'image de soi des codeurs en tant que héros robustes de l'ère de l'information. En réalité, la tendance - qui a une longue histoire - signale un rejet de la programmation prima donna en faveur du travail d'équipe et de la collaboration.

Dans l'industrie du logiciel, le code bogué a longtemps été accepté comme un fait de la vie, bien que aggravant et coûteux ( voir Pourquoi le logiciel est si mauvais, ENFANTS Juillet / Août 2002 ). Le problème est que dans les logiciels, les gens font trop confiance à leur propre ingéniosité, explique Michael Stiefel, un consultant qui forme ses clients aux méthodes de fiabilité des logiciels. Je voyais tous ces jeunes dans la vingtaine faire les mêmes erreurs que nous avons commises dans les années 70 et 80, et je me demande pourquoi nous devons revivre tout ça.

Pour réduire les erreurs, les réformateurs vantent des approches de l'ingénierie logicielle - connues dans l'industrie sous le nom de développement agile - qui mettent l'accent sur le travail d'équipe, la collaboration avec les utilisateurs finaux et une approche flexible du changement. Pour créer son logiciel anticollision, la société de Raad a utilisé un type de développement agile, appelé programmation extrême, qui met l'accent sur les tests constants ainsi que sur la collaboration.

Si vous êtes capable d'appliquer [un environnement collaboratif] à sa pleine puissance, la qualité des produits sera meilleure, déclare Michele Marchesi, fervent défenseur de la programmation extrême et professeur de génie électrique à l'Université de Cagliari en Italie.

L'un des aspects les plus puissants de la programmation agile est ce qu'on appelle la programmation par les pairs, dans laquelle les développeurs s'associent et écrivent à tour de rôle du code et expliquent sa logique à l'autre. Les paires sont temporaires, se séparant et s'échangeant périodiquement pour encourager encore plus d'interaction. De nouveaux yeux examinent chaque morceau de code, créant un processus de révision continue.

Deux personnes peuvent échanger des idées, explique Frank Arkell, ingénieur logiciel en chef chez l'entrepreneur de défense General Dynamics Decision Systems, qui utilise des techniques collaboratives depuis deux décennies. Pour garder les équipes à jour, General Dynamics les modifie pour chaque projet.

Un autre avantage de la programmation par les pairs ? Pression des pairs. Personne ne veut être la personne qui se relâche, alors ils travaillent tous les deux plus dur, explique Scott W. Ambler, président de Ronin International et auteur et conférencier sur le développement agile.

Mis à l'épreuve

Les approches collaboratives transforment également la façon dont les logiciels sont testés. Traditionnellement, les tests étaient un processus en deux étapes. Premièrement, les programmeurs écrivent du code en fonction des exigences. Ensuite, un groupe distinct teste le résultat. Mais lorsqu'un logiciel comprend des millions de lignes de code, le processus en deux étapes est analogue à la conception d'une automobile sur papier, à sa construction, puis à la vérification pour voir si la conception a fonctionné.

Cette approche n'a tout simplement pas fonctionné pour des développeurs comme Nicholas Stamos, directeur technique de Phase Forward, basé à Waltham, MA. Phase Forward développe des logiciels pour la conduite d'essais cliniques pharmaceutiques, et ses produits doivent satisfaire aux exigences strictes de la Food and Drug Administration des États-Unis.

Stamos affirme que Phase Forward répond à ces exigences, en partie grâce à une collaboration étroite et constante entre les programmeurs de l'entreprise et le personnel d'assurance qualité. Vous ne pouvez pas le jeter par-dessus le tableau arrière et espérer, dit-il. La qualité doit être intégrée dès le premier jour. Lorsque les programmeurs terminent un composant, l'équipe qualité vérifie leur travail. Ensuite, les équipes échangent leurs places pour une autre série de corrections de bugs. Enfin, l'application intégrée est testée pour trouver des problèmes d'interaction entre les composants. Au lieu de l'ancienne approche en deux étapes, les tests deviennent un processus interactif et continu.

Certaines entreprises essaient une approche itérative similaire non seulement pour tester, mais pour concevoir le code en premier lieu. Cognizant Technology Solutions, une société de conseil basée à Teaneck, dans le New Jersey, a découvert que les méthodes existantes consistant à commencer par des spécifications formelles puis à écrire du code pour les satisfaire auraient pu fonctionner il y a 20 ou 30 ans. Mais dans un monde qui fonctionne sur le Web et a besoin de flexibilité, formel peut signifier rigide.

Lorsque nous avons essayé d'utiliser les processus traditionnels pour ces nouveaux types de projets, soit les clients étaient vraiment frustrés parce que nous les avons forcés à geler le processus, soit les équipes de projet ne suivaient tout simplement pas le processus, explique Kumar Mahadeva, PDG de Cognizant. Au lieu de cela, les projets utilisent une série de prototypes suivis d'un cycle d'industrialisation, permettant à l'entreprise de gérer les changements soudains des clients d'une manière qui a moins d'impact sur la fiabilité que d'ajuster un programme une fois celui-ci terminé. Les futurs utilisateurs fournissent un flux constant de commentaires au fur et à mesure que l'application prend forme.

Mais les limites ultimes de la qualité du logiciel peuvent ne pas résider dans les compétences des programmeurs ou dans la force du processus de développement. C'est l'énigme à laquelle nous et de nombreux fabricants sommes confrontés aujourd'hui : qu'est-ce qu'un niveau de qualité acceptable ? déclare James Hymel, directeur de l'ingénierie logicielle chez Motorola. Si vous avez des concurrents qui produisent des [produits] mignons, bon marché, mais buggés et que les clients disent que c'est acceptable, c'est-à-dire qu'ils dépensent leur argent pour eux, vous seriez mis au défi.

Avec des méthodes telles que le développement agile, le partenariat de développement et de test et l'implication des utilisateurs finaux, les développeurs de logiciels prennent des mesures pour améliorer leur produit. Mais en fin de compte, la plus grande contrainte à la qualité peut être les mêmes personnes qui l'exigent le plus fort : les consommateurs.

cacher