SyntaxHighlighter

2010/12/03

Agile... ou pas

Nous sommes dans une époque où être dans un environnement de développement de logiciel de type "Agile" est un mot magique, comme les expressions "lean manufacturing" ou "just in time" le sont dans le domaine de la production, par exemple. C'est tendance, comme on le dit dans les émissions télé qui transforment un salon grotesque en un salon à la mode mais qui deviendra aussi grotesque dans quelques années.

Être "Agile" est un concept qui met l'emphase sur le fait que le développement de logiciel doit pouvoir s'adapter aux besoins des clients. Ces besoins sont complexes et peuvent parfois mal se déclamer de manière succinte; ils sont clarifiés au fur et à mesure qu'un logiciel se développe, se précise. L'esprit d'équipe est au coeur des méthodes agiles: scrum (inspirée du rugby) et la méthode XP (Extreme programming) entre autres. Tout cela est louable et a prouvé ses mérites. Mais ce n'est qu'un concept cependant...

Dans certains cas, c'est une raison à portée de la main qui vise à justifier le fait que les documents nécessaires dans le contexte de développement logiciel ne sont pas maintenus ou simplement produits.

Par opposition à Agile, il y a la méthode "waterfall" (chute d'eau, en anglais) qui dit que toute la conception, l'analyse, la documentation, doivent être produites avant même de taper la plus solitaire ligne de code. C'est une autre extrême et il y a un juste milieu entre les deux.

Personnellement, j'ai travaillé dans une entreprise qui se réclamait de suivre des méthodes de développement dites Agile. Jamais je n'ai vu une entreprise où la documentation était aussi bâclée. J'ai même eu à consulter de la documentation sur des modules existants lors de mon entrée en fonction dans la compagnie. Plusieurs phrases étaient même incomplètes sur l'un de ces documents, pourtant enregistré comme version officielle dans le système de documentation ISO. Preuve que ce ne sont pas là des gages de qualité...

Par opposition, j'ai travaillé dans une entreprise qui se dit ne pas suivre les méthodes Agiles. Pourquoi? Tout d'abord pour des raisons historiques: cette entreprise a commencé à développer du code il y a environ quinze ans. À ce moment, les méthodes Agiles n'étaient pas tendance.

Ensuite, il y a des contraintes de respect de budget: les clients s'attendent à payer un certain prix, pré-déterminé, pour une modification à du code existant ou des nouvelles fonctionnalités. Pour évaluer convenablement ces coûts, il faut qu'une analyse soit faite au préalable afin de déterminer les embûches potentielles, les implications, les tests à effectuer, la traduction de certaines informations, etc. Mais Être Agile rend cette évaluation plutôt difficile, du moins du point de vue de la première entreprises décrite ci-haut, car

1) on ne peut se fier à documentation existante: on répète les erreurs déjà observées mais dont les solutions sont non-documentées.

2) on néglige l'aspect analyse du travail et on s'engage sur un terrain inconnu.

Notons que la mauvaise documentation peut être compensée par la formation croisée: au lieu de consigner l'information dans des documents, on la consigne dans le savoir collectif. Mais une entreprise qui se dit Agile souhaite réduire ses coûts. Et si elle mets de côté la production de documentation sur le code existant (mettons de côté les documents d'analyse pour l'instant), alors il y a fort à penser que les ressources humaines sont limitées...

Il faut se méfier de méthodes "à la mode"; elles peuvent représenter plusieurs aspects qui sont intéressants mais qui tentent de cacher l'essentiel. Dans le cas présent, il faut produire du logiciel. Le lecteur intrigué pourra lire l'essai de Paul Graham intitulé The Revenge of the Nerds qui parle aussi du problème de langages de programmation qui sont "à la mode".