Mots-clés

, , , , ,

Le taux de réussite des projets IT a du mal à franchir les 50% ; ce qui signifie qu’un projet sur deux échoue.

Depuis une bonne dizaine d’année, plusieurs Directeurs de Transformation ont organisé leurs projets autour de petites équipes (10 personnes maximum) ayant la responsabilité de conduire un sujet depuis l’analyse jusqu’à la mise en production.

 La méthode AGILE repose sur plusieurs règles

  • décomposer le domaine en activités appréhendables de bout en bout
  • donner la responsabilité d’une activité à une équipe
  • chaque équipe dispose de l’autorité nécessaire pour définir le fonctionnement futur
  • chaque équipe est autonome en termes de capacité de décision, et de compétence technique
  • le client est impliqué au plus près des activités informatiques tout au long du cycle (depuis le design en passant par les tests, jusqu’à l’acceptation finale)

Ce qui différencie la méthode AGILE des autres méthodes, est qu’elle intègre, par définition, la notion de changement et la notion de clarification.

Ce sont ses deux notions qui conduisent en général les projets à l’échec ; une fois que l’analyse a été finalisée, les développements s’effectuant sur un mode forfait, doivent être réalisés dans les délais les plus courts, sur la base des dossiers d’analyse.

Les demandes de changement, les modifications font l’objet d’une gestion particulière ; ils sont, ou pas, intégrés dans les développements ultérieurs: Principe du Troc

Avec AGILE, le client est intégré en amont, tout au long de la phase de conception.

Mais le client est également sollicité durant toute la période des développements ; les périodes de développement (sprints) ne dépassant pas 3 semaines, le client peut se rendre compte immédiatement des dérives éventuelles, des incompréhensions, et ainsi fournir les explications complémentaires pour ramener l’équipe de développement dans le bon chemin.

De fait avec AGILE, le projet fera très précisément ce que l’équipe qui en avait la charge aura décidé.

 La fragilité de la méthode repose sur

  • le fait qu’il faut pouvoir trouver au sein des équipes du client, un représentant qui ait à la fois l’autorité et la connaissance métier pour être le référent face aux équipes informatiques pour définir le système métier futur ;
  • le fait qu’il faut réunir une équipe de développeurs qui maitrisent impérativement leurs outils pour apporter en permanence, la meilleure traduction aux demandes – trouver un bon interprète ;
  • le fait qu’il faut disposer d’intégrateurs expérimentés pour vérifier le bon fonctionnement des développements une fois débouchonnés ;
  • le fait qu’il faut intégrer très en amont les problématiques d’exploitation, pour ne pas être bloqué au moment de l’intégration dans les phases d’exploitation.

Antagonisme apparent entre AGILE et intervention au forfait

La méthode AGILE semble ne pas permettre de réaliser de projets au forfait, du fait des changements effectués au fil de l’eau.

La réalité est plus contrastée.

La définition du besoin demeure un incontournable (Definition of Work); et c’est de la qualité de la définition du besoin que dépend tout le reste du cycle du projet.

Le cycle développement – tests étant de deux à trois semaines, il est très facile au client de pouvoir influer sur les défauts de la définition du besoin, soit pour compléter les oublis, soit pour apporter les clarifications

En travaillant ainsi, chaque partie (client / prestataire) se trouve « contrainte » de fournir ses meilleurs intervenants pour ne pas alourdir sa charge financière.

 De la théorie à la pratique

1-      Il est extrêmement difficile de trouver réunies en une seule personne à la fois la compétence métier et l’autorité pour décider du fonctionnement futur. Il est habituel de constituer un groupe d’experts métier qui va à la fois définir le besoin et répondre aux questions des équipes informatiques.

2-      Si la méthode AGILE est simple dans son expression, elle impose de mettre en place un travail collaboratif au sein de l’équipe elle-même, en incluant également le management du côté client et du côté prestataire.

3-      La méthode impose un débrief quotidien sur le travail réalisé, les progrès et les difficultés rencontrées.

 Le goulet d’étranglement

Quelle que soit la méthode utilisée, la difficulté consiste à passer du stade d’une application testée, validée et approuvée par le client, au stade d’application en exploitation.

Que la méthode s’appelle RAD, SCRUM ou Extreme Programming, le goulet demeure, sauf à introduire dans le périmètre les activités de mise en exploitation avec la démarche DevOps

Mais attention, il y a deux obstacles à franchir : un obstacle organisationnel et un culturel.

Les structures de développement et celles de production ont pris l’habitude de travailler avec des organisations distinctes (ITIL) avec des objectifs différents.

 La méthode AGILE est un bon alibi pour apprendre aux équipes informatiques à travailler ensemble.

Publicités