Adopter une approche agile
CHAPITRE 7
229
• Nous n’avons pas de ressources formées pour cela.
Argumentation : nos ressources sont déjà expérimentées ; elles possèdent des connaissances techniques et/ou fonctionnelles, une expérience des projets et des qualités humaines.
Elles ont donc déjà des acquis précieux : leur expérience les mettra en garde contre
d’éventuels écueils rencontrés par le passé ; leurs qualités humaines ne demandent qu’à
être développées et leur expertise technique ou fonctionnelle est leur cœur de métier.
Les compétences agiles ne sont pas des compétences spécifiques. En revanche, des
formations et des prestations d’accompagnement pour aider à utiliser efficacement les
compétences existantes peuvent se révéler très utiles. Surtout pour les managers qui ont
besoin d’une formation pour animer une équipe auto-organisée.
• Nous ne pouvons fonctionner sans un planning détaillé basé sur le recueil exhaustif
des besoins.
Argumentation : les besoins ne sont jamais recueillis de façon exhaustive, par conséquent, le
planning détaillé est amené à changer tout au long du projet. Et même avec un planning
détaillé, la plupart des projets sont en retard. Ce qui est important, c’est de fixer une date
butoir que l’on estime réaliste et des étapes qui jalonnent le projet. Au fur et à mesure, on
planifie en détail l’étape qui démarre, on actualise l’estimation globale du travail à réaliser et on vérifie que la date butoir est toujours réaliste. Si elle ne l’est pas, le client peut
décider de maintenir la date et de revoir ses besoins à la baisse ou bien de dépasser la date
s’il veut maintenir son niveau d’exigences. En résumé, le client ne subit plus les dépassements de délais mais les contrôle grâce à de meilleurs éléments d’aide à la décision.
• Ce sont les coûts que l’on ne contrôle pas.
Argumentation : ce qui est valable pour le délai l’est tout autant pour le budget. Le client
peut décider qu’il soit fixe ou variable en fonction des enjeux du projet. Ce qui est variable,
ce sont le périmètre et les exigences. Mais ce n’est pas nouveau, c’est un constat fait
depuis longtemps que l’on accepte aujourd’hui et que l’on ne combat plus. D’ailleurs, les
coûts sont-ils mieux contrôlés avec des plannings qui dérapent ? La progression par
étapes facilite, précisément, l’évaluation et le contrôle du budget.
• Et la qualité, comment la contrôler alors que l’application évolue tout le temps ?
Argumentation : la qualité est contrôlée en permanence dès le début du projet (grâce à
l’intégration continue) et plus fréquemment tout au long du projet. Les tests sont intégrés
à chaque étape pour tester ce qui est produit et vérifier qu’il n’y a pas de régression par
rapport à l’étape précédente ; on s’interroge régulièrement sur la qualité de la méthode
par des rétrospectives, pour identifier l’origine des écarts ou des problèmes constatés.
C’est peut-être le premier argument à mettre en avant sur les bénéfices attendus d’une telle
démarche : l’amélioration de la qualité et de la conformité avec les attentes du client.
• Il paraît difficile que des utilisateurs puissent collaborer avec des informaticiens.
Argumentation : c’est précisément cette barrière que veulent faire tomber les méthodes agiles.
Des réunions dédiées au recueil et à la compréhension des besoins, à la hiérarchisation, à
GestProjInform Livre Page 229 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 7
229
• Nous n’avons pas de ressources formées pour cela.
Argumentation : nos ressources sont déjà expérimentées ; elles possèdent des connaissances techniques et/ou fonctionnelles, une expérience des projets et des qualités humaines.
Elles ont donc déjà des acquis précieux : leur expérience les mettra en garde contre
d’éventuels écueils rencontrés par le passé ; leurs qualités humaines ne demandent qu’à
être développées et leur expertise technique ou fonctionnelle est leur cœur de métier.
Les compétences agiles ne sont pas des compétences spécifiques. En revanche, des
formations et des prestations d’accompagnement pour aider à utiliser efficacement les
compétences existantes peuvent se révéler très utiles. Surtout pour les managers qui ont
besoin d’une formation pour animer une équipe auto-organisée.
• Nous ne pouvons fonctionner sans un planning détaillé basé sur le recueil exhaustif
des besoins.
Argumentation : les besoins ne sont jamais recueillis de façon exhaustive, par conséquent, le
planning détaillé est amené à changer tout au long du projet. Et même avec un planning
détaillé, la plupart des projets sont en retard. Ce qui est important, c’est de fixer une date
butoir que l’on estime réaliste et des étapes qui jalonnent le projet. Au fur et à mesure, on
planifie en détail l’étape qui démarre, on actualise l’estimation globale du travail à réaliser et on vérifie que la date butoir est toujours réaliste. Si elle ne l’est pas, le client peut
décider de maintenir la date et de revoir ses besoins à la baisse ou bien de dépasser la date
s’il veut maintenir son niveau d’exigences. En résumé, le client ne subit plus les dépassements de délais mais les contrôle grâce à de meilleurs éléments d’aide à la décision.
• Ce sont les coûts que l’on ne contrôle pas.
Argumentation : ce qui est valable pour le délai l’est tout autant pour le budget. Le client
peut décider qu’il soit fixe ou variable en fonction des enjeux du projet. Ce qui est variable,
ce sont le périmètre et les exigences. Mais ce n’est pas nouveau, c’est un constat fait
depuis longtemps que l’on accepte aujourd’hui et que l’on ne combat plus. D’ailleurs, les
coûts sont-ils mieux contrôlés avec des plannings qui dérapent ? La progression par
étapes facilite, précisément, l’évaluation et le contrôle du budget.
• Et la qualité, comment la contrôler alors que l’application évolue tout le temps ?
Argumentation : la qualité est contrôlée en permanence dès le début du projet (grâce à
l’intégration continue) et plus fréquemment tout au long du projet. Les tests sont intégrés
à chaque étape pour tester ce qui est produit et vérifier qu’il n’y a pas de régression par
rapport à l’étape précédente ; on s’interroge régulièrement sur la qualité de la méthode
par des rétrospectives, pour identifier l’origine des écarts ou des problèmes constatés.
C’est peut-être le premier argument à mettre en avant sur les bénéfices attendus d’une telle
démarche : l’amélioration de la qualité et de la conformité avec les attentes du client.
• Il paraît difficile que des utilisateurs puissent collaborer avec des informaticiens.
Argumentation : c’est précisément cette barrière que veulent faire tomber les méthodes agiles.
Des réunions dédiées au recueil et à la compréhension des besoins, à la hiérarchisation, à
GestProjInform Livre Page 229 Vendredi, 3. avril 2009 12:07 12