SFEIR, la métamorphose Agile

La méthodologie satisfait très majoritairement tous ceux qui la pratiquent et sa prise d’ampleur le confirme. Peut-on alors parler de succès limité à la conduite/gestion de projet ou étendre ce succès aux clients/sponsors des applications ? En particulier le « client final » (utilisateur de l'application) s’y retrouve-t-il ?

Chaque cas est bien évidemment particulier sachant que la mise en place de la méthodologie peut être soit portée par la gestion de projet (scrum) soit portée par le développement (XP).

Même si dans la majorité des cas ce sont les deux qui vont de paire...

Je fais donc le choix d'utiliser ma propre expérience afin de mettre en exergue les difficultés rencontrées et les succès majeurs de cette méthode. Tout d'abord, plantons le décor : nous avons appliqué Scrum (AMOA) combiné avec XP (plateau de développement composé de prestataires). Je suis client (chef de projet / product owner) de plusieurs applications :

• 1er cas : un projet de refonte d’une brique du SI,
  

• 2ième cas : un nouveau projet (application from scratch),
  

• 3ième cas : un projet « purement technique » (mise en place d’un ESB).
  

Les utilisateurs concernés sont des populations métiers bien différentes et ont une vision distincte des applications.

Considérons chaque cas :

Dans le 1er cas, l’application souffre d’un comparatif avec l’existant en plus de nouveaux besoins à implémenter. Dans un premier temps, l’application a été découpée en 3 lots distincts afin de pouvoir délivrer en 3 phases l’application complète. Un suivi de projet utilisateur en alternance avec les planning games est mis en place. Les utilisateurs sont porteurs et très enthousiastes quant au fait de voir l’application grossir en emportant leurs besoins. Cette satisfaction va de paire avec la volonté de voir leurs nouveaux besoins apparaître sachant que la refonte (éléments de base) n’est pas encore terminée… Puis vient la date fatidique de mise en production du lot n°1. Et là patatra : « on ne peut pas mettre en production une application qui ne couvre pas tout le périmètre ! ». Est-ce un problème de communication de la part de l’Informatique ? A priori non, car ce découpage et ce lot de livraison sont en permanence rappelés. Il s’avère que l’utilisateur n’est finalement prêt à basculer que si son environnement de travail bascule d’un coup. Il ne conçoit pas de gérer une partie des données dans l’ancien système et l’autre dans le nouveau. La méthodologie a dans ce cas complètement satisfait les utilisateurs, même s’ils n’ont pas eu l’occasion de profiter de mise en production incrémental plutôt qu’une bascule complète vers cette application. L’Equipe quant à elle, est surmotivée par cette application qui leur permet de s’exprimer pleinement avec des interfaces riches, et une méthodologie de développement ultra communicante en accord avec leur façon de voir les choses.

Dans le 2ième cas, il s’agit de mettre en place une application, qui par la même occasion, met à plat les interactions entre trois services allant du back au front office. L’application est rapidement développée mais sa mise en place est décalée, ceci à cause d’un point purement business. Une fois en place, elle est vécue dans un premier temps un peu comme une contrainte car chaque service voit alors clairement les dépendances les uns vis-à-vis des autres, puis elle devient enrichissante car facilite les échanges et évolue très rapidement. Cette facilité de l’Agile est exploitée de façon très poussée par les utilisateurs et donc répond très bien à leur besoin. Par contre, l’Equipe le vit beaucoup moins bien car ils ont l’impression de faire et défaire en permanence : « pourquoi se presser puisque de toute façon on va revenir dessus… ». Même si, en tant que Product Owner, je remonte le fait que l’application est très satisfaisante pour les utilisateurs, le moral de l’équipe est difficilement maintenable au beau fixe et la lassitude se fait souvent sentir. De ce fait, la méthodologie est de temps en temps ressentie comme une contrainte (peu de binômage), même si de leur point de vue, aucune autre méthode n’est envisageable.

Enfin le 3ième cas est plus un projet technique et je suis donc l’utilisateur final est tant que PO et chef de projet. Chacun des deux premiers exemples entrainent un besoin à mettre en place dans cet ESB. De ce fait, la méthodologie Agile répond parfaitement car on ne sait pas réellement ce que l’on doit mettre en place dans cette application et on le « découvre » pour la prochaine itération. La façon de concevoir cet ESB sous forme de scénarios a satisfait d’une part le client dont le besoin émergeant est pris rapidement, et d’autre part l’Equipe qui voit les fruits de ses efforts utilisés peu de temps après leur développement.

En conclusion chaque projet a été ressenti de façon différente :

• par les utilisateurs finaux selon le périmètre de l’application, l’impact sur les process métier. Le point commun remonté est le fait que, grâce aux livraisons itératives, ils ont à disposition un produit fonctionnel qui leur permet de valider rapidement la conformité avec le business ;
  

• par l’Equipe, selon la variété du produit, l’utilisation du refactoring et le résultat de leur travail qui était utilisé rapidement ou non.

La méthodologie a fait l’unanimité, même s’il convient de bien réfléchir à la façon de la vendre auprès des différents intervenants afin de ne pas les frustrer quand à la rapidité avec laquelle sera mise en place la produit.

11/05/2010 - Thierry TREPIED Directeur de projets – Coach Agile SFEIR Groupe