Méthodes agiles : Éléments d'introduction et retours d'expérience

La rapidité des cycles ou la proximité du code ne doit pas être un prétexte à bâcler ou à ne pas réfléchir.

Une bonne conception, un algorithme intelligent ou un programme efficace demandent le même temps de réalisation en méthode agile ou traditionnelle.

Ce n'est pas parce qu'au projet est géré en mode agile qu'il n'y a aucune formalisation et aucun suivi des tâches. Cette formalisation doit répondre au juste besoin et mobilisent les principes du management visuel : information accessible à toutes les parties prenantes, forme facilitant la compréhension de l'information et favorisant la prise de décision afin de donner à chacun le plus d'autonomie possible.

Il ne s'agit pas de passer de la méthode traditionnelle à la méthode R.A.C.H.E (http://www.la-rache.com/)

Il faut des hommes qui s'engagent, or...

...tout le monde est chef de quelque chose, mais personne n'est responsable de rien !

Les salariés sont souvent dans une démarche personnelle plutôt que collective d'entreprise (qui le leur rend bien)...

Moins formelles, les approches agiles sont plus ancrées sur les personnes, le turn-over chez les prestataires, mais surtout chez le responsable de projet côté client, est catastrophique :

Il faut tout renégocier avec le nouveau responsable du projet, tout peut être remis en cause, et la confiance acquise devient parfois au contraire source de suspicion : « c'est pas normal qu'ils s'entendent bien ! C'est pas sérieux... ».

Ces approches fonctionnent lorsque le rapport de force est équilibré :

• une dépendance trop forte au client par exemple risque de devenir source de domination sur le prestataire ;

• au contraire, un client trop absent ne pourra pas réguler son prestataire.

Les projets agiles sont évaluables au résultat mais pas (ou peu) aux processus, donc pour celui qui n'accède pas au résultat (n'en perçoit pas la valeur) ou qui a en charge l'évaluation des processus (qualité), ils sont peu visibles.

Pour pouvoir livrer des applications tous les mois et avoir des retours, il faut des terrains et des utilisateurs eux aussi agiles, disponibles et adaptables.

On ne peut pas déployer plusieurs milliers de postes ou changer l'interface d'un site Internet chaque mois.

NB : Une alternative est un terrain de test qui n'est pas le terrain réel.

Toutes les technologies ne s'adaptent pas bien aux méthodes agiles, les applications informatiques lourdes (grosses bases de données par exemple) coûtent cher à défaire et à refaire et sont moins modulaires (surtout quand il y a une ancienneté à gérer).

Ils s'articulent mal en général avec des approches moins formelles (mais il y a des solutions...)