Blog des développeurs Cegedim Insurance Solutions: Feature Team en LESS : Partie 1 : Worflow de développement sous JIRA

Introduction

Cette première partie est consacrée aux retours sur la configuration des Workflows JIRA en agilité à large échelle (Less.works). La 2ème proposera une approche novatrice d'analyse des Burndowns avec une proposition de Burndowns améliorés.

Workflows de développement

Il y a plusieurs écoles en ce qui concerne les Workflows de développement en Agilité/Scrum et les outils tels que JIRA Cloud supportent très bien la customisation et le choix des équipes.

Certaines personnes sont favorables aux workflows les plus ouverts possibles, Todo, Active, Done avec l'ensemble des transitions possibles entre ces 3 états de base. Cela est certainement très intéressant dans une équipe d'experts dans une Startup, se connaissant bien, maîtrisant parfaitement l'agilité.

Workflow Agile "Ouvert"

Déployant l'agilité à une échelle plus large qu'une Feature Team, il nous paraissait intéressant d'avoir un processus bien huilé pour que chaque étape du cycle de vie de la User Story soit bien décomposée et que les responsabilités soient clairement identifiées à chaque étape dans ce processus collaboratif.
Sachant qu'un développeur réalise entre 3 à 4 User stories par sprint, cela fait au maximum 30 clics liés au respect du workflow, mais avec un avantage, celui de la scalabilité, notamment pour tous les nouveaux qui nous rejoignent (30 personnes en 1 an), pour ne rien oublier, ce qui au global fait gagner du temps à tout le monde.

Voyons dans cet article l'implémentation que nous avons choisi de faire et le feedback correspondant après plusieurs semestres d'utilisation :

Quelques principes de bases

Voici quelques bonnes pratiques que l'on a tirées de la configuration des Workflows après 2 ans d'utilisation de JIRA Cloud :

On crée une étape à chaque fois qu'on change de Rôle. Grâce au Misc Extensions de JIRA Cloud, on peut facilement déterminer des assignations automatiques avec des règles complexes du type :

Ex : Assigner au dernier Product Owner ayant travaillé sur la User Stories, ce qui permet d'assigner au bon Product Owner si jamais il y en a plusieurs
Ex : Assigner au Mister (Ingénieur Qualité)

On crée des types d'Issue spécifiques si jamais on veut un Workflow particulier :

Ex : Ainsi le workflow de bug n'a pas autant d'étapes que peut le comporter le workflow des User Story.
Si on partage les workflows et que des étapes n'ont pas de sens, les collaborateurs vont parfois sauter les étapes en se disant que telle ou telle étape n'a pas de sens, mais pourraient également en oublier sur les Issues où c'est réellement nécessaire

Mettre des contrôles sur les champs structurants de la DoD (Definition of Done)

Ex : Dans la Definition of Done, il est indiqué qu'on souhaite systématiquement avoir un lien vers l'environnement de tests (pour les tests fonctionnels du Product Owner, les autres tests sont automatisés), et il est demandé aux développeurs de mettre un lien dans un champ personnalisé afin de limiter le nombre de réouvertures.

Type d'Issues

Dans JIRA, il est assez facile de créer des Issues spécifiques, et nous avons donc utilisé et créé les types d'Issues suivantes avec des icônes facilement identifiables :

User Story : la base de Scrum
Bug : déjà présent et configuré dans JIRA. Nous avons la règle simple de corriger l'ensemble des bugs dans les 1ers jours (en général 1 ou 2 suffisent) du Sprint, pour ne pas créer d'accumulation. Dans le cas où derrière le bug se cache en réalité une fonctionnalité et pas un dysfonctionnement, il est requalifié par le Product Owner. Grâce à cette technique, nous n'avons pas besoin d'une équipe Support, et nous n'avons pas de dérive ni de Management de bugs compliqués. Comme chaque développeur sait qu'il va traiter les bugs en priorité au Sprint suivant, il est encore davantage "responsabilisé".
Spike : lorsqu'il est difficile de chiffrer des User Stories ou que l'équipe ne sait pas comment aborder un point technique et en tirer une décomposition de User Story claire, il est nécessaire de réaliser une Spike sous forme de petite étude, avec des propositions de décomposition ou un No Go sur la faisabilité technique de telle ou telle approche
Improvement : Les User Stories ne doivent provenir que du Product Owner, car sinon cela crée de la confusion entre les besoins réels, et les idées du reste de l'équipe. L'idée est que l'ensemble des bonnes idées passent par des "Improvements", puis que celles-ci soient transformées ou non en collaboration avec la personne qui l'a écrite en User Story ou non. Grâce à cela, le Product Owner garde la maîtrise du contenu du sprint (ce qui évite les dérives où on rajoute des User Stories au fur et à mesure sans jamais finir la feature/Epic associée).
CIFail : lorsque l'intégration continue est cassée sur la branche principale (ce qui doit normalement être extrêmement rare, voire impossible dans le cas d'une approche de type "Build incassable"), nous avons implémenté un mécanisme au sein de Jenkins, qui crée automatiquement ce type d'Issue et qui l'assigne au Scrum Master. De cette façon, le build cassé est vite réparé. Il est préférable de passer par des issues au sein du Sprint que par des mails, qui risquent d'être passés à la trappe (filtres automatiques par exemple), alors qu'une Issue est bien "visible" par tous dans le Sprint, ce qui permet de les traiter en priorité.
Team Foundation Services (TFS) de Microsoft adopte par exemple ce principe en natif dans le produit si on le configure correctement.

Exemple de Workflow : User Stories

La première réaction sera peut-être de considérer que le diagramme est une usine à gaz, mais en réalité, après plusieurs itérations / corrections et l'utilisation sur 2 ans (nous avions beaucoup moins d'étapes au début), nous sommes très satisfaits de son utilisation, car elle satisfait les principes énoncés plus haut, et permettent à chacun de ne rien oublier, et finalement de valider une User Story de manière beaucoup plus fluide qu'auparavant.

Voyons la justification de chaque état :

Etats du processus nominal

New : Statut par défaut. Il correspond au méta-état JIRA "Todo", et est créé par le Product Owner principalement lors du Backlog Grooming. Les autres membres de l'équipe doivent utiliser les Improvements pour suggérer des nouvelles User Stories et non pas créer celles-ci au risque de tomber dans de l'auto-alimentation de backlog par les équipes. En effet, les besoins en Agile doivent continuer de provenir du représentant métier qui est le Product Owner.
Initiated : On peut y passer dès lors qu'on a rajouté une description, un lien vers la Feature (Epic) correspondante. Il est préférable pour le Product Owner d'y avoir ajouté des critères d'acceptances pour faciliter le travail du Mister T. Cette étape est dédiée à la validation des critères d'acceptance par le Mister T (Ingénieur QA/Automatisation), ce qui garantit qu'une User Story a été conçue dès l'origine pour être testable de façon automatisée. Cela a l'avantage de clarifier énormément pour le développeur la façon d'aborder cette User Story et d'éviter des nombreux allers-retours avec la QA car il a bien en tête comment celle-ci sera testée. C'est une étape clé dans le processus de raffinement (refinement en anglais) des User Story jusqu'à l'étape Ready. En général, les "Gherkins" Cucumber, c'est-à-dire les définitions de tests sous forme compréhensible par un fonctionnel (et pas leur implémentation) sont écrits à ce moment par le Mister T.
Designed : A cette étape, les critères d'acceptance ont été validés par le Mister T et le Product Owner reprend la main (assignation automatique) pour l'estimation au reste de l'équipe lors du Poker Planning
Ready : C'est à partir de cette étape qu'une User Story est éligible à être positionnée dans un Sprint pour démarrage, puisque l'estimation a été faite, et est valide du point de vue de la "Definition of Ready", qui est une description formelle des éléments que doit contenir une User Story pour pouvoir être prise en charge par l'équipe de développement. A ce stade, on est sûr d'avoir par exemple pour des API la liste des règles métiers, pour des UI des Mock écrans de type Balsamiq, et dans tous les cas les critères d'acceptance.
Active : C'est l'étape la plus évidente. A noter que grâce aux JIRA Misc Extensions Workflow, si on déplace une tâche, on a la capacité à mettre également la User Story active, ce qui est pratique, car les développeurs sont davantage centrés sur le Board de Tâche que sur le Board de User Story. Cela évite donc d'avoir des états incohérents entre les tâches et les User Stories.
TechnicalReview : Cet état est celui de la validation liée à une demande de Pull-Request de la branche de feature vers la branche d'intégration, et la relecture systématique par 2 reviewers (en général, le Pair Programmeur, ainsi que le leader technique).
QualityReview : lié à la validation du Mister T, qui revalide si l'implémentation et la couverture des tests d'intégrations sont corrects. Même si une QualityGate au niveau de Sonar empêche qu'un développeur puisse incorporer du code avec une faible couverture, une relecture du code de tests est toujours précieuse pour être sûr de l'intérêt des tests (on n'écrit pas des tests pour des tests, mais bien pour se prémunir de régressions)
Completed : étape réservée au Product Owner, qui après être sûr de la qualité technique, et de la qualité des tests (notamment tests aux limites) peut se concentrer sur la validation fonctionnelle de la User Story, en général sur des comportements nominaux.
Done : Etat final lié à la validation par le Product Owner de la User Story. Cet état est également lié au Méta-état "Done" de JIRA, lui permettant de comptabiliser les points de Sprint (ce qui fait descendre le Burndown).

Autres Etats

Reopened : n'importe quelle invalidation au moment des Reviews repasse par cet état global, et on doit repasser toutes les étapes de validation (qualité, technique, fonctionnelle ...). En effet, une correction dans le code liée à un problème fonctionnel (au niveau de l'étape Completed) nécessitant une modification technique pourrait poser un problème de sécurité, de performances ou autre, et il est important de revalider tous les aspects même pour une modification mineure
Cancelled : permet d'éviter la suppression d'une User Story, qui ne sera pas faite, mais dont on veut garder une trace sur le fait qu'on a décidé de ne pas la faire maintenant ni dans une version ultérieure.
Waiting : cet état doit être normalement très peu utilisé, car il s'agit d'un blocage lié à une autre User-Story, ce qu'on évite au maximum dans l'agilité.

Conclusion

Nous avons vu l'intérêt que peut avoir l'utilisation de Workflows personnalisés dans JIRA, l'utilisation de Workflow Misc Extensions permettant d'assigner automatiquement à chaque transition aux bons correspondants (ce qui évite le syndrome de la User Story au bon état mais pas à la bonne personne, avec un temps de feedback qui augmente ce qui est contraire aux principes d'agilité). Dans le prochain article dédié au Burndown, nous allons voir comment nous pourrions utiliser ce Workflow et les méta-états pour créer une amélioration du Burndown que l'on voit habituellement ...

Feature Team en LESS : Partie 1 : Worflow de développement sous JIRA