Software Craftsmanship et Agilité

Me présentant comme artisan logiciel, je suis confronté à des réactions souvent étonnantes. Ainsi, lorsque je parle du temps passé à améliorer la qualité du code, j’entends parfois : « Ah, mais alors, tu refuses l’agilité et les deadlines ? »

On voit ainsi que les perceptions des méthodes agiles peuvent être très erronées. Pour certains, pas encore sortis des cycles en cascade et en V hérités de l’industrie du siècle dernier, l’agilité est souvent confondue avec la gestion temporelle du projet.

J’aimerais montrer ici que les méthodes agiles ont une autre finalité qu’être des moyens de « mise sous pression » des équipes. Au contraire. Ceci étant posé, nous verrons alors en quoi agilité et artisanat logiciel se complètent avec pertinence.

Ce que ne sont pas les méthodes agiles

Si l’agilité sert à mettre la pression à une équipe, c’est qu’elle a été dévoyée, par ignorance ou intentionnellement.

Les méthodes agiles permettent de gérer des projets d’une manière pragmatique, impliquant plus le donneur d’ordres et permettant une plus grande réactivité et une meilleure prise en compte de ses demandes. Elles reposent sur un cycle de développement itératif, incrémental et adaptatif.

Elles prônent quatre valeurs fondamentales :

  • Les individus et interactions comptent davantage que les processus et outils
  • Les Fonctionnalités comptent plus qu'une documentation exhaustive
  • La Collaboration avec le demandeur est plus importante que la contractualisation
  • Il vaut mieux accepter le changement plutôt que de suivre un plan

La confusion avec la mise sous pression vient du fait que, dans un monde où la notion « d’objectif », est encore trop et mal présente, certains vivent mal de ne pas réussir à réaliser l’intégralité des fonctionnalités prévues sur un Sprint Scrum par exemple.

Pourtant un Sprint n’est pas un objectif. C’est une ambition, et surtout la mesure d’une estimation de travail collectif. Ne pas tout boucler dans un Sprint n’est pas un échec, cela signifie simplement que l’on a sous-estimé le travail. On sera alors meilleur pour le suivant. En attendant, on livre toujours au PO une version enrichie.

Tout au plus, Scrum, Kanban ou Lean peuvent donner un rythme à un projet, mais ne sont en aucun cas une garantie de tenue d’une date de livraison, puisque dépendantes aux changements par définition introduits en permanence.

Elles permettent au contraire, à un développeur qui estime qu’il lui faut plus de temps pour réaliser une fonctionnalité, d’exposer son point de vue, d’échanger et d’expliquer à l’équipe et au demandeur, afin d’obtenir les moyens nécessaires.

Ne voyons donc plus un cycle agile comme l’impératif de réaliser un objectif, ni la mise en flux de l’équipe comme une mise sous pression. Travailler agile signifie travailler en rythme et dans la collaboration, mais en aucun cas travailler vite et mal. N’oublions pas que le mauvais travail perdure très longtemps après que la rapidité ait été oubliée...

Les lacunes de l'agilité

Cependant, si les méthodes agiles donnent un cadre qui permet des apports essentiels, elles ne garantissent pas la qualité du produit. Tout au plus le développement par les tests permet de conserver une cohérence, mais tant que ça passe, rien n’empêche de coder n’importe comment...

Des équipes, sentant ce besoin, ont commencé à introduire au sein de méthodes agiles, vers la fin des années 1990, des principes visant à produire un code de meilleure qualité, comme par exemple l’eXtreme Programming (XP).

Puis arriva la déferlante du Web 2.0, avec la grande époque des SSII, où le développement logiciel est devenu une industrie, dont les dérives de jeunesse ont perverti l’esprit même de l’agilité, comme vu ci-dessus, et où quantité s’est mise à primer sur qualité.

Il a fallu attendre 10 ans, jusqu’en 2009, pour que paraisse le « Manifeste pour l’Artisanat Logiciel », qui réaffirme qu’il ne suffit pas qu’un logiciel soit fonctionnel, il faut aussi qu’il soit bien conçu.

Le Software Craftsmanship en tant que nécessité à l’agilité

L’artisanat Logiciel consiste à remettre les pratiques non prises en compte par l’agilité au cœur de la production logicielle. Il promeut une culture d’amélioration et de transmission du savoir par la pratique, adossée à un ensemble de techniques et de retours d’expériences, dans le but de fournir un logiciel de qualité, affirmant que la « non-qualité » induit un coût stratégique et aussi financier.

Il s’agit fondamentalement d’un retour à l’XP de 1999, et surtout une reformulation des quatre valeurs de base de l’agilité :

  • Individus et interactions davantage que processus et outils : pour cela il est indispensable de créer une communauté professionnelle.
  • Fonctionnalités plutôt que documentation exhaustive : pour cela il faut que le logiciel soit bien conçu.
  • Collaboration avec le demandeur plutôt que contractualisation : pour cela il faut savoir créer des partenariats productifs.
  • Acceptation du changement plutôt que suivre un plan : cela nécessite un ajout constant de valeur.

Ainsi, on voit bien que l’artisanat logiciel n’est finalement qu’un produit et une extension des méthodes agiles : c’est en visant les valeurs agiles (à gauche) que l’on trouve que les valeurs de l’artisanat (à droite) sont indispensables.

Il s’ensuit que le Software Craftsmanship emprunte aux autres méthodes agiles et particulièrement à XP, au travers de :

  • La qualité : conception simple, DDD, OO, refactoring, TDD (XP)
  • L’humilité : remise en question et amélioration continue (rétrospectives)
  • Le partage : binômage, pair programming et propriété collective (XP)
  • Le pragmatisme : Je comprends les contraintes et je m’adapte (Scrum)
  • Le professionnalisme : Je traite mon client comme un partenaire (XP)

En conclusion

On voit donc bien que Artisanat Logiciel et Méthodes Agiles sont complémentaires et partagent la même philosophie. Le Software Craftsmanship vient juste améliorer les méthodes les plus répandues de l’agilité, les complétant pour le meilleur, en y ajoutant la dimension de qualité responsable.

Quant au débat sur la fameuse deadline, il est complètement indépendant de tout cela. Ni l’agilité, ni le Craftsmanship n’ont vocation à gérer ou accélérer la temporalité d’un projet. Cela reste du ressort de la gestion des ressources humaines.

Je pense cependant que si le code est de meilleure qualité, le produit sera lui aussi plus qualitatif. Maintenance et ajout de fonctionnalités seront grandement facilités. Je fais le pari que le temps investi à produire un code de qualité fera au final certainement gagner énormément de temps sur la livraison d’un produit fiable et évolutif, pour une meilleure satisfaction du client et de l’utilisateur.