19 Déc 2014

Pourquoi développer en Agile est-il si différent ?

Avant de répondre à cette question,  il est important de rappeler quelques principes[1] émergeant des 4 valeurs du manifeste agile de développement logiciel, en l’occurrence :

  • Notre priorité première est de satisfaire le client en livrant au plus tôt et de manière constante un logiciel de qualité.
  • Tout changement, même tardif, des exigences pendant le développement est bienvenu.
  • Respecter un cycle de développement cours et une cadence de livraison régulière.
  • Une attention particulière à l’excellence technique, via l’amélioration continue des designs et des architectures.
  • Un logiciel qui fonctionne et qui répond au besoin, est le meilleur indicateur de progrès.
  • Les meilleures architectures et les meilleures conceptions sont  issues de l’auto-organisation de l’équipe.
  • La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est essentielle.

Bien évidemment, il ne s’agit pas de suivre à la lettre ces principes. Toutefois, il est important de comprendre les vraies valeurs de ces méthodes de développement dites méthodes agiles.

« Des méthodes, il y en a des millions, et même d’avantage, mais il n’existe que quelques principes. L’individu qui comprend ces principes peut choisir avec succès ses propres méthodes. Mais celui qui essaie des méthodes en ignorant les principes va droit dans le mur »[2].

Quand j’ai commencé des projets en Scrum chez AXA, je ne me suis jamais demandé si je devais revoir ma façon de développer. Il était évident pour moi que la manière de développer doit être la même, peu importe la méthodologie suivie. Certes, il y a des « best practices » à suivre, cependant, ces normes sont les mêmes pour tous les projets. Il se trouve que j’avais tort…

Le développement dans les projets agiles exige une autre façon de concevoir les logiciels.

Il y a quelques mois j’ai découvert un livre très passionnant de Robert Martin[3] – surnommé « Uncle Bob » – où il décrit les challenges du développement et les principes à suivre dans un contexte agile.

1-      La réponse au changement

Il faut savoir que, dans un contexte projet agile, le changement de besoin client fait partie des mœurs et que l’équipe de développement doit s’attendre à tout changement à n’importe quel moment du projet[4].

Cependant, la question qui se pose, c’est comment procéder dans nos méthodes de développement pour être en mesure de répondre à ces changements ?

La première règle, c’est de se focaliser sur le développement des fonctionnalités qui ont de la valeur pour les utilisateurs. Tout ce qui n’est pas indispensable pour l’utilisateur est non prioritaire dans nos développements. Il ne faut surtout pas essayer de résoudre des problèmes techniques ou fonctionnels, qui n’intéressent pas l’utilisateur. En effet, nous avons tendance à chercher des solutions pour des problèmes qui ne se posent pas et qui ne se poseront probablement jamais. Peter Drucker dit ainsi : « il n’existe certainement rien de plus inutile que de faire à la perfection des choses qui ne devraient pas être faites du tout ».  C’est également l’idée du principe YAGNI[5]. L’exemple le plus fréquent dans nos développements, c’est les solutions génériques pour des problèmes bien spécifiques sans intérêts.

La deuxième règle, c’est d’être en mesure de résoudre un problème une et une seule fois. Généralement, ces problèmes se posent suite à un changement de besoin client. De ce fait, il faut prévoir une solution générique, car il faut s’attendre à d’autres changements. Par conséquence, votre code ne doit pas être rigide, bien au contraire, il doit être facilement modifiable avec le moins d’impact possible. Un nouveau changement ne doit pas modifier catégoriquement votre code.  En outre, surtout pas de copier/coller dans le code.

Le développement en agile demande une certaine maîtrise technique, notamment les designs patterns et les principes SOLID[6] de développement. Bien évidemment, un changement de besoin peut impacter la date de livraison et peut générer un coût supplémentaire qui n’était pas prévu au démarrage du projet. Ce que Donald Reinertsen le considère comme le coût de la variabilité.

2-      La qualité

La qualité est l’un des facteurs clés de succès les plus importants dans un projet agile. En effet, outre les exemples de qualité de code dans la section précédente, il faut savoir que notre façon de développer doit être agile. En d’autres termes, notre code doit nous permettre d’être réactifs. Bien évidemment, une meilleure qualité de développement, nous fait gagner énormément de temps.

« L’excès d’erreurs/anomalies est le principal gaspillage constaté dans le développement logiciel. »[7]

C’est pour cela,  que nous avons défini plusieurs actions à suivre, notamment :

–        Les tests unitaires : c’est indispensable, car cela nous permet de non seulement vérifier que le code répond bien au besoin définit. Autrement dit, une détection rapide des bugs, mais aussi d’assurer en cas de modification qu’il n’y a pas de régressions. Dans ce cadre, une démarche très intéressante que nous sommes en train de suivre dans nos développements c’est le TDD (Test Driven Development).

–        Les revues de codes : cela permet à l’équipe de partager le code et de vérifier les éventuelles améliorations qu’il faut appliquer. Les revues de codes, permettent aussi d’améliorer le niveau technique de l’ensemble de l’équipe.

–        Le « refactoring » continu du code : Dans un projet agile, il est essentiel de chercher toujours à garder le code propre et simple. De ce fait, le « refactoring » du code n’est plus un choix, c’est une obligation.

En plus de la qualité de code,  l’avantage de travailler dans un projet agile, c’est qu’avec des livraisons rapides et continues, sur des courtes durées, nous assurons un retour rapide des utilisateurs. Ainsi, nous pourrons valider ce qui a été produit, ou bien, s’adapter aux éventuelles demandes de changement.

Une étude du MIT a été publiée en 2001 sur la production logiciel[8] qui montre une forte corrélation entre le nombre de livraison au cours d’un projet et la qualité du produit à la fin, moins il y a des fonctionnalités livrées au début, plus la qualité est meilleure à la fin.

3-      Le besoin client

Si je reviens au premier principe – « Notre priorité première est de satisfaire le client en livrant au plus tôt et de manière constante un logiciel de qualité » -, je trouve que nous sommes souvent disposés à oublier la vraie valeur d’un logiciel. Vous pouvez développer une application avec la meilleure architecture technique, les derniers outils et frameworks, votre couverture de code est à 100%, etc. Ceci, n’a aucun intérêt, si votre logiciel n’est pas utilisé ou ne répond pas à un besoin client. La valeur d’une application se trouve dans son taux d’utilisation et sa capacité à répondre aux besoins clients.

Cependant, comment pouvons-nous être sûrs que ce que nous produisons correspond vraiment au besoin client ?

Steve Jobs disait : « Ce n’est pas aux clients de savoir ce qu’ils veulent ». C’est un peu contre intuitif mais ce n’est pas faux. En réalité, les utilisateurs ont tendance à exprimer leurs problèmes avec des solutions qu’ils imaginent. Tandis que, c’est à nous, développeurs, de leur proposer la solution.

Généralement, en cherchant à satisfaire le client, on se trouve guidé par la solution qu’il nous propose et parfois celle-ci ne répond pas vraiment à son réel besoin. Il faut toujours essayer de comprendre le vrai besoin, de faire la distinction entre la solution et le problème afin de bien comprendre ce qu’on nous demande de faire et pourquoi on nous le demande.

En conclusion, le développement agile c’est tout un ensemble de démarches et d’actions à suivre, dictées par des principes centrés sur la production de logiciels de qualité, qui répondent aux besoins client dans un cycle de développement court et avec une cadence de livraison régulière.

 


[1] Cette liste n’est pas exhaustive, il y a 12 principes sous-jacents
[2] Ralph Waldo Emerson, Philosophe et poète américain
[3] Agile Principles, Patterns, and Practices in C#.Robert C.Martin et Micah Martin
[4] Manifeste agile : L’adaptation au changement plus que le suivi d’un plan.
[5] YAGNI: You aren’t gonna need it. Il s’agit d’un principe de la méthode  extreme programming (XP) qui invite les développeurs à ne pas implémenter une fonctionnalité tant qu’ils n’ont pas besoin. Il faut choisir la solution la plus simple et qui satisfait le besoin de l’utilisateur.
[6] SOLID : Single responsibility principle, Open/closed principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle
[7] David J.Anderson, Kanban, Enclenchez le Moteur d’Amélioration Continue de votre IT
[8] Product-Development Practices That Work. MIT Sloan Management Review winter 2001.

Share