Valeur d’affaire d’un développement Agile: remplacement d’un système
Je suis tombé sur cette présentation très intéressante qui démontre comment un système développé en suivant un processus Agile apporte une valeur d’affaire beaucoup plus grande à long terme. Bien que je sois totalement en accord avec ce qui est y est présenté, par expérience je sais que la situation est un peu différente lors du remplacement d’un système existant par une nouveau développé en Agile.
Lorsqu’on remplace un système la barrre est haute fonctionnellement parlant et on ne peut que rarement mettre en production un système qui fait moins que le système qu’on remplace. La valeur minimale acceptable devient en quelque sorte égale à ce que le système existant fait déjà, car peu de gens sont prêts à perdre des fonctionnalités qui leurs sont utiles.
Cela change le graphique car la ligne pointillée correspondant à la valeur minimale acceptée se déplace vers le haut pour devenir égale aux fonctionnalités de la version existante. Notez ici qu’on parle des fonctionnalités vraiment utilisées, non pas toutes celles de l’application existante (ce qui peut être assez différent, sachant qu’au plus 35% des fonctionnalités des logiciels sont utilisés sur un base régulière).
Toutefois, si la gestion du projet est rigoureuse et que les fonctionnalités clés (le 20% utilisé souvent) sont ciblées en premier, il est possible d’arriver quand même assez rapidement avec une version qui atteint le même niveau de valeur d’affaire que l’application à remplacer… Probablement même plus rapidement qu’on ne pourrait le faire avec un processus traditionnel, avec en plus les bénéfices à long terme d’une application développée en Agile.
