L'approche "Bones" pour la gestion de projet

R.I.P. (en latin "requiescat in pace") est une phrase que l'on peut voir sur certaines pierres tombales. Les projets informatiques ont souvent le même sort. Après la livraison, ce qui peut leur arriver de mieux est une petite célébration pour l'équipe. Personne ne se préoccupe d'examiner formellement le déroulement du projet, de comprendre ce qui a bien ou moins bien fonctionné, de trouver les causes de ces résultats de manière à formaliser et transmettre l'expérience acquise aux prochains projets. Il existe néanmoins une activité pour analyser les projets après leur fin. Cette activité est appelée analyse "post-mortem" (d'où la référence aux pierres tombales) ou "rétrospective" dans les approches agiles. Vous ne devez pas avoir honte si vous ne connaissez pas cette pratique. Moi-même, je ne l'ai jamais vue mise en oeuvre. Même dans l'enquête sur l'agilité réalisée par Version One où une large majorité des participants se réclament des approches agiles, seulement 39% utilisent cette pratique. Pourquoi?

La première explication est que le temps est une ressource considérée comme rare dans les services de développement. Il existe donc un sentiment d'urgence qui incite les gens à utiliser le temps disponible pour les activités qu'ils jugent les plus essentielles et il est difficile de faire rentrer la rétrospective dans le haut de ce classement. Il est déjà parfois difficile de faire admettre qu'il faut penser un peu avant de coder. Dès lors, essayer d'avoir du temps pour réfléchir après avoir codé peut sembler une utopie ;o). Il est aussi difficile pour un chef de projet de proposer d'utiliser des jours/hommes après la fin du projet pour examiner ce qui pourrait être amélioré. N'êtes-vous pas censés faire les choses parfaitement du premier coup?

Il est également difficile de créer un contexte de critique constructive. Ceci provient principalement de notre difficulté à dissocier les problèmes des personnes qui sont concernées. Ceci est un élément important dans les entreprises où une partie de la rémunération peut être liée à la réalisation de certains objectifs professionnels. Seriez-vous prêts à parler des problèmes rencontrés dans un projet si vous (ou un collègue) avez à un bonus lié à des objectifs de qualité? Peut-être pas....

Il existe cependant des techniques qui peuvent vous permettre de profiter des expériences vécues dans un projet sans créer de conflits personnels. Les articles ci-dessous (en anglais) sont des ressources intéressantes dans le domaine de l'analyse post-mortem ou  pour la pratique de rétrospectives.

* Refactoring Your Development Process with Retrospectives by Rachel Davies (HTML)

* Retrospective Agility by Tim MacKinnon in Objective View issue #8 (PDF)

* Plan of Action by Bas Vodde (HTML)

* Project "Post Mortem" Review Questions by Michael Greer (HTML)

* A Review of Small and Large Post-Mortem Analysis Methods by Mauri Myllyaho1 et al. (PDF)

* Agile survey by Version One