La gestion du suivi du "Reste à Faire" peut se faire sur des projets agiles en Scrum comme le cas pour les projets gérés par une approche traditionnelle ou dite "Cycle en V", sauf que ce n'est pas de la même manière, mais plutôt avec un usage plus fin et précis, que ça soit au niveau d'un Sprint, d'une "Release", ou pour le projet en totalité.
Chez les projets informatiques gérés par une approche traditionnelle, le suivi du reste à faire peut se faire au niveau de tout le projet en globalité, au niveau d'une étape (Analyse, Développement, test, ...Etc.), ou bien par lot, et cela en calculant le nombre de "Jours/homme" restants par rapport au ceux planifiés au début du projet, vu que les estimations sont faite en jours/homme. Comme ça le chef de projet peut avoir une visibilité sur l'avancement et le risque d'avoir ou pas des dérives (Charge restante (JH) = Consommé + RAF).
En gestion de projets agiles, et chez les équipes "Scrum", l'analyse et le suivi du reste à faire peut s'effectuer d'une manière quotidienne cette fois-ci, et à plusieurs niveaux :
Au niveau d'un Sprint :
Lors du "Daily Meeting", l'estimation du reste à faire est ajustée chaque jour par l'équipe Scrum, et cela par le biais de l'indicateur du "Burn-Down Chart" qui permet la visualisation de l'avancement du Sprint. Ce graphique peut se baser soit sur les User Stories terminées par rapport à celles en cours ou non encore démarrées, soit sur les tâches-techniques composant une User Story, mais c'est toujours le même principe, c'est à dire en fonction de des statuts des US / Tâches-techniques (Terminée ou pas terminée), et pas en fonction de nombre d'heures restantes car ça n'a pas de sens en agile.
Au niveau d'une Release :
Le "Product Owner" peut générer ce qu'on appelle l'indicateur "Burn-Up Chart" à n'importe quel moment selon le besoin, afin de visualiser l'avancement du Release qui peut être composée d'un ou plusieurs Sprints. Ce graphique permet de visualiser sur une Release et Par sprint par rapport au nombre de "Points d'Histoire" réalisé et les points restantes. sachant qu'on insiste toujours sur le fait d'effectuer les estimations en Points de complexité et pas en jours/homme ou en heures.
Au niveau du contenu du Product Backlog :
Cela peut se faire si l’environnent est prédictif, et que l'équipe de développement a pu estimer tout le Backlog et elle a une vélocité stable, comme ça le "Product Owner" peut suivre graphiquement l'avancement des développements du projet, mais cela reste toujours temporaire vu que le "Product Backlog" est vivant et son contenu peut changer d'un instant à l'autre.
Conclusion :
À part le "Scrum Board" ou le kanban visuel affichable sur le mur, le Scrum BurnDown / BurnUp est un outil graphique intéressant et indispensable dans les projets Scrum permettant un suivi rigoureux au quotidien de l'avancement de travail, que ça soit au niveau d'un "Sprint", au niveau d'une "Release", ou au niveau de tout le projet si possible bien sûr.
Lorsque on utilise le "Pattern TAF" (Découpage d'une User Story en plusieurs sous-tâches techniques) il est recommandé d'effectuer un découpage permettant d'avoir des sous-tâches techniques très fines, comme ça on peut avoir un suivi du reste à faire plus précis et efficace.
Plusieurs outils de gestion des projets agiles permettent la génération des graphiques BurnDown / BurnUp, en occurrence "JIRA", "ASANA", et "TRELLO".
Comentarios