| Structure | Supports | RH | Réunions | |||||||
| Product Owner (P.O) | Réunions Produit | |||||||||
| Produit {nom} | Bac à sable | > Rôle de chef de produit/MOA fonctionnel et technique | Désignation d'un P.O | |||||||
| > Représentant client (communique avec lui et le représente) | Découpage en Projet(s) | |||||||||
| > Gère le bac produit et planifie les releases | ||||||||||
| Project Team (P.T) | Planifications Projet (@P.O + P.T ou client) | |||||||||
| Projet {nom} | Cahier des charges | 1 P.O | Elaboration du cahier des charges, Découpage en Release(s) | |||||||
| Bac(klog) Produit | N Développeurs | Constitution de la PT, présentations du projet | ||||||||
| N Stackeholders (partis prenants, ou acteurs fonctionnels du projet) | ||||||||||
| > Certains membres de la PT se retrouveront aussi dans les ST ou RT | Planification de release (@P.O + client) | |||||||||
| Release {n°} du {deadline} | Plan de release | Quelles fonctionnalités doivent être livrés en Imperatif et Souhaité | ||||||||
| Quelle date de début et quelle deadline | ||||||||||
| Découpage en Sprint(s), constitution d'une S.T pour chaque Sprint | ||||||||||
| Scrum/Sprint Team (S.T) {nom de code} | Planification du sprint (2h, @S.T). | |||||||||
| Sprint {n° & nb semaines} | Bac(klog) Sprint | 1 P,O | Le P.O définit un le Bac Sprint Prévisionnel et le présente à la ST | |||||||
| board Scrum/Kanban | 1 Scrum Master (S.M) : un dev qui veille au respect des règles Scrum, | Définition du Bac Sprint Initial (avec l'accord de toute la S.T) | ||||||||
| des réunions (respect des heures et hors-sujets), | et du whiteboard Scrum/Kanban : limitations à chaque étapes etc | |||||||||
| intercepte les dérangements nuisant au sprint | Revue hebdo (tous les Jours-5 de 15h30 à 16h45, @S.T) | |||||||||
| Semaine de sprint 1 | 2-7 Scrum Devs (S.D), tous égaux dans l'équipe. | Point sur les tâches accomplis dans la semaine, | ||||||||
| > Le SM et la SD choisissent le nom de code de leur S.T | les problèmes rencontrés et si le planning est respectable. | |||||||||
| > Flot continu : Développer , tester, documenter et pousser en préprod | Eventuellement, modification du restant dans le Bac Sprint Final | |||||||||
| Jour de sprint 1 | > Chaque Sprint peut avoir une S.T différente | Stand-up (Tous les jours de 11h00 à 11h15, @S.T) : | ||||||||
| Chaque personne parle quelques minutes : | ||||||||||
| ... | de ce qu'elle a fait hier | |||||||||
| va faire aujourd'hui | ||||||||||
| /Jour de sprint 5 | des problèmes rencontrés, et suggestions diverses | |||||||||
| Revue de Sprint (Dernier jour de 14h00 à 15h30, @P.T) | ||||||||||
| /Dernière semaine | Bilan sur le sprint, graphs et tableaux à l'appui, à toute la P.T | |||||||||
| Retrospective de Sprint (Dernier jour de 15h30 à 16h45, @ S.T) | ||||||||||
| L'équipe fais le bilan sur les problème rencontrés | ||||||||||
| et comment optimiser les process pour les prochains Sprint | ||||||||||
| Release Team (R.T) {n° de release} | Rapport de Release (@P.O + client) | |||||||||
| /Livraison Release | Plan de déploiement | 1 P.O | Le client et le PO font le point sur la livraison de la release : | |||||||
| (Jamais de mise en prod | N Développeurs | Bugs rencontrés, respect des temps et des engagements | ||||||||
| le vendredi) | Release doc | > Vont re-tester l'ensemble puis gérer le déploiement et la livraison | Revue de livraison (@P.T) | |||||||
| > La R.T peut être la même équipe que la S.T, | Le bilan sur la livraison, satisfaction client | |||||||||
| ou un mix entre les S.T ou même une équipe dédiée | Rajout/Modifications de tâches dans le bac produit par le P.O | |||||||||