SFEIR, la métamorphose Agile

·  Pouvez-vous vous présenter rapidement ?

Ma participation à des projets de grande dimension (refonte du SI de TF1 Publicité menée par Accenture), puis mon rôle de Responsable Etudes et Développement d’AIG Marketing Europe France (Marketing Direct dans le monde de l’Assurance), ont été des expériences significatives dans la recherche d’une méthode projet optimale. En intégrant la DSI de M6, j'ai mis en pratique les méthodes Agiles (Scrum et XP). Convaincu par cette vision projet, j'intègre SFEIR an avril 2010 en tant que Directeur de projets et Coach Agile.

·  Qu'est-ce que l'agilité pour vous ?

Une méthodologie qui permet de fournir un produit très rapidement et le plus en accord possible avec les besoins métier, dans un contexte d'échanges, de confiance et de découverte.

·  Le manifeste agile prône les valeurs suivantes:

1.      Les individus et les interactions plutôt que les processus et les outils

2.      Un logiciel qui fonctionne plutôt qu’une documentation détaillée

3.      La collaboration avec le client plutôt que la négociation de contrats

4.      Accepter le changement plutôt que suivre le plan

Laquelle de ces valeurs est la plus importante selon vous ?

Les "individus et les interactions" car de ce principe les autres peuvent en découler. 

·  Quelles méthodologies agiles connaissez-vous ?

Scrum et XP pour la mise en pratique. Lean pour quelques notions.

·  L'agilité, est-ce plus : de la gestion de projet, de l'ingénierie logicielle, de l'organisation d'entreprise ?

C'est une façon de penser et de faire. C'est donc adaptable à tout type de contexte que ce soit MOA, MOE en informatique ou un autre secteur de l'entreprise. Scrum est plus de la gestion de projet et XP plus côté développement. Le lean a souvent été employé dans les organisations de type industriel (né chez Toyota).

·  Qu'est-ce que l'agilité change pour le développeur ?

Il devient autonome, prend part aux décisions, dialogue avec le client et est facteur d'amélioration et de qualité.

Il a désormais une vision complète du besoin, connait les objectifs et les contraintes. Dans un cycle classique, on lui attribuait une tache à effectuer dans un certain temps...

·  Qu'est-ce que l'agilité change pour le manager ?

Le suivi est quotidien; Il connait exactement l'état d'avancement de son application et ce n'est plus un chiffre sur un planning donné un peu au pifomètre (le célèbre "on en est à 80 %"...)

·  Qu'est-ce que l'agilité change pour l'utilisateur ?

Le produit devient ce dont il a besoin à l'instant t et non une demande formalisée il y a 6 mois, voir plus. Le produit colle au métier et donc répond précisément à ces attentes.

·  Qu'est-ce que l'agilité change pour vous, à votre poste chez sfeir ?

Si j’ai rejoint sfeir, c’est pour pratiquer l’agilité…

·  Comment les technologies RIA peuvent-t-elles faciliter la mise en place de l'agilité ?

Je ne suis pas sûr du lien entre technologie et agilité. Elles introduisent un facteur d'échange plus important avec l'utilisateur car les possibilités de mise en place graphique sont variées, ce qui n'est pas le cas avec un écran type AS400...

·  Quelles évolutions avez-vous vu dans le paysage informatique avec l'apparition des méthodes agiles?

Les échanges entre SSII et client final n'étaient auparavant basés que sur des contrats. L'agilité a amené de la confiance et des échanges plus intenses et si possible sur du long terme. Mais c'est surtout du point du développeur qui n'est plus un pion dans un espace de travail mais une personne avec un nom qui échange directement avec le client.

·  Voyez-vous des convergences ou des divergences entre l'agilité et CMMI ?

Je ne connais pas trop CMMI, je passe ;)

·  Que pensez-vous du "lean software development" ?

Je (re)passe...

·  Quelles sont les différentes prestations agiles proposées par Sfeir ?

Tout ce qui concerne l'agilité, de la découverte et la formation, à la mise en place d'un centre de services en passant par du coaching.

·  Comment abordez-vous les aspects contractuels d'une prestation agile ?

Nous prônons un système de confiance et si possible à long terme avec le client. Le mode régie est donc le bienvenu.

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