Livrer tôt est différent de maximiser le retour sur investissement
Auteur : Mattias Skarin
Source : Early release is not same as maximizing your return
Date : 22/04/2011
Traducteur : Fabrice Aimetti
Date : 22/04/2011
Traduction :
N’avez-vous jamais vu une fonctionnalité très pratique dans un logiciel en vous demandant : "sensas ! mais qui a eu du temps pour faire ça ?"
Il arrive de temps à autre que je rencontre des représentants du métier qui me disent combien ils sont heureux que leurs équipes, une fois passées à l’Agile, soient maintenant capables de livrer le logiciel à un rythme régulier : "Avant, ils donnaient l’impression de ne jamais avoir fini, il restait toujours quelque chose à faire".
Bien que ce soit un grand bond en avant, penchons-nous sur certains des dangers d’étendre cette pratique à toutes les fonctionnalités de votre système.
Vous serez probablement d’accord pour visualiser à peu près de la manière suivante la valeur d’une fonctionnalité par rapport à l’effort dépensé...
Dans ce cas, il est parfaitement logique de livrer la fonctionnalité dans une fenêtre où la valeur peut être maximisée :
Mais il y a une chose qui manque… Si nous essayons de déployer la fonction sur une population importante, le rendement attendu a probablement la forme d’une courbe exponentielle, qui à un certain point, fait que la fonctionnalité a atteint suffisamment d’ampleur pour être capable de se propager à l’ensemble des utilisateurs. Si l’on ajoute cette courbe au-dessus des autres :
Nous constatons alors que livrer la fonctionnalité en fonction de notre cadence normale va court-circuiter nos retombées économiques et minimiser notre retour sur investissement.
Conscient de cela, je préconise de ne pas considérer toutes vos fonctionnalités de la même manière. Beaucoup d’entre elles tireront partie d’être livrées selon un cycle régulier de livraison, mais pas toutes si nous sommes intéressés par maximiser notre rendement économique.
