Planifier son projet
CHAPITRE 4
145
Ce qu’il faut retenir
valeur à nos clients ? Nous acceptons ce niveau de détail jusqu’à ce que nous abordions la
planification d’une release du produit ».
Lorsque l’équipe aborde la planification d’une release, les items qui ont la plus haute priorité
dans le product backlog doivent être suffisamment détaillés pour permettre à l’équipe de dire,
soit « Oui, nous sommes prêts à nous engager à livrer toutes ces fonctionnalités dans cette
version du produit », soit « Non, compte tenu de notre niveau de connaissance à ce jour, nous
ne pouvons nous engager à livrer ces fonctionnalités dans cette version du produit ». Ainsi, à
ce stade d’avancement, la granularité des items doit être suffisante pour estimer leur valeur par
rapport au risque et au coût de leur implémentation. Généralement, les équipes font ce travail
en sélectionnant la fonctionnalité et en la découpant en plusieurs exigences plus petites appelées les stories. On attribue, alors, une taille relative à chaque story (cette story est deux fois
plus complexe que celle-ci) et non une taille absolue (cette story nécessite cinq développeurs,
quatre heures par jour durant les trente-cinq prochains jours, une autre deux développeurs,
huit heures par jour durant dix-neuf jours).
Une fois que les items prioritaires du product backlog sont découpés en stories, les développeurs, les testeurs et le client commencent à fournir davantage de détail pour permettre la
planification de l’itération. Dans certains cas, l’aide d’un architecte ou d’un analyste métier est
nécessaire pour amener un item à ce niveau de détail. Cela peut prendre la forme d’un jeu de
cas de tests ou de tests aux limites, un scénario de use case ou une simple liste des critères
d’évaluation. L’équipe est toujours invitée à éliminer le gaspillage en ne fournissant que le
détail suffisant pour que l’équipe dise si elle peut s’engager ou pas à livrer cette stor y dans
l’itération.
Le niveau de granularité le plus détaillé d’un PBI émerge au travers du travail quotidien au
cours d’une itération. Chaque jour, le développeur, le testeur et le client travaillent pour se
mettre d’accord sur les conditions de la recette finale de l’item. Cela détermine ce que doit être
le niveau de détail final nécessaire.
Les architectes, les analystes métier, les ergonomes, l’équipe support et les rédacteurs techniques doivent aussi contribuer à obtenir cette vision détaillée de l’item. Finalement, l’item est
dans sa forme de spécification la plus détaillée lorsqu’il a été accepté : le code contient le
détail complet, et toutes les spécifications contiennent le détail pour supporter le code.
Planifier est un véritable « casse-tête » pour un chef de projet, surtout s’il s’efforce de tout
vouloir planifier, très tôt dans le cycle de vie du projet.
Il s’agit tout d’abord de définir une enveloppe globale ; plusieurs techniques de macro-estimations, certaines empiriques, d’autres plus « scientifiques » permettent de déterminer cette
enveloppe. Une fois l’enveloppe calculée, l’exploitation qui en sera faite dépendra de la stratégie de planification retenue.
Une approche prédictive consiste à vouloir définir un planning basé sur des besoins que l’on
aura préalablement figés, puis sur les tâches à réaliser pour satisfaire ces besoins. Cette
approche est supportée par des outils de planification qui permettent d’élaborer des structures
de découpage, des diagrammes de Gantt, de repérer le chemin critique sur les diagrammes de
GestProjInform Livre Page 145 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 4
145
Ce qu’il faut retenir
valeur à nos clients ? Nous acceptons ce niveau de détail jusqu’à ce que nous abordions la
planification d’une release du produit ».
Lorsque l’équipe aborde la planification d’une release, les items qui ont la plus haute priorité
dans le product backlog doivent être suffisamment détaillés pour permettre à l’équipe de dire,
soit « Oui, nous sommes prêts à nous engager à livrer toutes ces fonctionnalités dans cette
version du produit », soit « Non, compte tenu de notre niveau de connaissance à ce jour, nous
ne pouvons nous engager à livrer ces fonctionnalités dans cette version du produit ». Ainsi, à
ce stade d’avancement, la granularité des items doit être suffisante pour estimer leur valeur par
rapport au risque et au coût de leur implémentation. Généralement, les équipes font ce travail
en sélectionnant la fonctionnalité et en la découpant en plusieurs exigences plus petites appelées les stories. On attribue, alors, une taille relative à chaque story (cette story est deux fois
plus complexe que celle-ci) et non une taille absolue (cette story nécessite cinq développeurs,
quatre heures par jour durant les trente-cinq prochains jours, une autre deux développeurs,
huit heures par jour durant dix-neuf jours).
Une fois que les items prioritaires du product backlog sont découpés en stories, les développeurs, les testeurs et le client commencent à fournir davantage de détail pour permettre la
planification de l’itération. Dans certains cas, l’aide d’un architecte ou d’un analyste métier est
nécessaire pour amener un item à ce niveau de détail. Cela peut prendre la forme d’un jeu de
cas de tests ou de tests aux limites, un scénario de use case ou une simple liste des critères
d’évaluation. L’équipe est toujours invitée à éliminer le gaspillage en ne fournissant que le
détail suffisant pour que l’équipe dise si elle peut s’engager ou pas à livrer cette stor y dans
l’itération.
Le niveau de granularité le plus détaillé d’un PBI émerge au travers du travail quotidien au
cours d’une itération. Chaque jour, le développeur, le testeur et le client travaillent pour se
mettre d’accord sur les conditions de la recette finale de l’item. Cela détermine ce que doit être
le niveau de détail final nécessaire.
Les architectes, les analystes métier, les ergonomes, l’équipe support et les rédacteurs techniques doivent aussi contribuer à obtenir cette vision détaillée de l’item. Finalement, l’item est
dans sa forme de spécification la plus détaillée lorsqu’il a été accepté : le code contient le
détail complet, et toutes les spécifications contiennent le détail pour supporter le code.
Planifier est un véritable « casse-tête » pour un chef de projet, surtout s’il s’efforce de tout
vouloir planifier, très tôt dans le cycle de vie du projet.
Il s’agit tout d’abord de définir une enveloppe globale ; plusieurs techniques de macro-estimations, certaines empiriques, d’autres plus « scientifiques » permettent de déterminer cette
enveloppe. Une fois l’enveloppe calculée, l’exploitation qui en sera faite dépendra de la stratégie de planification retenue.
Une approche prédictive consiste à vouloir définir un planning basé sur des besoins que l’on
aura préalablement figés, puis sur les tâches à réaliser pour satisfaire ces besoins. Cette
approche est supportée par des outils de planification qui permettent d’élaborer des structures
de découpage, des diagrammes de Gantt, de repérer le chemin critique sur les diagrammes de
GestProjInform Livre Page 145 Vendredi, 3. avril 2009 12:07 12