Dans le premier article sur les bases de l’agile nous avons vu que dans le manifeste agile il y a 4 valeurs :
Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan
Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
Agile Manifesto
Nous avons abordé les 2 premières valeurs. Dans ce second article, nous aborderons les 2 dernières.
La collaboration avec les clients plus que la négociation contractuelle
Dans un processus classique de gestion de projet, le client rédige un cahier des charges. Ensuite, l’entreprise de réalisation chiffre son activité et fournit un devis. Elle fait suivre ce devis d’une reformulation du cahier des charges appelée spécifications fonctionnelles.
A partir de là, ces documents servent de « contrat » à toute réalisation ou demande future. Et toute demande du client sortant de ce cadre devra faire l’objet d’une négociation, devis, relecture, validation de devis,…
On se retrouve en plus dans un cercle vicieux : le client demande une évolution ou modification à son prestataire. Le prestataire dit « oui à condition de payer une rallonge parce que ce n’était pas ce qui était signé au départ ». Et donc au prochain projet, le client prendre plus de de temps pour la rédaction du cahier des charges car il aura peur de réitérer ce qu’il aura identifié comme une erreur. Parfois (et je n’exagère pas) le client fera appel à un autre prestataire pour lui déléguer la responsabilité du cahier des charges. Il contractualisera ce travail de rédaction avec ce nouveau prestataire ce qui déportera le problème d’un cran et on recommence à l’infini …
En agile, nous pensons que collaborer avec le client afin de créer la meilleure valeur possible est le plus important. Nous essayons au maximum de réduire ces négociations chronophages.
Nous préconisons donc de retravailler les contrats qui lient le client et l’entreprise de réalisation. Ce nouveaux contrats portent plus sur un engagement de collaboration plutôt que sur le périmètre à réaliser. La satisfaction du client, la valeur des réalisations et la réactivité aux changements du marché étant plus valorisées que le volume de développement livré mêlant l’utile et l’obsolète.
L’adaptation au changement plus que le suivi d’un plan
La notion principale de la gestion de projet est le plan. On dit d’ailleurs que le plan c’est 80% du projet. Un projet bien planifié est un projet qui a beaucoup plus de chance de réussir. Souvent dans cette façon de traiter les projets, une place importante est accordée à la gestion des risques. Et justement, nous voyons trop souvent les changements comme des risques d’écart au plan initial. Pourtant, on ne soupçonne pas assez l’opportunité qu’est un changement pris au vol.
Comme expliqué plus haut, chaque changement de périmètre implique des négociations contractuelles donc du temps de travail administratif supplémentaire. Mais en plus, selon l’avancement dans la phase de projet global dans laquelle on est, du rework (refaire du travail déjà terminé) peut être nécessaire. Les réalisateurs peuvent se retrouver à devoir mettre à jour quantité de documentations, codes, tests,…
En agile, du fait de travailler en itératif-incrémental, le client et l’équipe de réalisation n’engagent en développement que le contenu de la prochaine itération. Pour peu que l’itération soit de courte de durée, il y a peu de chances de changer en cours de réalisation. On s’adapte donc plus vite et de façon plus souple aux changements de besoin et de marché. On réduit ainsi du travail superflu de documentation en étant plus proche du client. Et on s’adapte plus vite au marché ce qui n’est pas négligeable à l’ère du big data et de l’intelligence artificielle où rapidité ou même instantanéité est de mise.
En conclusion
L’utilisation du mot agile dans le domaine informatique implique un certain nombre de notions. Toutes ces valeurs, mais également 12 principes la composent. Pourtant il est très fréquent d’entendre ce mot utilisé pour n’utiliser que la définition – très pratique on en convient – du dictionnaire plutôt que toutes ces notions. Donc attention à l’utiliser dans le bon contexte.
Toutes ces notions, bien qu’elles semblent être logiques ou du bon sens, sont confrontées à un contexte où des habitudes ancrées et des convictions créées peuvent les faire paraître trop simplistes. Or ces notions simples ne sont en l’occurrence pas simplistes et méritent qu’on les rappelle. Se laver les mains régulièrement c’est du bon sens, ça n’a pas empêché qu’en période de crise sanitaire de la Covid-19 les autorités soient obligées de rappeler ces consignes …
Maintenant, que pensez-vous de ces différentes valeurs ? Arrivez-vous à les transposer sur d’autres domaines que le développement informatique ?
