Julien Dubois
Le périmètre de votre itération est prêt, l'équipe s'est engagée à livrer le périmètre convenu et n'attend plus qu'une chose, poser les mains sur son clavier pour coder ! Lâchez les fauves, l'heure est venue de les laisser s'exprimer.
Suite à la préparation du périmètre de votre projet l'équipe se met au travail. La prochaine grande étape du projet va résider dans le pilotage des deux ou trois semaines qui composent une itération. L'équipe va passer beaucoup de temps avec le périmètre de l'itération, il doit respirer au rythme des commits et des échanges entre les équipiers. Une des valeurs importantes des méthodes agiles est l'auto-gestion, chaque personne doit être pro-active pour s'attribuer du travail et lever les obstacles qu'elle rencontre lors de la réalisation des fonctionnalités techniques ou utilisateurs. Il est capital qu'à chaque fois qu'une fonctionnalité est démarrée, change d'état pour être envoyée en test ou se termine, le périmètre de l'itération soit mis à jour en conséquence. Le backlog permet d'un simple coup d'œil de savoir qui travaille sur quoi et de suivre l'état d'avancement de l'itération sans avoir à solliciter une personne.
Identifier les goulots d'étranglement
Parfois l'équipe a beau se montrer concernée, elle a le sentiment de faire du sur place. Il y a 6 ou 7 fonctionnalités qui n'arrivent pas à démarrer. Comment comprendre ce qui bloque ? Les fonctionnalités pourront-elles vraiment être traitées dans cette itération ? Pour répondre à ces questions, gardez le numéro de votre marabout préféré dans votre poche, on va plutôt chercher à répondre à cela de façon analytique.
Deux outils (au moins) sont à notre disposition pour mesurer notre activité, le burndown chart et le diagramme de flux cumulé.
Le premier est une courbe illustrée ci-dessous sur laquelle on rapporte le nombre de jours écoulés en abscisse et le nombre de points de complexité en ordonnée. Chaque jour nous allons rapporter le nombre de points de complexité restant à faire. On démarre au premier jour à 120 si c'est la valeur de l'engagement de l'équipe et on soustrait tous les jours le nombre de points de complexité que l'équipe a réussi à fermer. Le but du jeu étant d'arriver à 0 avant le dernier jour du sprint. Cette courbe s'appelle un burdown si vous partez de 120 pour aller à 0, elle s'appelle un burnup si vous partez de 0 pour aller à 120 avant le dernier jour. On représente souvent le rythme idéal sur la courbe pour comparer la vitesse de progression réelle.
Oui mais voilà, le burndown ne montre pas tout, comment se rendre compte si de nombreuses fonctionnalités sont coincées en attente de tests ou en attente de réponse ? Dans ce cas là nous devons nous appuyer sur un autre outil, le diagramme de flux cumulé. Qu'est ce que c'est ? Ne faites pas cette tête, c'est très simple. Il s'agit un graphique qui représente le cumul des points de complexité pour toutes les fonctionnalités de l'itération. De cette façon vous savez si vous avez un grand écart entre le nombre de fonctionnalités en cours de développement, de test ou en attente de réponse. Cela permet de repérer les goulots d'étranglement. Une image valant mille mots, en voici un exemple.
Dans l'exemple présenté, on ne voit à aucun moment une masse prendre le dessus sur l'autre, s'il y avait une prédominance à tester on demanderait à l'équipe du client de se focaliser sur les tests avant d'avancer sur quoi que ce soit d'autre afin de fluidifier la circulation des fonctionnalités vers l'état terminé. Le but étant je vous le rappelle de livrer le plus de valeur ajoutée possible. Avoir des fonctionnalités commencées mais non terminées ne nous avancerait pas.
Quel flux de travail pour mes fonctionnalités ?
Un point important pour que l'équipe avance sans à-coups est qu'elle connaisse le flux de travail que les fonctionnalités doivent suivre. Il n'y a pas UN flux de travail à suivre, c'est à vous de l'adapter au projet et à l'équipe mais je vais vous présenter les états qui composent celui que l'on suit chez Happyculture.
- A faire : État par défaut d'une fonctionnalité.
- En cours : Utilisé dès qu'une développeuse choisi de travailler sur une fonctionnalité.
- À déployer : Sert à indiquer que les développements sont terminés mais pas encore disponibles pour être testés, la fonctionnalité reste assignée à la développeuse tant qu'elle n'est pas prête à être testée. La revue de code devant être faite avec intégration au dépôt principal.
- Attente d'informations : Une développeuse a une question sur un point précis ou au porteur de projet pendant ses tests veut vérifier quelque chose. La personne qui se voit assignée la tache est celle qui doit répondre à la question.
- À tester : La fonctionnalité est prête à être testée, le lien vers la page précise et les instructions pour clore la tache sont précisées en même temps que la fonctionnalité est assignée au porteur de projet.
- À terminer : La fonctionnalité a été testée et nécessite encore un peu de travail. Pour ne pas la noyer au milieu des choses à faire, nous les isolons dans un état dédié afin de travailler dessus en priorité.
- Terminée : Tout le monde a bien fait son travail, la fonctionnalité fonctionne comme prévu.
Comment gérer les demandes à côté ?
Il peut arriver au cours des tests de fonctionnalités que le porteur de projet tombe sur un bug d'intégration ou sur une phrase à reformuler. Pour gérer ces demandes particulières nous ne ré-ouvrons pas des fonctionnalités qui auraient pu être candidates à recevoir ces demandes, on s'appuie plutôt sur une fonctionnalité particulière qui se promène d'itération en itération et qui est un agrégat de toutes les petits demandes du genre. L'équipe y consacre quelques points de complexité à chaque itération selon les priorités. Si certaines taches sont plus grosses, on ouvre une fonctionnalité dédiée qui sera intégrée à l'itération suivante si nécessaire.
Au final, le périmètre de l'itération est au cœur de l'activité, il permet de s'assurer que tout le monde avance sur ses fonctionnalités et permet de constater qu'aucun goulot d'étranglement ne se forme, si tel est le cas il est de la responsabilité de l'équipe de trouver les solutions, le scrum quotidien est là pour ça.