SCRUM : Gérer les bogues au cours d'un sprint

Mise à jour du 17 septembre 2008 : Veuillez noter qu'il s'agit d'une très ancienne publication datant des premiers jours de PatientKeeper, avant que nous n'apprenions à éliminer le "Sprint d'assurance qualité" ou "Sprint de stabilisation" avant de passer à la production complète dans un système hospitalier. Le sprint de stabilisation impliquait pleinement les équipes interfonctionnelles. En 2003, un nouveau PDG a demandé pourquoi la définition de "DONE" ne pouvait pas être au moins quatre grands systèmes hospitaliers en production sans aucun problème en suspens à la fin de chaque sprint mensuel. Il nous a fallu deux ans de travail pour y parvenir et, depuis 1995, PatientKeeper est mis en service à la fin de chaque sprint, sans délai supplémentaire pour les tests d'assurance qualité, de régression ou de performance. Le Sprint dont il est question ici était également une urgence qui nous a douloureusement appris qu'un Sprint de plus d'un mois ne devrait jamais être réalisé. Ce Sprint représente un mode d'échec que nous n'avons jamais reproduit.

La bonne nouvelle, c'est qu'elle montre que PatientKeeper a mis en place très tôt le meilleur système de suivi Scrum que j'aie jamais vu. Il présente toujours des avantages significatifs par rapport à n'importe quel outil Scrum sur le marché. Il a été migré vers Jira comme système de stockage sous-jacent pour toutes les tâches. Les bogues sont simplement une autre tâche de développement dans ce système.

Récemment, une question a été posée sur le site liste des objets technologiques demande comment gérer les bogues pendant un sprint SCRUM. Nous avons affiné l'art de la gestion de projet SCRUM chez PatientKeeper au cours des deux dernières années pour gérer plusieurs sprints simultanés avec des milliers de tâches simultanées, en intégrant le suivi des bogues avec le suivi du projet de développement. Le système de gestion de projet devait être mis à jour en moins de 60 secondes par jour et par développeur, et en moins de 10 minutes par jour pour que le chef de projet puisse établir des rapports complets avec des diagrammes et des graphiques.

Pour répondre à cette exigence, les développeurs ne pouvaient pas utiliser d'autre logiciel que le système de suivi des bogues qu'ils utilisaient déjà. Nous n'avons ajouté que quelques éléments de données pour inclure les tâches de développement dans les bogues - classe (tâche de développement ou bogue), estimation initiale, temps investi et pourcentage d'achèvement. Notre équipe utilisait déjà un système de suivi des bogues open source GNATS. Nous avons amélioré le GNATS en y ajoutant ces éléments d'information et la possibilité de déverser les données dans une feuille de calcul Excel automatiquement, tous les jours, pour le gestionnaire de projet.

Le tableau d'évaluation ci-dessus a été publié dans : Sutherland, Jeff. Agile Can Scale : Inventer et réinventer SCRUM dans cinq entreprises. Cutter IT Journal 14:12:5-11, décembre 2001. Si vous souhaitez obtenir une copie, envoyez-moi un courriel.

Le graphique représente un sprint assez long nécessaire pour livrer la version 6 du produit mobile PatientKeeper pour les résultats cliniques. La planification de ce projet a commencé en avril (alors qu'une autre version était en cours) et les éléments de développement ont été saisis dans le GNATS, y compris les estimations initiales. Les estimations initiales sont gelées et ne peuvent être modifiées après leur saisie. Cela nous permet d'évaluer la précision des estimations à une date ultérieure. Vous pouvez voir le carnet de commandes s'étoffer au fur et à mesure que de nouveaux éléments de projet sont saisis. Le sprint a été lancé en juin et le carnet de commandes a rapidement augmenté à mesure que le marketing produit ajoutait de nouvelles tâches et que les développeurs découvraient que leurs estimations initiales étaient trop courtes ou qu'il manquait des tâches. Dans la première partie d'un sprint, le défi consiste à compléter le carnet de commandes et à commencer à piloter la courbe du carnet de commandes jusqu'à la date de livraison. Dans le cas présent, la livraison s'est arrêtée au 20 août.

Au fur et à mesure que des bogues sont découverts, ils sont enregistrés dans le même système. Il est possible d'entrer des estimations pour la correction des bogues, mais nous les suivons généralement en fonction du nombre de bogues. Les données transmises au chef de projet permettent d'examiner les données de différentes manières. Cette mesure est l'une des informations les plus critiques pour évaluer la stabilité du code, ainsi que la réussite du projet. Dans le sprint de développement qui s'est achevé le 20 août, l'accent est mis sur le nombre cumulé de jours restants pour les tâches inachevées, ce qui inclut le travail des testeurs avec les développeurs pour éliminer les bogues. Le 20 août, nous sommes passés à un sprint de stabilisation pour nous assurer que le système était entièrement prêt pour la production et pour le mettre en service dans un grand système hospitalier. Les équipes se sont alors concentrées sur le nombre de bogues restants jour après jour, y compris les flux entrants et sortants.

Les tests se poursuivent pendant le cycle de développement et les tâches ne doivent pas être achevées tant que les bogues prioritaires n'ont pas été éliminés. Si des bogues sont découverts après que la tâche a été enregistrée comme terminée, elle peut être rouverte, ou le bogue peut être corrigé par le développeur propriétaire pendant qu'il travaille sur d'autres tâches. Dans tous les cas, cet effort se traduit par une courbe ascendante ou descendante du carnet de commandes. À la fin de chaque journée, chaque développeur examine les tâches et les bogues sur lesquels il travaille dans la même interface utilisateur GNATS, et met à jour la base de données en moins de 60 secondes.

C'est le meilleur système de gestion de projet que j'aie jamais vu ou expérimenté. Le temps nécessaire à la mise à jour et à la communication des statistiques de gestion de projet a été réduit d'au moins deux ordres de grandeur par rapport à d'autres approches que j'ai vues. En outre, la courbe du carnet de commandes reflète des milliers d'estimations individuelles qui sont mises à jour quotidiennement. Ce micro-costing de l'effort du projet permet d'obtenir des estimations plus précises de l'achèvement du projet que d'autres approches. Hautement recommandé !