Projets & développement
Développement agile pour débutants : rôles, événements et artefacts Scrum du premier sprint
Débutant | 2 pages de tableau blanc · Tableau des tâches à 5 colonnes (4 tâches parentes, 12 sous-tâches)
Débutant : Sans termes techniques. Il suffit de répondre aux questions du tableau blanc en suivant les exemples de remplissage pour obtenir un résultat.
Ce modèle pour débutants sert à comprendre les 3 rôles, 5 événements et 3 artefacts de Scrum et à dérouler un premier sprint quand on découvre le développement agile ou rejoint une première équipe. Le tableau blanc réunit l'idée de base du développement agile, le déroulé d'un sprint de deux semaines en 5 étapes, trois cadres pour les 3 rôles, trois cadres pour les 3 artefacts, un tableau des 5 événements, quatre colonnes MoSCoW pour choisir ce qui entre dans ce sprint et une rétrospective KPT. Le tableau de tâches compte cinq colonnes - Product Backlog, Sprint Backlog, En cours, En attente de revue et Terminé - et démarre avec 4 tâches parentes et 12 sous-tâches, du vocabulaire à la rétrospective, toutes à faire. Arriver dans une équipe sans connaître Scrum, c'est se laisser distancer par les mots, alors suivez ce tableau pendant un sprint et vous saurez quoi dire au daily. À la différence d'un tableau pour équipe déjà rodée, celui-ci porte sur le vocabulaire et le premier tour.
Avec un compte gratuit, vous pouvez copier ce modèle depuis le marché
Aperçu du tableau blanc
Lire le texte du tableau blanc
Kit de démarrage agile
Mode d'emploi : (1) Lire l'idée de base → (2) Suivre le déroulé du sprint de deux semaines → (3) Vérifier les 3 rôles et les 3 artefacts (tableaux 3-8) → (4) Fixer les dates des 5 événements (tableau #9) et trier avec MoSCoW ce qui entre et ce qui attend (tableau #10) → (5) Faire le bilan avec KPT (tableau #11)
1. Ce qu'est le développement agile (construire, montrer et corriger sur de courtes périodes)
- En une phrase Sur une période courte d'environ deux semaines, construire quelque chose qui fonctionne, le montrer, recueillir des avis et corriger. Puis recommencer.
- Ce qui change par rapport à avant ex. au lieu de figer toutes les spécifications avant de construire, on fixe l'ordre de fabrication et on avance par petits bouts. L'ordre peut changer en route.
- Ce que cela apporte ex. comme on voit du concret toutes les deux semaines, une mauvaise direction se repère en deux semaines. Il n'y a qu'un sprint à refaire.
2. Le déroulé du sprint de deux semaines (le daily se répète chaque jour)
- 1. Planification du sprint Premier jour du sprint. Trier avec MoSCoW sur le tableau
- 2. Développement (deux semaines) Ne construire que ce qui a été choisi. Même si une nouvelle demande arrive, elle n'entre pas dans ce sprint, par principe. ex. avancer uniquement les 3 éléments de connexion, soit 13 points.
- 3. Daily Scrum (15 minutes par jour) Chaque jour de ces deux semaines, 15 minutes à heure fixe. Chacun dit ce qu'il a fait hier, ce qu'il fera aujourd'hui et où il est coincé. Cela se répète tous les jours en parallèle du développement. ex. debout, tous les matins à 10 heures.
- 4. Revue de sprint Dernier jour. Montrer aux parties prenantes quelque chose qui fonctionne et recueillir leurs avis. 2 heures maximum. Montrer l'écran, pas des diapositives. ex. manipuler en direct le nouvel écran de connexion.
- 5. Rétrospective Juste après la revue. Regarder non pas ce qui a été construit mais la manière de travailler. 1 heure 30 maximum. Fixer le prochain pas avec KPT sur le tableau
3. Product Owner
- La personne qui décide de ce qui sera construit en premier
- Elle répond de l'ordre du Product Backlog
- ex. elle décide que l'amélioration de la connexion passe d'abord
- C'est elle que l'on consulte en cas de doute sur le contenu
4. Scrum Master
- La personne qui veille au respect de la manière de travailler
- Elle lève les blocages et fait tenir la durée de chaque événement
- ex. elle reçoit une demande imprévue et la replanifie
- Elle ne donne pas d'ordres et n'est pas forcément cadre
5. Développeurs
- Celles et ceux qui construisent, conception, code et tests compris
- Ce qui tient en deux semaines est estimé par les développeurs eux-mêmes
- ex. trois personnes se répartissent le Sprint Backlog
- Développeur désigne ici un rôle, pas un intitulé de poste
6. Product Backlog
- Tout ce que l'on veut construire, rangé dans l'ordre de fabrication
- Plus c'est haut, plus c'est tôt. L'ordre est fixé par le Product Owner
- ex. amélioration de la connexion / réglages des notifications / recherche dans l'admin
- Une liste sans fin. Elle peut s'allonger en cours de route
7. Sprint Backlog
- Uniquement ce qui a été retenu pour ces deux semaines
- Choisi en planification, rien ne s'y ajoute en cours de sprint
- ex. les 3 éléments de connexion, soit 13 points au total
- On y voit aussi qui a pris quoi en charge
8. Incrément
- Ce qui fonctionne et existe à la fin des deux semaines
- Ce qui ne satisfait pas la definition of done (les conditions convenues à l'avance dans l'équipe pour dire qu'une chose est finie) n'en fait pas partie
- ex. l'amélioration de la connexion, testée et vérifiée
- C'est cela que l'on montre en revue de sprint
9. Les 5 événements en un coup d'œil
| Ce qui s'y passe | Qui y participe | Durée indicative | |
|---|---|---|---|
| Sprint | Sprint Le cadre de deux semaines qui contient les quatre autres. Sa durée ne s'allonge jamais. | Toute l'équipe Scrum (Product Owner, Scrum Master, développeurs) | Deux semaines Fixe, un mois au maximum |
| Planification | Planification du sprint Choisir ce qui sera construit en deux semaines et constituer le Sprint Backlog. | Toute l'équipe Scrum | 4 heures maximum Matin du premier jour |
| Daily Scrum | Daily Scrum Dire ce qui a été fait hier, ce qui est prévu aujourd'hui et où cela coince. | Développeurs (les deux autres rôles écoutent) | 15 minutes Chaque jour, même heure et même lieu |
| Revue | Revue de sprint Montrer ce qui fonctionne et recueillir des avis. L'écran, pas les diapositives. | Équipe Scrum et parties prenantes (demandeurs, utilisateurs) | 2 heures maximum Le dernier jour |
| Rétrospective | Rétrospective de sprint Regarder la manière de travailler, non ce qui a été construit. | Toute l'équipe Scrum | 1 heure 30 maximum Juste après la revue |
10. Choisir ce qui entre dans ces deux semaines (MoSCoW)
Must (indispensable)
- Uniquement ce sans quoi l'objectif du sprint est hors d'atteinte. ex. corriger le défaut qui empêche le courriel de réinitialisation d'arriver
Should (important)
- Important, mais l'objectif tient même en le laissant de côté cette fois. ex. réécrire les messages d'erreur incompréhensibles
Could (si le temps le permet)
- Entre dans le sprint, mais sort en premier si le temps manque. L'objectif tient sans cela. ex. remplacer le logo de l'écran de connexion
Won't (pas cette fois)
- Écarté volontairement. Ne pas le supprimer, le laisser dans le Product Backlog (tableau #6). ex. reporter les réglages des notifications et la recherche dans l'admin à un sprint ultérieur
11. Bilan du premier sprint (KPT)
Keep (à garder)
- Depuis que le daily est fixé à 10 heures chaque matin, tout le monde est présent
- Comme les blocages ont été dits sur le moment, ils ont été levés en une demi-journée
Problem (ce qui a manqué)
- Sur les 13 points retenus, 5 ne se sont pas terminés en deux semaines
- Les demandes arrivées en cours de route n'ont pas pu être refusées et le Sprint Backlog a enflé
Try (à tester ensuite)
- Démarrer le prochain sprint à 8 points et n'ajouter que s'il reste de la place
- Les demandes imprévues sont d'abord reçues par le Scrum Master
Contenu du tableau des tâches
Product Backlog 16 éléments
Le vocabulaire Scrum
Le premier obstacle, c'est le vocabulaire. En le retenant par trois blocs, les rôles, les événements et les artefacts, vous ne perdez plus le fil des échanges.
Noter les 3 rôles
Écrivez nommément qui est Product Owner, qui est Scrum Master et qui sont les développeurs. Si quelqu'un cumule deux rôles, précisez-le.
Ranger 5 événements
Mettez le sprint, la planification, le daily, la revue de sprint et la rétrospective dans l'ordre chronologique, puis inscrivez la date et l'heure de chacun.
Voir les 3 artefacts
Vérifiez où se trouvent réellement le Product Backlog, le Sprint Backlog et l'incrément.
Monter le 1er sprint
Retenir les mots ne suffit pas. Fixez le cadre de deux semaines et allez jusqu'à ne choisir que ce qui tient dedans.
Fixer les dates
Arrêtez la date de début, la date de fin ainsi que le jour et l'heure de chaque événement. La durée ne s'allonge jamais en cours de route.
Remplir le backlog
Sortez tout ce que vous voulez construire dans la colonne Product Backlog, puis classez-le dans l'ordre de fabrication. Cet ordre appartient au Product Owner.
Choisir 2 semaines
En partant du haut, ne déplacez vers le Sprint Backlog que ce qui se termine en deux semaines. Si c'est trop, désignez d'abord les Won't avec MoSCoW sur le tableau
Tenir le daily
Le rituel quotidien du sprint, aussi appelé stand-up. N'en faites pas une réunion de reporting, mais un moment où les blocages sortent immédiatement.
Hier et aujourd'hui
Chacun dit en une minute ce qu'il a fait hier et ce qu'il fera aujourd'hui. Les discussions détaillées ont lieu après le daily.
Dire les blocages
Dites toujours à voix haute où vous êtes coincé. La résolution est reprise par le Scrum Master après le daily.
Bouger les cartes
Déplacez les cartes vers En cours, En attente de revue et Terminé pour que le reste à faire se voie d'un coup d'œil.
Revue et rétro
La clôture des deux semaines. Traiter séparément les avis sur le produit et les avis sur la manière de travailler fait partie du modèle Scrum.
Montrer le produit
En revue de sprint, montrez aux parties prenantes un écran qui fonctionne vraiment plutôt que des diapositives, et recueillez leurs avis.
Retours au backlog
Remettez les retours reçus sous forme de cartes dans la colonne Product Backlog, comme matière au prochain classement.
Un Try en KPT
En rétrospective, réexaminez la manière de travailler et fixez un seul Try à tester au sprint suivant.
