Qu’est-ce que le tableau de tâches de sprint

---

Qu’est-ce qu’un tableau de tâches de sprint ?

Une boîte de tâches de sprint est une période définie. Chaque sprint a une date de début et une date de fin durant lesquelles un ensemble d’histoires d’utilisateurs sélectionnées doit être complété et confirmé. L’image suivante vous montre les éléments clés d’un sprint, notamment un ensemble d’histoires d’utilisateurs, les membres Scrum impliqués, l’affectation des tâches, la durée et la date de fin (coin supérieur droit).

Au début d’un sprint, le propriétaire du produit, les parties prenantes et l’équipe de développement se réunissent pour prioriser, puis sélectionner les histoires d’utilisateurs à accomplir durant le sprint. Étant donné que différentes parties ont des préférences, des considérations et des préoccupations différentes concernant le projet et le planning du projet, l’objectif de cette réunion est de donner à chaque participant l’occasion d’écouter et de comprendre les points de vue des autres, et de parvenir à un ensemble d’histoires d’utilisateurs accepté par toutes les parties.

Durée du sprint

La livraison rapide de travail de qualité est l’une des raisons pour lesquelles les équipes logicielles souhaitent adopter des méthodologies agiles. Ainsi, bien qu’il n’existe pas de durée de sprint universellement applicable, il est généralement convenu que la durée devrait être aussi courte que possible. Mais quelle devrait être sa durée ?

Bien qu’une durée de sprint longue ne soit pas souhaitée, une durée excessivement courte peut affaiblir la motivation de l’équipe de développement à accomplir un travail significatif, voire entraîner une qualité médiocre des livrables.

Ainsi, le choix de la durée du sprint résulte d’une discussion menée par toute l’équipe – propriétaire du produit, chef de projet Scrum et membres Scrum tels que concepteurs de bases de données, programmeurs, concepteurs UX, testeurs, analystes, etc. Mais à la fin, quelqu’un doit prendre une décision. À ce moment-là, le chef de projet Scrum est généralement celui qui donne la réponse.

Traditionnellement, un sprint dure de trois semaines à un mois, mais de plus en plus d’équipes réussissent avec des sprints de deux semaines. Après tout, il n’existe toujours pas de durée fixe pour les sprints. Un bon chef de projet Scrum possède des compétences collaboratives et facilitatrices pour déterminer la durée du sprint, afin de garantir que les travaux soient accomplis comme prévu. Voici quelques facteurs que le chef de projet Scrum peut prendre en compte :

1. Planning du projet convenu
2. Disponibilité des clients/parties prenantes/propriétaire du produit (qui peut clarifier les doutes potentiels)
3. Culture de travail des clients
4. Capacité de l’équipe Scrum
5. Expérience Scrum

Une fois que l’équipe a atteint un consensus, tous les sprints futurs suivront la même durée sans la modifier fréquemment d’un sprint à l’autre. Toutefois, il est une bonne pratique pour l’équipe Scrum de continuer à évaluer l’efficacité du sprint, et de chercher une durée optimale qui convienne le mieux à tous.

Confirmation des travaux (histoires d’utilisateurs) dans le sprint

Les activités de développement s’organisent autour des histoires d’utilisateurs après le début du sprint, et de plus en plus d’histoires d’utilisateurs sont mises en œuvre au fur et à mesure que le sprint progresse. Toutefois, la mise en œuvre complète d’une histoire d’utilisateur n’est pas la fin de l’histoire. Il reste encore une étape importante à franchir : la confirmation.

Confirmer une histoire d’utilisateur consiste à tester la fonctionnalité mise en œuvre et à décider si elle a été correctement implémentée. Le jugement doit être basé exclusivement sur les critères établis lors de la détaillisation des histoires d’utilisateurs, exprimés sous forme d’éléments de confirmation. Pendant la confirmation, le propriétaire du produit reçoit un environnement de test ou un appareil pour tester le travail mis en œuvre. Le propriétaire du produit parcourt les éléments de confirmation inscrits sur l’histoire d’utilisateur un par un. Si tous les éléments sont confirmés comme terminés, l’histoire d’utilisateur est considérée comme confirmée. Si un élément est trouvé non terminé ou ne fonctionne pas comme prévu, le propriétaire du produit demandera à l’équipe de développement une correction. Les processus de correction et de confirmation seront répétés jusqu’à ce que l’histoire d’utilisateur soit entièrement confirmée.

Quand confirmer ?

Le sprint, et en réalité l’agilité, est un processus de livraison continue. Au lieu de confirmer les histoires d’utilisateurs à la fin d’un sprint, la confirmation doit être effectuée immédiatement après la fin de chaque histoire d’utilisateur. Toutefois, si le propriétaire du produit ne peut pas participer à une confirmation continue, vous pouvez organiser des réunions hebdomadaires d’une à deux heures chacune. Pendant la réunion, le propriétaire du produit travaillera avec l’équipe pour confirmer les histoires d’utilisateurs terminées. La réunion inclut également une session de discussion qui clarifie les doutes rencontrés lors de la mise en œuvre des autres histoires incluses dans le sprint.

La confirmation n’est pas équivalente au test

Comme dit précédemment, le but de la confirmation est de s’assurer que l’histoire d’utilisateur a été correctement mise en œuvre. Le jugement repose exclusivement sur les éléments établis comme éléments de confirmation lors de la détaillisation de l’histoire d’utilisateur, ni plus ni moins. L’étendue du contrôle est bien insuffisante pour garantir que la fonctionnalité est prête à être utilisée en production. Alors, quand effectuer un « vrai test » ?

Différentes équipes ont des pratiques différentes concernant le test logiciel. Certaines équipes préfèrent un test par sprint, qui consiste à effectuer des tests comme le test d’intégration et le test de régression à la fin d’un sprint. D’autres équipes préfèrent mettre en place un sprint de stabilisation, comme son nom l’indique, pour tester et corriger les bogues. Aucune nouvelle activité de développement ne sera entreprise durant ce sprint.

Peu importe l’approche que vous choisissez, gardez à l’esprit que le choix n’appartient pas à une seule personne, mais à tous.

Visual Paradigm fournit tous les outils dont vous avez besoin dans développement logiciel agile, qui inclut outil de diagramme de cas d’utilisation UML, (agile) histoire utilisateur, sprint, storyboard et maquettes pour la conception UX, outil de gestion des tâches, etc.