Développement agile pour débutants : rôles, événements et artefacts Scrum du premier sprint

Projets & développement

Développement agile pour débutants : rôles, événements et artefacts Scrum du premier sprint

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.

0 J'aime 0 Copies Auteur: WeProcess
développement agile Scrum sprint équipe de développement débutant
Inscrivez-vous gratuitement et utilisez ce modèle

Avec un compte gratuit, vous pouvez copier ce modèle depuis le marché

Aperçu du tableau blanc

Mode aperçu Développement agile pour débutants : rôles, événements et artefacts Scrum du premier sprint
Inscrivez-vous gratuitement et utilisez ce modèle

Aperçu du tableau blanc

1. Ce qu'est le développement agile (... 2. Le déroulé du sprint de deux semai... 3. Product Owner 4. Scrum Master 5. Développeurs 6. Product Backlog 7. Sprint Backlog 8. Incrément 9. Les 5 événements en un coup d'œil Kit de démarrage ... Mode d'emploi : (... Definition of Don... Rôles et règles c... Blocages et obsta... Enseignements et ... En une phraseSur 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 à avantex. 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 apporteex. comme on voit du concret toutes les deux semaines, une mauvaise directionse repère en deux semaines. Il n'y a qu'un sprint à refaire. 1. Planification du sprintPremier 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 sprintDernier 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étrospectiveJuste 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 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 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 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 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 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 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 Ce qui s'y passe Qui y participe Durée indicative Sprint SprintLe 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 semainesFixe, un mois au maximum Planification Planification du sprintChoisir ce qui sera construit en deux semaines et constituer le Sprint Backlog. Toute l'équipe Scrum 4 heures maximumMatin du premier jour Daily Scrum Daily ScrumDire 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 minutesChaque jour, même heure et même lieu Revue Revue de sprintMontrer ce qui fonctionne et recueillir des avis. L'écran, pas les diapositives. Équipe Scrum et parties prenantes(demandeurs, utilisateurs) 2 heures maximumLe dernier jour Rétrospective Rétrospective de sprintRegarder la manière de travailler, non ce qui a été construit. Toute l'équipe Scrum 1 heure 30 maximumJuste après la revue 10. Choisir ce qu... 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 conne… 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 notificatio… 11. Bilan du prem... 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
100%

Faites glisser pour déplacer, utilisez la molette pour zoomer

Contenu du tableau des tâches

Product Backlog 16 éléments

Le vocabulaire Scrum
Monter le 1er sprint
Tenir le daily
Revue et rétro
Noter les 3 rôles
Ranger 5 événements
Voir les 3 artefacts
Fixer les dates
Remplir le backlog
Choisir 2 semaines
Hier et aujourd'hui
Dire les blocages
Bouger les cartes
Montrer le produit
Retours au backlog
Un Try en KPT

Sprint Backlog 0 éléments

En cours 0 éléments

En attente de revue 0 éléments

Terminé 0 éléments