Gestion de projet – Vers les méthodes agiles
210
La preuve que l’équipe a apporté une vraie valeur ajoutée est le nombre de fonctionnalités prioritaires (considérées comme telles par le client lui-même) développées et livrées au
client ; et, dans un projet Agile, ce nombre de fonctionnalités est tangible puisqu’à la fin
de chaque itération, l’application, même partielle, fonctionne et est exploitable.
Le client peut donc rapidement mesurer la valeur ajoutée au niveau de ses activités (gain
de temps, réduction du coût de la main-d’œuvre, augmentation de la marge, nombre de
nouveaux clients…) ; il peut, de fait, revoir ses priorités en fonction du feedback des
utilisateurs et mettre à jour le calcul du retour sur investissement sur la base des premières
livraisons.
La préoccupation première est donc bien la satisfaction du client qui se mesure en termes
de valeur ajoutée, de satisfaction par rapport aux besoins réels au moment où le produit est
livré, par une meilleure collaboration et par le respect des coûts et des délais.
Depuis le début du déploiement des méthodes agiles, de nombreuses initiatives ont été
lancées pour mettre au point un système de mesure du degré d’agilité des équipes et de
leur progression vers l’agilité.
On trouve, par exemple, le modèle développé par Bill Krebs et Per Kroll, Agile Evaluation Framework (Agile:EF) 1 : il mesure l’état d’adoption des pratiques agiles au travers
d’un questionnaire qui permet d’évaluer si telle pratique est utilisée (toujours, la moitié
du temps ou jamais). La figure 7-1 présente les résultats d’une enquête menée auprès des
membres d’une équipe agile.
Sur cette figure on peut observer, sur une échelle de 0 (jamais utilisé) à 10 (toujours
utilisé), l’adoption d’une pratique : la barre indique le résultat moyen de l’équipe, la ligne
les écarts représentés par les réponses individuelles.
Un dispositif objectif vous permet-il d’analyser la satisfaction de l’ensemble des utilisateurs
finals ? Si oui, le client est-il satisfait parce que le produit livré est « bien » ou parce que le
produit livré est « mieux » que ce qu’il attendait ?
Dans le premier cas, le client est satisfait, mais envisage peut-être une deuxième version du
produit qui prendra en compte des évolutions et des besoins non exprimés initialement, apparus au cours du premier projet. La satisfaction du client n’est donc pas totale et le coût final
risque d’augmenter.
Dans le second cas, cela signifie que vous avez répondu à des attentes implicites ou même
inconnues de l’utilisateur et que vous avez peut-être su identifier ce qui n’était pas vraiment
utile et l’éliminer du produit final en hiérarchisant ; vous avez été capable d’intégrer le besoin
émergent au fil de l’eau, pour une plus grande satisfaction du client, à coût égal, sans en
passer nécessairement par une deuxième version du produit.
Une approche agile vous permet d’intégrer ce besoin au fil de l’eau, pas une méthode traditionnelle prédictive qui fige les besoins.
1. http://www.agilejournal.com/articles/columns/articles/750-using-evaluation-frameworks-for-quickreflections
GestProjInform Livre Page 210 Vendredi, 3. avril 2009 12:07 12
210
La preuve que l’équipe a apporté une vraie valeur ajoutée est le nombre de fonctionnalités prioritaires (considérées comme telles par le client lui-même) développées et livrées au
client ; et, dans un projet Agile, ce nombre de fonctionnalités est tangible puisqu’à la fin
de chaque itération, l’application, même partielle, fonctionne et est exploitable.
Le client peut donc rapidement mesurer la valeur ajoutée au niveau de ses activités (gain
de temps, réduction du coût de la main-d’œuvre, augmentation de la marge, nombre de
nouveaux clients…) ; il peut, de fait, revoir ses priorités en fonction du feedback des
utilisateurs et mettre à jour le calcul du retour sur investissement sur la base des premières
livraisons.
La préoccupation première est donc bien la satisfaction du client qui se mesure en termes
de valeur ajoutée, de satisfaction par rapport aux besoins réels au moment où le produit est
livré, par une meilleure collaboration et par le respect des coûts et des délais.
Depuis le début du déploiement des méthodes agiles, de nombreuses initiatives ont été
lancées pour mettre au point un système de mesure du degré d’agilité des équipes et de
leur progression vers l’agilité.
On trouve, par exemple, le modèle développé par Bill Krebs et Per Kroll, Agile Evaluation Framework (Agile:EF) 1 : il mesure l’état d’adoption des pratiques agiles au travers
d’un questionnaire qui permet d’évaluer si telle pratique est utilisée (toujours, la moitié
du temps ou jamais). La figure 7-1 présente les résultats d’une enquête menée auprès des
membres d’une équipe agile.
Sur cette figure on peut observer, sur une échelle de 0 (jamais utilisé) à 10 (toujours
utilisé), l’adoption d’une pratique : la barre indique le résultat moyen de l’équipe, la ligne
les écarts représentés par les réponses individuelles.
Un dispositif objectif vous permet-il d’analyser la satisfaction de l’ensemble des utilisateurs
finals ? Si oui, le client est-il satisfait parce que le produit livré est « bien » ou parce que le
produit livré est « mieux » que ce qu’il attendait ?
Dans le premier cas, le client est satisfait, mais envisage peut-être une deuxième version du
produit qui prendra en compte des évolutions et des besoins non exprimés initialement, apparus au cours du premier projet. La satisfaction du client n’est donc pas totale et le coût final
risque d’augmenter.
Dans le second cas, cela signifie que vous avez répondu à des attentes implicites ou même
inconnues de l’utilisateur et que vous avez peut-être su identifier ce qui n’était pas vraiment
utile et l’éliminer du produit final en hiérarchisant ; vous avez été capable d’intégrer le besoin
émergent au fil de l’eau, pour une plus grande satisfaction du client, à coût égal, sans en
passer nécessairement par une deuxième version du produit.
Une approche agile vous permet d’intégrer ce besoin au fil de l’eau, pas une méthode traditionnelle prédictive qui fige les besoins.
1. http://www.agilejournal.com/articles/columns/articles/750-using-evaluation-frameworks-for-quickreflections
GestProjInform Livre Page 210 Vendredi, 3. avril 2009 12:07 12