UPDATE 03/09/2012 : Ce billet de blog a été retravaillé (et sans doute amélioré) pour être publié en tant qu’article au JDN ; clickez ici.
Vi vi vi vi vi, le cycle en “V”… Tout à fait
Le principe du cycle en V est le suivant : un certain nombre d’étapes sont nécessaires pour réaliser un projet informatique. Une partie de ces étapes sont préalables au développement, tandis que d’autres suivent pour garantir la qualité de ces développements. Chacune de ces étapes donne lieu à la production de documentation et, de chaque côté du cycle (descendant et montant), cette documentation fait le lien entre les étapes pré et post codage.
La plupart du temps, deux principaux reproches sont formulés à l’encontre de cette méthode.
Premièrement, le temps passé à rédiger la documentation. Et cette rédaction nécessite l’intervention de nombreuses parties à des moments clefs mais pas à chaque étape du projet. Deuxièmement, et ceci découle de la remarque précédente, les documents produits sont réputés immuables pendant toute la durée du projet et ceci induit un effet tunnel. Or, cet effet tunnel est préjudiciable au projet lui-même. En effet, selon la durée du projet, il est plus que probable qu’entre la rédaction du sacro-saint Cahier des Charges et la livraison, quelques changements interviennent dans l’environnement cible de l’application. Ou que de nouvelles contraintes techniques (internes ou externes) apparaissent, contraignant l’équipe de développement à revenir sur les fonctions escomptées.
L’utilisation de documentation étant intensive, le processus de développement en devient assez rigide. Les membres des différentes équipes auront tendance à s’appuyer exclusivement sur les spécifications publiées, comme d’un rempart à la critique. Cette pratique les amène à se “désimpliquer” du but ultime du projet : répondre aux besoins des utilisateurs finaux, y compris en termes de performances et, surtout, d’évolutivité.
Et l’Agilité, c’est quand on fait des acrobaties pour livrer dans les délais ?
Par ailleurs, on s’est aperçu depuis la mise en place du cycle en V que les développeurs sont faillibles. On voulait industrialiser la production de logiciels et, pour cela, créer des chaînes de montage (regardez bien à nouveau le schéma du cycle en V ci-dessus et pensez bien fort aux usines Ford, au Taylorisme). Malheureusement, l’humain est inconstant. Et les groupes d’humains le sont encore plus. Pire, l’humain exige d’être motivé pour faire son travail.
Quelques acteurs de l’industrie logicielle ont donc décidé de se réunir pour réfléchir à leurs conditions de travail. Cette réflexion a donné naissance à un Manifeste Agile qui a permis, avec les outils de l’eXtrem Programming (XP) d’imaginer une autre manière de travailler, en s’appuyant sur les personnes plutôt que sur la documentation, les contrats et la planification à long terme.
Au cœur de ces concepts se trouvent le Cycle Itératif et Incrémental ainsi que l’Intégration Continue. Rapidement résumé, on s’appuie sur des livraisons fréquentes, la possibilité de changer les priorités, le partage de la vision du projet (objectifs et avancement) et la collaboration entre les parties prenantes.
Pour ce faire, la méthode agile la plus populaire (?) définit plusieurs rôles au sein de l’équipe projet :
- Le Product Owner (PO) est le garant de la vision du projet, il administre la liste des fonctions à délivrer (product backlog), sous une forme synthétique que l’on appelle des Stories
- Le Scrum Master (SM) est l’animateur de l’équipe qui s’assure de la distribution des tâches et du rythme de développement, par exemple en fournissant un support d’architecture et de programmation
- Le Developer est réputé polyvalent ; certains développeurs expérimentés sont appelés des Champions (c’est toujours bon pour l’égo)
- Le StackHolder est un acteur externe au développement mais qui suit l’avancement du projet ; il peut s’agir d’utilisateurs finaux, ou de responsables hiérarchiques par exemple
Les méthodes Agiles comme Scrum (donc) organisent le développement en suivant des cérémonies et des bonnes pratiques (pair programming, TDD, etc.).
Les cérémonies journalières (la plupart du temps matinales), les scrums, assurent que l’information est bien partagée entre les membres de l’équipe et elles détectent les problèmes éventuels.
Une cérémonie de lancement d’un Sprint (quelques semaines de développement) permet d’évaluer la charge de travail nécessaire pour réaliser les fonctions jugées prioritaires et préciser la vision du Product Owner à l’instant présent. En fonction de l’estimation donnée par les développeurs eux-mêmes, le PO peut décider de revoir l’ordre de ses priorités.
A la fin d’un Sprint, l’équipe organise une Sprint Review (démonstration) des fonctions implémentées à l’intention de toutes les parties prenantes ; ceci afin de valider la direction prise par le projet.
Enfin, des Rétrospectives permettent de faire un point régulier sur les problèmes rencontrés, qu’ils soient techniques ou méthodologiques et d’ajuster le fonctionnement de l’équipe pour en améliorer le rendement.
C’est grâce aux Sprints (courts et intenses) que l’adaptation au changement est rendu possible dans les méthodes agiles. On supprime ainsi au maximum l’effet tunnel décrié dans le Cycle en V et l’on minimise le coût éventuel d’un retour en arrière. La documentation pléthorique et contractuelle est remplacée par le dialogue et la négociation. Les développeurs sont amenés à confronter leur travail à une vision élevée de l’application et à la réutilisation de leur propre code au sein de l’équipe.
Ok, ok, ok… Comment se retrouve-t-on “coincé au milieu du gué”, alors ?
Je vous jure que c’est vrai, il y a des équipes de recette qui n’utilisent pas le Cahier des Charges pour effectuer leurs tests à la fin du cycle en V. On a, par exemple, convié l’équipe de recette à participer aux réunions de préparation et elle se base sur son propre recueil de besoins pour effectuer sa mission, se réservant le droit d’interpréter ce que devrait être le produit fini. Cela se termine en général en pugilat, voire en guerre de tranchées, entre des équipes de développement et de test devenues ennemies farouches communicant par l’intermédiaire de billets plus ou moins secs dans le bug tracker.
Et il y a aussi des équipes “Agiles” qui n’ont pas de Product Owner. Elles fixent elles-mêmes les priorités, voire alimentent le backlog de produit en fonction des demandes faites sur un coin de table par un StackHolder (le plus souvent faisant figure d’autorité… hiérarchique) qui passe de temps en temps dans l’open space pour “voir comment ça avance”, en pleine journée. Il y a également des équipes qui sont débordées par une foule de petites tâches “urgentes et obligatoires” qui n’ont pas été intégrées dans le backlog de produit parce qu’elles sont transversales ou correspondent à des bugs détectés au fil de l’eau.
Mais je m’intéresse particulièrement aux cas où la MOA est en mode Cycle en V tandis que la MOE cherche à devenir Agile. Là, c’est le pompon ! En fait, cette technique porte un nom : c’est La RACHE. Au-dessus, on a des formalistes, qui pondent des rapports comme ils respirent et ne comprennent pas pourquoi les délais et la qualité (au choix) ne sont pas au rendez-vous en sortie de cycle. Tandis qu’en-dessous, des soutiers codent dans tous les sens, copient-collent outrageusement et prient en secret pour changer de département avant la mise en production… Imaginez Josef Mengele qui ferait de la chirurgie esthétique ; et figurez-vous que ça fonctionne (parfois, et compte tenu du turnover dans les prestataires – Oups) !
Comment en arrive-t-on là ? Mon impression personnelle est que le reporting a quelque chose de rassurant pour les managers et que par ailleurs pas mal de développeurs voient dans les méthodes Agiles une occasion de retirer leurs chaînes. Un jour, un développeur junior a voulu savoir pourquoi je lui demandais de saisir lui-même sont RAF (reste à faire) dans les tâches Scrum (découpage d’une Story en actions atomiques) alors que je pouvais tout aussi bien le faire moi (SM) pendant le Scrum. Je pense que la première chose à faire pour bâtir une équipe Agile est d’insister sur l’implication personnelle de CHACUN des acteurs ; d’amener tous les membres de l’équipe (PO, SM, Developer) à se demander en permanence où il en est (dans son rôle, au sein de l’équipe) et où il souhaite aller (que faire pour atteindre l’objectif et améliorer l’ensemble). A condition BIEN SUR de se donner les moyens de FAVORISER cette implication…
Il est très difficile de sortir de ces situations. Probablement plus difficile que d’accompagner le changement d’un point “V” installé dans les mœurs à un point “A” souhaitable. Il faut réunir tout ce beau monde, déconstruire la situation et parvenir à démontrer son improductivité (à la situation) voire sa nocivité. Chacun vous dira que tout fonctionne mal, mais que de toute façon on ne peut pas changer “ça”. Il faut pourtant parvenir à changer chaque bastion en nid d’évangélistes ; parce qu’il devient manifeste que pour chaque nouvelle fonctionnalité, les délais et les charges enflent constamment. Parce que, tout simplement, les couches de sédiments se sont accumulées malgré les superbes spécifications et rapports de fin de projet. Chaque nouveau projet met en danger l’existant, faute de tests de non régression ou d’une capacité infinie de recettage.
La grande majorité (toutes ?) des entreprises aujourd’hui est soucieuse de réduire ses coûts. Et la plupart du temps on ne voit pas pourquoi investir dans la réduction de la dette technique alors que tant de projets sont dans les cartons… Des dossiers considérés comme “urgentissimes”, par exemple adapter les clients SOA au rythme d’évolution effréné des entreprise partenaires.
Non, non, décidément c’est trop compliqué, trop cher. On n’y arrivera pas. Ce n’est pas un VRAI problème…
Conclusions personnelles
Premièrement : Ce n’est pas parce que les solutions ne sont pas évidentes qu’il faut s’interdire de faire les bons diagnostics. Et chacun devrait s’attacher à les discuter, à les rabâcher sur tous les tons.
Deuxièmement : Le changement est la plus difficile, voire la plus ingrate, des tâches. Cela peut prendre du temps, échouer, provoquer des antagonismes. Mais il est à la fois l’essence et l’objectif des groupes humains et des entreprises.
Troisièmement : Bien sûr les clients, les utilisateurs, sont demandeurs d’une meilleure qualité, d’une meilleure écoute. Le cycle court itératif apporte lui-même la démonstration de son efficacité dans sa capacité à l’amélioration et à la transparence.
J’espère que ces quelques arguments vous aideront et vous donneront de l’énergie pour braver les sinistroses rencontrées. L’Agilité, c’est quand la voix de chacun peut se faire entendre.
