Chapitre 4

Le talent et le timing

 

Dans ce chapitre :

• Structurer l’équipe de développement Scrum
• Exceller dans l’estimation du backlog
• Définir ce qui signifie « Terminé »
• Tirer parti des techniques d’estimation

 

« Le talent permet de gagner des parties. Mais c’est le travail d’équipe et l’intelligence qui permettent de gagner les championnats. »

 

Michael Jordan

 

 

 

L’équipe de développement est au cœur des projets Scrum. Le propriétaire du produit et le Scrum Master orbitent autour pour veiller à ce que l’environnement soit aussi idéal que possible afin que l’équipe de développement maximise sa productivité. Dans ce chapitre, vous allez découvrir comment l’équipe de développement doit s’organiser.

 

Une fois que vous avez défini les rôles dans l’équipe, la vision et la feuille de route, l’étape suivante consiste à commencer l’estimation du travail à fournir pour chaque exigence. L’équipe de développement commence par estimer l’effort requis pour les exigences prioritaires. Vous définissez ainsi un point de référence pour la suite. Vous faites le rapport numérateur (total du backlog du produit) / dénominateur (vitesse moyenne), ce qui vous donne une estimation du nombre de sprints nécessaires pour réaliser tout ou partie des éléments du backlog du produit. Je vais vous montrer comment produire rapidement et finement des estimations à ce niveau de généralité.

L’équipe de développement

À Hollywood, on désigne les acteurs et les chanteurs en parlant de « talents ». C’est eux qui vont sur scène et qui font le boulot. Tout le monde facilite ce processus, car lorsque le talent réussit, tout le monde réussit. Pensez donc à l’équipe de développement comme à un talent.

 

L’équipe de développement est un talent responsable de la création et du développement du produit. Elle détermine le comment et le combien. Autrement dit, elle peut déterminer comment elle va développer les exigences et combien elle peut en réaliser lors de chaque sprint. Elle est dédiée à un unique projet à la fois ; elle est polyvalente, auto-organisée et autogérée.

 

L’équipe de développement est intentionnellement limitée à sept membres, plus ou moins deux. Cette taille permet de créer un groupe autosuffisant et auto-organisé comprenant une diversité de compétences. Souvenez-vous, chaque fois que vous rajoutez un nouveau membre, le nombre de canaux de communication à établir croît géométriquement. S’il y a plus de neuf membres dans votre équipe de développement, elle ne sera plus en mesure de s’auto-organiser. Dans le modèle en cascade, ce problème est masqué à l’aide d’un chef de projet à qui il incombe de coordonner toute la communication. Scrum fait l’économie de trop de canaux de communication, ainsi que d’un chef de projet.

 

Si sept personnes, plus ou moins deux, est une taille gérable et efficicace, le facteur clé reste l’autonomie. L’équipe est-elle capable d’élaborer des exigences, d’en concevoir la réalisation, de les développer, de les tester, de les intégrer, de les documenter et de les faire approuver ? Les points de fragilité ont-ils été éliminés (autrement dit, une compétence est bien toujours partagée par au moins deux personnes) ? La taille totale est-elle bien de neuf personnes au plus ? Si les réponses à ces trois questions sont « oui », vous disposez d’une équipe de développement bien dimensionnée, polyvalente. Si un propriétaire du produit doit savoir décider et si un Scrum Master doit pouvoir influencer, le membre d’une équipe de développement doit être versatile et curieux, et être prédisposé au partage. Les premiers de la classe ne sont pas bienvenus.

La singularité d’une équipe de développement Scrum

Sur bien des points, l’équipe de développement Scrum s’oppose à une équipe classique. Dans Scrum, tout membre de l’équipe de développement va développer sa polyvalence. De plus, tous les membres de l’équipe sont impliqués dans le processus de fixation des objectifs, et ils contrôlent totalement la manière dont ils vont développer. Enfin, ils sont récompensés en tant qu’équipe.

Le psychologue d’Harvard Dan Gilbert a conduit une recherche dont les résultats ont montré que les personnes qui gagnent 5 millions de dollars par an ne sont pas plus heureuses que celles qui en gagnent 50 000.

Créer un environnement motivant

Daniel Pink écrit sur la motivation dans son excellent livre Drive : The Surprising Truth About What Motivates Us (La surprenante vérité sur ce qui nous motive, publié par Riverhead Books). Pink dénonce le mythe selon lequel il est possible de motiver les gens avec toujours plus d’argent. De manière surprenante, Pink a découvert que plus l’incitation monétaire est grande, moindres sont les résultats. L’argent est un facteur, mais seulement pour ne plus avoir ensuite à en parler.

 

En creusant le sujet, Pink a découvert trois facteurs spécifiques qui contribuent à créer un environnement propice aux meilleurs résultats, que ce soit chez vous comme à votre travail : l’autonomie, la maîtrise et l’utilité. Laissez ceux que vous encadrez déterminer comment faire leur travail, donnez-leur de l’espace et du temps pour développer leurs compétences et en acquérir de nouvelles, et donnez du sens à ce qu’ils font.

 

Le cadre de Scrum peut permettre de créer le type d’environnement évoqué par Pink. L’équipe de développement est conçue pour être auto-organisée et autonome dans son travail. La polyvalence et le développement de nouvelles compétences sont essentiels. La déclaration visionnaire et la communication directe avec le propriétaire du produit et les parties prenantes permettent à l’équipe de développement de comprendre ce qu’elle fait et pourquoi elle le fait.

 

Reportez-vous au livre de Pink ou à ses interventions sur TED pour plus d’informations sur ses recherches.

Des équipes dédiées et polyvalentes

Comme mentionné précédemment, les membres de l’équipe de développement sont dédiés à un projet à la fois. Vous souhaitez qu’ils puissent se focaliser chaque jour sur l’objectif du sprint. Que ce soit le management fonctionnel ou quelqu’un d’autre qui choisisse les membres de l’équipe, il faut chercher à ce qu’elle réunisse une diversité de compétences. Ce qui nous amène au point suivant : la polyvalence.

Les gens ne sont généralement pas polyvalents par nature ; ils le deviennent. Commencez par une équipe composée de talents divers et construisez-la pour qu’elle devienne polyvalente. Dans l’idéal, vous voudrez que chaque développeur soit capable de tout faire. Ce n’est pas toujours possible, mais vous voudrez au moins que tout développeur soit capable de faire plus d’une chose. Devenir polyvalent est un processus.

 

Quelle que soit votre entreprise ou votre organisation, une vérité demeure : les gens partent en vacances, ils tombent malades, ils prennent de nouvelles fonctions, ils changent de travail. Un jour, ils sont à vos côtés, et le suivant, ils sont ailleurs. Dans les projets traditionnels, lorsqu’un développeur clé part en vacances, c’est tout le projet qui va en congés. Il souffre de délais, soit parce qu’il faut attendre que la personne revienne, soit parce qu’il faut en recruter et en mobiliser une autre.

 

Dans Scrum, vous luttez pour que votre équipe de développement soit polyvalente. De cette manière, vous éliminez un risque de défaillance. Si un membre de l’équipe de développement attrape la grippe, quelqu’un d’autre peut prendre sa place et faire le travail. La polyvalence présente aussi d’autres intérêts, comme :

•  Permettre de multiplier les points de vue sur le développement pour trouver des solutions optimales.
•  Permettre de travailler à deux sur un même sujet afin de garantir une meilleure qualité.
•  Une des meilleures techniques pour améliorer votre compétence première est d’apprendre une compétence associée, car vous devrez alors vous frotter à d’autres manières de penser votre compétence première.
•  Permettre aux gens de travailler sur différentes choses pour préserver l’intérêt du travail.

Il existe plusieurs manières de développer la polyvalence d’une équipe ou d’une personne :

•  N’utilisez pas de titre. Encouragez les gens à jouer à égalité. Je trouve que cela stimule les développeurs juniors pour parvenir à travailler plus vite, et les compétences des seniors s’améliorent, car ils ne veulent pas se faire dépasser par des jeunes talents impatients. L’absence de titres peut aussi permettre de faire prévaloir les compétences sur la hiérarchie, encourageant le développement de compétences en général. Des statuts informels existent toujours, mais ils sont basés sur les compétences.
•  Pratiquez le travail en binôme. Souvent utilisée dans des pratiques de développement telles que eXtreme Programming, la programmation en binôme peut être utilisée par une équipe de développement pour développer n’importe quel produit. Deux développeurs travaillent sur la même fonctionnalité simultanément. Le développeur A fait le développement tactique (écrire le code, par exemple), tandis que le développeur B est libre de penser stratégiquement sur la fonctionnalité (montée en charge, extensibilité, risques, et ainsi de suite). Ils échangent leur rôle pendant la journée. Comme les développeurs collaborent étroitement, ils peuvent rapidement corriger les erreurs.
•  Utilisez le shadowing. Ici encore, deux développeurs travaillent ensemble, mais dans ce cas, un fait le travail tandis que l’autre observe et apprend.
  Le shadowing améliore aussi la qualité du produit. Souvenez-vous, la visibilité et la performance sont corrélées – une meilleure visibilité améliore les performances. Le développeur qui travaille ne voudra pas emprunter des raccourcis déshonorants devant celui qui apprend, et l’apprenti posera toutes ces « questions stupides » qui sont en fait pertinentes. Expliquer quelque chose en améliore votre connaissance, et verbaliser quelque chose utilise une autre partie de votre cerveau. Enfin, vous renforcez l’appropriation quand vous enseignez et expliquez.
  

L’effet Hawthorne (ou effet de l’observateur) est basé sur des études qui montrent que la productivité d’un travailleur augmente quand quelqu’un le regarde faire. Le nom vient de Hawthorne Works, un fournisseur d’électricité de la banlieue de Chicago où la célèbre expérience s’est déroulée.

La résolution du problème du canard en plastique ou test du canard en plastique sont des termes qui font référence à un phénomène observé souvent en ingénierie logicielle. Les développeurs doivent expliquer leur problème de programmation à haute voix et en détail à un canard en plastique. Je l’ai vu faire. La plupart du temps, avant que le développeur ait terminé d’expliquer, la réponse lui vient à l’esprit. Un phénomène similaire peut être observé lorsqu’un ami vient vous parler d’un problème. Le seul fait de verbaliser le problème stimule une partie différente du cerveau si bien que des réponses peuvent venir à l’esprit.

La structure organisationnelle d’une équipe Scrum permet de prévenir les goulots d’étranglement dans le flux du travail. Grâce à la polyvalence, à la programmation en binôme, à la colocation et à l’accès direct entre celui qui formule une exigence et celui qui la développe, les lignes de communication sont clarifiées et la diversité des compétences est assurée. Tout cela fluidifie le travail.

Auto-organisation et autogestion

Le mot-clé est ici l’appropriation. Les équipes auto-organisées et autogérées s’approprient ce qu’elles font. Dans une équipe de développement Scrum, c’est en partie ce qui garantit l’efficacité et le succès.

 

Mes clients me demandent parfois comment je peux leur garantir qu’ils obtiendront le maximum de leur équipe de développement. En réponse, je leur demande comment ils pourraient me garantir qu’une équipe de sport professionnelle donnera le maximum, sachant qu’ils perdront s’ils ne se donnent pas à fond. Rendre visibles leurs performances permet de renforcer l’implication.

La programmation en binôme

Quoique la programmation en binôme puisse de prime abord paraître onéreuse – employer deux développeurs pour faire le même travail – c’est une pratique qui, dans l’ensemble, permet de réduire les coûts. Les coûts de développement augmentent, mais ceux de l’assurance qualité chutent complètement.

 

Il est moins onéreux d’éviter d’introduire des défauts dans un système que de devoir les supprimer une fois ce système déployé, pour les raisons suivantes :

•  Si vous corrigez une erreur sur l’instant, le coût de la correction est minime.
•  Si le bogue est découvert après avoir fourni le code, il en coûte 6 fois plus pour remobiliser, trouver et corriger.
•  Si le bogue a échappé aux tests et part dans l’environnement de production, pour finalement être repéré des jours ou des semaines après, le temps de mobilisation est encore plus long, de même que le temps pour le détecter et le corriger ; le coût est approximativement 15 fois supérieur.
•  Si le même bogue est mis sur le marché et qu’il doit être corrigé par un groupe qui n’a jamais développé l’application – comme le groupe de support à la production – le coût peut être 100 fois plus élevé qu’au départ.

Pour chaque défaut, l’équipe de développement doit trouver le bogue, développer le code pour le corriger, et espérer que la correction n’engendrera pas de nouveau défaut. Souvenez-vous, chaque fois que deux défauts sont corrigés, un nouveau défaut est généré lors du processus.

La visibilité et la performance sont étroitement corrélées. Améliorez la performance en augmentant la visibilité.

 

Une technique parfois utilisée consiste à disposer de deux équipes de développement (voire plus). Synchronisez leurs sprints de sorte que les revues des sprints se déroulent en parallèle. Invitez un responsable à assister à une revue choisie au hasard durant quelques minutes et demandez-lui de poser au moins une question avant de partir. Chaque équipe de développement sait que sa performance sera observée par le responsable, et elle voudra se faire bien voir. Par le passé, elles n’ont peut-être même jamais été reconnues pour le travail qu’elles ont fourni. Maintenant, elles peuvent produire un résultat dont elles sont fières. Elles s’exposent et sont reconnues. C’est extrêmement motivant, et cela favorise l’implication.

 

L’appropriation, et donc la responsabilisation, peuvent être renforcées dans une équipe Scrum des manières suivantes :

•  L’équipe de développement est directement responsable des livrables qu’elle produit. Ce n’est pas toujours facile pour elle, car la visibilité génère une course à la performance, mais la visibilité développe aussi l’appropriation.
•  La polyvalence développe l’appropriation, car il n’y a pas de « mon travail contre le tien ». Tout est « notre travail ».
•  Comme l’équipe Scrum est tenue intégralement responsable, la performance individuelle est améliorée. Chacun gagne pour l’équipe ; tout le monde contribue au succès de chaque sprint.
•  L’équipe de développement participe activement à l’élaboration des objectifs du sprint et à la démonstration du bon fonctionnement lors de la revue du sprint.
•  L’équipe de développement a la responsabilité de produire un reporting tactique chaque jour. En moins d’une minute (voir les graphiques au Chapitre 5), l’organisation obtient un niveau de reporting tactique inégalé à ce jour.

L’équipe de développement est d’autant plus performante qu’elle est stable. Nourrissez-la de projets, et donnez-lui ce dont elle a besoin pour faire le meilleur travail possible. Chaque fois que vous devez changer des membres de votre équipe, il faut du temps pour que la situation se stabilise. Protégez votre équipe de développement pour entretenir sa dynamique.

La théorie de la dissonance cognitive décrit notre tendance à nous en remettre à des informations, des croyances et des stimuli qui sont cohérents avec nos croyances et nos comportements. Dans Scrum, si l’équipe de développement a voix au chapitre, et qu’elle a le contrôle, elle se donnera plus de mal pour atteindre les objectifs prescrits. Elle essaiera de faire en sorte que ce qu’elle délivre soit cohérent avec ce à quoi elle s’est engagée.

Colocaliser ou garder tout à portée de main

La plupart des gens ont oublié ce que c’est que de travailler au même endroit et de faire l’expérience de l’amélioration de la productivité qui en résulte. Les gens apprécient l’idée, mais ne comprennent pas toujours les principes sous-jacents. Voici quelques avantages que procure une équipe colocalisée :

•  Une communication en face à face plus rapide et plus efficace, surtout grâce aux gestes, à la tonalité de la voix, aux expressions faciales et ainsi de suite.
  La valeur ajoutée de la communication en face à face ne doit pas être sous-estimée. Albert Mehrabian, docteur et professeur émérite en psychologie de l’UCLA, a démontré les choses suivantes :
  
  • • 55 % du sens est convoyé par le langage corporel et les expressions faciales ;
  • • 38 % du sens est paralinguistique (convoyé autrement que par la parole).
  • • 7 % du sens est convoyé par les mots prononcés.
    Ces chiffres constituent à eux seuls un argument pour colocaliser votre équipe.
    
•  L’utilisation d’outils simples pour planifier et communiquer – comme le tableau blanc et les Post-it.
•  Faciliter la clarification immédiate des questions.
•  Comprendre ce sur quoi travaillent les autres membres de l’équipe.
•  Faciliter le soutien aux autres membres de l’équipe dans leurs tâches.

Pourquoi les équipes de développement adorent Scrum

Les équipes de développement adorent Scrum pour tout un tas de raisons, notamment parce qu’elles se retrouvent dans un environnement qui leur procure de l’autonomie et qui les motive. Lorsque vous permettez à des gens de contribuer, ils deviennent partie du processus et s’approprient les résultats. L’effet fait boule de neige :

•  Le succès est clairement défini par l’objectif du sprint, la définition de « terminé », et le critère de réussite de chacune des exigences.
•  Les membres participent à l’élaboration de l’objectif du sprint, ce qui renforce l’appropriation.
•  Le critère d’acceptation des exigences est clair. L’équipe comprend clairement ce qu’il faut entendre par succès.
•  C’est un environnement centré uniquement sur les résultats. Travaillez comme vous voulez, seul le résultat compte.
•  La communication directe avec le propriétaire du produit est possible.
•  Les efforts de l’équipe sont reconnus lors des revues de sprints.
•  Les processus sont améliorés rationnellement lors des rétrospectives de sprints.
•  La connaissance s’accumule lors des rétrospectives de sprints.

Lorsque vous pratiquez la colocalisation, votre propriétaire du produit et votre équipe de développement ont accès l’un à l’autre toute la journée. Toutes sortes de banalités peuvent être échangées, et il est tentant de penser que cela pourrait constituer du gaspillage. Toutefois, j’ai constaté que c’est alors que le vrai bon travail se fait. Les petites choses ne sont finalement pas si petites – ce sont des choses qui comptent, car elles font la différence. La qualité a besoin d’un retour, et le retour a besoin d’écoute. Lorsque l’écoute est bonne, de grandes choses deviennent possibles.

Parfois, sous-traiter est l’unique solution viable pour votre entreprise ou votre organisation. Dans ce cas, faites-le dans les règles de l’art. Colocalisez toute votre équipe Scrum. Votre équipe de développement a besoin d’un propriétaire du produit disponible, alors envoyez-en un, travailler directement avec l’équipe Scrum distante. Ou alors, créez un propriétaire du produit local, même s’il doit commencer à travailler comme un délégué du propriétaire du produit (voir Chapitre 2). Le gain en qualité et en efficacité dépassera de loin le coût du propriétaire du produit.

Comprendre l’estimation du backlog

Lors de l’élaboration de la feuille de route du produit (voir Chapitre 1), l’équipe de développement produit une estimation générale de la quantité de travail que le projet représente. La valeur pratique de cette estimation n’apparaît pas avant que les sprints démarrent (voir Chapitre 5), mais elle permet de disposer d’un point de référence à partir duquel calculer d’autres estimations. C’est l’équipe de développement qui réalise l’estimation, car c’est aux gens qui font le boulot qu’il revient d’estimer l’effort qu’ils devront fournir.

Les techniques d’estimation du backlog ne sont pas exigées par Scrum. Ce sont des bonnes pratiques que les praticiens de Scrum ont dégagées et trouvées utiles sur le terrain.

 

La feuille de route du produit constitue l’amorce du backlog. Ce qui figure sur votre feuille de route, c’est ce que vous devez développer. Alors comment placer tous ces éléments dans votre backlog, et sur la base de quelle estimation du volume de travail ? Quelques bonnes pratiques peuvent être utilisées selon la situation. Avant de passer chacune en revue, il est important que vous compreniez ce que vous cherchez à faire en les mobilisant.

Votre définition de « terminé »

Si vous demandez à chaque membre de l’équipe Scrum ce qu’il entend par une exigence « terminée », vous obtiendrez autant de réponses que de membres de l’équipe. Avant de démarrer un projet, l’équipe Scrum doit définir ce que « terminé » signifie. Tant que vous ne serez pas parvenu à un consensus, les estimations seront basées sur des données erronées.

 

Comme expliqué au Chapitre 3, pour chaque exigence d’un sprint, vous devez parcourir les étapes suivantes du développement :

•  Élaboration de l’exigence
•  Conception
•  Développement
•  Tests compréhensifs
•  Intégration
•  Documentation
•  Approbation

Cette définition de « terminé » doit être spécifique, précise, et bien décrire ce que cela signifie de mener des choses à leur terme pour obtenir le niveau de qualité que vous visez pour le projet. Considérez dans quel environnement le produit ou le service doit fonctionner et quel niveau d’intégration dans ce dernier peut être considéré suffisant. Par exemple, « Fonctionne dans l’environnement de développement », est probablement une mauvaise définition de « terminé ».

 

Tenez compte de ces quatre facteurs dans votre définition de « terminé » :

•  Développé : Le produit a été totalement développé par l’équipe de développement.
•  Testé : L’équipe de développement a testé totalement le produit pour s’assurer qu’il fonctionne dans l’environnement requis sans problème.
•  Intégré : Le produit a été totalement intégré dans le produit considéré comme un tout ou dans le système auquel il est lié.
•  Documenté : L’équipe de développement a créé toute la documentation requise. N’oubliez pas que cet objectif, comme tout dans le domaine agile, doit être « juste suffisant ».

Lorsque vous êtes parvenu à une définition de « terminé », écrivez-la sur un poster que vous collerez sur le mur. Faites en sorte qu’elle soit en permanence devant le nez de l’équipe de développement et du propriétaire du produit. C’est ce que j’appelle de la documentation en face à face. Pas de couverture, pas de table des matières. Je rédige la documentation dans cet esprit : comment faire passer le message avec le minimum de mots.

Timebox (littéralement, la fenêtre temporelle) est le terme utilisé pour désigner le temps alloué à un évènement ou une activité. Si votre sprint prend deux semaines, sa timebox est de deux semaines.

 

Dans votre définition de « terminé », tenez compte du développement, mais aussi de la profondeur du test et de la documentation dont vous aurez besoin. Par exemple, vous pourriez considérer les tests suivants :

•  Unitaire
•  Fonctionnel/Système
•  Performances /Charge
•  Sécurité
•  Recette utilisateur

Considérez aussi les documentations suivantes :

•  Documentations techniques
•  Documentations utilisateur
•  Documentations d’administration et de maintenance

Chacun de ces tests et chacune de ces documentations peut être plus ou moins opportun selon qu’on se place au niveau du sprint ou de la livraison – même si j’aurais tendance à dire que votre définition au niveau du sprint devrait englober tout ce qui est nécessaire pour la livraison. Vous pourriez aussi souhaiter inclure des éléments organisationnels. C’est votre choix ; tout ce qui compte, c’est d’avoir une définition claire de « terminé », élaborée par l’équipe Scrum pour tout le projet.

Une livraison correspond au moment où un ensemble de fonctionnalités est fourni par l’équipe Scrum. Cela peut survenir plusieurs fois durant un sprint, à la fin de chaque sprint, ou après une série de sprints. Ces fonctionnalités sont livrées à des utilisateurs finaux ou à des parties prenantes externes, qui vont les utiliser pour de vrai et faire un retour.

Un sprint régulier implique de terminer le développement, le test, la documentation et d’approuver les éléments figurant dans le backlog du sprint. Toutefois, avant de procéder à une livraison du produit, il peut être nécessaire de réaliser d’autres activités (comme des tests de performance ou de charge) qui sont hors de portée de l’équipe de développement durant le sprint. C’est pourquoi l’équipe Scrum procède à un sprint de livraison avant la livraison elle-même, pour procéder à ces tests supplémentaires. La clé, c’est qu’au terme de chaque sprint, les exigences doivent fonctionner et que cela doit pouvoir être démontré. Vous pouvez tester les exigences pour les ajuster durant le sprint de livraison, mais elles doivent fonctionner à la base.

Bonnes pratiques pour estimer la fin

Il est nécessaire d’estimer l’effort que le développement des exigences du backlog du produit requiert (au Chapitre 3, je traite de l’affinage du backlog du produit). Par exemple, vous pouvez passer 30 minutes sur des estimations chaque jour, à 17h00, avant que les membres de l’équipe ne quittent les lieux. De cette manière, à la fin de la semaine, vous aurez couvert le sujet, et vous serez prêt pour démarrer le sprint. Quelques équipes n’aiment pas développer le vendredi après-midi, et affinent plutôt alors le backlog. À vous de voir – seul le résultat compte.

 

Les équipes affinent généralement leurs estimations à trois niveaux. Cela fait partie du processus de décomposition des exigences pour être prêt à démarrer le prochain sprint. Vous pourriez prévoir plus de niveaux, selon votre produit. Généralement, vous affinerez dans cet ordre :

•  Feuille de route du produit
•  Planning de livraison
•  Planning de sprint

L’équipe de développement est responsable de l’estimation de l’effort requis pour réaliser toutes les exigences. Le Scrum Master peut faciliter ce processus, et le propriétaire du produit peut apporter des clarifications, mais la décision finale appartient aux développeurs qui font le boulot.

J’utilise des estimations relatives au lieu d’estimations précises (absolues), car dans nombre de situations, c’est beaucoup plus praticable. Par exemple, si je vous demande de regarder par la fenêtre et de me dire quelle hauteur fait le bâtiment voisin, quelle sera la précision de votre réponse ? Bonne – il fait 40 mètres. Quelle sera la justesse de votre réponse ? Faible. Pourquoi ? Parce que franchement, vous n’en avez aucune idée ; vous jouez aux devinettes. Mais si je vous demande de regarder deux bâtiments voisins et de m’indiquer lequel est le plus haut, je peux vous garantir que vous me donnerez la réponse juste à moins que vous n’ayez des problèmes de vue. Je mets cette précision à profit.

Les nombres de Fibonacci et les points de l’histoire

Les nombres de Fibonacci sont une excellente technique pour procéder à une estimation relative.

 

Avec Fibonacci, si quelque chose est plus grand, vous pouvez vous faire une idée de combien c’est plus grand. Les deux derniers nombres dans la séquence sont ajoutés pour créer le nombre suivant. Voici à quoi cela ressemble :

 

1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, et ainsi de suite.

 

Tandis que l’énumération progresse, la distance entre les nombres augmente. Nous utilisons cette propriété pour admettre qu’une évaluation est d’autant moins précise qu’elle concerne un gros travail.

Un point d’histoire est le nombre de Fibonacci attribué à une exigence individuelle (autrement dit, une histoire utilisateur).

 

Les exigences prioritaires sont estimées au niveau de la feuille de route du produit :

•  Dans les équipes Scrum avec lesquelles j’ai travaillé, l’équipe de développement décrétait que les exigences dont le nombre de Fibonacci estimé était compris entre 1 et 8 pouvaient être ajoutées à un sprint. Ce niveau d’affinage débouchait généralement sur une histoire utilisateur.
•  Les exigences dont les estimations sont comprises entre 13 et 34 sont celles que vous admettriez pour une livraison, mais qu’il faudrait décomposer avant de les ajouter à un sprint. À ce niveau d’affinage, je les désigne comme des épiques.
•  Les exigences comprises entre 55 et 144 sont trop importantes pour une livraison, mais peuvent être estimées au niveau de la feuille de route du produit. Ces exigences correspondent généralement à des fonctionnalités.

Qui est ce type ?

Leonardo Pisano Bigollo, aussi connu sous le nom de Fibonacci, a vécu près de Pise, en Italie, entre approximativement 1170 et 1250. Reconnu largement comme un brillant mathématicien, il a non seulement inventé la célèbre suite de Fibonacci, mais aussi importé le système numérique indo-arabe en Europe. De nos jours, c’est la représentation symbolique des nombres utilisée dans le monde.

Les exigences de plus de 144 doivent être décomposées avant que l’équipe de développement puisse produire un semblant d’estimation qui tienne la route, alors n’estimez pas au-delà de 144. Il s’agit généralement des thèmes les plus généraux.

 

Quel que soit le nombre de Fibonacci, seules les cartes prioritaires doivent être décomposées en exigences adaptées à un sprint (dont je recommande de limiter le nombre à 8). Si vous avez assigné le nombre de Fibonacci 21 à une exigence prioritaire, elle doit être décomposée en exigences plus petites avant de pouvoir être intégrée à un sprint.

 

Les tailles étant établies, je peux appliquer quelques techniques pour estimer les exigences :

•  Lorsque j’ai des centaines d’exigences, je commence par une estimation par affinité (présentée plus loin dans ce chapitre).
•  Lorsque j’ai une liste plus courte d’exigences, je commence par un planning poker.

Dans le processus d’estimation des plus petits projets, l’équipe de développement commence comme suit : je les fais asseoir avec leur pile d’exigences écrites sur des cartes de 8 x 13. Je leur demande de prendre une exigence sur laquelle ils peuvent s’entendre sur un niveau d’effort de 5. Cela crée un point de référence.

 

Je leur demande de prendre une autre carte, et en se basant sur la première qui est à 5, je leur demande quel nombre affecter à la carte. S’il est plus grand que 5, serait-ce un 8 ? Un 13 ? Un 21 ? Le processus continue jusqu’à ce que quelques tailles soient établies. Je peux alors me lancer dans le planning poker.

 

 

Le planning poker

Une technique pour estimer l’effort repose sur une variante du poker.

Figure 4-1 : Des cartes de planning poker pour estimer l’effort requis par chaque exigence.

Vous aurez besoin d’un tas de cartes de planning poker, comme représenté sur la Figure 4-1 (vous pourrez en trouver sur le site https://plantinumedge.com/store/estimation-poker-cards). Vous pouvez aussi télécharger notre application de planning poker pour iPhone et/ou Android en recherchant « Platinum Edge Estimation Poker »). Vous pouvez même constituer votre propre jeu de cartes à l’aide de fiches cartonnées et d’un marqueur.

 

Comme seule l’équipe de développement décide de l’effort requis pour développer une exigence, seuls ses membres jouent. Le Scrum Master facilite et le propriétaire du produit lit les exigences et fournit des détails à leur sujet, mais aucun des deux ne donne d’estimation. Les choses se déroulent ainsi :

1. Le propriétaire du produit lit une exigence devant l’équipe de développement.
2. L’équipe de développement pose des questions et obtient les clarifications requises.
3. Chaque membre de l’équipe de développement prend dans son tas la carte qui correspond à la difficulté qu’il attribue à l’exigence.
   L’estimation doit porter sur la définition de « terminé » ; il ne s’agit pas que de produire le code.
   Les membres ne montrent pas leur carte, car il ne faut influencer personne.
   
4. Une fois que chacun a pris une carte, les membres montrent leur carte simultanément.
   • • Si tout le monde a fait la même estimation, il n’y a pas de discussion. Affectez cette estimation à l’exigence et passez à la suivante.
   • • Si les estimations sont différentes, ceux qui ont fait l’estimation la plus grande et la plus petite doivent expliquer pourquoi. Le propriétaire du produit fournit des clarifications supplémentaires au besoin.
   • • Les membres étant désormais mieux instruits des enjeux de l’exigence, chacun procède de nouveau à une estimation en répétant les étapes 3 et 4.

Je réalise généralement jusqu’à trois tours de planning poker pour chaque exigence afin que les principales inconnues soient révélées et découvertes, puis je fais ensuite estimer sur la base d’un nombre plus réduit de possibilités.

 

Si tous les développeurs sont d’accord sur un nombre au bout de trois tours, je peux passer à l’exigence suivante. Toutefois, il n’est pas obligatoire que tous les développeurs s’accordent sur un même nombre alors. Parvenu à ce point, j’utilise une technique d’élaboration du consensus nommée les cinq doigts.

 

 

Les cinq doigts

Méthode rapide et efficiente pour parvenir à un consensus, la méthode des cinq doigts peut être utilisée seule ou en complément du planning poker. L’idée est de parvenir rapidement à une estimation sur laquelle tous les membres de l’équipe peuvent s’entendre.

Figure 4-2 : Les cinq doigts, une méthode efficiente pour parvenir à un consensus dans bien des situations.

Peut-être que certains membres de l’équipe ont produit une estimation de 5, et d’autres une estimation de 8 pour la même exigence.

 

Le Scrum Master prend la carte de l’exigence et demande, par exemple, « Jusqu’à quel point un 8 pourrait vous convenir ? ». Chaque membre de l’équipe montre alors sa main, le nombre de doigts non repliés exprimant son niveau de confiance. Si tout le monde montre trois, quatre ou cinq doigts, l’affaire est entendue.

 

Si certains développeurs ne montrent qu’un ou deux doigts, tout comme lors du planning poker, la minorité doit s’expliquer et plus d’informations doivent être fournies si nécessaire. Le jeu des cinq doigts est alors répété, jusqu’à ce que tous les membres de l’équipe montrent au moins trois doigts (au moins « Oui, ça pourrait m’aller »).

 

Quand les cinq premières exigences ont été estimées, je peux passer à la planification de la livraison ou du sprint. J’en traite au Chapitre 5.

 

 

L’estimation par affinité

Le planning poker et les cinq doigts sont des méthodes efficaces pour parvenir à un consensus sur de petits projets. Mais que faire si le backlog du produit comprend plusieurs centaines d’exigences ? Il faudrait des jours pour estimer tout cela. C’est ici que l’estimation par affinité entre en jeu.

 

Au lieu de commencer par les nombres de Fibonacci, vous commencez par un concept plus familier – les tailles de t-shirt (par exemple, XS, S, M, L et XL).

 

Avec l’estimation par affinité, vous créez autant d’emplacements que de tailles, puis vous placez chaque exigence dans un des emplacements. Le déroulement est le suivant :

1. Trouvez de petites tables pour poser les cartes.
   Marquez une table comme « À clarifier », et chacune des autres par une des catégories suivantes :
   • • Extra-small
   • • Small
   • • Medium
   • • Large
   • • Extra-large
   • • Épique (trop grand pour tenir dans un sprint, sachant qu’il faut qu’une exigence ne dépasse par Extra-large pour cela ; pour en savoir plus, voir le Chapitre 5).
   
   
2. Pour chaque taille, donnez 60 secondes à votre équipe de développement pour choisir une exigence dans la pile des exigences et la placer sur la table correspondant à la taille.
   Cela permet d’établir un repère pour chaque taille.
   
3. Chaque membre de l’équipe de développement prend une pile d’exigences.
4. Chaque membre place chaque carte sur la table dont la taille associée lui semble correspondre au repère posé sur cette dernière.
   Comme vous pouvez le constater, il y a des t-shirts de toutes tailles. Chaque « taille » correspondra finalement à un nombre de Fibonacci :
   • • Exra small vaut 1
   • • Small vaut 2
   • • Medium vaut 3
   • • Large vaut 5
   • • Extra-large vaut 8
   
   Tout ce qui est plus grand que 8 doit être décomposé avant de pouvoir entrer dans un sprint.
   Ne laissez pas les membres de l’équipe tergiverser trop longtemps sur leur pile d’exigences. Établissez une limite de temps pour travailler, par exemple, 20 minutes pour 20 cartes.
   La Figure 4-3 montre la relation entre les tailles et les nombres de Fibonacci.
   

   Figure 4-3 : L’estimation par affinité utilise des tailles de t-shirt pour les tailles des histoires utilisateur et affecte à chacune le nombre correspondant de la suite de Fibonacci.

   
5. Faites tourner les membres de l’équipe de développement de table en table jusqu’à ce qu’ils s’accordent sur les tailles de chaque exigence.
   Dans cette rotation, les membres de l’équipe passent en revue toutes les cartes sur toutes les tables et donnent leur avis uniquement sur les cartes qui ne leur semblent pas figurer sur la bonne table.
   Par exemple, si un membre de l’équipe veut déplacer une histoire utilisateur de Small à Medium, vérifiez que la personne qui l’a placée sur Small en premier lieu n’est pas en désaccord. Si la personne est en désaccord, placez la carte sur la table « À clarifier ». Ne rentrez pas maintenant dans des discussions approfondies.
   
6. Invitez le propriétaire du produit pour passer en revue tous les désaccords majeurs.
   • • Si le propriétaire du produit constate qu’une exigence qu’il aurait pensé voir sur la table S figure sur la table M, ne perdez pas votre temps à discuter. C’est à l’équipe de développement de se prononcer sur la taille des exigences.
   • • Si vous avez plus d’une table de différence entre celle sur laquelle les membres de l’équipe de développement pensent que la carte devrait être placée et celle sur laquelle le propriétaire du produit l’aurait placée, placez la carte sur la table « À clarifier ». L’équipe de développement n’a peut-être pas compris les explications de l’exigence données par le propriétaire du produit.
7. Quant aux cartes qui sont sur la table « À clarifier », rejouez-les au planning poker (comme montré plus tôt dans ce chapitre).

En peu de temps, vous serez en mesure d’évaluer l’effort de centaines d’exigences. Vous pourrez alors planifier votre première livraison et/ou premier sprint.

Vélocité

Une fois que vous avez attribué des nombres de Fibonacci à vos exigences, vous disposez de points d’histoire avec lesquels travailler.

 

Le Chapitre 5 vous montre comment planifier les livraisons et les sprints. En gros, pour planifier votre premier sprint, l’équipe Scrum détermine un petit nombre d’exigences sur lesquelles travailler parmi les exigences de 1 à 8 points d’histoire. À la fin du sprint, l’équipe Scrum additionne les points des exigences terminées. Cela peut donner 15, 25 ou 35 points d’histoire. C’est la mesure de la vélocité de l’équipe sur le premier sprint, un premier retour qui permet à l’équipe de savoir ce qu’elle serait en mesure de réaliser lors du prochain sprint.

La vélocité est la somme des points d’histoire des exigences que votre équipe a terminées dans un seul sprint. C’est une donnée post-sprint utilisée pour affiner le prochain sprint, et non un objectif à se fixer pour ce dernier.

Pour déterminer précisément la vélocité, vous aurez besoin de plus d’un sprint pour parvenir à une moyenne. La vélocité suit la loi des grands nombres – plus vous avez de points de mesure, mieux c’est. Au minimum, il vous faudra trois points pour établir une extrapolation optimiste, une autre pessimiste, et enfin une probable du nombre d’exigences qui seront réalisées durant le projet. Une fois que vous disposez de ces mesures, vous pourrez annoncer aux parties prenantes un nombre optimiste, un nombre pessimiste et un nombre probable d’exigences prioritaires du backlog du produit qui pourront être réalisées à l’occasion du projet. Ce genre de plage d’estimation permet de fournir aux parties prenantes ce qu’elles recherchent, tout en permettant de concéder à l’équipe de développement une certaine flexibilité le temps qu’elle trouve son rythme de développement.

 

Lors des premiers sprints, la vélocité de l’équipe varie grandement. Elle se stabilise tandis que l’équipe adopte un rythme de développement. Bien entendu, les changements survenant dans l’équipe ou la durée des sprints font varier la vélocité de l’équipe.

La vélocité n’est pas un objectif ; c’est un fait utilisé pour des extrapolations. Un grand nombre ne vaut pas forcément mieux qu’un petit.

 

Lorsque les points d’histoire sont utilisés, on observe que certaines équipes font des estimations pessimistes. Elles accumulent plus de points d’histoire que prévu. À l’inverse, d’autres équipes pèchent par optimisme ; elles sont moins rapides qu’on pouvait l’attendre. Elles accumulent moins de points d’histoire que prévu.

 

Si la vélocité d’une équipe optimiste est de 15 et que les estimations sont de 150 points, il faudra dix sprints pour tout produire.

 

Si la vélocité d’une équipe pessimiste est de 30 et que les estimations sont de 300 points, il leur faudra aussi dix sprints.

Optimiste ou pessimiste, cela n’est guère important, car une équipe reste généralement cohérente avec elle-même, si bien que tout s’équilibre à la fin.

 

C’est pourquoi vous évaluez toujours la vélocité d’une équipe par rapport à elle-même, et jamais par rapport à celle d’autres équipes.

En fait, ne communiquez la vélocité d’une équipe à personne. Considérez sa mesure comme contribuant à un système d’extrapolation, et non à un système de performance.

 

Lorsque vous disposez d’une méthode pour estimer l’effort requis pour réaliser chaque exigence, et que vous disposez d’une mesure de la vélocité moyenne de l’équipe de développement, vous pouvez prédire précisément la quantité de produits qui pourront être créés dans des contraintes de temps et de financement déterminées. Vous domestiquez vos variables.

Les points d’histoire et la vélocité en temps réel

Voici ce que pourrait donner un exemple de points d’histoire et de vélocité dans le monde réel.

 

Supposons les choses suivantes :

•  Ce qui reste dans le backlog du produit s’élève à 500 points d’histoire.
•  La durée de votre sprint (timebox) est d’une semaine, du lundi au vendredi.
•  La vélocité de l’équipe de développement est en moyenne de 20 points d’histoire par sprint.
•  Nous sommes lundi 5 janvier 2015.
•  Votre équipe de développement coûte 100 000 € par membre et par an, et vous avez sept membres, ce qui veut dire un coût de 700 000 €, soir 13 462 € par mois.

En quelques minutes, vous pouvez produire une estimation solide de ce qu’il en coûtera de produire le projet. Avec ces données, votre projet prendra 25 sprints, et il vous faudra donc 25 semaines pour le terminer. Le coût sera de 336 550 €, et vous aurez terminé le vendredi 26 juin 2015.

 

Qu’arrive-t-il si votre équipe de développement fait monter sa vélocité à 25 points d’histoire par sprint au lieu de 20 ? Reprenez votre calculatrice. Le coût va chuter à 269 240 € (vous économisez 67 310 €), et vous livrerez le vendredi 22 mai 2015. C’est l’avantage de disposer d’un Scrum Master qui peut lever les obstacles et lutter contre l’inertie organisationnelle qui pourrait s’opposer à l’équipe.