Durée des cycles agiles

La durée des cycles est une question qui revient fréquemment quand on parle de mettre en place des méthodes agiles dans une entreprise.
Évidement, il est impossible de donner une durée absolue ; comme pour le reste, il faut l’adapter à l’entreprise, les personnes, les besoins… La plupart du temps, plusieurs visions s’affrontent :

• Les développeurs qui ont déjà travaillé “en agile” ou qui ont lu des articles sur le sujet, et pour qui un sprint fait 2 semaines. C’est comme ça.
• Les “décideurs”, pour qui il est plus efficace de faire des cycles longs − entre 1 et 3 mois de développement − car cela maximise la durée de développement par rapport au reste.
• Les clients (internes ou externes), qui oscillent entre un désir brûlant de voir l’avancement de leurs projets et de demander des modifications en temps réel d’un côté, et de l’autre un dégoût prononcé pour les tests et peu de temps à consacrer pour faire des remontées structurées.
• Les personnes qui participent à la conception et dont l’avis peut varier énormément suivant qu’elles aient été formées à l’agilité ou non. Quand elles ne le sont pas, elles ont tendance à imaginer le produit parfait, sans vouloir le découper de manière incrémentale ; auquel cas, elles préfèrent évidemment des longs cycles. Celles qui ont été formées à l’agilité connaissent les avantages de réfléchir de manière plus itérative et n’hésitent pas à partir moins loin dans leurs conceptions.

La conception

Il est assez intéressant de voir que la plupart des informations qu’on peut trouver sur le sujet − que ce soit sur Internet ou dans les formations agiles − se concentrent uniquement sur le développement. Même en lisant des choses sur les principes agiles appliqués à la spécification (user stories, principalement), tout le monde semble penser que la création de ces spécifications est une chose hyper-facile et pour laquelle il n’y a pas vraiment besoin d’établir un process, et qu’en conséquence on peut partir du principe que tout commence une fois que l’équipe de développement reçoit les user stories (ou qu’elle n’a qu’à piocher dans un backlog bien rempli).

Mais c’est une erreur complète.

Les phases de conception sont au moins aussi importantes que celles de développement, de test et de déploiement.
Pour être menées correctement, elles doivent être faites de la bonne manière, par les bonnes personnes, avec des processus bordés.

J’ai un exemple en tête. Une entreprise qui est passée à une organisation agile (du Scrum «by the book») avec des cycles de 2 semaines, sans se préoccuper vraiment de  la manière dont les spécifications étaient réalisées. Leur idée a été de mener en parallèle les spécifications et le développement (jusque-là rien d’incohérent), en misant sur le fait que deux semaines de spécification étaient suffisante pour alimenter deux semaines de développement. Ainsi, un “Sprint Zéro” devait alimenter le premier sprint de développement qui commençait deux semaines plus tard.
Si certains développements peuvent être spécifiés très rapidement, d’autres demandent beaucoup plus de temps. Spécification et développement sont sur des temporalités très différentes. Ce qui devait arriver arriva : Le premier sprint de développement n’a pas pu être complètement alimenté par le sprint zéro. Et surtout, il ne suffit pas de dire à des gens «Vous avez deux semaines pour spécifier, démerdez-vous» pour qu’elles réussisse à faire leur boulot ; il faut un peu de process si on ne veut pas partir dans tous les sens (et donc arriver nulle part).

Les cycles et ce qu’ils impliquent

Un cycle représente une unité de temps au bout de laquelle on va (tenter de) créer quelque chose dont le résultat sera montrable.

Se focaliser uniquement sur le travail de développement est une erreur car cela peut entraîner de graves oublis dans les phases amont (spécification) aussi bien que dans les phases situées en aval (test, déploiement).
Il est de la responsabilité de l’ensemble de l’équipe de fournir du logiciel utile et de qualité. “Utile” implique que le client s’en servent, et donc que les spécifications soient menées correctement (en prenant en compte les besoins et en sachant changer de direction quand il le faut) ; “de qualité” veut dire que l’on se donne les moyens pour réduire les bugs, augmenter l’évolutivité, réduire les coûts inutiles, documenter ce qui doit l’être, etc.

J’ai expliqué précédemment pourquoi je pense que la manière de produire les spécifications doit être prise en considération dans la mise en place d’un cycle agile. Similairement, on ne se pose plus trop la question sur le fait de tester le logiciel avant de le déployer en production.

Avoir un cycle implique donc que ce qui en sort est testé et validé. Et il faut voir que cela a un coût, mais qu’il est difficile de mettre le curseur au bon endroit. En effet, une phase de test & déploiement a une durée incompressible ; une telle phase ne sera pas deux fois plus longue à la fin d’un cycle de 4 semaines qu’après seulement 2 semaines de développement. Par contre, attendre 3 mois avant de vouloir valider quoi que ce soit paraît suicidaire, car le risque de rencontrer des problèmes bloquants (ou juste très importants) augmente avec le temps qui passe.

Le rôle des développeurs

Si je mets en avant les lacunes des organisations qui se focalisent sur le développement au détriment de la vue d’ensemble (depuis les spécifications jusqu’au déploiement), c’est parce que tout problème a tendance à retomber sur l’équipe de développement.

Une fonctionnalité a été mal spécifiée ? Pas de problème, la demande sera précisée en cours de développement ; avec plusieurs changements en cours de route si nécessaire. C’est le meilleur moyen pour cumuler les retards et générer du code spaghetti.
Un développement n’a pas été testé correctement ? Mettons-le quand même en production. Si un bug est trouvé par la suite, on se dépêchera de faire un correctif. C’est parfait pour avoir des problèmes énormes en production (pouvant impacter le chiffre d’affaire ou la réputation à long terme, par exemple), et à faire des correctifs rapides et eux-mêmes buggués, conduisant au sur-accident.

Non seulement la qualité globale du travail de l’équipe diminue, mais en plus cela fait peser une pression inutilement forte sur les développeurs, juste parce que d’autres personnes n’ont pas fait leur travail ou l’ont mal fait.

Le rôle des développeurs sur les projets est triple :

• Accompagner les phases de conception, pour proposer des solutions techniques aux problèmes fonctionnels.
• Réaliser le code qui implémente la demande fonctionnelle, en cherchant à trouver la bonne mesure entre le temps passé et la valeur intrinsèque de la fonctionnalité, en suivant les bonnes pratiques de l’entreprise.
• S’assurer que son code fonctionne, que ce soit d’un point de vue technique (adéquation avec le reste de l’architecture, performance, etc.) ou fonctionnel.

À cela s’ajoute des responsabilités parallèles en fonction des situations (propositions techniques, organisation de conférences ou de hackathons, ou autre).
Mais dans tous les cas, les développeurs ne se destinent pas à prendre sur eux les lacunes des autres…

Les cycles de deux semaines

Lorsque quelqu’un me dit qu’il travaille sur des cycles de 2 semaines, je lui réponds «Non, ça c’est la durée de votre sprint de développement». Je ne remets pas en question ce choix, deux semaines étant souvent une durée ni trop courte ni trop longue pour assurer des développements.
Mais que ce passe-t-il pour ceux qui essayent vraiment de faire tenir leur cycle en deux semaines ? Pour commencer, les spécifications ne sont pas prises en considération ; c’est une erreur, je ne vais pas revenir là-dessus. Ensuite, on peut imaginer que le cycle se déroule de la manière suivante :

• En début de cycle, une demi-journée est consacrée aux rituels de début de cycle (étude des user stories, planning poker).
• En fin de cycle :
  • Une demi-journée est utilisée pour faire la démo des nouveaux développements aux clients.
  • Une demi-journée est consacrée aux tests fonctionnels (automatisés et/ou par les clients). Le déploiement sur un environnement de test (préprod, qualification, appelez-le comme vous voulez) conditionne cette demi-journée, qui peut être réduite si tout ne s’est pas bien passé…
  • Une demi-journée ou une journée est consacrée aux résolutions de bugs mineurs, en fonction des retours de tests. Les bugs majeurs font que le développement est sorti de la release et sera traité sur un autre cycle.
  • Une demi-journée est consacrée au déploiement en production.
  • Une demi-journée est réservée pour ce qui permet de clore le cycle : la rétrospective ou le niko-niko, l’analyse de ce qui a été écarté durant le cycle, etc.

Au final, il reste donc au mieux 7 jours de développement (ce qui n’est pas si mal en fait). Mais surtout, ce genre de cycle a deux impacts qui sont souvent oubliés un peu facilement :

• Le moindre grain de sable peut tout enrayer. Une mise en préprod un peu longue, des tests qui démarrent un peu tard ou qui durent plus longtemps que prévu, une longue liste de bugs à corriger absolument… et c’est l’ensemble du cycle qui risque de déborder. Avec pour résultat un « inter-cycle » qui ne servira qu’à faire les tests, les débogages ou le déploiement qu’on n’avait pas eu le temps de faire.
• On fait peser une contrainte forte sur l’ensemble des partie-prenantes. Les clients ont une fenêtre de tir extrêmement réduite pour tester les développements qui les concernent. Les développeurs n’ont pas de temps de répit qu’ils peuvent consacrer à des refactorings.

Le sentiment d’urgence continuelle créé par la combinaison de ces deux points peut se révéler très anxiogène à la longue. Comme le dit Jason Fried au sujet des cycles utilisés chez Basecamp (j’y reviens plus bas) :

These are not sprints. I despise the word sprints. Sprints and work don’t go together. This isn’t about running all out as fast as you can, it’s about working calmly, at a nice pace, and making smart calls along the way. No brute force here, no catching our collective breath at the end.

Automatisation et déploiement continu

Sur un cycle de 2 semaines, on cherche évidemment à automatiser le plus possible les tests, pour minimiser le temps passé à tester et pour réduire les impacts possibles.

Mais il n’en reste pas moins que tout n’est pas testable automatiquement. Que ce soit dans le design (pour un site web) ou pour des questions d’infra-structure (une plate-forme de production peut légitimement avoir des différences par rapport à une plate-forme de test), il faut souvent valider à la main certains point-clés.

Le déploiement continu est quelque chose qui peut être très efficace lorsqu’il est correctement conduit. En mettant en production les développements au fur et à mesure qu’ils sont prêts, on augmente la réactivité de l’entreprise.
Sauf que lorsque cela est mal mené, on peut vite tomber dans un travers assez classique : On se dépêche de mettre en production des développements qui ne sont pas suffisamment testés (que ce soit de manière automatisée ou non), parce qu’il sera toujours facile et rapide de mettre en ligne un correctif s’il le faut. Sauf qu’en procédant de la sorte, on fait encore peser la responsabilité sur les seules épaules du développeur (s’il y a un bug, c’est de sa faute et non celle de celui qui a mal testé), et on risque de fonctionner à coups de correctifs qui s’empilent en faisant perdre toute vison d’ensemble.

Dans une entreprise que j’ai visitée il y a quelques années, un graphique était affiché sur un écran dans l’open-space. Une courbe montrait l’évolution du chiffre d’affaire, et des barres verticales symbolisaient les mises en ligne ; ainsi, lorsqu’un bug avait pour effet de faire chuter le chiffre d’affaire, il était facile d’identifier le développement responsable.
Sauf que je considère qu’on doit tout faire pour ne pas risquer d’avoir un site tellement bogué qu’il ne va générer aucun chiffre d’affaire, ne serait-ce que 5 minutes. Que ce soit pour le manque à gagner financier ou la perte d’image qui peut se révéler catastrophique à moyen terme, cela me semble trop grave. Surtout lorsque l’alternative est de différer le déploiement de seulement 2 semaines… De plus, on peut imaginer que des développements bogués passent à travers les mailles du filet, simplement parce qu’ils impliquent une faible baisse du chiffre d’affaire (mais une baisse quand même).

Pour que ça fonctionne sans accroc, il faut y mettre des moyens humains et techniques assez importants.

Les cycles de 6 semaines

Les gars de Basecamp ont mis en place des cycles de 6 semaines. Ils l’ont annoncé sur leur blog, puis sont revenu dessus pour expliquer comment cela se passait.

Je vous invite à lire les deux articles, qui sont assez longs.
En résumé, ils constituent des équipe de 2 ou 3 personnes (un ou deux développeurs et un designer), en fonction de ce sur quoi les gens ont envie de travailler pendant les 6 prochaines semaines. Chaque équipe réalise un “gros projet” (qui occupe tout le cycle) ou plusieurs “petits projets”.

Ils n’expliquent malheureusement pas clairement comment le travail se découpe au long de ces cycles. On apprend néanmoins qu’ils ont une équipe QA (Assurance qualité) de 2 personnes, qui est mise à contribution par les autres équipes pour s’assurer de la qualité des projets avant leurs mises en ligne.
(quand je parlais de moyens humains, on peut en voir un bon exemple ; ils ont 2 personnes dédiées à la qualité, pour 4 développeurs et 4 designers)

Mon expérience

J’ai déjà parlé sur ce blog (ici et là) de la manière dont j’avais mis en place les cycles chez Fine Media, continuellement améliorée pendant 6 ans.

Pour commencer, les projets étaient pré-dimensionnés suivant la technique des tailles de t-shirt (S, M, L, XL) − technique aussi bien utilisée dans les organisations agiles que dans des grosses entreprises. La durée de conception dépendait de cette estimation, et la partie plus classique «développement + test + déploiement» durait toujours un mois.

Si on prend l’exemple d’un projet Medium (environ 3 jours de développement), on avait une chronologie comme suit à partir de la validation de l’expression de besoin écrite par le client interne :

• 1 semaine pour réaliser les wireframes
• 2 semaines pour faire les maquettes
• 1 semaine pour écrire la spécification fonctionnelle
• 1 semaine pour écrire la spécification technique
• 2 semaines [DEVeloppement] pour réaliser le développement
• 1 semaine [STABilisation] pour tester le projet (par le développeur et par le client)
• 1 semaine [Mise En Prod] pour valider en préprod puis mettre en prod

De manière un peu plus graphique, ça donne ça :

Vous pouvez imaginer que les cycles se chevauchent. Durant la semaine de MEP, la priorité des développeurs est de résoudre les bugs qui seraient trouvés en préprod (voire en prod) ; comme cela ne les occupe pas à plein temps, ils font les analyses techniques nécessaires pour les projets qu’ils auront à développer le mois suivant.

La semaine dévolue aux tests permet aux clients de s’organiser pour réaliser les validations nécessaires sans être dans la précipitation. Pour l’équipe technique, ce temps était mis à contribution pour faire des débogages mais aussi pour réaliser des refactoring mineurs ou lancer des projets purement techniques qui sont ajoutés à la liste des projets par la suite.

À titre de comparaison, voici le cycle complet pour un projet Large (de 4 à 10 jours de développement). Vous pouvez voir que les durée de conception sont adaptées en conséquence :

Toutes ces durées sont évidemment d’ordre indicatif, certains projets ayant besoin de plus de temps pour certaines étapes, alors que d’autres projets pourront carrément se passer de certaines autres (par exemple, pas de maquettes sur des projets de back-office). Mais elles sont cohérentes face à ce qui avait pu être constaté. On peut trouver certaines durées très longues, mais elles sont aussi à mettre en perspective avec le fait que les mêmes personnes s’occupaient de plusieurs projets à la fois.

Ce workflow permettait de s’assurer qu’on était bien dans les clous, et qu’on n’essayait pas de faire tenir à tout prix un projet dans un cycle alors que les phases de conception étaient à la ramasse.
Et cela permet de voir que même avec des mises en production tous les mois, la vraie durée des cycles de développement est bien plus longue.

Et vous ?

Ça m’intéresserait de savoir comment les choses sont organisées dans votre équipe/entreprise. Est-ce que les phases de conception sont gérées ? Êtes-vous sur des cycles qui se résument à des sprints de 1, 2 ou 3 semaines ? Utilisez-vous des cycles plus longs, et si oui comment sont-ils structurés ?