Scrum et XP depuis les Tranchées

En plus du backlog de produit habituel, le directeur de produit définit une liste des seuils d'acceptation qui est une classification simple de ce que signifient les niveaux d'importance utilisés dans le backlog de produit par rapport aux aspects contractuels.

Voici un exemple de règles de seuils d'acceptation :

• Tous les éléments avec une importance >= 100 doivent être inclus dans la version 1.0, ou sinon nous serions condamnés à payer des pénalités de retard.
• Tous les éléments avec une importance de 50-99 devraient être inclus dans la version 1.0, mais nous devrions être en mesure de nous en sortir en les incluant dans une release disponible à court terme.
• Les éléments avec une importance de 25-49 sont requis mais peuvent être faits dans une version future 1.1.
• Les éléments avec une importance <25 sont spéculations et pourraient ne jamais être requis.

Et voici un exemple de backlog de produit, avec un code couleur basé sur les règles ci-dessus.

Rouge = doit être inclus dans la version 1.0 (banane - poire)
Jaune = devrait être inclus dans la version 1.0 (raisin - oignon)
Vert = peut être fait plus tard (pamplemousse - pêche)

Donc si nous livrons tous les éléments de banane à oignon à temps nous sommes sains et saufs. Si le temps se met à manquer nous devrions nous en sortir en écartant raisin, cacahuète, beignet ou oignon. Tout ce qui est en dessous d'oignon est du bonus.

Afin de faire la planification de releases, le directeur de produit a besoin d'estimations, au moins pour toutes les histoires qui sont incluses dans le contrat. Tout comme la planification de sprint, il s'agit d'un effort mutuel entre le directeur de produit et l'équipe - l'équipe estime, le directeur de produit décrit les éléments et répond aux questions.

Une estimation en temps a de la valeur si elle se révèle être proche de la réalité, moins de valeur si elle se révèle être à coté, disons, de 30%, et complètement sans valeur si elle n'a aucune relation avec la réalité.

Voici mon interprétation de la valeur d'une estimation en temps en relation avec ceux qui la calculent et combien de temps ils y passent dessus.

Tout cela est juste une façon verbeuse de dire :

• Laissez l'équipe faire les estimations.
• Ne leur faites pas passer trop de temps dessus.
• Assurez-vous qu'ils comprennent que les estimations en temps sont des estimations approximatives, non des engagements.

Habituellement le directeur de produit rassemble toute l'équipe dans une pièce, fournit quelques boissons, et lui explique que le but de cette réunion est d'estimer en temps les 20 premières (ou autre) histoires du backlog de produit. Il aborde chaque histoire une fois, puis il laisse l'équipe retourner travailler. Le directeur de produit reste dans la pièce pour répondre aux questions et clarifier le périmètre de chaque histoire si nécessaire. Juste comme pendant la planification du sprint, le champ « comment démontrer » est un moyen très utile pour réduire le risque de malentendus.

Cette réunion doit être strictement bornée en temps, sans quoi les équipes auraient tendance à passer trop de temps à estimer trop peu d'histoires. Si le directeur de produit veut passer plus temps sur cela, il programme simplement une autre réunion plus tard. L'équipe doit s'assurer que l'impact de ces réunions sur leurs sprints en cours est clairement visible pour le directeur produit, de telle sorte qu'il comprenne que leurs estimations en temps ne sont pas gratis.

Voici un exemple qui montre à quoi les estimations en temps pourraient ressembler (en points d'histoire) :

OK, alors maintenant nous avons des sortes d'estimations brutes pour les histoires les plus importantes. La prochaine étape est d'estimer notre vélocité moyenne par sprint.

Cela veut dire que nous avons besoin de définir notre facteur de focalisation. Voir page XXX « Comment l'équipe choisit les histoires à inclure dans le sprint ? ».

Le facteur de focalisation revient fondamentalement à se demander « quelle est la part du temps passé par l'équipe consacrée aux histoires adoptées en cours ? ». Ce n'est jamais 100% car les équipes perdent du temps en faisant des choses non prévues, en changeant de contexte, en aidant les autres équipes, en lisant leurs emails, en réparant les problèmes d'ordinateur, en discutant politique dans la cuisine, etc.

Disons que nous déterminons un facteur de focalisation de 50% pour l'équipe (très bas, normalement on tourne autour de 70%). Et disons que notre sprint dure 3 semaines (15 jours) et que la taille de l'équipe et 6.

Chaque sprint fait alors 90 jours*homme, mais produira seulement 45 jours*homme d'histoires (à cause du facteur de focalisation de 50%).

Notre vélocité estimée est donc de 45 points d'histoire.

Si chaque histoire avait une estimation en temps de 5 jours (ce qui n'est pas le cas) alors cette équipe avalerait approximativement 9 histoires par sprint.

Maintenant que nous avons des estimations en temps et une vélocité (45) nous pouvons facilement découper le backlog de produit en plusieurs sprints :

Chaque sprint contient autant d'histoires que possible dans la limite de la vélocité estimée de 45.

Maintenant on peut voir que nous aurons probablement besoin de 3 sprints pour finir tous les « doit être inclus » et les « devrait être inclus ».

3 sprints = 9 semaines calendaires = 2 mois calendaires. Maintenant est-ce vraiment la date de livraison promise au client ? Cela dépend entièrement de la nature du contrat ; à quel point le périmètre est-il fixé, etc. Généralement nous ajoutons une réserve significative pour nous protéger contre les mauvaises estimations en temps, les problèmes imprévus, les fonctionnalités inattendues, etc. Donc dans ce cas nous pouvons nous mettre d'accord sur une livraison dans 3 mois, ce qui nous donne 1 mois de « réserve ».

Ce qui est bien c'est que nous pouvons démontrer quelque chose d'utilisable au client toutes les 3 semaines et l'inviter à modifier ses exigences au fur à mesure que nous avançons (cela dépend bien sûr du type de contrat).

La réalité ne s'adaptera pas à un plan, c'est plutôt le cas inverse qui se passe.

Après chaque sprint, nous regardons la vélocité effective pour ce sprint. Si la vélocité effective était très différente de la vélocité estimée, nous revoyons la vélocité estimée pour les futurs sprints et mettons à jour le plan de release. Si cela devait nous mettre en situation difficile, le directeur de produit pourrait commencer soit à négocier avec le client, soit à voir comment il peut réduire le périmètre sans rompre le contrat. Ou peut-être lui et l'équipe trouvent le moyen d'augmenter la vélocité ou le facteur de focalisation en supprimant des obstacles sérieux qui ont été identifiés durant le sprint.

Le directeur de produit pourrait appeler le client et dire « Bonjour, nous sommes un peu en retard mais je crois que nous pouvons livrer à temps si nous enlevons la fonctionnalité «Pacman embarqué» qui prend beaucoup de temps à développer. Nous pourrons l'inclure dans une version qui sortira 3 semaines après la première release si vous le souhaitez ».

Ce n'est peut-être pas une bonne nouvelle pour le client, mais au moins nous sommes honnêtes et nous laissons le choix au client tôt dans le projet - doit-on livrer les choses les plus importantes à temps ou doit-on tout livrer après la date prévue ? Ce n'est pas un choix si difficile en général :o)