Les origines de l'Agile

Même si votre équipe de développement n'est pas encore passée aux méthodes agiles comme Scrum ou Extreme Programming, il est très probable qu'elle y réfléchisse au moins. L'« Agile » s'attaque effectivement à certains des plus grands problèmes dont souffrent les équipes logicielles depuis des décennies. Cependant, de nombreux chefs de produit, designers et professionnels de l'assurance qualité sont d'abord déconcertés par l'Agile, car ils ne sont pas encore vraiment familiers avec leurs rôles dans les méthodes agiles. Ces méthodes nécessitent absolument ces rôles, mais j'attribue cette confusion aux origines des méthodes agiles. Pour éclairer les problèmes que l'« Agile » est censé résoudre et pour identifier les défis qui persistent, il est utile que j'explique les origines de l'Agile.

Beaucoup de gens sont surpris d'apprendre depuis combien de temps Scrum – la méthode agile la plus connue – existe. Elle est née en 1986 au Japon. (Un exemple de la durée que peut prendre une nouvelle idée avant de vraiment percer.)

Les origines de l'Agile se trouvent dans le développement logiciel sur mesure

Le plus important, c'est que ces méthodes viennent du monde du logiciel sur mesure (Custom Software).

Développer un logiciel sur mesure, c'est-à-dire un logiciel pour un objectif spécifique et pour un client spécifique, a longtemps été une forme extrêmement difficile de développement logiciel. C'est en partie parce que les clients ne savent notoirement pas exactement ce qu'ils veulent. Ils ont cependant un besoin et signent donc un contrat avec une entreprise de logiciel sur mesure ou se réunissent avec leurs équipes informatiques internes, qui doivent alors travailler dessus. Mais quand quelque chose est livré, les clients disent systématiquement que ce n'est pas ce qu'ils voulaient et tout recommence, la frustration grandissant naturellement. Le besoin fondamental persiste cependant et cela a assuré l'emploi d'innombrables développeurs, entreprises et prestataires de services.

De plus, dans le développement de logiciels sur mesure, on a souvent eu le dessous quand il s'agissait de recruter et de s'assurer les meilleurs talents en développement. C'est probablement en partie parce que les professionnels préfèrent travailler dans des entreprises qui développent des logiciels pour des milliers, voire des millions de clients. La raison en est notamment que les professionnels reçoivent une meilleure rémunération dans les entreprises où l'équipe produit doit développer des logiciels que beaucoup de gens veulent, sinon elles ne gagnent pas d'argent. Ces entreprises savent qu'elles doivent embaucher de bonnes personnes pour créer des produits à succès et la rémunération en découle naturellement. Cependant, seul un faible pourcentage de développeurs travaille sur des logiciels standards, la plupart développent des logiciels sur mesure.

L'avantage de l'Agile ?

Comme le client, dans le cas du logiciel sur mesure, pense savoir ce qu'il veut, on y trouve rarement le rôle du chef de produit. De même, on ne trouve pratiquement jamais de designers d'expérience utilisateur. Les raisons en sont assez complexes et incluent une certaine méconnaissance (peu de gens dans le monde du logiciel sur mesure savent ce que font les UX Designers et à quoi ils servent) et une sensibilité aux coûts (réduire les coûts en laissant les développeurs faire le design). En toute équité, il faut dire que les rares designers de notre secteur sont immédiatement happés par les entreprises de produits qui ont compris l'importance des designers. Il reste donc peu de designers pour les équipes développant des logiciels sur mesure, quand les dirigeants ont enfin compris qu'ils en ont besoin. De même, l'assurance qualité en tant que discipline à part entière est quasi inexistante dans le logiciel sur mesure et on attend donc des développeurs qu'ils se chargent aussi des tests.

Un autre point important pour comprendre le monde du logiciel sur mesure est que la plupart des projets de logiciels sur mesure sont relativement petits et doivent soutenir les activités internes d'une entreprise – par exemple les ressources humaines, la facturation, la production, etc. Donc des domaines où il n'y a qu'un nombre limité d'utilisateurs et où des choses comme la scalabilité et la performance ne sont généralement pas aussi importantes.

Le processus en cascade

Autrefois, dans le logiciel sur mesure, on avait besoin du processus en cascade parce que les différentes parties prenantes avaient besoin d'un moyen de suivre l'avancement pendant le long processus de développement des applications souhaitées. En fait, la méthode en cascade trouve aussi son origine ici.

Dans le logiciel standard, acheté pour ses performances et ses avantages, certains rôles ont été introduits. Le chef de produit doit recueillir et représenter les besoins de tous les clients. Les designers doivent créer une expérience utilisateur utilisable et désirable, et les testeurs de l'assurance qualité doivent vérifier que le logiciel fonctionne bien comme promis au client dans la publicité.

La solution aux problèmes du processus en cascade est venue avec les méthodes agiles

Dans le logiciel sur mesure, cependant, les mêmes problèmes continuaient d'apparaître quand il s'agissait de créer quelque chose qui satisfasse les clients. Pour ces équipes en particulier, les méthodes agiles représentent une amélioration significative. La communication entre clients et développeurs s'améliore. Le risque est considérablement réduit grâce à des itérations plus petites et plus fréquentes. Les clients peuvent ainsi découvrir beaucoup plus rapidement s'ils aiment quelque chose, plutôt que de continuer à attendre la fin d'un long processus. De plus, les méthodes agiles aident à introduire des concepts modernes de test logiciel et évitent aux équipes de passer des heures à créer des documents qui ne sont de toute façon presque pas lus et deviennent rapidement obsolètes.

L'Agile pour le logiciel sur mesure et standard

Fondamentalement, ces avantages s'appliquent aussi au logiciel standard, mais je souligne toujours que certaines choses doivent alors être adaptées. Un autre domaine où il y a eu des difficultés est l'architecture logicielle ou la conception logicielle.

Les méthodes agiles encouragent les développeurs à ne pas trop se figer sur leur façon de mettre en œuvre, car tout doit pouvoir être revu ou modifié rapidement et facilement. Même si cela fonctionne souvent bien dans le logiciel sur mesure, cette approche est trop naïve par exemple pour les grands services Internet qui ont des centaines, des milliers ou des millions d'utilisateurs.

Il n'est donc pas surprenant que de nombreuses équipes de logiciels standards aient eu des problèmes avec les méthodes agiles, car les origines des méthodes agiles se trouvent dans le logiciel sur mesure. Les nombreux livres, articles et cours qui ne mentionnent ni les chefs de produit ni les designers d'expérience utilisateur (designers d'interaction et designers visuels) ne sont pas destinés au développement de logiciels standards.

Les équipes qui veulent passer aux méthodes agiles en développement logiciel devraient donc vérifier au préalable si l'entreprise censée aider leur organisation comprend aussi ce qui est nécessaire pour le logiciel standard. Ce n'est pas toujours le cas, mais assez souvent.