Mary et Tom Poppendieck décrivent dans leur ouvrage Lean Software Development: An Agile Toolkit, une technique qui est contre-intuitive pour amener à de meilleures prises de décisions :

Faire du développement logiciel de manière concurrente signifie à la fois démarrer le développement lorsqu’on a seulement une partie des exigences qui est connue et développer en courtes itérations, cette manière de faire permet d’obtenir du feedback qui permet de faire émerger le système. Le développement concurrent rend possible de retarder l’engagement jusqu’au dernier moment responsable, c’est-à-dire, le moment où ne pas prendre de décision permet d’éliminer une option importante. Si les engagements sont retardés au-delà du dernier moment responsable, alors les décisions prises le sont par défaut, ce qui n’est pas généralement une bonne approche pour prendre des décisions.

Paradoxalement, il est donc possible de faire de meilleures prises de décisions en ne décidant pas. Je suis un procrastinateur de niveau mondial, alors qu’est-ce qui m’empêche d’interpréter ceci comme étant d’avoir carte blanche1 ? Pourquoi faire aujourd’hui ce que je peux remettre à demain ?

Prendre des décisions au dernier moment responsable n’est pas de la procrastination ; c’est de la paresse éclairée2. C’est une stratégie solide et essentielle d’évitement du risque. Des décisions prises trop tôt dans un projet sont beaucoup trop risquées. Souvent, des décisions prisent précocement ont pour conséquence de faire faire du travail qui devra être mis ensuite à la poubelle. Cela peut être encore pire, ces décisions prises trop tôt peuvent avoir des conséquences inévitables et handicapantes pour tout le reste du projet.

Au début d’un projet, vous devriez prendre le moins de décisions structurantes possibles que vous aurez à gérer par la suite. Cela ne signifie pas, bien sûr, arrêter de travailler - cela signifie que vous vous adaptez à la nature hautement versatile du développement logiciel. Souvent, votre meilleure décision est d’avoir les couilles de dire “Je ne sais pas”2. Ce qui sera immédiatement suivie de “… mais nous y travaillons”.

Jeremy Miller a participé à une table ronde sur le TDD3 avec Mary Poppendieck et il a recollé les morceaux2 de manière tout à fait logique entre le dernier moment responsable et YAGNI4 :

La clé est de prendre des décisions aussi tardivement que vous pouvez attendre de manière responsable, parce qu’il s’agit du moment où vous avez le plus d’informations sur lesquelles baser votre décision. En conception logicielle, cela signifie que vous renoncez à créer des solutions générales ou des structures de classes jusqu’au moment où vous savez qu’elles sont justifiées ou nécessaires. Je pense qu’il y a une tendance naturelle chez les humains de construire ou d’acheter des choses par anticipation de futurs besoins, même s’ils sont improbables. N’est-ce pas là la devise des scouts2 - Être toujours prêt2 ?

En tant qu’ancien scout moi-même, je pense que nous devrions résister à notre tendance naturelle de trop préparer à l’avance. Mon atelier est rempli d’outils inutilisés dont je pensais avoir besoin. Pourquoi est-ce que j’ai ce compresseur à air ? Quand est-ce que j’ai utilisé mon aspirateur de chantier la dernière fois ? Est ce que j’ai déjà utilisé ce coffret de douilles ? C’est un vrai gaspillage d’argent et d’espace dans mon garage. Sans compter tout le temps que j’ai passé en atermoiement à sélectionner ces outils que je n’utilise pas. Depuis, j’ai adopté l’approche du dernier moment responsable pour mon atelier. Je me force à acheter seulement des outils que j’ai déjà utilisé ou des outils dont j’ai besoin spécifiquement pour un projet qui va bientôt démarrer.

Soyez prêt. Mais pour demain, pas pour l’année prochaine. Décider trop tard est dangereux, mais décider trop tôt dans ce monde du développement logiciel qui change rapidement peut être plus dangereux de manière tout à fait justifié. Laissez donc le principe du dernier moment responsable être votre guide.


Auteur : Jeff Atwood
Source : The Last Responsible Moment
Date de parution originale : 17 Octobre 2006


Traducteur : Nicolas Mereaux
Date de traduction : 28/06/2016


Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.


  1. NdT - en français dans le texte 

  2. NdT - article en VO non traduit  2 3 4 5

  3. NdT - développement piloté par les tests - plus d’informations dans cet article sur Wikipedia 

  4. NdT - acronyme de “you ain’t gonna need it” traduisible par « vous n’en aurez pas besoin » - l’acronyme YAGNI en VO a donc été conservé car plus répandu (et moins beau/intelligible) que VNAPB - plus d’informations dans cet autre article sur Wikipedia