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
Au
début, c'est clairement le client (utilisateur final) dont le but est d'arriver
au sommet et un accompagnateur (guide qui possède des connaissances techniques
poussées et des ascensions peut être similaires). Ca me rappelle quelque
chose...
Les
personnes apprennent à se jauger, se mesurer, et cerner les compétences et
facilités de chacun. L'important est de se connaitre, se faire confiance, voir
lier des premiers liens et affinités... dans la limite du raisonnable bien
évidemment....
La cadence est
celle du groupe et non celle d'un individu, même si le guide joue le rôle de
garant et surveille la cadence. Ne serait ce pas un scrum master finalement ?.
Le rythme est soutenu mais soutenable. Le groupe est solidaire et est lié par
une corde. Cela ressemble beaucoup à une itération : le but est de mener
l'équipe au camp suivant, Tous sont liés par la corde.