Perplexité, complexité, vélo­cité … une autre vue

J’ai lu « Perplexité, complexité, vélo­cité » sur le blog d’OCTO. L’ar­ticle est bien tourné et on sort complè­te­ment convaincu. Mon problème c’est que quelques heures après j’ai commencé à avoir des doutes et plus les jours avancent plus mes doutes se trans­forment en avis contraire. Je vous encou­rage à lire d’abord le billet d’OCTO, le mien n’aura de sens qu’en réponse.

À quoi sert la vélo­cité ?

À quoi sert la vélo­cité ?

1.     Esti­mer ce qui sera réalisé ou non dans le sprint

2.     Mesu­rer la produc­ti­vité de l’équipe

3.     Mesu­rer le réalisé pour le projet, le produit

Ma diver­gence avec l’ar­ticle source vient d’un constat simple : Nous n’uti­li­sons pas cet indi­ca­teur dans le même objec­tif. Lui l’uti­lise pour mesu­rer la produc­ti­vité, moi pour amélio­rer les esti­ma­tions.

Amélio­rer les esti­ma­tions

Amélio­rer les esti­ma­tions c’est faire en sorte de mieux évaluer ce qui sera livré dans chaque sprint et aider à la prio­ri­sa­tion. Bref, gérer le projet.

Pour amélio­rer nos esti­ma­tions on tente de se baser sur les tâches simi­laires précé­dentes et on en réuti­lise l’es­ti­ma­tion sans tenir compte de la produc­ti­vité de l’équipe. On utilise pour cela une unité virtuelle qui nous détache des jours/hommes : le point. Réali­ser une esti­ma­tion ainsi est de plus en plus simple, rapide et fiable.

Pour prendre en compte les évolu­tions de produc­ti­vité (équipe plus effi­cace ou dette tech­nique gran­dis­sante) c’est le nombre de points réali­sable dans un sprint qu’on fait varier. Afin de ne pas sortir le dé pour évaluer ce nombre de points, on se base sur ce qui a été réalisé dans les quelques sprints passés et on tente de rester sur une courbe la plus stable possible.

Nos réfé­rences d’es­ti­ma­tion sont stables, nos esti­ma­tions se fiabi­lisent avec le temps. Le nombre magique de points qu’on peut mettre dans un sprint, c’est pour moi ce qu’est la vélo­cité de l’équipe.

En prenant en compte la tech­nique

Si on calcule en points et pas en heures ou en jours, ce n’est pas parce qu’on compte en complexité fonc­tionne, c’est pour s’au­to­ri­ser à faire varier la somme totale plutôt que chaque esti­ma­tion.

Il ne faut pas perdre de vue que notre objec­tif reste bien d’éva­luer une charge de déve­lop­pe­ment. Il faut donc tenir compte dans nos esti­ma­tions de tout ce qui est néces­saire à évaluer le temps de déve­lop­pe­ment et livrer la fonc­tion­na­lité : Ça va des besoins fonc­tion­nels à la complexité tech­nique en passant par les contraintes orga­ni­sa­tion­nelles spéci­fiques.

Si je ne prends en compte que la complexité fonc­tion­nelle, l’es­ti­ma­tion n’aura plus aucun lien avec le temps de déve­lop­pe­ment. Pour savoir ce qui tient ou pas dans le sprint, on en vien­dra à faire une esti­ma­tion globale, au jugé, sans réfé­rences simi­laires : tout l’in­verse de l’objec­tif.

Outil privé versus indi­ca­teur public

À mon humble avis l’er­reur de l’ar­ticle n’est pas seule­ment de faire de la vélo­cité une mesure de produc­ti­vité, c’est en plus de l’avoir commu­niquée à l’ex­té­rieur de l’équipe.

Du coup, forcé­ment, la vélo­cité devient un enjeu poli­tique. L’équipe, son mana­ger, son coach commencent à avoir inté­rêt à amélio­rer l’in­di­ca­teur au lieu de se concen­trer sur ce qui devrait être leur seul objec­tif : appor­ter de la valeur au produit.

Que la vélo­cité augmente, dimi­nue, c’est quelque chose propre à l’équipe. S’il faut un indi­ca­teur de produc­ti­vité et de pertur­ba­tion, il faut publier la seule chose impor­tante : la progres­sion de la valeur du produit (si ça ressemble au para­graphe précé­dent, ce n’est pas une coïn­ci­dence).

Cette vélo­cité doit être prise pour ce qu’elle est : un outil d’es­ti­ma­tion, de plani­fi­ca­tion et de prio­ri­sa­tion. Comme tous les outils, il a voca­tion à être utilisé en interne, par l’équipe, et nulle part ailleurs.

Et la complexité fonc­tion­nelle ?

Mon second problème est là : Selon moi la complexité fonc­tion­nelle n’in­dique rien de valable. Ce n’est pas une mesure de ce que coûte la fonc­tion­na­lité, ce n’est pas une mesure de ce qu’ap­porte la fonc­tion­na­lité, et inci­dem­ment ce n’est pas une mesure de l’im­pli­ca­tion ou de la produc­ti­vité de l’équipe.

Tout au plus la complexité fonc­tion­nelle permet de faire une première esti­ma­tion des histoires utili­sa­teurs qui ne sont pas prévues pour tout de suite ou dont on ne connaît pas la complexité tech­nique.

Rejoindre la conversation

11 commentaires

  1. Merci pour cet billet qui alimente le vaste sujet de la complexité. Je comprends l’intérêt de parler de complexité par rapport aux fonctionnalités plutôt que l’effort (qui, au final, est toujours de 100%…), c’est plus factuel et centré sur la valeur. Mais est ce que ce n’est pas plutot la valeur métier qui est là pour ça ?

    Il y a pire : quand les équipes sont payés au point-story accompli.

    Personnellement, les raisons qui me font encore utiliser la vélocité sont de faire monter en compétences les équipes sur les estimations et de donner une limite afin de rester un minimum KISS.

  2. Bonjour,

    Je suis étonné de voir le terme productivité et vélocité mélangé. La productivité est le rapport entre la quantité (vélocité) de travail réalisé et le nombre d’heure nécessaires pour le réaliser.  La productivité n’est tout simplement pas par définition une vélocité. 

    A proposer « d’améliorer les estimations »,  On estime pas une vélocité, c’est une quantité de travail réalisé. elle se mesure en sortie du sprint.  Ce que l’on améliore c’est le travail d’estimation en story point des user story. Une meilleur estimation n’apporte pas en revanche une meilleur vélocité. 

    Le total des story point pour un sprint indique une vélocité moyenne d’une équipe  Une moyenne indique qu’il est probable qu’elle fera cette vélocité lors d’un sprint, nous ne pouvons pas dire qu’elle fera cette vélocité lors de ce sprint. 

    @2168f37bb0b5cd95a32f9e6094bc053c:disqus  : « quand les équipes sont payés au point-story accompli. » Cela se nomme du travail à la chaine.  Cela existe vraiment ?

    Bonne journée
    Yannick 

  3. C’est juste. L’amalgame peut sembler étonnant et pourtant c’est une réalité : pour le client, et certains managers, la vélocité est un indicateur de productivité. Quelques phrases familières : « quelle équipe a la meilleure vélocité? »; »votre vélocité ne décolle pas »; « LE problème du projet c’est la vélocité qui n’augmente pas ».

    Sur les équipes payés au point accompli, c’est indirect évidemment. Nous sommes en France heureusement ! Je parlais plus des projets agiles externalisés. La facturation s’appuyait sur la vélocité, d’où l’accent dessus.

  4. @Yannick: Pourtant c’est bien le problème de base. Trop facilement les gens concernés mais non impliqués regardent les indicateurs qu’ils ont à leur disposition, et tentent de les faire coller à leur vision. « vélocité » implique « est-ce qu’ils vont vite » dans la tête, et donc productivité.

    Je lis ta réponse sur les story point mais elle ne me convient pas tout à fait. En particulier :
    – Que mets tu dans les story point ? complexité fonctionnelle ? complexité technique ? tâches techniques externes mais en dépendances ?
    – Si la vélocité n’est pas prévisible pour un sprint particulier, à quoi sert-elle pour toi ? comment te sers tu de l’indicateur et pour quoi faire ?

  5. Des SSII ou des client qui sont dans une relation de défiance et qui prennent la vélocité comme base (ou qui souhaitent le faire) j’en ai vu, c’est effectivement malheureusement une réalité. Malheureusement aussi je les comprends, faire autrement demande une relation de confiance, qu’ils ne sont pas entrainés à avoir, et une prise de risque vis à vis de leur direction qu’ils ne sont pas encouragés à prendre. En général il faudrait leur dire « alors ne partez pas en agile, ça ne correspond pas à vos besoins », mais sur leur fiche d’objectif il y a marqué « passez à l’agile, c’est mieux ».

    Merci aussi d’avoir pointé le « quelle équipe a le meilleure vélocité ». C’est presque le pire ça. On cumule tous les défauts.

  6. « Que mets tu dans les story point ? complexité fonctionnelle ? complexité technique ? tâches techniques externes mais en dépendances »

    @Eric:disqus 
    Les story point sont une mesure d’effort pour réaliser une US. Qu’elles soient techniques ou fonctionnelles. C’est la base de la planification Scrum. 
    La vélocité d’un sprint d’une c’est l’addition des points d’US terminée dans un sprint. 
    La vélocité d’une équipe, c’est la moyenne des vélocités sur un projet, soit total de la vélocité divisé par le nombre de sprints. 

    Voici un exemple :

    J’ai un tas de gravier, je dois le déplacer ce tas, c’est mon projet. 

    J’estime à 20 tours de brouette pour déplacer ce tas (planning poker avec mon équipe).  Un tour de brouette c’est 2 points . Donc 40 points pour déplacer le tout. À cela s’ajoutent 20 points pour un aller-retour pour chercher ma brouette. 

    Habituellement pour un sprint de 4 heures, mon équipe à une vélocité de 20 points. Il me faudra 3 sprints pour réaliser l’ensemble du projet. Mon planning de release (projet) est de 3 sprints (je ne prends pas de mou :).  Je donne le prix au client et le temps. 

    Super, j’ai respecté mes engagements sur ce projet, ma vélocité moyenne par sprint est est toujours de 20 points. 

    Un deuxième client me demande le même service, j’estime facile à 3 sprints. Mince, un accident sur la route, mon US « je suis un pépiniériste, je veux aller chercher ma brouette à la maison » qui était de 20 points ne pourra pas être pris dans mon sprint, elle n’est pas terminée… J’ai fait 0 point sur ce sprint. Je recommence cette US dans un autre sprint, je l’ai terminé. 
    Il me faut 1 sprint de plus pour terminer ce projet. Sur ce deuxième projet, ma vélocité moyenne est maintenant de 15 points. 60 points divisé par 4 sprints. 

    Un troisième client arrive, « – c’est combien que ça coûte ? »

    Quelle vélocité je prends : 
    – La plus haute, mais avec le risque de mécontenter le client si j’ai un problème, mais aussi de gagner plus d’argent ?
    – La plus basse, mais avec le risque de perdre de l’argent (1 sprint gaspillé) si je finis plus tôt ?
    – La moyenne, je gagne un peu moins d’argent, mais je perds un peu moins d’argent.  

    Voilà l’objectif de la vélocité. C’est une mesure que l’on suit tout au long des sprints.  Elle permet de connaitre la vélocité d’une équipe sur un projet pour faire le planning de release d’un projet. Durant le projet, dlle doit être communiquée vers l’extérieur pour agir en cas de baisse importante ou de hausse. 

    Cela nous permet d’anticiper plus rapidement pour agir sur le projet (soyons Agile), ajouter une nouvelle personne pour finir dans les temps, prévenir en avance le  client que nous ne finirons pas dans les temps, donc peut être de revoir les priorités ou de supprimer des fonctionnalités, etc. 

    Garder constante la vélocité sprint après sprint est pour ma part impossible. Tout simplement parce que des obstacles arrivent, des anomalies tout au long du développement.  Il y avait un accident sur la route…

    Bonne journée
    Yannick

  7. Je comprends bien Yannick, mais finalement tu ne réponds pas à mes interrogations.

    Plus exactement si j’en crois ta réponse : « Elle permet de connaitre la vélocité d’une équipe sur un projet pour faire le planning de release d’un projet ». La Vélocité qui sert à connaitre lavélocité, c’est déjà un peu le serpent qui se mord la queue.

    Estimer le planning de release c’est effectivement un objectif bon mais si comme tu dis plus haut tu ne peux pas prévoir la vélocité du sprint à venir, je ne vois pas bien la valeur de ton planning. Si c’est juste garder « oh, en gros on va faire X, ou 20% de plus ou de moins », franchement le dé convient aussi bien.

    Si toute ton utilisation c’est d’avoir une grosse fourchette et donner la fourchette haute à ton client, AMHA tu perds tout le bénéfice de l’exercice. On savait déjà aussi le faire en comptant en jour/homme ça.

    Effectivement, avoir une constante ne fonctionne que quand il n’y a pas d’incident. Mais il y a des incidents prévisibles et d’autres non. Normalement les imprévisibles sont soit exceptionnels, soit réguliers et dans ce cas ils sont déjà pris en compte dans la vélocité et ne l’impacteront pas. L’idée c’est d’avoir une vélocité continue (pas forcément constante) hors incident exceptionnel, parce que justement ça permet d’avoir un planning plus fiable.

    Mais c’est bien pour ça que je te posais la question de ce que tu prends en compte. En me répondant « des story points » tu ne me réponds pas vraiment. Tu utilises quoi pour compter tes points ?

    Par exemple, tu fais des trajets Paris – Marseille dans tes sprints. Complexité fonctionnelle : toujours la même, le trajet est connu, la voiture reste la même. Complexité technique : tu sais que le vendredi il y a plus de monde et ça met plus longtemps, et qu’en plus depuis 3 mois il y a des travaux vers Lyon.

    Tu utilises uniquement la complexité fonctionnelle pour calculer le nombre de points ? alors tu garderas la même estimation quel que soit le cas, et tu vas te planter dans ton planning, le pire c’est que c’est prévisible. Bref, tu as loupé ton objectif.

    C’est ce point qui est à l’origine de mon billet. Dire qu’on compte en points ne change malheureusement rien, tant que tu ne me dis pas sur quoi tu bases tes points, ce que tu comptes ou pas dans ton estimation.

  8. p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Georgia}
    p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Georgia; min-height: 15.0px}

    Je pense que les questions que tu te poses tu peux les trouver dans les ouvrages classiques de l’Agilité, comme l’ouvrage de Mike la su planification agile. Je ne fais qu’appliquer la méthode rien de plus, rien de moins. 

    Un plan de release, c’est un roadmap de livraison.  Par exemple dans 2 mois, je livre telles fonctionnalités pour que les Admin Sys. puisse réaliser des tests de déploiement ou avoir un premier retour utilisateur avec la méthode de Kano.  Si je me réfère au standish group, les projets classiques finisse à 30 % dans les temps, nous passons à 42 % avec Agile. Ce n’est pas du dé, mais une pratique maîtrisé avec le temps et l’expérience.  Nous savons tous par expérience que personne ne peut en début de projet savoir si nous finirons dans les temps. 

    Concernant la technique pour calculer les estimations d’une user story en story point, nous prenons des users story de références qui ont été jugées par l’équipe fiable en terme d’estimation et simple à comprendre même pour un débutant. 

    Dans nos équipes nous avons trois US de référence.  Je vais me répéter une dernière fois, mais on mesure un effort. Cela sous-entend que les US sont bien INVEST et qu’une équipe est passée avant pour réaliser une première estimation, ce que nous faisons avec une réunion d’estimation 1 fois par semaine. Je détaillerais rapidement cette réunion sur mon blog. 

    Les plannings de sprint sont réalisés de plus en plus souvent en magic estimation, nos équipes possèdent bien les estimations. Notre concentration se porte alors sur 1 ou 2 story qui peuvent sembler complexes. Les équipes ne se posent pas la question de complexité sur 80% des US, les dernières sont dépouillées pour comprendre comment les faire. Une fois la solution trouvée on estime.  Il y a donc plus de complexité, mais simplement la mesure d’un effort pour la réaliser. 

    Les équipes réalisent de très bonnes estimations au bout de trois de sprint, les vélocités sont calculées sur l’ensemble du projet. Nous regardons la vélocité à la fin des sprints pour en discuter en rétro.

    Je suis actuellement la vélocité de 7 équipes Scrum simultanément, elle varie parfois, elle monte et parfois descendes… Que ce soit pour des congés de maladie, des retours de vacances, un build qui coince sur un Hudson, une montée de version qui a plantée, les maquettes qui ne sont pas arrivées en temps, etc. Mercredi nous avons du restaurer un SVN, la machine a crashé… 

    La vélocité ne se mord pas la queue, pour le premier projet la question se pose, si aucune vélocité est connue. Quelle est la vélocité de l’équipe et comment je fais mon planning de release ?

     C’est très simple, durant le sprint 0 nous faisons des réunions d’estimation du backlog et nous préparons avec l’équipe projet un premier planning sur 2 sprints.   Nous obtenons une première estimation qui s’ajuste au bout de trois sprints (retour d’expérience dans la plupart des SM).  Si nous avons un BP de 300 points en début de projet et que nous estimons une vélocité de 50 points par sprint (résultat du planning de sprint). Nous avons 6 sprints. 

    Tout au long du projet, nous restimons le BP, plus le projet avance plus notre connaissance de « comment faire cela » est meilleure.  Il n’y a pas de jeu de dé, aucune méthode ne propose cela à part Scrum. Je n’ai jamais vu un projet « classique » on l’on revient chaque semaine sur les estimations des fonctionnalités pour les ajuster. 

    Nous savons qu’aucun projet ne peut être estimé de manière juste, il suffit d’entendre parler des retards des sociétés d’avionique ou autre.  La méthode Agile propose de revenir sans arrêt sur nos estimations pour les ajuster et prendre les bonnes décisions. 

    Pour terminer et répondre à l’ensemble des questions. Utiliser des story points c’est avant tout pour utiliser une technique simple et compréhensible par tous que je sois ébéniste ou développeurs.  

     Que ce passe t’il si je fais des estimations en heures, les temps d’estimations sont doublés.  Je le test sur chaque nouvel arrivant dans les projets Scrum. En 2010, j’ai fait passer environ 200 personnes sur Scrum en les accompagnant sur des périodes 6 mois à 1 an.  Scrum ça marche. Mais ne garantis pas de faire tout ce que le client veut dans les temps impartis. 

    Si cela peut aider, certaines équipes Agile utilise de l’Ideal Days quand les équipes ne sont pas encore familiarisés avec Agile.  Mais cela ne fait que repousser l’apprentissage. 

    Les ST c’est déroutant la première fois, comme à peu près tout…

  9. Je crois qu’on pars sur une incompréhension. Je ne challenge pas scrum ou l’agilité. Pas besoin de me ressortir les bouquins pour tenter de me convaincre, ce n’est pas du tout la question. Je pratique depuis pas mal de temps, et j’ai vu passer pas mal de façon d’aborder la chose.

    Je réagis face à un billet particulier, d’un coach scrum que je sais expérimenté, qui visiblement met derrière la vélocité autre chose que moi. Quand je te lis je lis de la littérature mais pas du détail. L’effort tu mets quoi derrière ?

    Pour reprendre le billet auquel je répondais : si derrière une US assez classique cette fois ci tu sais qu’il faut refactoriser en profondeur le logiciel, est-ce que tu reprends l’ancienne estimation (ce qu’il fait) ou est-ce que tu essayes plus de coller à une autre estimation voire en fait une nouvelle (c’est plus ainsi que moi j’aborde) ?

    Quant à la vélocité, de mon expérience, passé les premiers temps et outre les cas exceptionnels et majeurs, elle est plutot continue justement. Pour moi c’est d’ailleurs un des seuls intérêts de l’exercice.
    Chiffre à moyen et long terme en jour/homme avec une fourchette pas trop mauvaise, je t’assure que les chefs de projets expérimentés y arrivent très bien. Là où ça coince c’est ailleurs … et sur le détail. Je suis convaincu que l’utilisation des références passées faites par scrum aide à faire mieux, mais le gros bénéfice ne vient que quand on a une vélocité prédictible à court terme, et donc continue.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

À propos de ce site, du contenu, de l'auteur
Je poste parfois ici des humeurs ou des pensées. Parfois je change, parfois je me trompe, parfois j'apprends, et souvent le contexte lui-même évolue avec le temps. Les contenus ne sont représentatifs que de l'instant où ils ont été écrits. J'efface peu les contenus de ce site, merci de prendre du recul quand les textes sont anciens. Merci

À toutes fins utiles, ce site est hébergé par Scaleway, ONLINE SAS, joignable par téléphone au +33 (0)1 84 13 00 00 et joignable par courrier à l'adresse BP 438 - 75366 Paris Cedex 08.