J’ai donné aujourd’hui un « lightning talk » au Forum PHP, au sujet des cycles agiles d’un mois.
J’ai déjà parlé de ces cycles sur ce blog (ici et ici), comment je les ai mis en place dans plusieurs entreprises, et comment ils ont permis d’augmenter la productivité tout en améliorant la qualité.
Voici les slides de la présentation :
Et la vidéo :
Transcription de la vidéo :
Slide 1. Bonjour, je vais me présenter rapidement pour donner un peu de contexte. Je m’appelle Amaury.
Slide 2. J’ai été cofondateur et CTO d’Ooreka pendant 10 ans. J’ai fait partie des coordinateurs de l’AFUP Paris dans les années 2010. Je suis CTO d’Homunity. J’ai plusieurs projets open-source à mon actif. Et je tiens le blog De geek à directeur technique.
Slide 3. Qu’est-ce qu’on connait comme cycles agiles : habituellement on connaît bien les sprints d’une semaine, on les utilise souvent quand on fait du prototypage, la R&D, les premières phases d’existence d’une startup. Les sprints de deux semaines, c’est plus répandu, je vais revenir dessus. Les cycles de six semaines, vous connaissez peut-être la méthode Shape Up. Ou pas de cycle, quand on fait du kanban, du déploiement continu.
Slide 4. Donc le plus répandu, comme je disais, les cycles de deux semaines.
Slide 5. Sauf qu’un sprint, c’est beaucoup de choses à la fois.
Slide 6. Et chaque sprint a ses objectifs. Appelez ça comme vous voulez, des objectifs, des projets, des user stories, des tâches.
Slide 7. Mais en pratique, un sprint déborde toujours sur les sprints suivants. Vous faites votre développement, mais il reste un peu de validations à faire, et ça réduit la bande passante qu’on a sur le sprint d’après. Et même encore après, il reste un peu de déploiement à faire, et tout ça s’accumule et au fur et à mesure ça réduit la bande passante réelle qu’on a sur chaque sprint.
Slide 8. Il y a d’autres écueils, comme par exemple des spécifications qui arrivent en étant incomplètes ou au contraire qui nous sont complètement imposées. Une validation qui finit par reposer uniquement et intégralement sur l’équipe technique. Et enfin, un rythme qui épuise les équipes. Vous connaissez l’adage, en fait ce qu’on fait, nous, c’est pas des sprints, c’est un marathon.
Voilà. Tout ça, ce sont des soucis.
Slide 9. La solution ?
Slide 10. C’est de ralentir, pour faire plus et mieux.
Slide 11. On en arrive à des cycles d’un mois. Le but : améliorer la qualité, améliorer la productivité, améliorer le confort. C’est le fruit de 13 ans d’amélioration ; ce n’est pas très étonnant, on fait de l’agile depuis plus de 20 ans, du SCRUM depuis plus de 15 ans. Et ça a été créé en collaboration avec des gens du produit, du métier, du design.
Slide 12. Alors un cycle d’un mois, comment ça marche ? Pendant deux semaines, on développe. On ne fait que du développement. Ensuite, pendant une semaine, il y a de la validation métier. Donc on inclut les gens du métier dans les tests. Pendant ce temps-là, l’équipe de développement peut faire des refactorings. Quatrième semaine, on merge, on tague, on déploie en préprod, on valide, on déploie en prod. En parallèle de ça, les développeurs peuvent faire des spécifications techniques. Au minimum, réfléchir sur ce qu’ils vont développer le mois suivant. Et en amont, les équipes fonctionnelles, les product owners, l’équipe produit, peut préparer les spécifications fonctionnelles de ce qui va être développé le mois d’après.
Slide 13. Donc vous avez vos cycles qui s’enchaînent. Des fois, vous avez des spécifications fonctionnelles qui prennent un peu plus de temps que d’autres, mais c’est fine, pas de souci.
Slide 14. Tout ça est simple et très clair à comprendre pour tout le monde dans l’entreprise. Informaticiens, informaticiennes, on est formés à la gestion de projets, mais ce n’est pas le cas du reste de nos entreprises. Quand on dit à quelqu’un “Ton projet est pour novembre”, ils savent qu’on va faire la spécification ensemble, en octobre. On fait des équipes pluridisciplinaires, on met quelqu’un du métier, quelqu’un de la tech, quelqu’un du design, quelqu’un du produit, et on va faire la spec.
Cette personne, on lui dit “Tu vas tester pendant la troisième semaine de novembre”. Et ça passera en production fin novembre.
Voilà, pas de questions à se poser, tout le monde comprend.
Slide 15. La qualité : des projets mieux spécifiés, ça fait moins de mauvaises surprises. Et la validation par les gens du métier, c’est une réduction vraiment massive des bugs en production.
Slide 16. Ça fait un rythme plus durable. On a du temps pour les refactorings. Je pense qu’on est nombreux à se dire qu’on a besoin d’avoir du temps pour réduire la dette technique. Là, voilà, il y a du temps qui est là pour ça. La quatrième semaine dans le cycle, qui joue un rôle de “cool-down”, pour éviter l’épuisement des équipes (encore une fois, c’est pas des sprints, c’est un marathon). Et l’air de rien, on fait des rétrospectives qui sont plus riches et plus utiles.
Slide 17. Bon, il y a quand même quelques petites difficultés. La première c’est que ça nécessite l’implication de toutes les équipes. Si on en revient uniquement à se dire que les cycles de développement c’est que pour l’équipe de développement, ça marche pas. Mais c’est pareil pour toute forme de méthodologie agile. Et enfin, il faut faire accepter le fait qu’il y a une seule mise en production majeure par mois. Même si le but c’est in fine d’avoir plus de projets en production (parce qu’il n’y a pas besoin de revenir dessus, parce qu’on ne réduit pas la bande passante des sprints suivants, etc.), même si on peut avoir des projets qui sont urgents, qui se retrouvent à être hors process et qui sont déployés en cours de mois, il n’empêche qu’on a une mise en production majeure par mois, et ça parfois il faut le faire accepter.
Voilà. Merci.