Vasco Duarte
Transcription (Traduit)
Bonjour à tous.
D'abord, je demande pardon, je ne pourrai pas faire la présentation en français.
Mais on peut parler après la présentation, on peut parler en français.
Alors, bonjour à tous. C'est un plaisir d'être ici pour parler d'un sujet qui a suscité beaucoup de discussions. Et cela m'a en fait surpris parce que Quand j'ai commencé à parler de l'absence d'estimations, je pensais que c'était sacrément évident. Je pensais que c'était si clair qu'il n'y aurait aucune question à ce sujet. Mais en fait, tout a commencé en 2005. Mon patron, je parlais à mon patron de l'absence d'estimations. Je présentais, hé, j'ai trouvé cette excellente méthode pour savoir où nous en sommes et quand nous allons livrer. Et c'est sacrément précis. Cela va vraiment nous aider à prendre des décisions sur ce qu'il faut inclure ou non. Et j'explique l'absence d'estimations. Je vais en expliquer un peu aujourd'hui également.
Il m'a regardé très sérieusement et il a dit, assieds-toi. Alors je me suis assis et ensuite il est allé à la porte, a fermé la porte. Et puis il m'a regardé et il a dit, Vasco, ne dis jamais cela à qui que ce soit. Les gens vont penser que tu es fou.
Et c'était en 2005. Et il m'a fallu jusqu'en 2012 pour avoir le courage d'en parler publiquement.
Et je suis censé parler plus près de ceci. Au fait, est-ce que vous m'entendez au fond si je parle comme ça ? Non. D'accord, bien. Merci. Alors, tout d'abord, j'aimerais vous offrir un cadeau. Si vous allez à cette URL là-bas, vous pouvez télécharger le livre gratuitement. Il coûte 27 dollars, donc c'est assez pour que vous puissiez dîner, n'est-ce pas ? Je viens de payer votre dîner aujourd'hui. Non.
Donc, mais ceci ne sera disponible que aujourd'hui. Donc si vous voulez le télécharger, vous devez y aller et vous inscrire aujourd'hui. Sinon, vous ne pourrez pas l'obtenir. Donc si vous regardez ceci dans le futur, bien au-delà de 2015, alors désolé, ce n'est plus disponible.
Mais vous verrez l'URL sur d'autres diapositives également. Aujourd'hui, je vais parler de 10 principes que je pense importants pour le développement logiciel et qui peuvent être dérivés de ce que j'appelle l'absence d'estimations. Maintenant, beaucoup d'entre vous vont dire, alors l'absence d'estimations n'est qu'une seule chose ? Et non, ce n'est pas le cas. Et le but n'est pas que ce le soit. Ce n'est pas de cela qu'il s'agit dans l'absence d'estimations. L'absence d'estimations est un espace pour nous permettre de discuter de ce qui fonctionne en termes d'aide à la prédiction de quand nous allons livrer des choses qui importent à l'entreprise. C'est aussi l'une des choses dont je parle dans le livre, à savoir que nous devrions parler des choses qui importent à l'entreprise, pas du coût de chaque chose, mais plutôt des choses sur lesquelles nous devrions nous concentrer.
Au fait, combien d'entre vous aiment le processus d'estimation ? Pouvez-vous lever la main ?
Combien d'entre vous aiment avoir ces longues discussions interminables pour savoir si une story est un trois ou un cinq ?
D'accord, donc ce n'est pas pour vous.
Mais l'absence d'estimations est pour vous si c'est ainsi que vous vous sentez en entrant dans une réunion d'estimation. Vous réagissez comme, quoi ?
Encore ? Ne pourrions-nous pas simplement, vous savez, continuer le travail ? N'est-ce pas ? De plus, l'absence d'estimations est pour vous si les estimations vous donnent un peu l'impression de faire ce travail.
N'est-ce pas ? Les estimations sont un peu comme piégées. Vous entrez dans une pièce et vous savez que quelque chose va exploser et vous espérez que ce ne sera pas vous.
Donc si vous vous sentez ainsi, l'absence d'estimations est aussi pour vous. Mais pour moi, l'aspect le plus important de l'absence d'estimations est que c'est pour vous si vous aimeriez rendre les gens heureux. N'est-ce pas simple ? La raison pour laquelle nous développons des logiciels est d'aider quelqu'un à accomplir une tâche, quelle que soit cette tâche, n'est-ce pas ? Peut-être essayons-nous de les aider, vous savez, à faire des choses simples comme lancer une fusée spatiale ou des choses compliquées comme calculer le montant de l'impôt pour la déclaration fiscale annuelle. N'est-ce pas ? C'est ce que nous aimons faire. C'est pourquoi beaucoup d'entre nous entrent dans le métier du logiciel. Parce que nous voulions aider les autres, parfois nous-mêmes, n'est-ce pas ? Parfois, nous sommes la personne que nous voulons aider. Voici donc la chose. Je ne sais pas comment fonctionnent les trains en France. Je ne sais pas si vous avez... Des trains qui sont toujours à l'heure.
Presque partout où je vais, les gens rient quand je pose cette question. Je ne sais pas ce que c'est, mais je pensais que le TGV était toujours à l'heure. Je pensais que c'était seulement la Deutsche Bahn qui était en retard. Mais ensuite, j'ai commencé à voyager autour du monde et il semble que les trains en retard soient une occurrence très courante. En Finlande, d'où je viens, nous avons une très bonne compagnie de trains. En gros, ils ne font face qu'à quatre problèmes. En fait, ils n'ont que quatre problèmes pour faire circuler les trains. C'est l'hiver, le printemps, l'été et l'automne. Ce sont les seuls quatre problèmes qu'ils ont, n'est-ce pas ? En été, les trains surchauffent. En hiver, le sol est gelé, donc les trains ne peuvent pas aller aussi vite qu'ils le pourraient. En automne, il y a trop de feuilles sur les voies, donc les trains mettent plus de temps à s'arrêter, ils doivent donc aller plus lentement. Et au printemps, je ne sais pas, peut-être qu'ils sont tous en vacances.
Mais voici la chose, ce train ici, au fait, qui sait ce qu'est ce train ? Shinkansen, exactement. Ce train ici, laissez-moi voir les chiffres parce que ces chiffres sont intéressants.
Ce train ici, en 2014, toute l'année, toute l'année, n'est-ce pas ? Ce train avait en moyenne 54 secondes de retard. Et cela inclut les catastrophes naturelles.
N'est-ce pas ? Donc ils ont trouvé comment résoudre ce problème. Dans les années 90, laissez-moi voir quelle année c'était ? 97. Ce train avait en moyenne 18 secondes de retard, moins de 20 secondes. Toute l'année. Comment ont-ils fait ?
Comment ont-ils construit un train qui est toujours à l'heure ?
Comment cela a-t-il été possible ? Alors avant d'y aller, réfléchissez à ceci. Quand vous allez à la gare et que vous allez prendre un train pour une réunion importante, disons, à Paris, et que vous êtes, je ne sais pas, à Lille ou Lyon ou Marseille, et que vous voulez prendre le train pour aller à Paris pour cette réunion très importante. Vous ne voulez pas rater la réunion, n'est-ce pas ? Donc, vous allez regarder l'historique de la ponctualité des trains et vous allez penser, hmm, devrais-je partir un jour avant au cas où, vous savez, si le train tombe en panne, je pourrai toujours sortir et louer une voiture ? Devrais-je partir cinq heures avant l'horaire prévu pour que, si le train est en retard, j'aie encore le temps d'arriver à ma réunion très importante sans la manquer ? Vous devez vous poser ces questions. Encore une fois, d'où je viens en Finlande, je prenais toujours le train plus tôt que celui que je pensais suffisant pour arriver à l'heure. Et la raison en était que je savais qu'il était probable que mon train soit en retard ou même qu'il n'arrive pas du tout.
J'étais donc nerveux. Chaque fois que j'entrais dans la gare. Je devais prendre des décisions qui n'avaient rien à voir avec ma vie, elles avaient à voir avec la fichue compagnie de trains. Ce n'était pas une question de mon affaire, c'était une question de l'affaire des trains. J'étais nerveux chaque fois que je prenais le train.
En revanche, si vous viviez au Japon et que vous alliez à une réunion très importante à Tokyo et que vous aviez l'un de ceux-ci, la seule décision que vous auriez à prendre serait de savoir si je prends le train que je dois prendre ou si je pars une demi-heure plus tôt pour avoir le temps de visiter ce magasin de manga que je voulais visiter depuis quelques années. Et vous savez quoi ? Vous seriez détendu. Parce que vous saviez que le train serait à l'heure.
Vous n'auriez pas à vous inquiéter d'être peut-être laissé au milieu de la voie, au milieu de nulle part, avec le train arrêté à cause de trop de feuilles sur les voies. Voilà donc ce qu'ils ont fait au Japon pour avoir un train toujours à l'heure. Le Shinkansen, dont le nom original était Nouvelle Ligne Principale, n'est-ce pas ? C'est de là que vient le Shinkansen. Ils ont construit une ligne de train entièrement nouvelle pour que ce train n'ait pas à se mélanger avec les trains plus lents. Ils ont construit un nouveau système conçu pour que les trains arrivent à l'heure aux gares où ils devaient se rendre. Ils n'ont pas essayé d'améliorer un système défaillant, ils ont construit un nouveau système. Et c'est en fait le premier principe de l'absence d'estimations. Si vous ne faites pas confiance au système dans lequel vous travaillez ou aux processus avec lesquels vous travaillez, changez les processus. N'essayez pas de les améliorer lentement. Demandez-vous, quelle est la cause fondamentale des problèmes auxquels nous sommes confrontés ? Et si être à l'heure est très important pour vous, par exemple, vous travaillez sur un logiciel de gestion fiscale.
Être à l'heure est extrêmement important. Alors vous construisez un système qui livre à l'heure. Vous n'essayez pas de mieux estimer. C'est un système défaillant. Il ne s'améliorera pas, peu importe nos efforts. Donc, c'est le principe numéro un.
C'est une histoire très intéressante. C'est un projet, un projet très important si je me souviens bien, et il était essentiellement divisé en deux phases, n'est-ce pas ? La première, que j'appelle phase de développement, et la seconde, que certaines personnes appellent assurance qualité, je l'appelle phase de test et de correction désespérée.
Et regardez la durée des phases.
C'est un vrai projet. Donc, nous avons la phase de développement qui représente un peu moins d'un tiers de la durée totale du projet. Mais regardez cette ligne bleue. La ligne bleue représente le nombre de D. défauts ouverts, n'est-ce pas ? Elle monte, monte, monte et monte encore. Et si vous êtes ici, à ce point, tout en haut de cette courbe, la question est : quand ce projet sera-t-il livré ?
Quelqu'un veut-il deviner ?
Jamais. Oui, ce serait une estimation juste, n'est-ce pas ? Mais regardez ensuite ce qui se passe. Boum ! La ligne bleue chute. Que s'est-il passé là ? Eh bien, nous ne sommes pas des magiciens, n'est-ce pas ? Donc, ce que nous avons fait, c'est que nous sommes allés dans Jira et avons commencé à retirer des éléments du projet. Nous ne corrigerons pas, nous ne le ferons pas, nous ne corrigerons pas, nous ne le ferons pas. Et, vous savez, tout descend. Et puis, bien sûr, nous avons fermé beaucoup de bugs à ce moment-là, et la qualité a commencé à s'améliorer, ou l'a-t-elle fait ?
Pas vraiment. Plus nous testions, plus nous trouvions de problèmes. Et devinez quoi ? C'est à cela que servent les tests, n'est-ce pas ? Donc, trouver plus de problèmes n'est pas vraiment une surprise. Mais attendez, ce projet s'est réellement terminé. Ils ont livré le projet. Comment ont-ils fait ?
Les clients continuent de tester.
Oui, donc déléguer les tests aux clients. Oui, ce serait une façon de faire.
En fait, la raison pour laquelle ce projet a été livré était très simple. Quand je travaillais dans cette entreprise, nous avions de nombreux projets. C'est en cours. Et quand cela s'est produit, je regardais l'historique des autres projets. Et voici ce que j'ai trouvé. Les grands projets avaient en moyenne une phase de test et de correction désespérée de trois mois. Les petits projets avaient en moyenne une phase de test et de correction désespérée de 90 jours. Les projets de taille moyenne avaient également une phase de test et de correction désespérée de trois mois. Et je ne sais pas pour vous, mais je ne crois pas aux coïncidences. Donc, lorsque nous avons réellement analysé ce qui se passait, nous avons découvert que la raison pour laquelle ces projets étaient livrés était que, vous savez, la direction en avait assez. Ils descendaient du bureau d'angle, allaient dans la salle de l'équipe et disaient, les gars, soit nous livrons maintenant, soit nous annulons le projet.
Voilà comment nous respectons les délais dans le monde réel. Il s'agit de quelqu'un qui perd patience ou perd de l'argent et dit, non, arrêtez, mettons-le en production. Alors, à quoi bon être précis sur les estimations ? Ceci n'est qu'un exemple. Bien sûr, vous savez, vous avez vos propres exemples dans vos propres entreprises et peut-être que vous le faites beaucoup mieux que cette entreprise. Mais voici le point. Lorsque vous avez des projets avec des phases de test et de correction désespérées, le calendrier de livraison ne dépend d'aucune estimation. Le calendrier de livraison dépend parfois de décisions très intuitives, décisions commerciales. Cela n'a rien
à voir avec les estimations. Peut-être que nous étions à l'heure avec ce projet. Qui s'en soucie ? Si nous étions à l'heure, c'était une coïncidence. Ce n'était pas par conception. Ce n'était pas parce que nous étions très bons en estimations. C'était parce que quelqu'un a dit, vous savez, assez. Sortons le produit.
Cela nous amène au principe deux, l'un des plus gros problèmes ici était cette phase de test et de correction désespérée parce qu'elle crée de l'incertitude. Le deuxième principe est donc de raccourcir le cycle de feedback. Et cela s'applique à tous les niveaux. Cela s'applique au niveau de l'entreprise, au niveau du projet, au niveau du sprint, au niveau de l'histoire utilisateur, au niveau quotidien. Et la raison est simple. Le feedback informera les décisions que vous devez prendre. Ce n'était pas par conception. Ce n'était pas parce que nous étions très bons en estimations. C'était parce que quelqu'un a dit, vous savez, assez. Sortons le produit.
Cela nous amène au principe deux, qui est l'un des plus gros problèmes ici : cette phase désespérée de tests et de corrections, car elle génère de l'incertitude. Le principe deux est donc de raccourcir le cycle de feedback. Et cela s'applique à tous les niveaux. Cela s'applique au niveau de l'entreprise, au niveau du projet, au niveau du sprint, au niveau de l'histoire utilisateur, et au niveau quotidien. Et la raison est simple. Le feedback informera les décisions que vous devez prendre. Plus vous avancez sans feedback, plus vos décisions seront mauvaises. Devinez quoi ? Si vous raccourcissez suffisamment le cycle de feedback, vous n'avez plus besoin d'estimer. Vous n'avez qu'à demander : sommes-nous prêts à livrer aujourd'hui ? C'est la seule question que vous devez poser. Et c'est en fait la question que je pose lorsque je travaille avec des équipes qui livrent des produits : pouvons-nous livrer aujourd'hui ? Devinez quoi ? Cette question, qui est bien sûr destinée à provoquer une réflexion, à faire réfléchir les gens, pourquoi ne pouvons-nous pas livrer aujourd'hui ? Qu'est-ce qui nous empêche de livrer aujourd'hui ? Cela nous donne la certitude dont nous avons besoin pour respecter les échéances qui nous sont imposées, que ce soit par la direction ou par le marché. Il s'agit de raccourcir le cycle de feedback. Vous pouvez être prêt à livrer chaque jour. Vous serez toujours à l'heure, peu importe l'heure.
Ainsi, vous pouvez commencer à construire votre propre Shinkansen, votre système fiable. Une autre question qu'on me pose tout le temps est : pouvons-nous être précis dans nos estimations ? Eh bien, certaines personnes diront que oui, et la seule raison pour laquelle vous n'êtes pas précis, c'est parce que vous êtes irresponsable et que vous jouez avec l'argent des autres. Oui, on me dit ça tout le temps sur Twitter. C'est bon. Je m'y suis habitué. Après tout, cela fait trois ans.
Voici une excellente vidéo, la vidéo de J.B. Rainsberger. C'est sur Vimeo, c'est de l'Ordev 2013.
C'est une vidéo très courte que je recommande vivement. Et il fait un point très important, et il parle de complication accidentelle. Voici le point. Il dit que le coût ou la durée de tout travail que vous devez faire est le produit de la complication essentielle, c'est-à-dire : S'agit-il d'une chose simple comme lancer une fusée ou d'une chose très complexe comme faire ses impôts ? C'est la complication essentielle, la complication naturelle du problème que vous essayez de résoudre. Par rapport à ou multipliée par la complication accidentelle. Et la complication accidentelle, c'est ce que JB appelle le fait que nous ne sommes pas très bons dans notre travail. N'est-ce pas ? Donc voici un exemple. Lorsque vous avez commencé à développer ce produit il y a cinq ans, était-ce plus facile ou plus difficile de travailler avec la base de code qu'aujourd'hui ? Dans la plupart des cas, ce sera plus difficile. Dans certains cas, si c'est le cas pour vous, félicitations, ce sera plus facile. Mais le point est que ce n'est pas la même chose, n'est-ce pas ? Maintenant, réfléchissez à ceci. Dans Scrum, on nous demande de faire des estimations en points d'histoire, qui sont des estimations relatives, n'est-ce pas ? Nous comparons la complication essentielle d'une histoire particulière avec une autre histoire que nous croyons avoir la même complication essentielle. Mais devinez quoi ?
La complication accidentelle, c'est-à-dire le fait que nous ne soyons pas très bons dans notre travail, est parfois si grande qu'elle domine, elle domine cette équation.
Un exemple très simple, lorsque nous avons commencé à développer un site web, nous utilisions peut-être simplement le framework de base. Les choses étaient propres, nous savions ce que nous faisions. Quelques années plus tard, nous livrons toujours ce même site web, et malheureusement c'est le cas dans l'une des entreprises avec lesquelles je travaille. Vous pourriez même réécrire le logiciel pour la troisième fois, car la complication accidentelle était devenue si élevée que vous pensez qu'il est préférable de tout réécrire à partir de zéro plutôt que d'essayer de modifier l'ancien logiciel. Quelqu'un développe-t-il ? Des sites web en PHP ici ? Vous savez probablement de quoi je parle, n'est-ce pas ? Alors voici la chose. Si dans une entreprise, ce n'est qu'un exemple, mais je suis sûr que vous pouvez faire le lien.
Si dans une entreprise, à un moment donné, vous décidez de réécrire le logiciel parce que la complication accidentelle était si grande que vous ne vouliez pas en payer le prix, qu'en est-il de cette technique d'estimation relative ? Comment cela fonctionne-t-il à nouveau ?
N'est-ce pas ? Vous essayez de relier la taille, le coût et la durée d'une histoire maintenant, alors que vous êtes sur le point de réécrire tout le système, avec la taille ou le coût et la durée d'une histoire, il y a quelques mois, lorsque vous étiez, vous savez, enfoncé jusqu'aux genoux dans la boue. Comment fonctionne à nouveau l'estimation relative ? En comparant des choses similaires.
Mais si la complication accidentelle, qui change avec le temps, domine cette équation, alors la seule conséquence logique est que les estimations relatives n'ont aucune valeur. Dans ce contexte où la complication accidentelle change et devient la partie dominante de ce qu'il faut, le coût et le temps qu'il faut pour livrer quelque chose. C'est donc un problème pour nous. Mais ce n'est pas le seul problème.
Voyez-vous, le fait est que certaines personnes prennent les files d'attente très, très au sérieux. Alors, combien d'entre vous ont 100 éléments ou plus dans leur backlog ? Si vous pouviez lever la main.
Vous voyez, c'est ce que je veux dire, n'est-ce pas ? Cet élément numéro 100, qui devait être livré en trois semaines il y a un an, comment se passe l'estimation pour celui-là ? Mais il y a d'autres problèmes, n'est-ce pas ? Parce que ce n'est qu'un site particulier ou une conséquence des files d'attente.
L'autre conséquence des files d'attente est que, vous savez, il y a deux semaines, vous avez commencé à travailler sur quelque chose et vous pensiez que cela prendrait deux jours, mais cela fait deux semaines et l'élément est toujours dans la file d'attente de quelqu'un d'autre. Depuis deux semaines. Comment cette estimation peut-elle être précise ? Les files d'attente peuvent avoir un impact si important sur votre organisation qu'elles détruisent complètement toute valeur que vous pourriez penser avoir en estimant le coût et la durée d'un élément.
Je ne sais pas pour vous, mais j'ai retiré des éléments des files d'attente, également connues sous le nom de JIRA, qui dataient de cinq ans ou plus.
N'est-ce pas ? Alors, quel est le point, encore une fois ?
Donc, le point avec les files d'attente est que les files d'attente auront toujours un impact très important sur la manière dont le travail circule dans votre organisation. Et elles auront un impact si important que tenter d'estimer un seul élément de travail n'a aucun sens tant que vous n'avez pas réellement commencé à l'exécuter.
Et lorsque vous commencez à l'exécuter, les files d'attente ont un impact si important dans votre organisation qu'il est en fait beaucoup plus utile de regarder le temps de cycle ou le délai d'exécution, selon ce que vous essayez de mesurer, des éléments passés que d'essayer de dire combien de temps cet élément prendra. Si les files d'attente sont si importantes dans la durée que le travail passe dans le système, essayer d'estimer la taille d'un élément est une très petite fraction de la décision de savoir quand cet élément sera prêt. Pourtant, certaines personnes soutiennent que nous pouvons être bons en estimation.
Alors, passons en revue quelques données à ce sujet.
Voici le rapport Chaos. 80 % des projets en 2004 étaient en retard ou ont échoué.
Encore une fois, le rapport Chaos. C'était en 95, mais c'était la seule répartition que j'ai pu trouver. Regardez les 51 à 100. Cela représente les projets dont le budget a dépassé de 51 à 100 % ou plus. Voilà les données concernant les dépassements de coûts et de délais. Des dépassements de temps de 100 % ou plus. Cela signifie que 68 % des projets ont un retard de 51 % ou plus.
Chaos Report 2009, dépassement moyen de temps de 63 %.
Chaos Report 2011, dépassement moyen de temps de 63 %. Mais d'accord, au cas où vous n'aimeriez pas le Chaos Report, parce que bien sûr, les gens diront que le Chaos Report n'est pas une vraie science et ainsi de suite. D'accord, très bien, regardons d'autres enquêtes. Gartner, échec des projets en 2012. D'ailleurs, échec ici signifie échec total, pas seulement un retard. Cela signifie comme ne rien livrer. Petits projets informatiques 20 %, grands projets informatiques 28 %.
Échoués. Pas même en retard. Il y a des projets en retard ici sur cette grande barre de 72 %.
Capers Jones, une personne très respectée dans le domaine de la défense. Cela a été écrit dans le Journal of Defense Software Engineering. Sur les grands systèmes qui sont achevés, environ 66 % connaissent des retards de calendrier et des dépassements de coûts.
C'était l'enquête sur la réussite des projets de Scott Ambler. Projets traditionnels, 53 % ont échoué ou ont été modifiés. Mais nous sommes agiles, n'est-ce pas ? Nous sommes bien meilleurs que ça. 40 % des projets agiles ont échoué ou ont été mis en difficulté.
Et c'est celui-ci qui m'a vraiment marqué. Cela provient de McKinsey, une enquête ou une étude sur les projets informatiques à grande échelle réalisée avec l'Université d'Oxford en 2012. 17 % des grands projets informatiques tournent si mal, si mal, qu'ils menacent la survie même de l'entreprise.
Réfléchissez-y une seconde.
Les grands projets informatiques tournent si mal qu'ils menacent l'existence de l'entreprise.
Je vais en publier davantage. Je vais écrire un article sur noestimatesbook.com à ce sujet parce qu'il y a beaucoup de gens qui disent : oui, ces conneries sur le fait que nous ne sommes pas bons en estimations, c'est juste fou. Bien sûr que nous sommes bons en estimations. Vous savez, vous le faites simplement mal. En fait, il n'y a aucune donnée pour soutenir cette affirmation. Il n'y a aucune donnée pour soutenir l'affirmation que nous pouvons être bons en estimations.
Donc, lorsque vous regardez cette statistique, 17 % des grands projets informatiques menacent la survie même d'une entreprise, demandez-vous, serais-je prêt à parier mon entreprise sur l'utilisation d'une technique qui a un si mauvais bilan ? Parce que c'est vraiment la question que nous posons. Je veux dire, lorsque vous demandez à un développeur de logiciels, pouvez-vous être bon en estimations ? Il pense à : puis-je écrire cette story ou le code pour cette story dans le temps que je pensais qu'il me faudrait pour l'écrire ? Il ne pense pas : puis-je écrire cette story de manière à ne pas faire faillite à l'entreprise ? N'est-ce pas ?
Mais les managers qui demandent aux équipes de développement de logiciels de faire leurs estimations de cette manière devraient se demander : est-ce que je demande à un développeur ou vraiment de prendre des décisions commerciales qui pourraient faire faillite à mon entreprise ? N'est-ce pas ma responsabilité ?
Voici donc le principe. Croyez les données, pas les estimations. Parce que voici la chose. Même si vous pouviez être bon en estimations, il est logique de regarder ce qu'est une bonne estimation.
Conte, Dunmore et Shen ont proposé qu'une bonne approche d'estimation est celle qui fournit des estimations à moins de 25 % des valeurs réelles 75 % du temps. Laissez-moi vous expliquer cela d'une manière que même moi je comprends. Je vais à la banque et il y a une personne de l'autre côté du comptoir qui dit : hé, j'ai un super investissement pour vous. Vous savez, vous me donnez 100 000 euros et je promets, je promets que je vous rendrai 75 000 euros. Je ne perdrai que 25 000 euros de votre argent et cela avec 75 % de chances. Cela pourrait aller beaucoup plus mal, mais ce n'est pas très probable. Feriez-vous jamais un investissement comme celui-là ? Croiriez-vous un banquier s'il vous disait cela ? Maintenant, vous réagiriez en disant : d'accord, vous êtes viré, n'est-ce pas ? Alors pourquoi utilisons-nous une technique qui, même en tant que bonne estimation, donne un si mauvais résultat ? du temps. Laissez-moi vous expliquer cela de manière à ce que même moi je comprenne. Je vais à la banque et il y a une personne de l'autre côté du comptoir qui me dit, hé, j'ai un super investissement pour vous. Vous savez, vous me donnez cent mille euros et je promets, je promets que je vous rendrai 75 000 euros. Je ne perdrai que 25 000 euros de votre argent et cela avec 75 % de chances. Ça pourrait aller beaucoup plus mal, mais ce n'est pas très probable. Feriez-vous jamais un investissement comme celui-là ? Croiriez-vous un banquier s'il vous disait cela ? Maintenant, vous vous diriez, d'accord, vous êtes viré, n'est-ce pas ? Alors pourquoi utilisons-nous une technique qui, même en tant que bonne estimation, donne un si mauvais résultat ? C'est un investissement minable, les gars. Pourquoi continuons-nous à utiliser cela ?
Donc, principe quatre, utilisez des alternatives à la prise de décision basée sur les estimations. Bien sûr, vous pouvez utiliser des estimations pour prendre des décisions. Je veux dire, personne ne peut vous empêcher de le faire, et vous le faites peut-être même de manière subconsciente. Mais essayez de trouver des alternatives. Que pourrions-nous utiliser d'autre que les estimations pour prendre des décisions ? Voici une autre chose. Vous savez quoi ? Ce projet, cette liste de projets, 17 projets de 2001 à 2003, le retard moyen était de 62 %. Mais, d'accord, certains projets étaient assez à l'heure. Vous savez, le numéro un était même en avance sur le planning. Le numéro deux était dans les temps. Le numéro trois était très proche d'être dans les temps. Mais regardez le projet 17. 200 à 245 % de retard. D'ailleurs, la barre bleuâtre indique quand les exigences, désolé, quand le projet a été approuvé et la barre bordeaux indique quand toutes les exigences étaient connues, ou nous pensions qu'elles étaient connues, évidemment. En ayant 200 % de retard, nous savons qu'elles n'étaient pas connues. Mais voici la chose, si vous me demandez ce qu'était le projet 1, je n'en ai aucune idée. Mais si vous demandez ce qu'était le Projet 17, le Projet 17 a changé l'entreprise. Il a créé un nouveau modèle économique, il a permis ou aidé l'entreprise à entrer sur un nouveau marché, il a créé un modèle économique de revenus actuels, ce qui, si vous dirigez une entreprise, est en fait assez bien parce que vos revenus augmentent lentement, mais ils augmentent continuellement parce que c'est cumulatif. C'était essentiellement un service basé sur abonnement. Quand j'ai quitté l'entreprise, le numéro 17 générait plus de 50 % des revenus de cette entreprise.
Alors voici le point crucial. Même si vous êtes bon en estimations, elles n'ont aucune signification sur le plan commercial. Parce que vous pouvez être mauvais en estimations et être tout de même extrêmement réussi. Donc non seulement nous ne sommes pas très bons en estimations, du moins c'est ce que les données nous disent, je vous dis aussi que bien estimer passe à côté de l'essentiel.
Cela n'a aucun sens. Cela ne vous aide à rien sauf peut-être à être dans les 25 % des résultats réels 75 % du temps, si vous croyez à la définition d'une bonne estimation. Parce que cette entreprise n'avait pas besoin d'être bonne en estimations pour changer complètement son modèle économique. En fait, le projet le plus problématique en termes d'estimation était le projet le plus réussi.
Dans une autre entreprise, nous travaillions avec une équipe qui livrait essentiellement des systèmes de commerce électronique, n'est-ce pas ? Vous savez, vous allez sur le web, vous achetez quelque chose. Et l'équipe était submergée de travail à faire. Ils avaient tellement de travail à faire qu'ils étaient complètement perdus. Ils étaient, vous savez, démotivés. Ils avaient, et je ne vous mens pas, des centaines d'éléments dans leurs backlogs qui étaient comme de petites améliorations, vous savez, changer la couleur, déplacer le bouton, ce genre de choses. Cela est malheureusement assez courant dans de nombreuses équipes de commerce électronique. Mais le product owner a décidé de consacrer un sprint dans cette entreprise particulière qui durait deux semaines. Il a décidé de consacrer un sprint à ce qu'il appelait un sprint d'innovation. Donc, évidemment, je travaillais avec eux, nous avons décidé de nous concentrer sur quelque chose qui aurait un impact commercial. Nous avons demandé, d'accord, que pourrions-nous faire qui aurait un véritable impact commercial ? Et nous avons eu une idée. L'idée était très simple. C'était de partager ce que vous aviez acheté. C'était de le partager sur Facebook, n'est-ce pas ? Ou ce que vous étiez sur le point d'acheter, le partager sur Facebook. Parce que l'idée était, eh bien, nous obtiendrons plus de trafic. Plus de gens viendront sur le site. Et, vous savez, nous augmenterons le nombre de ventes. Nous augmenterons le taux de conversion parce que c'est une sorte de recommandation par preuve sociale et ainsi de suite. Et quelqu'un a eu l'idée de dire, hé, attendez une minute. Moi aussi, vous savez, j'utilise le site web quand je suis dans le bus, mais je ne veux pas acheter avec ma carte de crédit dans le bus. Alors et si on m'envoyait, vous savez, un rappel, n'est-ce pas ? Juste par email. D'accord, très bien. Intégrons cela. Donc l'équipe était heureuse, ils s'amusaient avec des choses qu'ils aimaient, y compris les serveurs de messagerie, ce qui est apparemment très sexy pour les développeurs de commerce électronique. Et ils développaient cela, et après deux sprints, nous sommes passés en production.
Désolé, après deux semaines, un sprint, nous sommes passés en production. Et voici la chose. Deux jours après notre mise en production, nous gagnions de l'argent. Deux jours après notre mise en production. C'est deux semaines et deux jours après avoir commencé à travailler sur quelque chose. Si vous aviez demandé à cette équipe combien de temps il faudrait pour générer cette fonctionnalité, vous savez, sexy, belle, brillante... Partager sur Facebook ou Twitter ou Instagram, ils auraient probablement dit, vous savez, comme deux sprints, trois sprints, peu importe. Mais nous n'avions pas ce temps. C'était un sprint d'innovation. Nous avions l'autorisation pour deux semaines. C'est ce que nous avons fait. Nous sommes passés en production. Deux jours plus tard, nous générions de l'argent. J'ai reçu un email plus tôt cette année en été de la part du product owner qui travaillait dans cette entreprise. Cette seule fonctionnalité avait généré 250 000 euros de revenus au cours des sept premiers mois de l'année. C'est presque un demi-million par an. Non seulement cela, mais le taux de conversion de cette fonctionnalité était de 5 % comparé au taux de conversion moyen du site lui-même, qui était de 0,03 %.
Deux semaines ont totalement transformé la valeur que délivrait une équipe. Maintenant, imaginez ce que nous pourrions faire avec des entreprises entières si nous nous concentrions sur la valeur plutôt que de nous concentrer sur le fait d'obtenir les bonnes estimations.
Donc voici le principe cinq. Si vous allez tester, testez d'abord pour la valeur, puis testez pour la fonctionnalité. Parce que la valeur est ce que vous êtes là pour délivrer. Ce n'est pas qu'il fonctionne mieux, c'est qu'il a un impact commercial.
Donc certaines des techniques que vous pourriez utiliser pour cela sont, par exemple, l'impact mapping et le story mapping, qui vous donnent des options qui, au lieu de vous forcer à faire un tas de choses auxquelles vous vous êtes déjà engagés parce que vous les avez estimées, vous permettent en fait de prendre des décisions au fur et à mesure. Et je recommanderais définitivement de commencer par l'impact mapping et de se concentrer sur la valeur plutôt que sur les coûts des éléments que vous essayez de livrer.
Donc, évidemment, les plus responsables d'entre vous se demanderont, mais est-ce que cela peut fonctionner dans de vraies entreprises ? Je veux dire, vous savez, le commerce électronique et tout ça, mais je travaille pour des clients qui, vous savez, veulent l'offre, n'est-ce pas ? Ils veulent l'étiquette de prix lorsqu'ils achètent un logiciel de ma part. Est-ce que cela peut fonctionner avec de vraies entreprises ? J'ai donc interviewé le PDG Sven Dietz qui travaille pour une entreprise en Allemagne appelée Zeitgeist. Ils créent essentiellement des sites web et des systèmes de commerce électronique pour d'autres entreprises. Ils sont donc une entreprise de logiciels sous contrat. Ils sont principalement payés en temps et matériaux et livrent des logiciels qui aident les entreprises d'autres sociétés. Et dans cette vidéo, Sven explique comment ils sont passés de Passer par le processus normal d'appel d'offres, où l'on reçoit une liste de exigences et ensuite on essaie de déterminer combien de temps cela prendra. À un monde sans estimations où, et voici le point crucial, ils sont maintenant capables de contourner le processus d'appel d'offres. Ils n'ont même plus besoin de faire d'offres. Et la raison est simple. Lorsqu'ils reçoivent une demande d'offre, au lieu de s'asseoir et d'essayer d'estimer tout, ils écrivent leur logiciel. Et en quelques jours, ils vont voir le client et disent, voici ce que nous avons fait ces derniers jours. Souhaitez-vous que nous en fassions plus ?
Ils montrent un logiciel fonctionnel et opérationnel. C'est un concept novateur, n'est-ce pas ? Le logiciel plutôt que les négociations de contrat. Mais c'est ce qu'ils ont fait. Et l'interview, vous savez, je ne peux pas lui rendre suffisamment justice. Il faudrait la regarder. Mais dans l'interview, il explique comment ils font cela et comment ils ont effectivement contourné un long processus d'appel d'offres d'une grande entreprise européenne. Et ils ont commencé à livrer du logiciel immédiatement. Il dit, c'est la chose qui a vraiment retenu mon attention, que si l'on compte le temps qu'ils passent à estimer, à rédiger l'offre, à faire des négociations de contrat, maintenant ils travaillent sans contrats, donc ils ne sont payés que si le client les apprécie. Ils livrent un logiciel fonctionnel au lieu de rédiger des offres. Je parie que certains développeurs préféreraient cela. Mais voici la chose. Ils perdent moins d'argent maintenant qu'ils n'ont pas de contrats qu'avant lorsqu'ils en avaient. Parce que voici la chose. Ils passent 30 % de leur temps à rédiger des offres et à négocier des contrats. 30 % d'un projet moyen étaient consacrés à la rédaction d'offres, à la réalisation d'estimations, à la négociation de contrats. Ils n'ont plus besoin de faire cela maintenant.
Voici un exemple de la façon dont l'absence d'estimations ne fonctionne pas seulement dans de vraies entreprises, mais transforme également leur modèle économique.
Donc, évidemment, le principe ici est que l'estimation est un gaspillage. Remarquez que je ne dis pas que vous ne devriez pas estimer, je dis simplement que c'est du gaspillage. Et si vous êtes familier avec les principes lean, l'idée est de réduire le gaspillage. Vous ne pourrez peut-être pas toujours l'éliminer. N'est-ce pas ? Réduisez son impact sur votre entreprise.
C'est un aspect très important, que même si vous devez faire des estimations, n'essayez pas de gérer votre entreprise en vous basant sur les estimations elles-mêmes.
Et le principe sept est de mesurer les progrès uniquement par le biais de logiciels validés et opérationnels. C'est ce que Sven a fait dans son entreprise.
Donc, nous revenons à la définition d'une bonne estimation.
La réalité est, et c'est un graphique qui a été publié par Steve McConnell dans son livre Software Estimation, qui ironiquement essaie de vous dire comment être meilleur en estimations. C'est une entreprise qu'il cite. Et si vous regardez la définition d'une bonne estimation, être à moins de 25 % des résultats réels, et que vous regardez la réalité, nous pouvons voir que ce n'est pas vraiment le cas. Ceci est le nombre de projets. Chaque croix représente un projet. L'axe des ordonnées indique combien de jours il a fallu pour terminer le projet, et l'axe des abscisses indique combien de jours ils étaient estimés pour le faire. Mais que nous soyons mauvais en estimations, je l'ai déjà mentionné. Mais je voulais aborder un aspect très spécifique du fait d'être mauvais en estimations maintenant.
Regardez ces deux croix là-bas. Le coin en haut à gauche.
Ces deux croix, donc la première devait prendre quelque chose comme sept à neuf jours, et cela a pris environ 260 jours. Et la seconde devait prendre près de 20 jours et cela a pris presque 240 jours. Cela, ce que j'appellerais les valeurs aberrantes, peut en fait détruire votre entreprise, n'est-ce pas ? Nous devons donc être conscients que lorsque nous investissons dans les estimations, nous courons en réalité des risques de cette ampleur. Maintenant, bien sûr, si nous regardons cela, nous pouvons dire, eh bien, vous savez, il y a beaucoup d'autres projets qui ne sont pas autant en décalage. Je veux dire, celui-ci n'a pris que 120 jours alors qu'il devait en prendre un, n'est-ce pas ? Ce n'est pas si mal.
Mais c'est la réalité avec les estimations. Donc, quand vous arrivez au bureau, et que quelqu'un vous demande, eh bien, je vais vous demander de livrer 10 stories lors du prochain sprint. Évidemment, la réaction saine serait de dire, quoi ? Mais regardons ce qui se passe réellement. C'est l'un des aspects que nous abordons dans l'atelier No Estimates, à savoir que Nous travaillons au sein de systèmes, n'est-ce pas ? Voici notre système. Ceci est une équipe, soit dit en passant, 21 sprints, et la ligne bleue représente leur débit ou le nombre de stories livrées par sprint, et les autres lignes sont simplement des lignes de contrôle. Mais vous voyez qu'ils sont extrêmement prévisibles. Voici donc la chose. Notre objectif ne devrait pas être d'estimer combien de temps quelque chose prendra. Notre objectif devrait être de comprendre le système dans lequel nous travaillons. Parce que devinez quoi ? Il sera extrêmement prévisible si vous collectez des données. Et je vais prendre un risque ici et dire que certaines personnes dans la salle disent, eh bien, mais notre travail est différent, n'est-ce pas ? Notre travail n'est pas vraiment prévisible, n'est-ce pas ? Je veux dire, vous savez, parfois nous avons de petites choses, parfois nous avons de grandes choses. Je l'entends. Souvent. Mais voici la chose. Lorsque je mesure des systèmes, lorsque je vais dans des entreprises et que je travaille avec elles pour rendre le travail visible, je mesure le travail réel en cours et je mesure combien de travail est livré par unité de temps. Devinez ce que je vois ? Je vois ce genre de graphiques. Tout le temps. Donc voici la chose, nous avons déjà les données, si nous les mesurons, si nous les collectons, nous avons déjà les données qui nous permettent d'être aussi prévisibles que le Shinkansen. Nous avons ces données. Donc nous devrions simplement les mesurer. Nous devrions examiner nos organisations d'un point de vue systémique, en mesurant nos temps de cycle et nos délais d'exécution.
Parce qu'en fin de compte, nous voulons éviter des situations comme celle-ci. Et ceci n'est qu'une des dysfonctions auxquelles nous devons faire face dans nos organisations. Il y a quatre dysfonctions. Voyez comme j'ai bien estimé le nombre de dysfonctions que je trouverais ?
La négociation des estimations n'est qu'un des problèmes auxquels nous devons faire face, n'est-ce pas ? Je veux dire, vous connaissez cela en entendant des phrases comme, sérieusement, deux mois, les gars ? Quand j'étais développeur, nous le faisions beaucoup plus vite. Comment se fait-il que cela vous prenne deux mois ? Bien sûr, vous devriez dire, eh bien, en fait, la raison pour laquelle cela nous prend deux mois, c'est parce que cela vous a pris moins de temps, n'est-ce pas ? Parce qu'en fin de compte, nous voulons éviter des situations comme celle-ci. Et ceci n'est qu'une des dysfonctions auxquelles nous devons faire face dans nos organisations. Il y a quatre dysfonctions. Voyez comme j'ai bien estimé le nombre de dysfonctions que je trouverais ?
La négociation des estimations n'est qu'un des problèmes auxquels nous devons faire face, n'est-ce pas ? Je veux dire, vous connaissez cela en entendant des phrases comme, sérieusement, deux mois, les gars ? Quand j'étais développeur, nous le faisions beaucoup plus vite. Comment se fait-il que cela vous prenne deux mois ? Bien sûr, vous devriez dire, en fait, la raison pour laquelle cela nous prend deux mois, c'est parce que vous l'avez fait en moins de temps, n'est-ce pas ? C'est la complication accidentelle. Mais bien sûr, il y a la politique interne, n'est-ce pas ? Quels projets sont approuvés ? Quelqu'un a une idée ?
Les projets les plus précieux, n'est-ce pas ? Mais comment rendre un projet précieux ?
Vous négociez. Hé, tu me donnes cette fonctionnalité, je la mets dans mon projet, et puis tu me donnes cette autre fonctionnalité, je la mets dans mon projet, et ensuite je vais voir le conseil d'administration et je dis, j'ai toutes ces fonctionnalités à livrer, et au fait, ils sont d'accord avec moi. N'est-ce pas ? Politique interne. Faire approuver des projets en fonction de leur taille. Peut-être même trop gros pour échouer.
Report de blâme. Combien de temps vous faudra-t-il pour livrer cette fonctionnalité ? Deux semaines ? D'accord. Deux semaines plus tard, je viens vous voir, hé, vous aviez dit deux semaines. N'est-ce pas ? Maintenant, c'est de votre faute si vous n'avez pas livré. Le report de blâme est une dysfonction très courante avec les estimations. Les changements tardifs et bien sûr le sophisme des coûts irrécupérables, aussi connu sous le nom de nous avons déjà investi 5 millions dans ce projet, qu'est-ce qu'un million de plus ?
Donc le système dans lequel vous travaillez a des résultats prévisibles. L'objectif est d'apprendre à comprendre le système. C'est vraiment l'une des choses clés sur lesquelles je me concentre dans l'atelier parce que, malheureusement, soit dit en passant, ce n'est rien de nouveau, n'est-ce pas ? Des gens comme Deming parlaient de cela dans les années 20, 30, et il a même écrit des livres à ce sujet dans les années 90, mais personne n'y a prêté attention. Le fait est que nous travaillons tous dans des systèmes prévisibles. Les systèmes sont parfaitement conçus pour produire exactement ce qu'ils produisent. Donc si vous savez ce qu'ils produisent, vous pouvez être assez sûr qu'ils continueront à produire la même quantité de choses au fil du temps. À moins que vous ne les changiez. Et c'est pourquoi les comprendre est si important.
Donc, bien sûr, la prochaine question évidente est, mais pouvons-nous faire mieux ? Donc, voici une histoire, je l'ai racontée assez souvent, beaucoup d'entre vous l'ont peut-être déjà entendue, mais rapidement, c'était un long projet et nous essayions de déterminer quelle était la métrique la plus précise en termes de prédiction de ce qu'une équipe peut livrer sur un long projet. Cela faisait 24 sprints. Donc nous avons demandé, en comparant les points d'histoire avec le nombre d'histoires livrées sur 24 sprints, lequel est un meilleur prédicteur de la production de l'équipe sur ces 24 sprints ? Et nous avons posé cette question seulement après trois sprints, puis bien sûr nous l'avons reposée après cinq sprints, parce que nous avions plus de données. Donc nous pensions, hé, plus de données, plus précis. Essayons cela. Maintenant, je tiens à faire une mise en garde. Ceci n'est qu'un seul cas.
Si vous allez à cette URL, vous obtiendrez 21 autres projets, je pense qu'il y en a 22 de plus maintenant, qui ont des données pour tous les projets. Donc vous pouvez réellement regarder les données et faire vos propres expériences. Et je vous encouragerais à faire cette même expérience avec vos propres projets. Donc après seulement trois sprints, nous avons examiné le pouvoir prédictif des points d'histoire et nous avons découvert que 349,5 points d'histoire avaient en fait été complétés, mais si vous utilisiez la moyenne des trois premiers sprints, vous auriez prédit 418 points d'histoire. C'est 20 % de plus de prédiction que ce qui a été réellement livré, ce qui signifie que vous auriez 20 % de retard. Mais c'est bon. 20 %, c'est en fait mieux que la définition d'une bonne estimation, soit dit en passant.
Et si on comptait simplement le nombre d'histoires ? Donc la production réelle était de 228, la production prédite était de 220. C'est une erreur de 4 %, mais du bon côté, n'est-ce pas ? Donc vous auriez été en avance sur le planning. Eh bien, c'est super, mais je suis sûr que ça s'améliore, je veux dire que les points d'histoire s'améliorent après cinq sprints. Donc nous l'avons fait et oui, effectivement, ils se sont améliorés, 13 % d'écart, ce qui est plutôt bien. N'est-ce pas ? Je veux dire, si vous pouviez toujours être à moins de 13 % de vos prédictions, vous seriez probablement millionnaire à l'heure qu'il est.
Le pouvoir prédictif du nombre d'histoires n'a pas changé. D'ailleurs, ceci est purement une coïncidence. Il aurait pu être plus élevé ou plus bas, mais dans ce cas, il n'a pas changé et était toujours de 4 %.
Ce n'était qu'un seul cas, mais regardez ceci. Voici ce que j'appelle une expérience de magie d'estimation réalisée par Bill Handel et sortie de Microsoft. Ils ont estimé tout leur backlog, un, trois et cinq. Ceux-ci étaient les points d'histoire qu'ils ont utilisés, ce qui est déjà bien mieux que la plupart des entreprises. Et ils ont tracé leur version et c'était le 20 octobre 2014. Et ceci en utilisant l'estimation par points d'histoire. 1, 3, 5 pour dimensionner toutes les histoires. Et puis ils ont fait la magie de l'estimation, aussi connue sous le nom de magie Excel, et ont changé toutes les estimations. Un 5 est devenu un 3, un 3 est devenu un 2, et le 1 est resté un 1. Ils ne sont même plus dimensionnés de manière relative, n'est-ce pas ? C'est comme des nombres totalement différents. Date de sortie, le 14 octobre. Six jours de différence. Quoi ? Vous me dites que vous avez juste changé les estimations et que la date de sortie n'a pas bougé de plus de six jours sur presque une année ? Oui, mais ça devient mieux. Ensuite, ils l'ont changé pour seulement un. Que se passe-t-il si nous supprimons les estimations ? Vous savez, Excel permet de faire cela. Super truc. Date de sortie, le 29 septembre. Le 29 septembre. Toutes, toutes les estimations. Tant l'estimation réelle, l'estimation fausse, que l'absence d'estimation étaient à moins de trois semaines les unes des autres. À moins de trois semaines les unes des autres. C'est une erreur ou une marge entre la projection optimiste et pessimiste de 8 %.
Comparez cela à la définition d'une bonne estimation. Évidemment, Bill, qui a été très généreux de partager ces données avec moi, a dit après quelques échanges d'emails que nous avons eus, qu'à ce moment-là, il avait arrêté de penser que les estimations étaient même importantes. C'est vraiment ce que je vous demande de faire. Faites la même chose pour vos propres projets. Vous pourriez en fait arriver à la même conclusion que Bill. Et vraiment, une bonne estimation 25 % du temps effectif 75 % du temps, est-ce que c'est ça, une bonne estimation ?
J'ai reçu cet email peu de temps après avoir publié le livre. L'un des lecteurs parlait de sa propre expérience. Et c'est ce que je vous encourage à faire, vos propres expériences. Ne me croyez pas, croyez vos données. Ils ont examiné un projet de plus de 50 sprints, ou en fait 50 sprints, et ils ont découvert que s'ils n'avaient pas utilisé d'estimations, ils auraient obtenu des estimations 15 % plus précises. Et non seulement cela, mais sur 50 sprints, à aucun moment le story point n'a donné de meilleures estimations que le simple fait de compter le nombre d'histoires.
Donc le principe neuf est de ne pas miser votre entreprise sur des méthodes avec un aussi piètre bilan.
L'espoir est une mauvaise stratégie de gestion. Ne vous contentez pas d'espérer que vous allez vous améliorer en estimations. Il n'y a aucune donnée pour soutenir cela.
Dans le livre, je raconte l'histoire de Carmen. Carmen fait face à une situation très difficile. Elle a un projet qui doit être livré à temps. C'est un projet à enjeux élevés, et bien sûr, ce ne sera pas une surprise, le temps disponible pour le projet est limité par la concurrence. Parce que, soit dit en passant, c'est un effet secondaire du processus d'appel d'offres pour les projets logiciels : vous devez être plus rapide et moins cher que la concurrence, car, surtout dans les projets publics, vous êtes évalué sur la rapidité et le coût de livraison du logiciel. N'est-ce pas ? Dans le livre, je parle de ce que j'appelle le voyage en sept étapes vers l'absence d'estimations. Bien sûr, c'est juste une métaphore, il ne doit pas nécessairement y avoir sept étapes, cela peut être trois ou vingt-sept, c'est à vous de voir. Mais c'est l'histoire que Carmen traverse. Et j'explique comment vous pouvez passer d'un projet en cascade marqué, déjà en cours, et le transformer pour pouvoir utiliser l'absence d'estimations avec ce projet et en fait livrer plus de transparence aux parties prenantes. Au lieu de réduire vos options, vous générez des options lorsque vous apportez de la transparence.
Le livre est disponible maintenant. J'ai ajouté d'autres choses. Il y a en fait deux mini-livres. L'un traite de la planification de la capacité sans estimations, car c'est évidemment une question à laquelle vous serez immédiatement confronté. D'accord, oui, oui, très bien, pas d'estimations, mais comment faisons-nous la planification de la capacité ? Et puis bien sûr, le second est : très bien, mais nous devons rédiger des contrats. Nous devons y mettre le temps. Eh bien, il existe différents types de contrats. Regardez cela. Examinez les différents types de contrats que vous pourriez utiliser et appliquer tout de même l'absence d'estimations. Mais l'absence d'estimations est vraiment un problème de praticien. Ce n'est pas une question de théorie. J'ai interviewé neuf personnes différentes qui racontent leurs histoires. Sur la façon dont elles sont passées de l'estimation à l'absence d'estimation. Comment elles appliquent l'absence d'estimations à leur propre entreprise. Il y a deux interviews de PDG parmi ces neuf. Donc, il ne s'agit pas de jouer avec l'argent des autres. Il s'agit de personnes qui gèrent réellement des entreprises avec leur propre argent en utilisant l'absence d'estimations.
Enfin, le dixième principe. C'est quelque chose que j'ai emprunté à Deming, donc je n'en suis pas à l'origine. Mais voici la chose. Peu importe ce que vous faites, peu importe ce que vous pensez que l'absence d'estimations est, si vous voulez vous améliorer dans votre travail, la transformation commence par vous. Ne pensez pas que votre manager va la commencer ou que son manager va la commencer. Ne pensez pas que vos développeurs vont la commencer, car après avoir travaillé avec de nombreux développeurs, ils deviennent aussi fous quand vous dites, pourquoi faisons-nous des estimations ? J'ai travaillé avec une équipe et ils ont dit, hé, mais nous devons estimer pour ce sprint. Nous devons prendre un engagement, donc nous devons savoir combien nous pouvons livrer. Et j'ai dit, d'accord, très bien, si vous voulez estimer, allez-y, mais je n'en ai pas besoin.
La transformation commence vraiment par chacun d'entre nous en essayant ces idées, en voyant si elles fonctionnent pour nous.
Et même si elles ne fonctionnent pas, imaginez ce que vous apprendrez une fois que vous commencerez à mesurer le fonctionnement de votre système. Vous pourriez en fait être surpris.
Merci beaucoup.