Processus Scrum : des éléments du backlog de produit à l’incrément de produit livrable

L’objectif du travail quotidien d’un sprint est de créer un incrément de produit livrable pour le produit sous une forme qui peut être livrée à un client ou à un utilisateur.

Dans le contexte d’un sprint unique, un incrément de produit ou un incrément livrable signifie qu’un produit de travail a été développé, intégré, testé et documenté conformément à la définition du projet de terminé et est considéré comme prêt à être publié.

L’équipe de développement peut ou non publier ce produit à la fin du sprint – le calendrier de publication dépend du plan de publication. Le projet peut nécessiter plusieurs sprints avant que le produit ne contienne l’ensemble de produits commercialisables minimum (MMP) nécessaires pour justifier une mise sur le marché.

Pour créer des fonctionnalités livrables, l’équipe de développement et le propriétaire du produit sont impliqués dans trois activités principales :

Elaboration

Dans un projet agile, l’élaboration est le processus de détermination des détails d’une fonctionnalité du produit. Chaque fois que l’équipe de développement s’attaque à une nouvelle user story, l’élaboration garantit que toutes les questions sans réponse sur une user story reçoivent une réponse afin que le processus de développement puisse se poursuivre.

Le propriétaire du produit travaille avec l’équipe de développement pour élaborer des user stories, mais l’équipe de développement devrait avoir le dernier mot sur les décisions de conception. Le propriétaire du produit doit être disponible pour consultation si l’équipe de développement a besoin de plus de précisions sur les exigences tout au long de la journée.

Développement

Au cours du développement du produit, la majeure partie de l’activité incombe naturellement à l’équipe de développement. Le propriétaire du produit continue de travailler avec l’équipe de développement selon les besoins pour fournir des éclaircissements et approuver les fonctionnalités développées. Pendant le Sprint, les membres de l’équipe :

• Jumelez les membres de l’équipe de développement pour effectuer des tâches. Cela améliore la qualité du travail et encourage le partage des compétences.
• Suivez les normes de conception convenues par l’équipe de développement. Si vous ne pouvez pas les suivre pour quelque raison que ce soit, révisez ces normes et améliorez-les.
• Démarrez le développement en mettant en place des tests automatisés. Vous trouverez plus d’informations sur les tests automatisés dans la section suivante et au chapitre 15. Si de nouvelles fonctionnalités intéressantes apparaissent au cours du développement, ajoutez-les au backlog du produit. Évitez de coder de nouvelles fonctionnalités qui sont en dehors de l’objectif du sprint.
• Intégrez les changements qui ont été codés au cours de la journée, un ensemble à la fois. Testez l’exactitude à 100 %. Intégrez les changements au moins une fois par jour ; certaines équipes s’intègrent plusieurs fois par jour. Entreprendre des revues de code pour s’assurer que le code respecte les normes de développement. Identifiez les domaines qui doivent être révisés. Ajoutez les révisions en tant que tâches dans le backlog de sprint.
• Créez une documentation technique pendant que vous travaillez. N’attendez pas la fin du sprint ou, pire, la fin du sprint avant une release.

Vérification

La vérification du travail effectué dans un sprint comporte trois parties : les tests automatisés, l’examen par les pairs et l’examen par le propriétaire du produit. L’équipe peut réaliser :

Tests automatisés

Les tests automatisés consistent à utiliser un programme informatique pour effectuer la majorité de vos tests de code à votre place. Grâce aux tests automatisés, l’équipe de développement peut développer et tester rapidement le code, ce qui est un avantage considérable pour les projets agiles. Souvent, les équipes de projet agiles codent pendant la journée et laissent les tests s’exécuter pendant la nuit. Le matin, l’équipe de projet peut examiner le rapport de défaut généré par le programme de test, signaler tout problème lors de la mêlée quotidienne et corriger ces problèmes immédiatement au cours de la journée.

• Les tests automatisés peuvent inclure les éléments suivants : Tests unitaires : test du code source dans ses plus petites parties — le niveau du composant
• Test du système : tester le code avec le reste du système
• Tests statiques : vérifier que le code du produit respecte les normes basées sur les règles et les meilleures pratiques convenues par l’équipe de développement

Examen par les pairs

L’examen par les pairs signifie simplement que les membres de l’équipe de développement examinent le code des autres.

Avis du propriétaire du produit

Lorsqu’une user story a été développée et testée, l’équipe de développement déplace les histoires vers la colonne Accepter du tableau des tâches. Le propriétaire du produit examine ensuite la fonctionnalité et vérifie qu’elle répond aux objectifs de la user story, conformément aux critères d’acceptation de la user story. Le propriétaire du produit vérifie les user stories tout au long de la journée.

Sommaire

L’équipe de développement rend compte de l’avancement des tâches en mettant à jour le backlog de sprint avec lequel les tâches ont été terminées et combien de travail, en heures, reste à faire sur les nouvelles tâches commencées. Selon le logiciel utilisé par l’équipe Scrum, les données du backlog de sprint peuvent également mettre à jour automatiquement le graphique de burndown de sprint.

Autres articles Scrum

• Qu’est-ce que le modèle Rôle-Fonctionnalité-Raison ?
• Incrément de sprint vs produit potentiellement livrable vs MVP vs MMP
• Rédiger des objectifs SMART et INVESTIR pour les User Stories
• Le Manifeste Agile et les Douze Principes
• 10 règles de base les plus fréquemment mentionnées dans Scrum
• Que sont les événements Scrum ?
• Que sont les cérémonies Scrum ?
• Qu’est-ce que le Product Backlog Toilettage ?
• Qu’est-ce qu’un Sprint dans Scrum ?
• Battement de cœur de Scrum — The Daily Standup