Agilité et Craftsmanship : quelles interactions ?

Agilité ou craftsmanship ? Et pourquoi pas les deux ? En effet, très complémentaires et liées depuis leurs genèses respectives, ces deux pratiques de développement s’enrichissent mutuellement. On vous explique pourquoi !

Agilité et craftsmanship (ou artisanat logiciel en français) représentent deux mouvances distinctes dans le monde du développement logiciel. Chacune d’elles mériterait un article, plusieurs même, mais cet article-ci a vocation à vous présenter les interactions possibles entre les pratiques inhérentes à ces deux mouvances. Nous ne décrirons donc qu’en surface ce que recouvrent l’agilité et Craftsmanship, et leurs pratiques associées. C’est pourquoi, quelques connaissances préalables sont nécessaires à la bonne compréhension de cet article. L’artisanat logiciel est-il un prérequis à l’agilité ? L’agilité est-elle un frein à l’artisanat ? Comment concilier les deux ? Explications.

Agilité et craftsmanship de quoi s’agit-il ?

Sans entrer dans les détails, il est intéressant de replacer le contexte.

Tout d’abord, l’ingénierie logicielle est une activité relativement récente comparée à l’ingénierie matérielle ou au BTP. En effet l’ingénierie du logiciel n’est reconnue en tant que telle que de façon « anecdotique » lors du programme Apollo grâce à Margaret Hamilton en 1958, puis publiquement en 1968 lors d’une conférence de l’OTAN. L’agilité et l’artisanat logiciel datant des années 2000 (en tout cas, leur formalisation), d’autres techniques ont eu cours pendant le demi-siècle précédent.

L’ingénierie logicielle étant une pratique nouvelle, il était donc nécessaire d’en définir les pratiques d’ingénierie et de gestion de projet. À cette fin, les acteurs du monde logiciel se sont tournés vers des disciplines qui avaient fait leurs preuves, et se sont inspirés de ce qui se faisait dans l’ingénierie du matériel ou la construction de bâtiments.

Seulement voilà, on ne construit pas un logiciel comme on construit une cathédrale. En tout cas, on a rarement entendu un client changer d’avis quelques semaines avant la livraison et dire, qu’en fin de compte, il préférerait sa cathédrale en style baroque plutôt qu’en style gothique.

De l’agilité…

Nourries de ce sentiment, certaines pratiques essayant de faire les choses autrement et surtout mieux, ont ainsi émergé, comme par exemple l’extrême programming. Suivant cette trajectoire, en 2001, un groupe de personnes reconnues dans leurs domaines respectifs s’est réuni pour discuter de ces méthodes émergeantes et ont publié le manifeste agile. Si la publication du manifeste marque la naissance de l’agilité, c’est la diffusion de cadres de travail tels que Scrum ou SAFe qui la popularisera dans les entreprises.

Au final, qu’est-ce que l’agilité ? La culture de l’agilité vise à remettre l’humain au cœur des projets, à parler des utilisateurs finaux mais aussi de toutes les personnes qui travaillent sur un même projet. Dans quel but ? Celui de mieux réussir les projets et de réaliser de meilleurs produits. Une phrase que j’aime bien est de « réduire le gâchis humain ».

… à Craftsmanship

Malheureusement, en tout cas selon au moins un des signataires du manifeste, Robert C. Martin dit « Uncle Bob », il manque au manifeste une mention de la qualité technique. En proposant une 5^e valeur au manifeste agile lors d’une keynote en 2008, mais aussi avec l’apparition de certains livres comme Software Craftsmanship (2001) de Pete McBreen ou The Software Craftsman (2004) de Sandro Mancuso (et préfacé par Robert C. Martin), une mouvance ayant pour but d’améliorer les compétences des développeurs et la qualité technique des projets de développement logiciel apparaît : l’artisanat logiciel.

Par ce rappel historique, on s’aperçoit que ces deux pratiques, agilité et artisanat, sont étroitement liées dans leurs genèses.
Faut-il alors choisir l’une en ignorant l’autre ? Doit-on au contraire appliquer les deux ? Ou même, avons-nous le choix ?

Pour répondre à ces questions, il faut nous intéresser aux conséquences de la mise en place de pratiques liées à l’agilité ou à l’artisanat.

Pourquoi une entreprise voudrait devenir Agile ?

Il y a deux raisons pour lesquelles une organisation peut vouloir « devenir agile ».

• La bonne raison : changer des choses pour s’améliorer. Je dis « des » et pas « les », car l’agilité ne remet pas tout en question. Simplement, on considère sain de remettre en question des pratiques, et de les améliorer ou même de les supprimer si on le juge pertinent.
• La mauvaise : parce que tout le monde le fait ou parce que c’est tendance.

Je ne vais pas m’attarder sur la seconde. En revanche pour la première, il y a une composante importante à retenir : le changement.

Le problème du changement, c’est qu’il fait peur. C’est une réaction tout à fait naturelle de résistance au changement. Mais cette réaction conduit parfois à des comportements irrationnels dans lesquels toute demande de changement doit être justifiée, prouvée, vérifiée et validée, si possible avec le formulaire A39.

Lorsque l’on parle de changer des procédures transverses à plusieurs équipes, bien sûr qu’il ne faut pas faire les choses à la légère. Mais il ne faut pas non plus tomber dans des extrêmes de procédure. Quand cela se produit, même pour les changements de pratiques internes à une équipe, on tombe sur ce qui est pour moi le nœud du problème : un manque de confiance envers les acteurs du changement.

La confiance pour mieux travailler

L’une des valeurs agiles repose sur « Les individus et leurs interactions, plus que les processus et les outils ». Cependant, les processus existent pour plusieurs raisons : il ne faut donc pas simplement les balayer d’un revers de main pour se libérer des contraintes ou parce que l’on pense pouvoir mieux faire.

Il faut voir les processus comme des contrats, contrats qui assurent la confiance entre les parties. Lorsque les parties s’impliquent dans un processus, elles s’engagent alors sur ce qu’il faut faire, sur comment le faire et sur des durées. Une fois ces informations à disposition, on est alors davantage confiant dans la suite des choses.

Comme énoncé précédemment, si l’on souhaite s’exercer à l’agilité, c’est pour améliorer les choses. Or cette amélioration passe par la remise en cause des méthodes existantes. En ce sens, l’amélioration continue est le douzième principe du manifeste agile. En suivant ce principe, si une méthode ou un processus est jugé mal adapté au cadre de travail de l’équipe, celui-ci pourra être remis en question. Malheureusement, supprimer ou modifier un processus, c’est aussi se passer de la confiance qu’il apporte.

Ainsi, au risque de me répéter, changer les façons de faire peut faire peur et des questions légitimes peuvent être soulevées. Parmi lesquelles :

• Comment être sûr que les équipe délivreront les bonnes choses ?
• Les équipes délivreront-elles à temps ?

Il faut donc trouver des moyens pour maintenir, voire établir une confiance entre les divers acteurs d’un projet. Pour les équipes de réalisation IT, un moyen d’y parvenir réside dans la qualité dans la réalisation. On cherchera donc à améliorer la qualité intrinsèque, invisible à l’utilisateur, afin d’améliorer la qualité extrinsèque perçue par l’utilisateur.

L’artisanat logiciel au secours de l’agilité

Si l’on souhaite supprimer ou modifier une façon de faire existante, il faut s’assurer que les objectifs que l’on pouvait atteindre avant, soient toujours atteints après changement. Le processus ne doit pas être une fin en soi. C’est bien l’objectif voulu par le processus que l’on souhaite conserver, voire améliorer.

Néanmoins, les façons de faire en entreprise sont parfois trop datées ou trop générales, ou parfois simplement inadaptées au contexte de réalisation d’un produit en particulier. Or dans un cadre agile, on va remettre en question la façon de faire et proposer une nouvelle façon de faire plus adaptée à l’équipe.

Améliorer la qualité technique, et par extension la qualité des réalisations de l’équipe, va servir deux objectifs :

• Garantir que les objectifs précédemment définis soient toujours atteints.
• Établir ou améliorer la confiance envers l’équipe

Vous l’aurez sûrement deviné, mais une façon d’améliorer la qualité des réalisations techniques est la pratique de l’artisanat logiciel. Personnellement, je dirais même que l’artisanat logiciel consiste à l’amélioration de cette qualité technique et que les pratiques associées sont des moyens d’y parvenir.

Qu’est-ce que la qualité ?

Ainsi, dans le cadre de l’artisanat logiciel, la notion de « qualité » ne se contente pas simplement de signifier « ça marche », et encore moins « il n’y a pas trop de bugs ». Par qualité, ce qu’on entend vraiment, c’est :

• Pas de bug. En tout cas, pas sur ce qui est nouveau, ne pouvant nous engager sur l’existant. Il faut sortir de l’idée que les bugs arrivent. Il faut tout faire pour qu’ils n’arrivent pas et, au cas où, corriger non pas le bug, mais les actions qui ont mené à l’arrivée de ce bug. L’humain reste faillible, mais le bug doit être l’exception et non la règle. On est ainsi capable de délivrer des « logiciels opérationnels ».
• Une solution technique comprise. Pour vulgariser, si le code n’est pas clair, il y a de fortes chances que vous écriviez des bugs. Plus la solution technique est claire et maîtrisée, plus il sera simple d’ajouter de nouvelles fonctionnalités lors de « la collaboration avec les clients » ou de vous adapter au changement.
• Une solution technique partagée. Si tout le monde maîtrise le code, personne n’est indispensable et surtout chacun peut aider les autres. « Les individus et leurs interactions » participent à l’émergence du code en tant qu’œuvre collective et non pas de patchworks de codes individuels.
• Une solution technique pérenne. Les choix d’aujourd’hui ne doivent pas devenir des contraintes demain. « L’adaptation au changement » est donc possible voire simple.

Quelles conséquences pour la création de la confiance ? Moins de bugs, et une solution claire et maîtrisée par tous permettent alors de développer plus rapidement, sans allers-retours entre les différentes parties (métier, dev, QA) et même d’être plus prédictible. Les coûts de développement s’en voient ainsi considérablement réduits. Au final, satisfaire convenablement les parties prenantes permet de gagner leur confiance.

Mais si l’artisanat profite beaucoup à l’agilité, cela est aussi vrai dans l’autre sens.

L’agilité pour promouvoir l’artisanat logiciel

Deux aspects permettent de mettre en valeur l’artisanat logiciel :

• Si les partenaires d’une organisation qui souhaite devenir agile ont peur de la perte de certains processus, alors l’artisanat logiciel se présente comme une solution pour garantir un niveau de qualité suffisant pour avoir confiance dans les décisions de l’équipe.
• L’autre aspect, c’est l’autonomie des équipes.

En effet dans une organisation agile, les équipes sont plus autonomes. En Scrum par exemple, on donne des objectifs aux équipes mais les moyens pour les réaliser sont au choix de l’équipe. L’équipe est seule juge du niveau de qualité technique qu’elle souhaite mettre en place. Par conséquent, elle ne devrait pas avoir à se justifier de mettre en place des pratiques d’artisanat logiciel si elle le juge nécessaire à la réalisation d’un produit de qualité.

L’agilité devient un cadre d’expression pour l’équipe technique lui permettant à la fois de mettre en place l’artisanat logiciel, mais aussi de le promouvoir auprès des parties prenantes lorsqu’elle délivre avec succès et qualité.

Un tout plus grand que la somme de ses parties

Nous avons vu que chacune de ces deux pratiques, agilité et craftsmanship, apporte des bénéfices et se nourrit de l’autre. Dans la mesure où cela ne crée pas une charge cognitive trop importante sur les membres des équipes, vous avez tout intérêt à mettre en place les deux pratiques en même temps. Si vous pratiquez déjà l’une d’elles, alors je vous invite à approfondir l’autre et à essayer de la mettre en place. Votre équipe, votre produit et vos clients y gagneront.

---

👀 Découvrez nos « 5 conseils pour appliquer les méthodes agiles dans les grands groupes« 

👀 Découvrez également notre article  » Agile vs cycle en V : le combat du pilotage de projet »