réflexion sur les agendas des managers Agile

"Une entreprise dont l'agenda des managers est pleine n'est pas Agile".
Managers et vous, vous êtes dans quelle queue?  citation et photo de Oana Juncu Founder at cOemerge, Agile Organisation facilitator

 C'est de cette citation et photo que ma réflexion a commencée.

Les cérémoniaux de la méthode Agile sont :
-la planification de la release
-planning poker
-revue de sprint
-rétrospective de sprint
-scrum quotidien 

Ils ont chacun  un rôle qui sera  décrit dans un prochain post, il est bien sur indispensable de les planifier et de les respecter. La régularité est importante pour réussir le projet.

Comment le manager va s'organiser avec ces réunions et l'agilité ?  C'est de la gestion du temps.

Il doit dans son planning prévoir du temps pour l'imprévu: Avoir des plages de réunions planifiées et des plages de temps pour les réunions non planifiées.
par exemple :
10h à 12h et 14h  à 17h pour les réunions plannifiables
Il se garde de 9h à 10h,  12h à 13h et de 17h à 18 h  pour gérer les imprévus.
Pour cela, il doit mettre dans son agenda partagé que ces plages horaires sont occupées.

Ceci est un exemple bien sur, qui doit être adapté en fonction de la vie du projet et de l'entreprise. Il faut garder comme idée qu'il doit y avoir du temps pour l'imprévu. C'est à chacun de s'organiser en fonction de ses contraintes.

Qu'est ce qu'un backlog produit?

Une première définition du Product Backlog peut être :

« l'ensemble des fonctionnalités du produit que l'on veut développer »

 Mais ce n’est pas un cahier des charges !

Les fonctionnalités sont stockées dans le back log mais sont détaillées au fur et à mesure du projet. Elles sont priorisées régulièrement et ainsi on ne développe que les fonctionnalités nécessaires aux utilisateurs.  On simplifie le produit.

Alors que lorsque l'on doit tout spécifier dès le départ dans une expression de besoin "exhaustive", on a tendance à mettre absolument tout ce à quoi on pense, et de peur d'en oublier on s'efforce de penser à tous les cas de figure imaginables.

Les fonctionnalités du  Product Backlog  sont priorisées afin de fonctionnalités, le but étant  d'implémenter en premier ce qui rapporte  le plus de valeur. On considère en premier les items ayant une plus grande valeur métier.

Un élément  du Product Backlog n'a raison d'exister que si il apporte de la Valeur.

Le product Backlog peut être alimenté au fil de l’eau. 

Les Items ou Users Stories pourront donc être alimentés  ou supprimés lors de la vie du projet afin de produire uniquement les fonctionnalités utiles à l'utilisateur.

Ce mode itératif d'alimentation du backlog permet de ne pas rester figé dans une vision initiale mais permet en fonction des premiers sprints et de ses résultats d'adapter le produit au besoin des utilisateurs. 

Chiffrage: Méthode traditionnelle versus Méthode Agile

Dans un projet gérer selon la méthode traditionnelle du cycle en V c'est le chef de projet qui fait le chiffrage avec éventuellement l'avis des développeurs.
C'est lui qui est le garant du chiffrage et du planning.

Dans les méthodes Agiles, le chiffrage n'est pas au niveau du projet mais au niveau de la User Story.
Une User Story s'intègre à un sprint et cela permet de définir une planification.

C'est l'équipe qui est responsable du chiffrage, cela demande un consensus.
Les difficultés sont réparties dans des classes de difficultés qui suivent le suite de Fibinacci {0.1/2, 1, 2, 5, 8, 13, 20...}
Les chiffres ne représentent pas des heures ou des jours de travail mais une unité propre à l'équipe.
Par exemple, sur le projet sur lequel je travaille, le print de deux semaines représente 22 points en moyenne.
Les user Story sont classées lors d'une réunion appelée planning poker.
Dans la première partie de la réunion, l'équipe (les développeurs et les recetteurs) qualibre les US.
Chaque membre de l'équipe indique par une carte le nombre de points de la US. S'il y a un écart, les membres discutent et par un deuxième tour arrive à un consensus.
Le Product Owner ne participe pas au chiffrage.
Dans un deuxième temps, l'équipe choisit avec l'aval du Product Owner, les User Stories  à embarquer dans le sprint.
Dans le cas de mon projet, l'équipe ne peut pas embarquer plus d'une vintaine de points pour la quinzaine.

A l'inverse d'un chiffrage selon la méthode traditionnelle, le chiffrage est obtenu par le vue des différents experts  (développeurs, base de données, recetteurs), tous sont impliqués dans la réussite du sprint et du projet.
C'est une méthode collaborative qui demande aussi une souplesse d’esprit et un bon esprit d'équipe  !