BT

Planifier et Contrôler des Projets Complexes

Écrit par Jutta Eckstein , traduit par Vincent Uribe le 31 oct. 2013 |

Je travaille depuis plus de 10 ans sur de vastes et complexes projets agiles. Généralement la planification et la budgétisation dépendent de l'anticipation du développement. Très souvent les stories sont estimées par l'équipe de développement, mais le budget pour l'intégralité du projet est indépendant de ces estimations. Pour les projets complexes, cela apporte souvent des surprises (non-souhaitées). Cependant, la découverte du travail de Daniel Kahneman et des membres de Beyond Budgeting m'a beaucoup aidée à mieux comprendre comment la planification, l'estimation et la budgétisation sont liés et pourquoi les approches traditionnelles ne fonctionnent pas. Bien sûr, nous savons tous comment cela fonctionne à petite échelle, comment planifier et gérer un projet par itérations. Néanmoins, comment décider d'un projet dans sa globalité, comment définir le budget pour lancer un gros projet, et comment savoir de quelle manière vos petites itérations (à travers de nombreuses équipes) rentreront dans l'objectif à long terme du projet ? Notez que je ne parle pas de projets de petite ou moyenne taille mais d'un projet concernant entre 50 et 300 développeurs, déroulé sur 3 à 5 ans, comparable au lancement d'un produit ou d'une ligne de produits.

Il est impossible de prévoir.

Daniel Kahneman, Prix Nobel d'économie, bien qu'il soit psychologue, est arrivé à la conclusion que la plupart des choses qui se passent proviennent de coïncidences : l'un des exemples qu'il donne fait référence à l'Histoire : il y avait 50% de chances que l'embryon qui est devenu Adolf Hitler ait pu être femelle. Qui sait comment cela aurait pu changer les 100 dernières années dans le monde ? Cela signifie que prédire des évènements complexes n'est pas possible.

Cependant, Kahneman a réuni le travail de collègues qui ont mené des recherches dans le même domaine afin de vérifier son idée. Par exemple, Philip Tetlock, également psychologue à l'Université de Pennsylvanie a recensé plus de 80 000 prévisions politiques et économiques. Notons que les personnes qui ont établi ces prévisions ont pour profession de prédire le futur, nous parlons donc de véritables experts ! Le problème était que ces prévisions étaient plus pessimistes que la simple application de la courbe normale de distribution. Cependant, lorsqu'une prédiction s'avérait fausse, quasiment personne ne voulait le reconnaître, et presque tous les experts ont trouvé des excuses ou des raisons pour expliquer qu'ils ne s'étaient par trompés mais que le timing était mauvais. Sans pour autant fournir aucune information sur le bon timing.

Dans une autre étude, Terry Odeon, professeur de finance à l'Université de Berkeley a analysé environ 10 000 résultats de courtiers regroupant 163 000 transactions. L'aspect intéressant du courtage est que, pour chaque transaction, il doit y avoir quelqu'un qui pense qu'il vaut mieux vendre, un stock par exemple, et quelqu'un d'autre qui croit qu'acheter serait mieux. Pourtant, les deux courtiers sont généralement vus comme des experts dans leur domaine. Dans cette analyse Odeon a trouvé qu'en moyenne les stocks vendus ont connu une performance 3,2 % plus élevée que les stocks achetés.

Le dernier exemple s'appuie sur la propre expérience de Kahneman. Il a travaillé pour l'armée israélienne. Pour eux, il a créé un test qu'il utilisait avec son groupe pour évaluer les candidats à la carrière d'officier. Vous pouvez très bien imaginer ce genre de tests. Après des entretiens, les candidats devaient résoudre des problèmes difficiles dans lesquels ils devaient construire quelque chose, surmonter autre chose, ce qui faisait apparaître qui prenait la tête du groupe, qui s'opposait, qui était un bon joueur d'équipe et ainsi de suite. Kahneman et son équipe étaient confiants en l'utilisation de ces résultats d'observation pour établir la qualification des candidats. Cependant, les feedbacks reçus du commandant quelques mois plus tard révélaient que cette évaluation était à peine meilleure qu'un choix fait au hasard. Le fait intéressant est que ni Kahneman ni ses collègues n'ont modifié leur approche ou plutôt leurs conclusions après ce feedback. Lorsqu'un candidat prenait la tête, il était toujours aussi évident pour eux que ce serait un candidat parfait à la carrière d'officier. Ils étaient simplement tellement convaincus par leurs impressions que changer les conclusions leur semblait impossible.

Que pouvons-nous donc apprendre de ces études ? Il y a deux leçons majeures à en tirer :

  • Premièrement, les prévisions tendent toujours vers l'erreur, simplement parce que le monde, ou plutôt n'importe quel évènement complexe, est imprévisible.
  • Deuxièmement, la confiance subjective (comme les experts le prouvent souvent, peu importe si leur confiance concerne une carrière d'officier ou l'estimaion d'un projet) n'est pas un signe de précision, c'est simplement un signe que l'expert présente un scenario cohérent. Une haute forme de confiance (parfois appelée intuition) peut seulement être fiable si vous évoluez dans un environnement stable.
  • Il existe en fait une troisième leçon à tirer des recherches de Kahneman. Je n'ai pas pris la peine de la vérifier par une étude parce que c'est la base du développement itératif : en contradiction avec les tendances sur le long terme, les tendances à court terme peuvent être prédites avec une précision raisonnable aussi longtemps qu'elles sont basées sur des comportements, des modèles et des réalisations passés.

Beyond Budgeting à la rescousse

Beyond Budgeting est un développement mené par les directeurs financiers de différentes entreprises. Ils étaient mécontents de l'effet de la budgétisation sur leurs entreprises respectives. Leurs expériences, assez classiques, sont doubles et vous devriez pouvoir vous reconnaitre dans celles-ci :

  • Imaginez que quelqu'un demande un budget précis, par exemple pour un projet, et qu'au final ce projet est moins cher. Par crainte de se voir attribuer la fois suivante seulement la moitié de la somme, le responsable du projet va dépenser quoi qu'il arrive le reste de l'argent (pas forcément dans son projet initial). Ceci ne contribue pas vraiment au succès de l'entreprise.
  • Maintenant, imaginez que quelqu'un demande un budget précis, puis qu'ensuite le marché change et entraîne le doublement du coût du projet. Comme il ne l'a pas demandé à temps et qu'il n'est pas possible d'agir selon les besoins du marché, encore une fois, le succès de l'entreprise souffre de la budgétisation initiale.

En s'appuyant sur ces expériences, les memebres de Beyong Budgeting ont développé différents types de principes et de recommandations. Aucuns de ces derniers n'impose nécessairement de se débarrasser de la prévision budgetaire, mais de l'utiliser de manière plus flexible. Par exemple, la négociation d'un budget annuel est considéré comme une pratique inflexible. Ainsi, la recommandation est d'utiliser par exemple un budget roulant, ce qui signifie vérifier chaque mois où l'argent est le mieux dépensé. Une alternative au budget roulant est la budgétisation liée aux évènements, qui permet de revoir le budget dès qu'un changement intervient.

L'une des idées forces de Beyond Budgeting est, à mon avis, de différencier la cible de la prévision. Le raisonnement est que chaque objectif devrait être ambitieux en considérant que la prévision (ou l'estimation) est un moyen de s'approcher du but. Maintenant si les deux, la cible et la prévision, sont contraints par un chiffre, le résultat est que, soit la cible n'est plus assez ambitieuse, soit l'estimation est une tromperie.

Appliquer Beyond Budgeting

Afin de voter pour ou contre un projet ou un produit, on part d'une idée puis on demande par exemple à un développeur senior ou à une équipe de l'évaluer en termes d'effort et donc de coût. Le problème est qu'à cette étape, on sait peu de choses sur le projet et donc les estimations ne sont pas vraiment solides. Parfois ce sont les commerciaux qui font cette estimation sans consulter les développeurs, puis une décision est prise. Et bien sûr peu importe qui a fait la première estimation, on assure toujours à l'équipe de développement que ce montant ne sera pas pris au sérieux et sera ajusté une fois qu'on en saura plus...

D'après les résultats de Kahneman et de Beyond Budgeting cette approche est inutile. Tout d'abord elle ignore la différentiation que fait Beyond Budgeting entre la cible et la prévision. Ensuite, contrairement aux idées de Kahneman, elle considère que les projets complexes peuvent être prévus et enfin, elle va à l'encontre du conseil de Beyond Budgeting en suggérant d'approuver le budget directement.

A la place, il faut clarifier l'objectif global. Afin de ne pas juste s'appuyer sur un seul groupe d'experts (rappelez-vous les résultats de Kahneman), je recommande de confier cette clarification à un groupe mixte. Selon le projet, ce groupe devrait être composé par exemple du client, de commerciaux, des vendeurs, des gestionnaires de produit, et de s'appuyer sur des méthodes scientifiques afin d'évaluer les vrais besoins du marché comme le suggère Lean Startup. Le résultat de cette clarification n'est pas une estimation mais la définition de la "Valeur Métier" que l'entreprise (ou le client) pense dégager avec ce projet. Se pencher sur la "Valeur Métier" change l'état d'esprit de "qu'est-ce que cela va coûter" à "qu'est-ce nous allons gagner". Cette "Valeur Métier" peut être définie en discutant, en faisant une estimation Delphi ou, comme je l'ai fait par le passé, en utilisant une variation du planning poker. Pour cette dernière, au lieu d'utiliser des chiffres d'estimation pour diriger la discussion, les membres du groupe utilisent les chiffres en se référant à la valeur métier.

Ensuite, au lieu de demander combien de temps cela va prendre, le même groupe mixte doit trouver combien ils sont prêts à dépenser (considérant la "Valeur Métier" qu'ils ont précédemment établie). Naturellement ce groupe va s'efforcer (tout abord) d'établir une évaluation du coût de l'investissement comme le font les développeurs lors de leurs estimations. Enfin, l'entreprise doit décider dans quels postes elle va dépenser l'argent. Du point de vue des développeurs, tout peut être fait d'une façon très sophistiquée et coûteuse (ce qui est typiquement conforme à l'éthique de travail, par exemple le code propre) mais en même temps les choses peuvent être implémentées à moindre coût (ce qui mène à du code non maintenable). Là, l'entreprise doit produire des arbitrages en fonction de la "Valeur Métier" (ce qui peut amener à choisir une solution bon marché). Ceci ne veut pas dire qu'il ne reste aucune responsabilité aux développeurs en termes de planning - leur tâche est d'assurer que les décideurs comprennent l'impact qu'une solution bon marché (ou coûteuse) peut avoir. En conséquence, l'estimation n'est pas ce qui nous intéresse ici. C'est la décision sur la "Valeur Métier" et l'investissement que l'entreprise veut faire qui doit diriger le développement. Encore une fois, ces guides sont créés par le métier et non par le développement. Certaines équipes font simplement l'inverse, en demandant au développement non pas d'estimer seulement au niveau de la story, mais également au niveau de l'epic (en estimant par exemple en taille de t-shirt) ou au niveau du projet. Une estimation plus grossière n'est pas un problème en soi, tant qu'elle est utilisée pour mieux comprendre le contenu. Enfin, essayer de chiffrer le projet, l'epic ou la story (ou estimer le temps passé) soulève une mauvaise question. Encore une fois, les bonnes questions à se poser sont : combien vaut ce projet et combien sommes-nous prêt à investir ?

De cette façon, la "Valeur Métier" et l'investissement définissent un cadre pour piloter le développement. Au mieux, les deux devraient être ventilés au niveau de la story ou au moins au niveau de l'epic. Pour de grands projets, nous avons eu de bonnes expériences en planifiant sur au moins trois niveaux. Le plus haut niveau est le plan global du projet (souvent appelé feuille de route). Le niveau suivant est le plan de livraison, avec une livraison au maximum trimestrielle. Ainsi, avant de commencer une livraison, les epics pour cette livraison seront définies en termes de "Valeur Métier" et d'investissement. Au niveau des itérations (le plus bas niveau), la "Valeur Métier" et l'investissement pour les stories sont définis avant l'habituelle planification de l'itération (c'est-à-dire les sprint plannings un et deux). Selon la longueur des livraisons (et également selon la complexité du projet), nous avons parfois besoin de ce que Mike Cohn a nommé un "plan d'anticipation roulant". Ainsi, nous nous penchons sur la valeur métier et l'investissement des stories non seulement pour l'itération à venir mais également pour les deux, ou même trois itérations suivantes. Planifier sur ces différents niveaux fournit la possibilité à l'entreprise de définir tout de suite la "Valeur Métier" et l'investissement à un niveau global, puis d'affiner de manière itérative. Les définir directement à un niveau fin est tout d'abord impossible pour de gros projets et ensuite n'est pas utile - parce qu'il est très probable que la "Valeur Métier" (et les raisons de l'investissement) changera au cours du temps.

Appliquer cette approche à différents niveaux assure que le développement est toujours piloté par la "Valeur Métier" et l'investissement et non pas par l'estimation. Je recommande toujours à l'équipe de développement de faire une session de planning poker pour estimer les stories. Cependant, cela sert à créer de la connaissance autour des stories au sein de l'équipe, mais pas pour piloter le développement. Ainsi, les résultats de l'estimation ne sont importants que pour diriger la discussion, surtout lorsque les membres de l'équipe ne sont pas a priori d'accord sur les chiffres. La discussion basée sur leurs différentes hypothèses génèrera une compréhension partagée de la story. De cette façon, l'estimation est toujours utile à l'équipe mais ne dirigera pas la planification. La priorisation et la définition de ce qui est ou n'est pas dans le périmètre du développement s'appuient sur ce que vaut la story en termes de "Valeur Métier" et d'investissement (et non pas en termes de combien de temps cela va prendre ou combien de story points cela coûte). Ainsi, la "Valeur Métier" avec l'investissement fournissent un fil conducteur à la priorisation et au développement. Par exemple, si une story spécifique se voit assigner un faible investissement et ne produit pas une forte "Valeur Métier", la priorité de la story doit être remise en question (indépendamment de son estimation en story points). De plus, il devrait être évident que, pour une telle story, l'équipe de développement devrait chercher la solution la moins chère et, s'il n'y en a pas, alors la story devrait être échangée pour une autre qui produira une meilleure "Valeur Métier" (et/ou l'entreprise décide de faire un plus grand investissement).

La "Valeur Métier", aussi bien que l'investissement, doit être vérifiée régulièrement, similairement au budget roulant ou basé sur les évènements. Par exemple, il faut voir ce qui a été appris auprès des parties prenantes (par exemple, quels types de changements fourniront un avantage compétitif), du marché (par exemple où nous devons investir pour créer une plus grande "Valeur Métier"), et également auprès du développement (par exemple quels avantages une technologie spécifique va fournir). Ensuite, il faut analyser comment ceci influence la "Valeur Métier" et/ou l'investissement sur différents niveaux. C'est utile de regarder tout d'abord ce que cela signifie pour le plan de livraison. Souvent ça n'a d'incidence qu'à ce niveau, donc il n'y a pas de raison de revenir au niveau global du projet. Néanmoins, parfois il a tellement d'impact que même la feuille de route sera influencée par les changements. Il est certain que lors de la définition de la "Valeur Métier" et de l'investissement pour l'itération suivante (et si possible pour le plan de prévision roulant, c'est-à-dire les deux ou trois prochaines itérations) les nouvelles leçons devraient être prises en compte.

En général, si l'avantage compétitif du client est réellement notre point d'attention, alors le métier doit être piloté par la "Valeur Métier". Ainsi depuis longtemps dans le développement agile nous parlions de "Valeur Métier" mais nous ne considérions que les priorités (souvent d'après les estimations). Cependant seule sa combinaison avec l'investissement garantit que nous maximisions toujours la valeur dans l'intérêt du client..

Conclusion

De récents résultats de recherches, couplés aux idées de Beyong Budgeting, montrent ce que nombre d'entre-nous ont vécu : une prévision précise n'est pas possible car le monde n'est pas prévisible (particulièrement de nos jours). Avoir une grande confiance dans les prévisions d'un expert signifie simplement que cet expert propose un scenario cohérent et non pas que la précision de la prévision est élevée. Aussi, au lieu de vous adresser à un expert, constituez un groupe de personnes variées.

Pour ne pas tomber dans le piège de mélanger l'estimation et la planification, définissez une "Valeur Métier" et trouvez une somme à investir que vous êtes prêts à engager. Ensuite utilisez ces valeurs pour planifier. Elles vous aideront à décider du lancement d'un projet (ou d'un produit) et à réaliser une feuille de route ainsi qu'un plan de livraison. Ainsi, surtout au niveau projet et epic, la "Valeur Métier" et l'investissement défini piloteront le développement.

Les prévisions à court terme sont possibles, donc mesurez la vélocité et prenez-la en compte lors de la planification de la prochaine itération. Le feedback de l'itération et des parties prenantes aide à améliorer la gestion de la "Valeur Métier" et de l'investissement. Donc d'un côté la "Valeur Métier" de l'investissement pilote l'itération, et de l'autre le feedback de l'itération aide à améliorer la "Valeur Métier" et l'investissement. En d'autres termes, la feuille de route influence le plan de livraison qui influence l'itération et vice versa - le résultat de l'itération remonte dans le plan de livraison et celui-ci remonte dans la feuille de route. Ainsi, la "Valeur Métier" et l'investissement sont traités comme un budget roulant qui est revisité régulièrement afin que toutes les leçons apprises soient intégrées.

Lectures complémentaires

Daniel Kahneman, Thinking Fast and Slow, Penguin Books

Bjarte Bogsnes, Implementing Beyond Budgeting, John Wiley & Sons

Beyond Budgeting Roundtable (Accueil de Beyond Budgeting):

Mike Cohn, Agile Estimating and Planning, Prentice Hall

A propos de l'auteur

Jutta Eckstein est un coach indépendant, consultante et formatrice à Braunschweig, en Allemagne. Ses connaissances dans les processus agiles sont basées sur plus de quinze ans d'expérience en développement de projet et de produit. Elle met l'accent sur la mise en place du développement agile à un niveau organisationnel. Elle a aidé de nombreuses équipes et organisations dans le monde entier à faire la transition vers une approche agile. Elle a une expérience unique dans l'application des processus agiles au sein projets de taille moyenne aussi bien que de larges projets distribués et critiques. C'est également le sujet de ses livres 'Agile Software Development in the Large' et 'Agile Software Development with Distributed Teams'. C'est un membre de l'Agile Alliance et un membre du comité de plusieurs conférences européennes et américaines dans le domaine du développement agile, de l'orientation objet et des modèles.

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter

Contenu Éducatif

Rien ne serait possible sans le soutien et la confiance de nos Sponsors Fondateurs:

AppDynamics   CloudBees   Microsoft   Zenika
Feedback Général
Bugs
Publicité
Éditorial
InfoQ.com et tous les contenus sont copyright © 2006-2013 C4Media Inc. InfoQ.com est hébergé chez Contegix, le meilleur ISP avec lequel nous ayons travaillé.
Politique de confidentialité
BT