Les règles de la méthode Agile

– 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 et sont ou pas intégrés dans les développements ultérieurs.
Lecture recommandée du même expert Projet IT réussi : secrets d’un prestataire heureux

Le client est intégré en amont tout au long de la phase de conception

Le client est également sollicité durant les tests, les périodes de développement (sprints) ne dépassant pas 3 semaines, il se rend compte immédiatement des dérives éventuelles, des incompréhensions, et peut 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

Elle réside dans les conditions à remplir pour réussir :
– 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;
– réunir une équipe de développeurs qui maîtrisent impérativement leurs outils pour apporter en permanence, la meilleure traduction aux demandes – trouver un bon interprète ;
– disposer de testeurs expérimentés pour vérifier le bon alignement des développements avec les définitions de besoins ;
– 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.
Lecture recommandée du même expert Directeur de Programme, comment j’ai sorti une entreprise d’une mauvaise passe!

Antagonisme apparent entre AGILE et intervention au forfait

La méthode AGILE ne permettrait pas 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, et c’est de la qualité de celle-ci que dépend tout le reste du cycle du projet. Le cycle développement, les 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, ou encore accepter ou refuser les changements. Oublis et/ou clarifications de la définition des besoins sont de la responsabilité du client. Ils sont pris en charge par des avenants. La correction des bugs (qualité du code) est de la responsabilité du prestataire. 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.
lecture recommandée du même expert Projet IT réussi : secrets d’un prestataire heureux

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.
Pour en savoir plus sur la Méthode agile