Dimitar Bakardzhiev
Transcription (Traduit)
D'accord, alors commençons. Bonjour à tous et merci d'assister à cette présentation. Je m'appelle Dimitar et aujourd'hui, j'essaierai de vous montrer comment vous pouvez prévoir votre prochain projet en utilisant simplement Excel. Espérons qu'il y aura du temps pour cela à la fin. D'abord, nous passerons rapidement en revue les diapositives, puis nous nous concentrerons sur Excel.
Quelque chose à propos de moi, c'est un peu long, mais en général, je gère une petite entreprise de développement logiciel en Bulgarie.
Je suis AKT, ce qui signifie un formateur Kanban certifié. Et je publie également quelques livres en bulgare, par exemple le livre sur Kanban. Que je vois que vous l'avez en français, nous l'avons en bulgare depuis environ deux ans pour vous, et des livres d'Elie Godrat et W. Edwards Deming, j'espère que vous connaissez ces noms. Donc ce à quoi nous sommes toujours confrontés, du moins moi-même, en tant que fournisseur de logiciels, c'est que les clients viennent à nous avec une idée pour un nouveau produit et ils posent toujours les questions : combien de temps cela nous prendra-t-il et combien cela nous coûtera-t-il de le livrer.
Ils ont besoin d'une date de livraison et d'une estimation budgétaire, quoi qu'ils en disent.
expérience.
La réalité est incertaine, pourtant, en tant que développeurs de logiciels, nous sommes censés livrer de nouveaux projets avec certitude. Et pour augmenter nos chances de succès, nous devrions reconnaître l'incertitude et l'incorporer dans notre planification et aussi l'exploiter. Mon objectif avec le travail que je vais
vous montrer est que je crois que même si nous ne pouvons pas contrôler les vagues d'incertitude, nous pouvons apprendre à surfer dessus.
C'est poétique. Et cela s'aligne très bien avec le paradigme du « no estimates ». Pour moi, « no estimates » signifie deux choses. Premièrement, des estimations sans effort, ce qui signifie des estimations faites sans effort, et aussi l'utilisation d'aucune estimation d'effort. De nos jours, la planification déterministe, qui est utilisée, impose de la certitude à une situation incertaine et masque l'incertitude au lieu de la mettre en évidence. Elle est basée sur le premier principe de la gestion scientifique.
De Frederick Taylor, qui dit notamment qu'en principe, il est possible de tout savoir ce que nous devons savoir pour planifier.
C'est la base de la planification déterministe et elle se manifeste par la modélisation des projets en tant que réseau d'activités regroupées en lots de travail dans la structure de découpage du projet. Ainsi, le paradigme de la gestion de projet croit que l'incertitude joue effectivement un rôle,
mais qu'elle peut être éliminée par une planification plus détaillée. C'est pourquoi nous avons ces réseaux, les estimations d'effort, etc., etc. Nous allons remettre en question le paradigme de la gestion de projet.
Et nous suggérerons que, à des fins de planification, il est préférable de modéliser les projets comme un flux d'éléments de travail à travers un système. Voici la définition.
Que nous utiliserons, la définition d'un projet.
Un projet est simplement un lot d'éléments de travail, chacun représentant une valeur indépendante pour le client qui doit être livrée à ou avant la date d'échéance. C'est notre définition pour la planification des projets. Lorsque nous faisons cela, nous n'estimons pas la taille de chaque élément de travail. En fait, nous considérerons qu'il n'y a que deux tailles.
Assez petit et trop grand, et trop grand doit être divisé et ne doit pas être autorisé à entrer dans le backlog.
Voici une animation rapide pour montrer comment nous envisageons en fait un projet circulant à travers un système de développement.
C'est un tableau Kanban et nous avons quelques éléments dans le backlog et nous commençons à travailler, le système travaille dessus et ensuite ils traversent le tableau et finalement ils sont livrés.
C'est notre modèle de projet. Ce que nous allons essayer d'atteindre, c'est d'avoir un plan de haut niveau en utilisant la planification probabiliste. Ainsi, le plan de haut niveau ne planifie que le budget initial et la fourchette de la période pour le projet.
Il ne comprend aucun détail. Les plannings, par exemple, sont créés lors de l'exécution du plan. Et nous essayons de garder le focus sur l'intention du projet en faisant une série de petits choix.
Ensuite, nous évaluons nos actions et, espérons-le, il y a des succès inattendus que nous exploiterons.
Voilà donc la partie exécution du plan de haut niveau. Aujourd'hui, nous nous concentrerons uniquement sur la création du plan de haut niveau. La partie exécution est bien couverte par la méthode Kanban, le cadre Scrum, et tout ce qui s'y apparente. Notre méthode de planification probabiliste sera basée sur la prévision par classe de référence, qui repose sur les travaux de Daniel Kahneman, un psychologue de Princeton, qui a remporté le prix Nobel d'économie en 2002.
Ainsi, la prévision par classe de référence promet une plus grande précision dans les prévisions en adoptant une vision externe des projets à prévoir, basée sur la connaissance des performances réelles dans une classe de référence de projets comparables.
Donc, l'élément important ici, le plus important de mon point de vue et du point de vue Kanban, est que nous allons adopter une vision externe. Nous ne regarderons pas comment les projets ont été exécutés, seront exécutés. Nous regardons de l'extérieur. Et nous allons... essayer de placer le nouveau projet dans une distribution de projets comparables. Cela semble compliqué, mais en fait, encore une fois, l'idée est que tous les calculs sont dans un simple fichier Excel, et vous allez simplement l'utiliser.
Voici, disons, la preuve de la méthode. Ainsi, la prévision par classe de référence se compose de trois étapes. Premièrement, l'identification d'une classe de référence pertinente de projets passés similaires. La classe doit être suffisamment large pour être statistiquement significative, mais en même temps, elle doit être suffisamment étroite pour être comparable aux projets spécifiques sur lesquels nous travaillerons. À l'avenir. La deuxième étape consiste à établir une distribution de probabilité pour la classe de référence sélectionnée. Nous verrons comment faire cela. Et la troisième étape consiste à comparer nos nouveaux projets que nous devons planifier avec la distribution de la classe de référence. Afin d'établir un résultat plus probable pour le nouveau projet. Donc, la première étape consiste à identifier une classe de référence de projets similaires. Nous faisons cela en comparant les projets selon des caractéristiques spécifiques. La première de celles-ci est la structure de l'équipe.
Donc, nous cherchons à savoir si nous avons des projets avec une structure d'équipe comparable. Encore une fois, nous adoptons une vision externe. Donc, très probablement dans notre système, nous avons des équipes qui travaillent effectivement sur des projets, et elles sont assez stables, relativement stables. Donc, nous pouvons comparer le dernier projet sur lequel l'équipe a travaillé avec d'autres projets. Étape suivante, la caractéristique suivante à comparer : les technologies utilisées sont-elles comparables ? L'étape suivante est de savoir si les processus de développement sont comparables, et en particulier le processus de préparation des exigences ou de décomposition du travail en éléments de travail ou en stories. Et aussi, les types de clients sont-ils comparables ?
Par exemple, c'est la même équipe.
Nous aurons une performance différente si elle travaille pour une startup ou pour une entreprise du Fortune 500 en raison de la manière différente
de collaboration avec le client.
Espérons que vous voyez que nous adoptons à nouveau une vision externe et que nous prenons en compte le contexte dans
lequel les projets ont été exécutés et seront exécutés.
Encore une fois, nous adoptons une vision externe.
Bien sûr, nous avons examiné la structure de l'équipe, mais encore une fois, nous regardons de l'extérieur comment la structure de l'équipe est. De plus, nous examinons si les domaines d'activité sont comparables. Il y aura une énorme différence entre le développement par la même équipe de logiciels embarqués pour Arduino ou d'un nouveau système ERP. Différents domaines d'activité. Donc, en supposant que nous avons une telle classe de référence de projets comparables. L'étape suivante consiste à établir une distribution de probabilité pour celle-ci.
Et c'est la partie délicate car cela dépend du planificateur ou de nous quel type de paramètre utiliser. Et la métrique que nous devrions utiliser devrait nous permettre à nouveau d'adopter une vision externe du système de développement. De plus, elle devrait nous permettre de calculer le temps de livraison, car encore une fois, nous essayons de répondre à deux questions : combien de temps et combien, et généralement dans notre métier, combien est proportionnel à combien de temps.
Je le crois. Donc, la première caractéristique est la structure de l'équipe. Nous cherchons à savoir si nous avons des projets avec une structure d'équipe comparable. Et aussi, la métrique doit avoir du sens du point de vue du client. Donc, nous devrions être capables d'aller voir le client et de présenter cette métrique, et elle devrait avoir du sens.
Habituellement, comme hors-sujet, les points d'histoire n'ont aucun sens. Mais le temps... A généralement du sens. Et la métrique que nous allons utiliser s'appelle le temps de takt. Le temps de takt est défini comme le temps moyen entre deux livraisons successives. Il provient de la fabrication, mais dans notre contexte, nous le définirons comme le temps moyen entre deux livraisons successives au client.
Voilà la définition.
Dans quelle unité de temps sera mesuré le temps ? En fabrication, ils mesurent le temps de takt en minutes, en heures, voire en secondes. Dans la production de masse, nous mesurerons le temps de takt en jours. Pour le travail de connaissance, ce sera en jours.
Voici donc une simple animation, ce qu'est réellement le temps. Ceci est la courbe de livraison pour un projet fictif. Chaque boîte jaune représente un élément de travail livré à un moment particulier durant le projet. Encore une fois, nous ne nous intéressons pas à la taille de l'élément de travail ou à quoi que ce soit, ni à la manière dont ils ont été exécutés. C'est juste une vue extérieure.
Quand et combien d'éléments de travail ont été livrés. Donc, sur le côté gauche, nous avons le temps de début du projet et sur le côté droit, la date de fin du projet. Et nous pouvons voir qu'après cinq jours, le premier élément de travail a été livré et son temps de takt était évidemment de cinq jours, n'est-ce pas ? Parce que son temps de takt est à nouveau le temps entre deux livraisons successives. Après sept jours, nous en avons un autre, nous avons livré un autre élément de travail. Mais le même jour, nous en avons un troisième.
Puisque nous mesurons le temps de takt en jours et qu'ils sont livrés le même jour, le deuxième élément de travail aura un temps de takt de zéro jour. Encore une fois, c'est sept jours, donc sept plus zéro font sept, n'est-ce pas ?
Après deux autres jours, trois éléments de travail supplémentaires ont été livrés. Et encore une fois, en suivant la définition, le premier avait un temps de takt de deux jours, mais les deux autres un temps de takt de zéro jour. Et nous pouvons voir comment cela s'est passé et ce que nous avons livré. Et la chose très importante ici, encore une fois, est que lorsque nous additionnons toutes les valeurs du temps de takt pour chacun des éléments de travail, et vous pouvez les voir ci-dessous, cela donne le temps de livraison pour le projet. Dans ce cas, 22 jours. Encore une fois, notre métrique nous permettra de calculer le temps de livraison, tout simplement.
Voici l'histogramme de ce projet fictif, et c'est juste pour illustrer que nous avons des éléments de travail avec différents temps de takt. Beaucoup d'éléments de travail avec un temps de takt de zéro, ce qui signifie qu'ils ont été livrés en parallèle en même temps que quelque chose d'autre. C'est juste pour nous permettre de mieux comprendre le schéma. le temps de retour pour chacun des éléments de travail et vous pouvez les voir ci-dessous, cela donne le temps de livraison pour le projet, dans ce cas 22 jours, encore une fois notre métrique nous permettra de calculer le temps de livraison exactement comme cela
Et voici l'histogramme pour ce projet fictif, et c'est juste pour illustrer que nous avons des éléments de travail avec différents temps de cycle. Beaucoup d'éléments de travail avec un temps de cycle de zéro, ce qui signifie qu'ils ont été livrés en parallèle en même temps qu'autre chose. C'est juste pour nous permettre de mieux comprendre le modèle.
Donc voici la formule pour le temps de cycle si celui-ci est calculé en divisant le temps de livraison du projet par le nombre d'éléments de travail livrés. Et un exemple simple, pour notre projet fictif, le temps de livraison était de 22 jours et nous avons livré 10 histoires. Donc en moyenne, entre deux livraisons successives, nous avions 2,2 jours.
En utilisant la même formule, nous pouvons en fait calculer le temps de livraison pour la prochaine version ou un autre projet. Si nous supposons que pour le prochain projet, nous aurons le même temps de cycle, et que nous connaissons le nombre d'éléments de travail qui doivent être livrés, nous pouvons les multiplier et si nous avons, disons, 45 histoires à livrer la prochaine fois,
cela nous prendra 99 jours, n'est-ce pas ? C'est assez simple. Le point important ici est que cette valeur moyenne, le temps moyen entre deux livraisons successives, est effectivement une moyenne, et c'est une moyenne non qualifiée sans aucune variance.
ce qui est quelque chose que nous ne devrions pas utiliser.
En principe, mais parce que nous suivons la prévision par classe de référence, cela nous oblige à avoir une distribution de probabilité de cette valeur. Donc nous avons besoin de cette valeur, la distribution du temps de cycle, d'une manière ou d'une autre nous en avons besoin pour suivre la méthode. Donc encore une fois, mathématiquement, ce n'est pas un calcul crédible d'utiliser uniquement la valeur moyenne. Mais même d'un point de vue pratique, nous avons besoin de la distribution. C'est assez difficile parce que pour notre projet fictif, nous n'avions que 10 éléments de travail. Et ceux parmi vous qui sont conscients de... Statistiquement, vous devriez savoir que 10 événements ne sont pas suffisants, n'est-ce pas, pour revendiquer une distribution.
Nous allons utiliser une technique appelée bootstrapping. Donc le bootstrapping, il a été inventé par Bradley Efron. C'est une méthode mathématique bien connue. Elle est basée sur l'hypothèse qu'un échantillon aléatoire est une bonne représentation de la population inconnue, ce qui dans notre cas signifie que si nous avons ces 10 éléments de travail, nous supposons qu'ils sont une bonne représentation des milliers d'éléments de travail. que nous aurions si notre projet avait plus de 10 éléments de travail, disons 2000 éléments de travail. Encore une fois, nous adoptons une vue externe sur le système ici même. Nous ne regardons pas ce qui se passe à l'intérieur.
Le bootstrapping ne remplace pas ou n'ajoute pas de données aux données originales. C'est la méthode mathématique. Vous pouvez chercher sur Google et vous pouvez chercher plus de détails.
Et elle est basée sur l'hypothèse d'indépendance, ce qui est un sujet énorme ici. Je ne vais pas passer de temps ici sur ce point, mais si vos user stories ont été préparées en utilisant le mnémonique INVEST, qui connaît le mnémonique INVEST ? Indépendant, d'accord. Donc elles seront considérées comme indépendantes.
Voici donc la méthode pour appliquer le bootstrapping afin de préparer la distribution du temps de cycle moyen. Donc d'abord, nous avons cet échantillon.
La présentation est sur internet et elle sera disponible. Donc en général, nous avons l'échantillon des valeurs de temps de cycle. Nous avons le nombre d'éléments de travail livrés. Et nous tirons au hasard avec remplacement. Des valeurs de cet échantillon, nous calculons le temps de livraison pour chacun des échantillonnages que nous avons.
Et nous répétons cela de nombreuses fois.
Voici une rapide animation, juste pour faciliter la compréhension. Donc TTI, là, vous voyez 0, 0, 0, 1, 1, 1, 5, 7, c'est notre échantillon de notre projet fictif. C'est ce que nous avons. Et il ne contient que 10 points de données. Nous en voulons au moins 1000.
Quand nous les additionnons, le temps de livraison était de 22 jours et le temps moyen entre deux livraisons successives dans notre cas était de 2,2 jours. Ce que nous allons faire, vous le verrez dans Excel comme vous le verrez plus tard, nous tirons un échantillon avec remplacement. Tirer un échantillon avec remplacement signifie que nous tirons au hasard 10 fois à partir de ce tableau. De 10 événements
Et voici un échantillon, ce qui pourrait se produire. Et ensuite, nous utilisons cette formule et nous calculons le temps moyen entre deux livraisons successives pour cet échantillonnage particulier. Donc nous tirons 10 éléments et nous les remettons. C'est avec remplacement, n'est-ce pas ? Nous les remettons dans le seau. Ensuite, nous faisons cela 998 fois.
Et finalement mille fois. Et les mille fois, c'est exactement la même chose. Nous tirons avec remplacement 10 de ces événements. Nous calculons le temps de livraison pour le projet. Nous divisons par le nombre d'éléments de travail et nous obtenons la valeur moyenne. Donc l'idée ici est que cet échantillon et cet échantillon ci-dessus représentent une probabilité de temps de livraison pour notre projet.
Encore une fois, nous tirons des temps de livraison probables pour notre projet. C'est pourquoi nous avions besoin de la métrique pour nous permettre de calculer le temps de livraison pour notre projet. Donc quand nous additionnons tous les temps, toutes les valeurs de temps de cycle, nous obtenons le temps de livraison. Des questions ici ?
Oui ?
Quand vous faites l'échantillon, est-ce que vous tirez ?
Du tableau là-bas, n'est-ce pas ? 0, 0, 0, 1. Totalement au hasard. Totalement au hasard. En utilisant une distribution uniforme, si vous demandez, comme Excel, par défaut, utilise une distribution aléatoire pour générer des nombres aléatoires. Donc ce que je fais, c'est que j'ai 10 nombres, et j'en choisis un au hasard. Et je note simplement la valeur, j'en choisis un autre 10 fois, et je les additionne, et cela fera 21 jours cette fois-ci. Et je le fais presque 990 fois, puis 1000 fois encore la même chose. Donc c'est très facile. Excel est assez bon pour cela, même si le générateur de nombres aléatoires n'est pas si bon. Mais de toute façon, pour notre usage, c'est bon. Et nous avons une distribution de probabilité du temps de livraison pour notre projet. Encore une fois, nous adoptons une vue externe. D'accord ?
Oui, bien sûr.
10 éléments. 10 éléments, oui. Vous tirez exactement le même nombre.
Exactement le même nombre, oui. C'est la variation du bootstrapping que nous allons utiliser, n'est-ce pas ? D'accord. Je vais vous montrer dans Excel. Et le résultat, ce que nous avons, c'est en fait cet histogramme montre la distribution du temps moyen. Et nous pouvons voir que le temps moyen est de 2,19 quelque chose jours, ce qui est presque 2,2 jours. Mais avec la moyenne, nous avons certains percentiles, et nous avons la médiane, par exemple, et l'écart type.
Donc maintenant, nous avons complété la deuxième étape requise par la méthode de prévision par classe de référence, n'est-ce pas ?
Que devrions-nous faire avec cet histogramme ? Encore une fois, l'histogramme représente en réalité mille valeurs. Voilà, mille nombres. Nous devrions le mettre dans une bibliothèque.
Notez le contexte d'où proviennent ces données particulières. Encore une fois, l'équipe, le client, la technologie.
Et ces deux éléments ensemble, nous pouvons l'appeler paquet d'information stochastique. Cela vient du livre Flow of Averages. C'est un assez bon nom. Encore une fois, chaque paquet d'information stochastique contient un ensemble de résultats possibles, des nombres, et le contexte d'où proviennent ces nombres. Donc, c'est une sorte d'empreinte de votre système de développement vue de l'extérieur.
D'accord ? C'est juste un bon nom. Maintenant, la troisième étape de la méthode de prévision par classe de référence consiste à comparer un nouveau projet avec la classe de référence. N'est-ce pas ? Et calculer le temps de livraison, n'est-ce pas ?
Si vous revenez en arrière et vous rappelez un peu, cette formule suppose un taux de livraison linéaire. N'est-ce pas ? 22 jours, 10 éléments de travail, ligne droite. Habituellement, au moins dans mon projet, ce n'est pas le cas. Nous avons un taux de livraison assez différent. Ceci provient d'un projet réel. Et vous pouvez voir qu'il a commencé lentement puis a avancé très rapidement. Et à la fin, il était de nouveau plus lent.
Ce concept s'appelle la courbe en Z et provient d'un livre de David J. Anderson, son premier livre. En bref, il dit que la plupart des projets peuvent être, le taux de livraison peut être divisé en trois phases ou segments.
Et pendant le premier segment, généralement, c'est environ 20 % du temps du projet, mais nous livrons seulement 5 % du travail. La troisième étape est quelque chose comme ça. Encore une fois, 20 % du temps. Encore une fois, 5 % du travail. Et le vrai travail est à l'intérieur. 60 % du temps, mais 90 % du travail. Encore une fois, vos projets peuvent être différents.
Peut avoir seulement deux segments. Sans aucun défaut, par exemple, n'est-ce pas ? Mais, ou peut avoir un taux de livraison linéaire pour la prochaine version du même projet, n'est-ce pas ? Le même produit. Examinons chacun des segments. Donc chaque segment de la courbe en Z est caractérisé, premièrement, par un type de travail différent. Vous verrez quelle différence il y a, un niveau de variation différent, très important. Et un effectif différent en termes de nombre de personnes et de niveau d'expertise. Donc le deuxième segment de la courbe en Z représente le système lui-même. C'est une variation de cause commune que nous voyons ici. Le premier et le troisième segment, ce sont des événements spéciaux qui surviennent dans le projet. Par exemple, donc la première étape, généralement, vous pouvez l'appeler temps de mise en place. Généralement, l'équipe gravit la courbe d'apprentissage ou mène des expériences pour couvrir les éléments les plus risqués ou fait de l'innovation. Mise en place des environnements, adaptation à la culture et aux procédures du client, compréhension d'un nouveau domaine d'activité, maîtrise d'une nouvelle technologie, etc. C'est pourquoi peu de travail est livré, n'est-ce pas ? Beaucoup de réflexion, moins de livraison. Le deuxième segment, c'est la période de productivité, et si le projet est bien planifié, il devrait fonctionner comme une horloge, à un rythme soutenable, sans stress, sans surprises. Et le troisième segment est pour le nettoyage. L'équipe nettoiera le champ de bataille, corrigera certains défauts en suspens, soutiendra la transition du livrable en production. Et si nous... Additionnons les temps pour chacun des segments, nous obtiendrons le temps total du projet, n'est-ce pas ?
C'est logiquement simple. Donc la durée du premier segment, plus la durée du deuxième, plus la durée du troisième segment, nous donne en fait le temps de livraison pour l'ensemble du projet. Et ayant la formule pour le temps de cycle, lorsque nous substituons le temps de livraison pour chacun des segments, nous pouvons calculer le temps de livraison pour le projet en utilisant le nombre d'éléments de travail livrés dans la première phase multiplié par le temps de cycle pour la première phase plus le nombre d' éléments de travail livrés dans la deuxième phase multiplié par le temps de cycle pour la deuxième phase. Et bien sûr, plus le nombre d'éléments de travail livrés pendant la troisième phase multiplié par le temps pour la troisième phase, n'est-ce pas ? Mais encore une fois, ce que nous avons ici, ce sont des valeurs moyennes pour le temps de cycle, n'est-ce pas ? Ce qui est incorrect. Mathématiquement, c'est incorrect. Nous ne devrions pas utiliser cela. Nous utiliserons la simulation de Monte Carlo afin de sommer ces variables aléatoires, qui sont en fait représentées par les temps de cycle moyens.
Disons que nous avons un, c'est un exemple de,
planification d'un nouveau projet.
Disons que nous avons un nouveau projet qui est le même que, nous avons une classe de référence de tels projets dans notre base de données. Et le nouveau projet est pour la même entreprise, le même client, la même organisation l'utilise.
Souvenez-vous de la structure de l'équipe et de tout le reste. C'est la même technologie. Et nous pouvons supposer en toute sécurité que l'organisation de développement livrera ce projet de la même manière qu'elle a livré les précédents. Voici les distributions du temps de cycle pour chacun des segments de la courbe en Z. par les temps moyens.
Disons que nous avons un exemple, c'est un exemple de calcul, de planification d'un nouveau projet. Disons que nous avons un nouveau projet qui est similaire à ceux que nous avons dans une classe de référence de tels projets dans notre base de données.
Et le nouveau projet est pour la même entreprise, le même client, la même organisation l'utilise. Rappelez-vous la structure de l'équipe et tout le reste. C'est la même technologie. Et nous pouvons supposer en toute sécurité que l'organisation de développement livrera ce projet de la même manière qu'elle a livré les précédents.
Voici la distribution du temps de cycle pour chacune des phases de la courbe en Z. Cela se trouve dans notre base de données stochastique. Nous les avons. Et nous supposons que le nouveau projet suivra le même schéma. Encore une fois, nous adoptons une vision externe. Nous supposons que l'organisation de développement livrera de la même manière.
Et ce que nous devons faire, c'est en fait de les additionner d'une certaine manière. Ce qui est important, c'est que comme il s'agit de notre nouveau projet, nous devons décider combien, la quantité de travail qui sera livrée pendant la première phase, pendant la deuxième phase, et pendant la troisième phase. Et pour cette planification particulière, je vais supposer que 12 histoires seront livrées pendant la première phase, 70 histoires, la majorité du travail, seront livrées pendant la deuxième phase, et 18 histoires seront livrées pendant la troisième phase. Ce qui est important, c'est que vous devriez prendre en compte le coût du retard, d'autres éléments de travail à cet égard, et la charge de défaillance. Mais cela sort du sujet de cette simulation. La manière dont vous allez décomposer le travail sort de ce cadre. Je crois que chaque organisation a une sorte de procédure qu'elle utilise de manière régulière, une méthode, et il y a une façon de décomposer le périmètre. Donc, nous n'allons pas examiner comment.
Voici une visualisation de ce que nous allons essayer de faire. Donc, nous devons livrer 12 éléments de travail pendant la première phase de la courbe en Z, la phase d'innovation, la phase de mise en place, 70 éléments de travail pendant la deuxième phase, la phase de productivité, et 18 pendant la troisième phase. Encore une fois, notre projet pourrait avoir, nous pourrions décider qu'il n'y aura pas d'innovation. Nous commençons simplement à travailler, n'est-ce pas ? Pas de première phase de la courbe en Z. Zéro élément de travail. Nous ne nous en soucions pas. Ou pas de défauts, rien. Nous pouvons mettre zéro ici, n'est-ce pas ? Mais c'est le cas général. Nous avons trois phases, d'accord ? Des questions ici ? Donc, ce que nous devons faire, c'est additionner
des variables aléatoires, ces distributions. Bien que mathématiquement ce ne soit pas correct de dire que nous ne pouvons pas additionner des distributions, mais nous pouvons additionner des fonctions génératrices de probabilité. Donc, lorsque nous calculons cela, cela nous donnera la distribution du temps de livraison pour notre nouveau projet.
Voici comment nous le faisons, n'est-ce pas ? Nous avons le temps de cycle SIP qui représente les distributions que nous avons vues précédemment pour chacune des phases.
Nous tirons de la distribution une valeur à la fois. Nous utilisons la formule que nous avons vue avec la valeur moyenne du temps de cycle.
Et nous obtenons un temps de livraison probable pour notre projet. Nous faisons cela 49 090, 98 fois, et finalement 50 000 fois.
Encore une fois, presque comme le bootstrap. Nous calculons simplement un temps de livraison probable. Dans ce cas, nous obtiendrons 50 000 temps de livraison probables pour notre projet.
Que nous pouvons présenter sous forme d'histogramme.
Donc, le point important ici est que le temps de livraison moyen est de 78 jours. Cela est basé sur des données réelles. Les distributions que vous avez vues proviennent de mes classes de référence.
Donc, le temps moyen est de 78 jours. Le 85ème percentile est de 90 jours.
Et c'est à vous maintenant de savoir comment utiliser cet histogramme, ces données. Vous pouvez dire que nous nous engageons sur le 85ème percentile auprès du client, ou nous pouvons aller voir le client avec cette distribution et dire, voici notre prévision pour le temps de livraison de votre projet. Parlons-en, d'accord ? Et il y a beaucoup de présentations sur la façon d'utiliser cela. C'est très utile.
Encore une fois, nous adoptons une vision externe lors de la prévision d'un nouveau projet, et cela produira des résultats plus précis.
Plus rapide, beaucoup plus rapide, que d'utiliser la vision déterministe interne.
Encore une fois, parce que nous avons les données des classes de référence et que nous les utilisons simplement, n'est-ce pas ?
Voici les livres auxquels il est bon de prêter attention. Le livre Kanban, David J. Le premier livre d'Anderson sur la courbe en Z et quelques autres sujets. Flow of Averages, un très bon livre. Et un livre du Professeur Fleaberg sur la prévision par classe de référence appliquée à la prévision de projets.
Maintenant, voyons, il nous reste 30 minutes, je crois.
Voici mes données de classe de référence.
Celles que je vous ai montrées, cela provient d'un projet réel. Vous voyez, la première phase de la courbe en Z et une gamme de valeurs. Deuxième phase de la courbe en Z, gamme de valeurs. Troisième phase de la courbe en Z, gamme de valeurs. Temps de cycle moyen pour chacune des phases, ce sont des données réelles. J'ai obtenu cela en utilisant le Bootstrap, et je vais vous montrer comment c'est fait dans Excel, mais disons que nous avons ces données, et nous voulons prévoir notre projet assez rapidement, aussi vite que possible. Donc, les données, vous voyez, 1 000 valeurs. J'ai 1 000 valeurs pour chacune des phases.
C'est mon ensemble d'informations stochastiques. Il est unique à mon contexte. N'est-ce pas ? Mille. Juste pour montrer.
Mille valeurs, n'est-ce pas ?
Eh bien, ce que nous voulons prévoir, c'est ce nouveau projet. Nous avons décidé que nous livrerions 12 éléments de travail pendant la première phase, 70 éléments de travail pendant la deuxième phase, et 18 pendant la troisième phase. C'est mon entrée. C'est la seule chose que je vais entrer ici. C'est pourquoi c'est surligné en jaune. C'est la seule chose que je vais entrer.
Et ce que je vais faire, je veux ceci
réfléchir, n'est-ce pas ? Ce qui est, oui, vous pouvez voir la médiane, l'écart type, la moyenne et autres. C'est ce dont j'ai besoin. Comment puis-je faire cela ? Je vais dans le calcul et je dis calculer la feuille.
Je l'exécute 50 000 fois. Je peux l'exécuter un million de fois, et Excel n'est pas très bon pour cela, n'est-ce pas ?
Les chiffres changent un peu, si vous voyez. Mais faites attention à la moyenne et au 85ème percentile, à quel point cela va changer.
85 %, ça change un peu, n'est-ce pas ? Parce que nous n'avons que 50 000 exécutions de cette simulation. S'il y en a un million, cela ne changera pas du tout, n'est-ce pas ? Allons changer notre décision. En fait, nous livrerons 15 éléments de travail pendant la première phase.
Nous aurons un peu moins de défauts cette fois-ci. C'est notre décision, n'est-ce pas ?
Et retournons en arrière.
Voyons ce qui va se passer.
Terminé. Oh, assez rapide, n'est-ce pas ?
Ça change un peu, n'est-ce pas ? Ça a un peu changé, mais juste un peu. Et cela est basé sur mes données. Je ne sais vraiment pas. Je ne regarde pas comment l'équipe va travailler, n'est-ce pas ? Je prends une vue extérieure. Voyez, je crois que c'est assez rapide. Mettons ici 100 éléments de travail.
Donc je vous ai présenté le tapis, mais l'idée est que le tapis est à l'intérieur d'un outil, et nous l'utilisons simplement. Vous voyez ?
D'accord, des questions ici ? Il y a du temps pour les questions.
Pour moi, le problème est qu'il faut beaucoup de travail pour avoir suffisamment de données afin de faire le calcul.
Exactement, c'est pour cela que nous avons Excel.
Vous devez collecter des données dans les mêmes conditions, donc vous devez avoir la même équipe pour travailler.
Comparable, comme la chose la plus importante est qu'elles soient comparables, n'est-ce pas ? Cela pourrait être la même chose, et encore une fois, ce n'est pas l'équipe, la structure, n'est-ce pas ?
Mais vous avez aussi beaucoup de paramètres.
Exact. Oui, le contexte doit être comparable, n'est-ce pas ? Si je viens dans votre entreprise et que je commence à planifier à votre place en utilisant mes données de Bulgarie, cela n'aura pas de sens, n'est-ce pas ? Donc je crois qu'il est naturel de prendre le contexte en compte, n'est-ce pas ?
C'est votre organisation. Donc l'idée ici et la prévision par classe de référence est basée sur la notion que nous gérons des organisations. Et le prochain projet que l'organisation livrera sera... Eh bien, c'est la même organisation, n'est-ce pas ? Si la technologie est comparable, si la structure de l'équipe est comparable, si le client est comparable, si la technologie est comparable, et bien sûr, nous avons fait quelques analyses ici, combien d'éléments de travail seront livrés, n'est-ce pas ? Nous faisons un peu de travail ici, n'est-ce pas ? Il faut environ deux secondes pour obtenir le temps de livraison. Et c'est la manière la plus rapide dont je suis conscient, n'est-ce pas ? Mais encore une fois, nous avons des données à collecter ici, n'est-ce pas ? Nous avons ici des milliers d'éléments. Habituellement, un projet, alors comment Comment pouvons-nous faire cela ? Je crois que nous avons 20 minutes, donc nous avons... Donc ce sont mes données initiales. C'est un projet réel d'il y a environ trois ans. Ce dont j'ai besoin pour préparer ce package stochastique, ce sont seulement les temps de livraison, comme les dates, et combien d'éléments de travail nous avons livrés à cela. Donc vous pouvez voir que dans ce projet particulier, nous avons livré 78 fois.
78 fois.
C'est ce dont j'ai besoin comme entrée. Encore une fois, je prends une vue extérieure. Et encore une fois, point très important. Cette méthode n'est pas l'évangile, n'est-ce pas ? C'est en prenant une vue extérieure. Ensuite, vous pouvez préparer le réseau du projet, exécuter une simulation ou autre chose, obtenir un nombre différent, Comparer les deux nombres, n'est-ce pas ? Mais ceci est d'une perspective extérieure. Encore une fois, en Kanban, nous n'estimons pas. Nous prenons ici une perspective systémique. Il peut y avoir d'autres perspectives. À l'intérieur, nous pouvons regarder à l'intérieur si nous le pouvons, si nous avons le temps. Nous pouvons regarder à l'intérieur et comparer. Ce n'est qu'un autre outil, encore une fois, n'est-ce pas ? Donc c'est notre entrée.
Ce qui nous intéresse, c'est combien des éléments de travail ont été livrés. Comme nous avons besoin, rappelez-vous, du temps entre deux livraisons successives, n'est-ce pas ? Nous avons les livraisons, le nombre de livraisons. Nous avons les données, la date à laquelle elles ont été livrées. Donc c'est très simple, vous pouvez voir les formules. Et encore une fois, c'est un Excel que je partage, sur la façon de calculer le temps d'attaque. Et ici nous avons deux jours, quatre jours, quatre jours, et ici je calcule simplement le nombre d'éléments livrés en parallèle parce que le temps d'attaque est zéro, n'est-ce pas ? Et ce avec quoi je finis, si vous vous en souvenez, c'est cet histogramme. C'est pour le projet réel. 160 éléments de travail livrés en parallèle. Mais nous en avons un livré comme 21 jours. Après le précédent, n'est-ce pas ? C'était dans la première phase, une expérience que nous avons menée, un prototype. Donc c'est assez différent.
Et ce que je fais, je dis, eh bien, laissez-moi calculer la distribution seulement pour la première phase. Et parce que je connais le projet, Je descends, descends, descends, et je dis, eh bien, jusqu'à ce point, c'était notre première phase, n'est-ce pas ? Voyez, c'est une mise en évidence différente. Je connais le projet, je prépare les données pour celui-ci, n'est-ce pas ? Après cela, nous avons commencé comme la deuxième phase, n'est-ce pas ? Et ce que je fais, je copie ces données d'ici, juste une copie, et je les colle dans ceci Donc c'est assez différent. Et ce que je fais, je dis, eh bien, laissez-moi calculer la distribution uniquement pour la première étape. Et comme je connais le projet, je descends, descends, descends, et je dis, eh bien, jusqu'à ce point, C'était notre première étape, n'est-ce pas ? Voyez, c'est une mise en évidence différente.
Je connais le projet, je prépare les données pour celui-ci, n'est-ce pas ? Après cela, nous avons commencé tout comme la deuxième phase, n'est-ce pas ? Et ce que je fais, je copie ces données d'ici, je copie simplement, et je les colle dans ceci
dans ceci, comme, combien en avons-nous ? 42 éléments de travail, n'est-ce pas ? Le deuxième dans la première étape. Et en utilisant Excel, c'est une formule très simple. Et si vous vérifiez ce qu'Excel fait ici,
J'ai 42 événements et je fais en moyenne 42 échantillonnages aléatoires. Et la formule dans Excel est comme, ce que je fais, c'est que je dis à Excel de me donner une de ces 42 valeurs au hasard.
et la placer ici, et ici, et ici à nouveau. C'est un échantillon, n'est-ce pas ? C'est un échantillon. Et ici,
C'est la formule que je connais, en fait, la formule que j'utilise, quand j'ai cet échantillon, je le somme. Vous pouvez voir que c'est la somme de l'échantillon. Et vous pouvez voir un délai différent pour cette première étape.
Cela pourrait être 66 jours ou 150 jours, n'est-ce pas ? Et je le fais mille fois.
Et voici la distribution du temps moyen, encore 1 000 valeurs. Et comment je peux calculer ceci, c'est ce que je cherche.
Où il est.
Temps de livraison.
PDF. Oui, donc c'est la distribution du temps de balise pour la première étape. Et voici la fréquence, ici, sur le côté gauche. Et ce que je devrais faire, je vais simplement dire calculer la feuille, et elle commence à simuler mille fois. Vous voyez ? Et je peux le faire,
Le mieux est de le faire 50 000 fois, n'est-ce pas ? Mais comme c'est à des fins d'illustration, ce n'est pas le cas. Et je peux le faire plusieurs fois, n'est-ce pas ? Et vous pouvez, si vous vérifiez ici, la courbe change, mais
Les paramètres statistiques ne changent pas. Si je l'exécute à nouveau, voyez, c'est pour la moyenne. Donc ça va, oui, ça change un peu, n'est-ce pas ?
Mais pas tant que ça. Je fais la même chose pour la deuxième étape.
Oui, ceci est pour la deuxième étape, et ensuite je le fais pour la troisième étape.
Je prends ces mille valeurs d'ici, juste ici, et je copie et je les colle dans un nouveau fichier ici.
Le bootstrap.
Lequel, quoi ?
Le rééchantillonnage.
D'accord, donc ici dans ce rééchantillonnage, ce que nous faisons, nous sélectionnons une valeur au hasard dans cette colonne, n'est-ce pas ? Ce sont nos données.
Ce sont des valeurs réelles.
Ce sont des valeurs réelles, et nous en prenons une au hasard, d'accord ?
Non, au hasard dans cette liste. Vous voyez, s'exécute entre un. Donc ce que je dis, disons, Excel, voici les numéros de séquence de mon échantillon.
Dis-moi quel numéro de séquence, juste un numéro au hasard. Excel dit, eh bien, 10.
La valeur pour la 10ème valeur est 1. La prochaine fois, 18. La valeur est 0, n'est-ce pas ? Donc c'est pourquoi le générateur aléatoire dans Excel utilise la distribution uniforme, ce qui signifie... Que nous avons une distribution similaire, n'est-ce pas ? Entre 1 et 42.
C'est intégré. Et quand nous avons ceci, la liste, nous additionnons la liste. Dans ce cas, c'est 36. C'est l'un des délais probables
pour cette
courbe, n'est-ce pas ? Pour cette étape du projet, de la courbe en Z. Et nous allons ici, et c'est une fonction dans Excel appelée table, que l'on peut dire comme, faire une dissémination, qui sont les valeurs d'ici à ici. Fais-le pour moi automatiquement.
Oui.
Avez-vous comparé le résultat de la simulation à la fin du projet ? Avez-vous comparé la simulation avec la durée réelle du projet ?
Oui, et c'est une bonne question. Oui. Donc ici, vous pouvez voir la durée de la première étape de la courbe en Z.
N'est-ce pas ? La durée de la première étape. Le temps de livraison. Ceci est la distribution du temps de livraison pour la première étape. Mais nous savons en fait combien de jours la première étape a pris. N'est-ce pas ? Et ici, nous pouvons voir que le temps moyen issu de la distribution devrait être de 31,6 jours.
Voyons combien de temps cela a réellement pris.
Cela a pris 32 jours. C'est la réalité.
Notre simulation en fait, encore une fois, le bootstrap n'ajoute ni ne retire aucune donnée.
Il utilise simplement les données disponibles afin de préparer la distribution.
Et il est attendu que ce soit comme ça, n'est-ce pas ? La moyenne restera la même. La valeur moyenne devrait rester la même. C'est attendu.
Et si nous allons ici,
Je l'ai dans un autre fichier pour un projet réel, mais j'ai eu des cas où la durée totale du projet en fait, quand je prépare la distribution de probabilité pour l'ensemble du projet et ensuite je reviens à la réalité, Et j'ai trouvé qu'en fait, d'un point de vue probabiliste, nous n'avions que 40 % de chances de livrer dans le délai que nous avons respecté, n'est-ce pas ? Parce que ce qui est très important ici, c'est que les gens, nous oublions souvent cela, c'est que
Donc ce projet
La valeur médiane est de 88 jours. Le 85ème percentile est de 130 jours. La médiane signifie que 50 % du temps, nous livrerons en 88 jours ou moins. Quand nous disons qu'il y a 50 % de chances de livrer, et en réalité, ce que nous entendons, c'est 50 % de chances d'échec, n'est-ce pas ? C'est comme si nous entendions échec, 50 % du temps nous échouerons. Mais la vérité est que 50 % du temps, nous serons en dessous de 88 jours.
Et nous pouvons utiliser cette information selon la situation, n'est-ce pas ?
J'utilise généralement le 85ème percentile lorsque je dois prendre un engagement ou quelque chose de similaire. Parce que le 95ème percentile est assez élevé.
C'est trop conservateur, n'est-ce pas ? Et encore une fois, si vous avez entendu Don Reinertsen, en fait, la variabilité est là où nous gagnons de l'argent, n'est-ce pas ? Donc si nous disons toujours, eh bien, nous livrerons définitivement en 115 jours, nous serons définitivement livrés, n'est-ce pas ? Mais qui gagnera de l'argent, n'est-ce pas ? Nous ne gagnerons pas d'argent. Donc nous devrions utiliser cette information, n'est-ce pas, que 50 % du temps, ce sera moins de 88 jours, d'accord ? Et vous pouvez l'utiliser de différentes manières. Il existe des contrats qui sont appelés fixes. Plus incitatif. Donc vous pouvez dire, fixons-le à 103 jours. C'est un exemple, n'est-ce pas ? C'est à vous de décider. Mais si nous livrons en moins de 88 jours, nous avons un bonus.
Ce n'est qu'une idée, n'est-ce pas ? Cela dépend de votre situation. Mais avoir ces données, c'est bien mieux que de n'avoir rien, n'est-ce pas ? Et encore une fois, ces données sont censées être basées sur la performance réelle de vos organisations.
Donc cette méthode a été utilisée pour la première fois. C'était pour prévoir des projets. Ce n'était pas pour le logiciel. C'est pour la prévision.
Des projets de construction de l'ordre de centaines de millions de livres.
Si vous allez lire l'idée derrière la prévision par classe de référence, elle tente d'éviter certains biais cognitifs, principalement un biais appelé biais de planification.
Mais c'est hors sujet ici. Encore une fois, c'est pourquoi nous adoptons une vue externe. Nous n'entrons pas dans les détails, nous ne faisons aucune estimation d'effort, nous ne demandons pas aux gens combien de temps cela prendra ou quoi que ce soit de ce genre. Nous pouvons y aller après avoir obtenu cela et dire, eh bien, combien de temps pensez-vous que ce projet prendra ? Et peut-être que l'expert, notre expert, dira, eh bien, environ 90 jours, n'est-ce pas ? C'est mon intuition, n'est-ce pas ? Et c'est une autre prévision. Mais celle-ci, encore une fois, est basée sur un solide fondement mathématique.
Censée utiliser vos données réelles, ce qui est vraiment simple, n'est-ce pas ? Rappelez-vous, nous avons seulement besoin de savoir quand et combien vous avez livré. C'est tout.
Désolé, je suis plutôt technique, mais où utilisez-vous le temps de cycle et par exemple, le temps de traversée, le temps de cycle, ou est-ce autre chose ?
Ce n'est pas dans cette méthode, n'est-ce pas ? Mais le débit est la valeur réciproque du temps de cycle, n'est-ce pas ? Donc vous pouvez le remplacer en toute sécurité, mais c'est les mêmes résultats, n'est-ce pas ? Si vous préférez le débit. J'aime le temps de cycle parce que je peux le sommer très facilement, n'est-ce pas ? Et la sommation, nous pouvons remplacer.
Les choses, nous pouvons enlever une des choses, pour ne pas les additionner. Comme c'est vraiment sûr d'un point de vue statistique de sommer les choses. Diviser, multiplier, ce n'est pas toujours sûr. Mais la sommation est toujours sûre. C'est la manière la plus sûre. Et encore une fois,
Juste pour...
Veuillez aller sur SlideShare.
Quand vous tapez 'no estimates', cette présentation sera en tête de liste. Si vous tapez 'reference class forecasting', elle sera troisième de la liste.
Il y a les liens vers les deux fichiers que je viens de vous montrer. Les fichiers Excel sont là. J'ai préparé des vidéos sur la façon d'utiliser ces fichiers. Comme si vous oubliez probablement comment faire, c'est possible, n'est-ce pas ? Vous pouvez consulter les livres, surtout celui-ci.
Et l'autre, c'est, oui ?
Si vous n'aimez pas cette version, ce que je ne vois pas pourquoi vous ne l'aimeriez pas, mais Troy McGinnis a une autre version qu'il a mise sur GitHub. Donc si vous regardez le compte GitHub de Troy McGinnis, il en a une autre. Vous pourriez exécuter les deux et comparer les résultats. Ce serait amusant.
L'autre chose que j'allais dire, c'est que j'aime vraiment les systèmes qui sont faciles à manipuler et de manière à ce que la manipulation produise en fait le type de résultat que vous recherchez. Donc c'est assez évident à voir de la part des équipes de développement.
Vous réduisez simplement votre story en un petit temps. Nous voulons cela. C'est une bonne chose. Donc c'est une sorte d'encouragement à la valeur dont nous avons réellement besoin. Donc je suis tout à fait pour les choses qui sont faciles à obtenir si elles produisent le bon type de résultats.
D'accord.
Une dernière chose si je peux. C'est la théorie en tête de liste pour 'no estimates', mais c'est en fait ça. Votre courbe en Z fait un sacré bon cas pour expliquer pourquoi vous ne devriez pas vous embêter avec les projets. Exactement.
D'accord, d'accord.
Juste à propos de cette manipulation du système. En fait, même si, si vous y pensez, même si le développeur décide de diviser, de produire deux fois plus d'éléments de travail, n'est-ce pas ? Diviser le périmètre du produit en deux fois plus d'éléments de travail, d'un point de vue extérieur, il n'y aura aucun changement, à condition en fait que vous preniez des données après qu'ils aient décidé de faire des éléments de travail plus petits, n'est-ce pas ?
Mais Joshua a raison. Par exemple, nous avons des données quand ils ont utilisé une méthode pour diviser le travail accompli, disons, quelle méthode ? Product sushi. D'accord, si vous êtes au courant. Une méthode. Et puis ils décident d'utiliser une autre méthode. Si vous revenez en arrière, cela invalidera en fait nos données parce que la méthode pour diviser le travail accompli a changé. Nos données sont invalides à partir de ce moment-là. Nous devons collecter plus de données, n'est-ce pas ?
Nous n'avons besoin que d'un peu de données.
Oui, oui, mais nos données sont invalides. Donc le contexte est très important. Ici, il est montré que le contexte est roi.
Donc, cela accusera un retard, la nouvelle méthode accusera un retard de 11 jours.
Oui, oui.
Et vous pouvez l'utiliser avec la planification Scrum, la planification de release. Nous pouvons l'utiliser avec XP, les systèmes Kanban, le cycle en V, n'importe quoi. Pourquoi ? Parce que nous adoptons une vue externe. Encore une fois, une vue externe. Nous ne nous soucions pas du fonctionnement interne du système. Nous observons simplement de l'extérieur. Et encore une fois, ceci n'est qu'une méthode. Vous pouvez utiliser n'importe quoi de ce genre, apparemment pour quelque chose de différent, mais ceci est quelque chose de très simple, très rapide, et statistiquement solide.
D'autres questions ?