Parmi les patterns agiles intéressants déployés au sein des équipes Scrum, on trouve le "Pattern TAF" qui consiste à découper une "User Story" en plusieurs tâches techniques, comme ça plusieurs développeurs peuvent travailler ensemble en parallèle sur la même demande pour la finaliser et la valider rapidement, Or parmi les questions populaires posées lors des formations agiles, ainsi que par pas mal des agilistes : "Est ce qu'on doit estimer nécessairement les sous-tâches d'une User Story ou pas ?".
Lors de la réunion du "Backlog Refinement", ou durant le rituel du '"Sprint Planning", l'équipe de développement peut effectuer un découpage des "User Stories" en plusieurs sous-tâches techniques (Exemples : IHM / SQL / Algorithme / API / Assemblage technique, ...Etc.). Et pour finaliser l'User Story en question et la mettre en statut "DONE", il faut alors terminer et réaliser toutes les sous-tâches qui la composent.
La question qui se pose fréquemment dans ce sens, c'est le fait de décider par rapport à l'estimation des tâches techniques, est ce qu'elle est recommandée ou pas dans un projet agile en Scrum.
Dans la théorie de "Scrum", ce sont les "User Stories" qui sont estimées par l'équipe de développement en "Points de Complexité" (Par le biais de la technique du "Planning Poker" par exemple), alors que pour les sous-tâches techniques c'est pas la peine de les estimer, mais plutôt il faut juste effectuer un découpage permettant d'avoir des tâches qui ne doivent pas dépasser moyennement 1 ou 2 jours de travail.
Je vois chez certains équipes "Scrum", la pratique d'estimation des sous-tâches techniques d'une "User Story" en "Heures", or ça n'a pas de sens et d'utilité vu que les User Stories sont estimées en "Points d'effort" et pas en "Jours/homme", ce qui va générer une incohérence entre les deux, ainsi que la notion du "Reste à Faire" qui s'applique sur les User Stories et pas par rapport aux sus-tâches techniques.
Un autre point très important qui nous empêche d'estimer les sous-tâches techniques, c'est que tout simplement le faite que l'équipe va comparer le total des heures nécessaires pour finaliser tout le travail embarqué dans un Sprint avec la disponibilité de l'équipe, alors que parfois ce total dépasse la disponibilité de l'équipe en Jours/homme, même si la vélocité de l'équipe permet d'absorber ce travail planifié, et du coup on sera face à une inadéquation entre la vélocité et la disponibilité de l'équipe dans un Sprint.
De mon point de vue personnel, je déconseille l'estimation des sous-tâches techniques, mais plutôt je recommande un découpage d'une User Story en plusieurs tâches précises et fines qui ne doivent pas dépasser moyennement une journée de travail. Et c'est avec l'expérience que l'équipe peut apprendre à découper efficacement les "User Stories".
Conclusion :
Lors du "Stand Up Meeting" (Sprint Daily Meeting) l'équipe de développement met l'action sur l'état d'avancement par rapport à la réalisation des User Stories (Celles terminées et celle non), mais on peut se focaliser en parallèle sur les tâches terminées par rapport à celles à faire ou pas terminées, mais surtout pas mesurer l'avancement par rapport au temps restant sur une ou plusieurs tâches, car c'est binaire soit terminée soit non.
Cet article reste un point de vue personnel par rapport à mon expérience sur terrain, mais vous pouvez trouver autres agilistes qui disent le contraire. L'essentiel c'est de trouver les bonnes pratiques et les moyens pour faire avancer et faciliter le travail de l'équipe durant les Sprints.
Le "Burn-Down Chart" que vous générez à la fin de chaque "Daily Meeting", et qui permet de mesurer l'état d'avancement par rapport au reste à faire sur le Sprint en cours est basé sur les "User Stories" terminées par rapport à celles en cours ou non démarrées, du coup ça n'a rien à voir avec les sous-tâches techniques, qui reste qu'un moyen et pratique utilisée par les équipes "Scrum" pour identifier l'ensemble de travail requis pour une "User Story".
コメント