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