Lors du calcul de la durée du projet, nous évaluons traditionnellement la durée des étapes intermédiaires, puis les résumons et ajoutons un tampon pour toutes sortes d'accidents. Ensuite, la direction nous coupe cette période de moitié. Dans le cadre de cette note, l'auteur sera intéressé par nos calculs, car même un chef de projet ayant une vaste expérience comprend souvent que la période calculée est trop courte et beaucoup, parfois parfois, en contradiction avec son expertise personnelle. Oui, il corrigera les estimations des termes du projet et des étapes intermédiaires à son expertise et, avec une véritable maîtrise avec un certain traitement, respectera le délai avec une précision de 15%, mais les sédiments resteront.
Cette note explique la raison de l'écart entre les estimations d'experts et les estimations théoriquement calculées. On considère également pourquoi l'évaluation d'experts «surévaluée» est généralement sous-estimée si elle n'est pas effectuée sur la base de statistiques sur la mise en œuvre de projets similaires. En fin de compte, il est révélé comment calculer correctement la durée du projet et expliquer la situation aux parties intéressées avant le début du projet ou pendant le projet.
La racine de l'erreur
Lorsque nous évaluons la période de mise en œuvre d'un travail, nous déterminons le chiffre le plus probable. Il peut s'agir d'une expertise sur un point ou sur trois points, comme dans PERT. Dans un projet complexe, cela peut être une modélisation paramétrique. Dans tous les cas, nous faisons la même erreur. Le fait est que dans toutes les méthodes d'estimation classiques, on suppose que nous avons une distribution normale de la valeur estimée - selon Gauss. Les théoriciens aiment beaucoup cette distribution.
Une distribution normale signifie qu'un projet d'une durée correctement estimée de 6 mois est également susceptible de s'achever en 9 mois ou 3 mois. À égale distance du centre de distribution, la probabilité de réalisation du projet est égale - c'est une caractéristique de la courbe de Gauss. En revanche, dans la pratique, peu de gens ont vu un projet informatique qui s'est terminé deux fois plus vite (après 3 mois), mais des projets qui sont retardés d'une fois et demie en termes (9 mois), nous voyons régulièrement. De plus, avec une distribution normale, la moitié de nos projets se termineraient avant l'heure prévue, et l'autre moitié après. Mais cela n'est pas non plus observé dans la pratique. Cela suggère que la distribution normale pour l'estimation des délais n'est pas applicable. Autrement dit, nous n'avons pas de distribution normale, mais une autre, avec une probabilité d'achèvement différente avant la date la plus probable et après.
Considérez la distribution lognormale comme exemple d'une telle distribution. Il nous montrera les caractéristiques de cette classe de distributions. Pour la distribution lognormale, la médiane et les attentes mathématiques sont nettement au-delà du pic:
Dans le graphique présenté, le pic montre la plus grande probabilité de date d'achèvement du projet, ce chiffre comprenant généralement ce chiffre plus une certaine marge. La médiane indique un point de séparation auquel la moitié des projets seront achevés avant cette date limite et la seconde moitié après. L'attente mathématique indique la valeur moyenne de la durée du projet. Pour un fragment de travail, la distribution aura les mêmes caractéristiques: une grande différence entre la période la plus attendue pour la mise en œuvre du fragment de travail (les plans sont traditionnellement basés sur elle) et la valeur moyenne du terme.
Pour prédire la durée du projet, nous déterminons la chaîne la plus longue dans le temps et ajoutons la durée de ses fragments. Si nous additionnons les valeurs distribuées selon Gauss, alors en moyenne le terme final correct devrait être obtenu. En effet, la moitié des fragments de l'ouvrage sera achevée plus tôt que prévu, la moitié plus tard et ces hétérogénéités s'annuleront. Plus il y a de fragments, plus les inhomogénéités sont compensées avec précision. De plus, nous pouvons calculer l'erreur et décaler légèrement le délai d'un sigma ou deux, selon les conséquences du délai.
Mais nous n'avons pas de distribution gaussienne. Dans notre pays, l'allongement du temps d'exécution de chaque travail est beaucoup plus probable que le raccourcissement du même montant. Par conséquent, si l'on additionne les délais pour l'achèvement le plus probable de chaque œuvre, les hétérogénéités en terme d'achèvement ne sont pas compensées, mais amplifiées. De plus, ils s'intensifient dans le sens d'un allongement de la durée moyenne réelle du projet par rapport à l'estimation. Ce que nous observons dans la vie réelle: si le premier terme est en retard, alors tous les autres termes seront en retard, tandis que le retard ne fera que s'accroître. Ce n'est qu'en appliquant des efforts supplémentaires que le retard du projet peut être arrêté.
Une caractéristique de cette méthode de calcul est un fait bien connu: plus la fragmentation du travail pour évaluer la durée du projet est petite, moins l'estimation est précise. Bien qu'en théorie, ce devrait être exactement le contraire. La raison en est que notre expertise pour l'ensemble du travail et pour ses éléments constitutifs est tirée de l'expérience. L'expérience évalue chaque élément indépendamment, et non sur la base de l'arithmétique, selon laquelle la durée du travail devrait être la somme des durées de ses parties constituantes. L'arithmétique ne fonctionne pas ici, car la somme des délais les plus probables pour terminer les pièces ne donne pas le délai le plus probable pour terminer tous les travaux - seules les attentes mathématiques peuvent être correctement résumées.
Si nous essayons de déplacer légèrement le terme estimé pour l'ensemble du projet ou de ses parties d'un sigma ou deux, en considérant la distribution comme normale, cela n'aide pas beaucoup, car la queue de distribution est beaucoup plus épaisse que la courbe gaussienne. Par conséquent, en raison d'une telle augmentation de l'estimation du terme, on ne peut même pas atteindre la médiane, sans parler de la valeur moyenne de la durée du projet sous forme d'attente mathématique.
Que faire
D'une part, des attentes mathématiques devraient être ajoutées. D'un autre côté, nous ne sommes pas des mathématiciens. Nous sommes de la vraie vie et nous comprenons le problème du calcul des paramètres des graphiques même quand il y a du temps pour cela et quelques statistiques accumulées. Mais il existe d'autres moyens. En fin de compte, le problème de l'évaluation du calendrier de plus d'une douzaine d'années, et la pratique a appris à travailler avec elle.
Méthode Brooks : nous considérons la période de mise en œuvre du programme «sur le front» (l'utilisateur est le programmeur lui-même) et multiplions par 3 pour le produit logiciel (l'utilisateur est un cercle illimité de personnes) ou le complexe logiciel (dans les réalités actuelles - un ensemble de microservices) et 9 pour le produit logiciel système ( dans les réalités actuelles, un ensemble de composants d'infrastructure connexes). La provenance de ces coefficients est bien théoriquement justifiée dans le premier chapitre du livre de Brooks «Mythical Man-Month» et cette description de 1975 est bien adaptée aux réalités actuelles.
Méthode Scrum : nous introduisons une unité intermédiaire abstraite de la complexité de l'implémentation de la fonctionnelle, nous regardons les statistiques de l'implémentation de la fonctionnelle mesurées dans les unités données de la fonctionnelle, nous demandons à l'équipe d'évaluer la complexité des tâches du projet, de traduire les unités dans l'itération Scrum (sprints) de longueur connue et d'obtenir une estimation des termes pour cette équipe de développement. Comme nous travaillons avec des statistiques réellement collectées et que l'équipe est responsable de ses estimations de la complexité, la liaison de la durée à l'unité de travail est une attente mathématique et donc la moitié des sprints se terminera un peu plus tôt, la moitié un peu plus tard. En pratique, dans la moitié des itérations Scrum, l'équipe devra prendre une partie des tâches, et dans la moitié ajouter des imprévues, de sorte que la durée du sprint reste constante.
Le transfert de l'évaluation Scrum d'une équipe à une autre équipe est un art. Ils ne peuvent être reportés en introduisant simplement un facteur de conversion pour les unités de travail d'une équipe dans les unités de travail de l'autre équipe. Le fait est qu'une équipe a un bon front-end dans sa composition, mais elle n'a pas un bon spécialiste de base, et l'autre équipe a un bon spécialiste de base, mais les tâches de première ligne pour elle sont de plus en plus complexes. Les différences dans la spécialisation des développeurs conduiront au fait qu'en ce qui concerne les tâches backend, une équipe aura un excès de complexité envers les tâches sur la base de données, et l'autre sur le front. De plus, l'équipe elle-même détermine le niveau nécessaire de la qualité interne du produit et différentes équipes le déterminent de manière légèrement différente de celle des équipes voisines, ce qui rend également difficile le recalcul des unités de travail. Autrement dit, il est possible de traduire les unités intermédiaires d'une équipe en unités intermédiaires d'une autre équipe en comparant les estimations de tâches similaires, mais ces tâches doivent être prises à partir de différents types d'activités, en tenant compte des forces et des faiblesses des équipes et en tenant compte des particularités de la mise en place de leur Scrum.
Méthode des éléments fonctionnels : nous introduisons une unité intermédiaire de travail, compilons une liste d'éléments fonctionnels (écrans dans un navigateur, microservices, éléments d'infrastructure personnalisés, etc.), estimons la pénibilité du travail sur chaque élément fonctionnel en unités intermédiaires. Après cela, sur la base de notre expérience d'expert travaillant avec une équipe de développement spécifique, nous évaluons le facteur de conversion de l'unité intermédiaire au fil du temps. Personnellement, j'évalue toujours de manière indépendante les facteurs de conversion pour différents types d'activités: analytique, conception, rédaction d'énoncés de tâches, rédaction de code, mise en page, test, intégration, etc. Après cela, l'ordre des opérations, le temps de retard caractéristique entre la fin de l'opération précédente et le début d'une nouvelle doivent être pris en compte et la durée du projet doit être déterminée par la méthode du chemin critique.
Jusqu'à présent, nous avons travaillé avec les facteurs internes du projet. Mais nous en avons également des externes: des sous-traitants externes, des services connexes, des fournisseurs et le client. Les problèmes avec eux sont exactement les mêmes: ils répondent deux fois ou plus vite ou moins souvent une fois et demie plus longtemps que la valeur la plus probable. Autrement dit, il n'y a pas non plus de distribution temporelle normale. Cela devrait également être établi et pris en compte sur la base de statistiques sur le travail avec les clients, les entrepreneurs et les unités connexes et, si possible, être protégé à l'aide de sanctions.
Justification du temps
Et donc, nous avons estimé la durée projetée du projet. Comment justifier le terme reçu? Sur la base des calculs effectués. Par exemple, l'auteur d'une note pour des projets non Scrum crée généralement un grand tableau visuel multi-lignes dans Google Sheets avec un calcul détaillé par la méthode des éléments fonctionnels. Le calcul est basé sur la pratique, tous les coefficients et paramètres sont visuels, et la pratique pour les parties intéressées est généralement un argument solide et bon, même si cela s'avère être une période inconfortable pour certaines personnes. Surtout la pratique est visuelle et obtenue dans le cadre de la société actuelle.
Les parties prenantes, telles que la direction, seront-elles d'accord avec une évaluation chronologique bien faite et bien informée? Pas toujours, même si les parties intéressées comprennent et réalisent pleinement que l'évaluation est correcte. Parfois, l'évaluation est inacceptable pour des raisons externes, mais c'est déjà une douleur pour les parties intéressées, ce qui entraîne une décision difficile de la direction sur le calendrier. Néanmoins, en voyant les calculs basés sur l'expérience, la direction et les autres parties intéressées ont la possibilité d'influencer de manière prévisible la durée finale du projet en allouant des ressources et des pouvoirs supplémentaires. Parfois, la direction qui comprend la situation temporelle continuera de réduire les délais sans allouer de ressources et d'autorité supplémentaires. Comment vivre avec cela est le sujet d'une note séparée.