Une release se définit par une date de début et une date de fin, un thème et une sélection de fonctionnalités à implémenter. À l’intérieur d’une release, on définit des itérations, auxquelles sont affectées les différentes stories.
La durée d’une itération est-elle variable ? Y a-t-il une règle pour déterminer la date de début et la date de fin ?
1) La réponse du coach Laurent Bossavit, président de l’association eXtreme Programming France.
Une itération doit être de durée fixe. C’est un « timebox », ou boîte de temps : à la fin de la période, on arrête le travail en cours et on comptabilise ce qui a été réalisé. Dès lors qu’on a une réponse quantifiable à la question : « Combien de scénarios client pouvons-nous réaliser en une seule itération de deux semaines ? », il devient très simple de calculer le temps néces-saire pour réaliser un ensemble de scénarios client donnés ayant fait l’objet d’une estimation : c’est une règle de trois. On peut alors déterminer une date de livraison du projet, ou bien savoir s’il sera nécessaire de réduire le périmètre afin de livrer à une date donnée.
Dans la pratique, le plus simple est de faire courir une itération du lundi au vendredi de la semaine suivante, par exemple. Certaines équipes font débuter l’itération le mardi, pour pouvoir tenir les réunions de planification le lundi, lorsque tout le monde est bien reposé.
L’essentiel est de pouvoir répondre à la question « Quelle est l’itération en cours ? » d’un simple coup d’œil sur le calendrier.
2) La réponse du coach David Gageot, directeur technique de Valtech Technology Consulting, cabinet de conseil en technologies agiles.
Je laisse toujours une équipe décider de la durée de l’itération. Il est vrai que je les influence juste un peu au début du projet en leur donnant les points forts des itérations courtes. Sachant qu’ils sont à l’origine du choix, ils se sentiront plus à l’aise. En général, on arrive à une durée de 2 ou 3 semaines.
J’ai tendance à figer cette durée pour tout le projet pour permettre à l’équipe de trouver un rythme de croisière au plus vite. Cela permet même de caler des plannings figés dès le début du projet (ex. démonstration un vendredi sur deux, le jour d’avant en cas de jour férié).
Le modèle le plus classique est de commencer une itération un lundi et de la terminer un vendredi. Il m’est arrivé de changer ce schéma dans le cas d’équipes MOA (maîtrise d’ouvrage) distante. Pour minimiser les déplacements, on terminait les itérations le lundi et on commençait la suivante le mardi.
Parfois, l’équipe souhaite augmenter la durée des itérations pour avoir plus de temps pour finir.
Je leur montre alors qu’ils doivent peut-être au contraire réduire cette durée pour avoir moins de tâches à effectuer et donc mieux les maîtriser.
Gestion de projet – Vers les méthodes agiles
132
Il est en effet souhaitable d’avoir, au cours d’un projet, des itérations de même longueur, afin de rythmer le projet et de faciliter ainsi la planification des réunions ou les valida-tions pour toutes les parties prenantes. En outre, la vélocité, c’est-à-dire le nombre de story points développés par l’équipe au cours d’une itération, ne peut être calculée et réutilisée par l’équipe que sur des périodes comparables.
Planifier une release, cela revient par conséquent à ventiler des fonctionnalités dans des itérations dont la taille a été déterminée. Au préalable, il est souvent nécessaire de préciser ces fonctionnalités, voire de les découper pour les affecter efficacement et logiquement aux itérations ; cette répartition est fonction de la vélocité. Au cours d’une réunion de planifi-cation (release planning meeting), les fonctionnalités macroscopiques prioritaires sont alors détaillées en unités plus fines, qui sont estimées en nombre de points, selon leur complexité, et réparties sur les trois itérations de la release, en fonction de la vélocité de l’équipe.
On obtient ainsi le plan de la release (release plan), c’est-à-dire, pour cette première release, le nombre d’itérations, leurs dates de début et de fin, ainsi que les fonctionnalités que l’on envisage d’y développer, après calcul de la vélocité de l’équipe.
Ce plan de la release peut être mis à jour tout au long de la période, essentiellement à la fin de chaque itération, si la vélocité estimée de l’équipe se révèle être erronée ou si le client modifie ses priorités.
Les fonctionnalités des autres releases, de priorité moyenne ou faible, ne sont pas traitées, pour le moment.
Concrètement, comment se déroule une réunion de planification ? Trouve-t-on toujours un consensus entre tous les acteurs ?
La réponse du coach Jean Tabaka, agile coach, Rally Software Development, Colorado.
Les nouvelles équipes qui abordent le développement agile trouvent certaines pratiques diffici-les à adopter. L’une des plus délicates est d’amener l’équipe à se réunir pour créer le plan d’itération et se l’approprier collectivement. Au cours de la réunion de planification, non seule-ment tous les membres de l’équipe sont présents, mais ils doivent tous adhérer et s’engager sur le plan produit à l’issue de la réunion. En plus, cet engagement ne concerne pas unique-ment les développeurs et les testeurs ; il concerne aussi le client au travers de son représen-tant, le scrumMaster ou le coach ou le chef de projet.
Une réunion qui demande tant de la part de ses participants se doit d’avoir un agenda clair avec un objectif clair et d’être animée par un bon facilitateur, typiquement le scrumMaster ou le chef de projet. En outre, toute l’équipe doit avoir suffisamment de disponibilité, dans un cadre qui facilite les conversations et le dialogue pour arriver à obtenir cet engagement. Ce qui peut déranger, c’est que le management est peu habitué aux dialogues efficaces, aux brainstor-mings et à la recherche du consensus. Très souvent, une équipe agile retombe dans le vieux style de management : « J’ordonne, je contrôle », par des décisions imposées sur le plan pour terminer la réunion plus rapidement. Ces décisions sont souvent exigées aussi par le manage-ment pour obtenir ce qu’il veut, pour imposer son choix, même si chacun, dans la pièce, est susceptible de lui fournir des informations sur les options possibles.
Planifier son projet
CHAPITRE 4
133
La recherche de consensus est un concept nouveau dans beaucoup d’équipes de développement.
Habituellement, le chef de projet ou le team leader ou l’architecte prend les décisions concernant le travail, les tâches, leurs estimations et leurs affectations. Dans la planification agile, c’est l’équipe qui construit sa décision sur ces aspects ; lorsque tout le monde tombe d’accord sur le travail, les tâches, les estimations et les affectations, ils assument, entre eux et auprès du management, leurs décisions, en l’appliquant et en la soutenant.
Voilà le vrai consensus et c’est réellement ainsi que les équipes agiles collaborent et s’engagent.
Celles qui essaient de court-circuiter la prise de décision sans rechercher le consensus ne font que nuire à la bonne collaboration. Dans ce cas, les équipes se sentent contrôlées et manipulées, et finalement ne prennent aucune responsabilité sur des décisions qu’on leur a imposées.
Obtenir le consensus au sein de l’équipe, c’est s’assurer que tous les membres se sentent écou-tés et compris. Par conséquent, le bon chef de projet agile devient très efficace en aidant le groupe à réfléchir, à recenser toutes les options possibles, à faire des recommandations avant de prendre une décision collective. S’il y a conflit, cela provoque de nouvelles hypothèses et fait émerger de nouvelles informations, afin que l’équipe prenne un engagement fondé sur une meilleure décision. Le scrumMaster prépare l’agenda de la réunion de façon à ce que le partage d’information soit possible ; cet agenda est visible de tous durant la réunion par affichage mural.
Voici un exemple d’un agenda avec un objectif simple, utilisé pour conduire une réunion de planification (figure 4-9).
Dans ce cas, pour chaque thème de l’agenda, l’équipe, composée de treize personnes, devait produire l’information au travers de plusieurs ateliers de réflexion et de groupes de discussion.
Au final, pour le thème « I », c’est-à-dire sur l’engagement pris, l’équipe s’était préparée à s’engager sur une release grâce à toute l’information qu’elle avait recueillie et les décisions qu’elle avait prises.
☞
Figure 4-9
Agenda d’une réunion de planification (release)
Gestion de projet – Vers les méthodes agiles
134
En conclusion, à la fin de ces réunions, le chef de projet devrait amener l’équipe à analy-ser si la réunion a été un succès ou pas : ce qui a bien fonctionné durant la réunion et ce qu’il faudrait changer pour la prochaine réunion. Ces rétrospectives, intégrées à la réunion, aident les équipes à améliorer leur processus de planification.
Concrètement, comment se déroule une réunion de planification ? Trouve-t-on toujours un consensus entre tous les acteurs ? (suite)
Certains agendas sont plus longs que dans cet exemple afin de faire ressortir davantage d’informations dont l’équipe a besoin pour prendre ses décisions. Cela peut être des informa-tions de l’architecte sur la nouvelle architecture ; ou bien, ce peut être un représentant d’un département fonctionnel qui explique une exigence particulièrement complexe et ses critères d’acceptation. Parfois, les équipes commencent leur réunion par un rapide bilan de la dernière itération ou de la dernière release.
Sur la figure 4-10, voici représenté l’agenda d’une réunion de planification d’une itération qui a permis à une équipe de sept personnes de s’engager sur une itération de deux semaines avec un ensemble de tâches et d’estimations pour chaque story.
Il faut remarquer que l’équipe élabore prudemment son planning en faisant le point sur ce qui s’est passé dans l’itération précédente. Pour cette équipe, c’était important parce qu’elle s’interrogeait sur sa stratégie de test dans l’itération précédente et avait donc besoin de cette information pour planifier la nouvelle itération. Elle fait également le point sur sa capacité (disponibilité) et tous les changements sur venus dans le product backlog avant de définir ses tâches, ses estimations et ses inquiétudes (points « G », « H » et « I »).
Figure 4-10
Agenda d’une réunion de planification (itération)
Planifier son projet
CHAPITRE 4