Gestion de projet agile : estimer l'inconnu

Les chefs de projet expérimentés savent que la première question que les clients posent sur tout nouveau projet est « Combien ? » suivi de près par « Dans combien de temps ? Chaque fois que le sujet de la gestion de projet agile est abordé, il est inévitable qu'une question soit posée : « Comment fournir un devis au client ou aux sponsors lorsque vous n'avez pas de document d'exigences complet, aucune spécification signée et aucun calendrier ratifié ? " Les opposants aux méthodes agiles, profondément attachés aux techniques structurées et prédictives défendues par le Project Management Institute (PMI) et le Software Engineering Institute (SEI) de l'Université Carnegie Mellon, soulignent cela difficulté comme le clou dans le cercueil des méthodologies agiles. Même les organisations désireuses d'essayer les méthodes agiles soulèvent souvent cette question avec appréhension. Chaque fois que j'écris une chronique sur les méthodes agiles, cette question d'estimation apparaît sans faute dans les commentaires.

Estimation in Agile

Avant d'explorer les techniques d'estimation dans un environnement agile, rappelons-nous un élément fondamental fait : même dans des environnements de projet matures et hautement prédictifs comme ceux recommandés par PMI et SEI, l'estimation est un sérieux défi, et les estimations développées (même avec des exigences approfondies et plusieurs approbations d'utilisateurs) sont souvent erronées. Je le note afin que nous ne commencions pas notre discussion sur l'estimation agile sous un malentendu.

Les questions souvent posées sur l'estimation agile sont tout aussi valables lorsqu'on les pose sur les méthodes prédictives. Nous avons peut-être rassemblé et documenté des classeurs remplis d'exigences des utilisateurs et obtenu que les sponsors et les parties prenantes les signent avec leur sang, mais les utilisateurs se réservent toujours le droit de dire « Non, ce n'est pas ça » lorsque nous leur montrerons notre premier prototype. Le fait que nous ayons un plan de projet en 300 étapes avec des activités programmées à l'heure ne signifie pas que le travail se déroulera comme prévu. En bref, lorsque nous défions les promoteurs agiles de prouver que les méthodes de développement itératives et incrémentielles peuvent être estimées, nous ne devrions pas être surpris s'ils se retournent et exigent de voir les estimations d'une précision irréprochable que nous avons créées dans nos projets prédictifs.[19659010] Il ne s'agit pas de nier qu'il y a des avantages à élaborer un cahier des charges complet et un plan de projet dès le départ et à les utiliser comme base pour l'estimation. Surtout dans les projets similaires à ceux que nous avons livrés précédemment, l'historique peut être un guide utile et peut nous permettre de dériver des estimations relativement précises en fonction des tâches que nous avons effectuées auparavant. Comme indiqué dans ma chronique précédente, les méthodes agiles sont les plus appropriées dans les projets innovantsqui n'ont pas ce record historique. C'est dans ces projets inventifs (sans analogie avec les efforts antérieurs sur lesquels s'appuyer) qu'émerge le véritable défi de l'estimation dans les programmes agiles. L'estimation est un défi dans tout effort de projet, mais dans ces initiatives inédites, cela peut sembler impossible.

En fait, ce n'est pas le cas. Certains concepts simples peuvent rendre l'estimation agile beaucoup moins intimidante qu'il n'y paraît. Le premier principe général, valable dans les environnements de projet agiles et prédictifs, est « ne pas estimer plus loin que ce que vous pouvez voir ». Lorsque nous appliquons une approche de développement incrémental, les projets sont divisés en une série d'itérations ; chaque itération aboutit à la livraison d'un prototype fonctionnel que le client peut évaluer puis être modifié ou étendu. La plupart des techniques agiles exigent que chaque itération soit à la fois limitée dans le temps et liée aux fonctionnalités. Avant le développement de chaque prototype itératif, l'équipe et le sponsor s'entendent sur le temps qu'il leur faudra pour livrer cette itération et sur les fonctionnalités qui seront livrées. Avec cette méthode, il devient assez évident de savoir comment estimer le temps nécessaire pour livrer cette itération ; c'est la « boîte à temps » (pour utiliser le langage agile commun) qui a été établie par consentement mutuel. Cette boîte de temps est généralement établie en répertoriant les fonctionnalités attendues dans l'itération en cours et en estimant le temps qu'il faudra pour fournir ces fonctionnalités.

Estimation de l'inconnu

En tant qu'agile. le projet commence, l'ensemble des fonctionnalités à fournir initialement est souvent limité aux fonctionnalités les plus fondamentales requises pour valider le concept du projet, avec les « cloches et sifflets » et les capacités les plus avancées reportées aux itérations ultérieures. Ainsi, à partir de la longue liste de fonctionnalités documentées en tant qu'éléments du produit final, nous sélectionnons les fonctionnalités pour les itérations initiales qui démontreront que le concept sous-jacent est réalisable, et qui permettront au client de commencer le « plus de ceci, moins de cette » conversation qui se produit inévitablement lorsque nous exposons le prototype à la communauté des sponsors. En limitant les premières itérations à cet ensemble de fonctionnalités réduites, nous facilitons l'accord sur un délai pour ces fonctionnalités. Nous estimons uniquement l'itération en cours, l'estimation des futures itérations étant différée jusqu'à ce que nous ayons une idée plus précise de l'adéquation de notre prototype développé avec la vision et les attentes du client. Ensuite, nous répétons ce processus, itération par itération.

Cela ne répond pas au dilemme de la budgétisation de l'ensemble du projet, ce qui est souvent ce à quoi les sponsors s'attendent. Après tout, le but d'une estimation dans le monde de l'entreprise est de permettre au commanditaire de prévoir un budget pour l'ensemble de l'initiative, pas seulement l'itération en cours. Cette tâche d'estimation n'est pas non plus si déconcertante. Comme les itérations sont limitées dans le temps, les projets entiers sont à la fois limités dans le temps et liés aux coûts. Lorsqu'un acheteur demande à une entreprise de construction de construire une maison, la première question évidente est : « Combien êtes-vous prêt à dépenser ? » La question suivante est généralement : « Quand pensez-vous emménager ? » après quoi le développement des plans et des fonctionnalités peut commencer. Le client définit le budget qui régit les caractéristiques qui seront incluses dans la nouvelle maison, de la roulotte préfabriquée la plus humble au manoir le plus luxueux.

TROUVÉ. C'EST UTILE ? PARTAGEZ-LE