La méthode « Agile » constitue un complément intéressant et désormais indispensable à la gestion de projet conventionnelle qui, parfois, s’accroche un peu trop au plan initial (waterfall development : Requirements => Analyse/Design => Implementation => Testing => Rollout => Maintenance) sans réellement être capable d’intégrer des modifications et des changements en cours d’exécution.
Etre « Agile » est plus le respect d’une philosophie que l’application de techniques ou méthodes particulières. Dans la description ci-dessous, je vais me contenter de citer (recopier :-)) le « manifeste Agile » qui en décrit l’essence sans vraiment décrire et détailler une méthode particulière (RAD, SCRUM, Extreme programming, Crystal Clear, …). http://agilemanifesto.org/iso/fr/manifesto.html
Le Manifeste agile est un texte rédigé par 17 experts du développement d’applications informatiques. Ces experts estimaient que le traditionnel cycle de développement en cascade (waterfall) ne correspondait plus aux contraintes et aux exigences des organisations en évolution rapide. Les méthodes agiles ne sont pas apparues avec l’Agile Manifesto en 2001 mais celui-ci détermine leur commun dénominateur et consacre le terme d’« agile » pour les référencer.
Le reproche principal à la méthode traditionnelle est sa lenteur d’exécution et surtout son manque de souplesse et de réactivité face à l’évolution du besoin du client (parce que celui-ci a évolué ou par ce que la maturité du client face à ce besoin a évolué :-)).
Cela est dû au fait que dans, cette approche traditionnelle, le besoin est décrit tout en amont du processus de développement et est « fixé » contractuellement avant le début même du développement. Le client reçoit donc ce qu’il a contractuellement « demandé » et « validé » mais souvent le « délivrable »ne correspond pas ou plus au besoin réel et/ou actuel.
Alors que l’agilité était au départ, de par ses origines, exclusivement réservée au développement de programme informatiques, cette pratique est désormais sortie de son cadre stricte et s’exporte avantageusement à la gestion de projet de toute nature et même à la gestion d’une entreprise.
Les valeurs et les principes mis en avant par le « Manifeste Agile », de par leur caractère universel, sont selon moi parfaitement applicables dans l’ensemble des aspects de la vie professionnelle mais aussi personnelle.
Le « Manifeste Agile » préconise et favorise tout d’abord quatre valeurs fondamentales :
- Les individus et leurs interactions plus que les processus et les outils.
- Du logiciel qui fonctionne plus qu’une documentation exhaustive.
- La collaboration avec les clients plus que la négociation contractuelle.
- L’adaptation au changement plus que le suivi à tout prix du plan initial.
Cela ne signifie pas du tout que les items situés à droite n’ont pas ou plus d’importance mais bien que la préférence/priorité doit se porter sur les items qui se trouvent sur la gauche. Donc les uns n’excluent pas les autres mais deviennent prépondérant par rapport à ceux-ci.
Ces valeurs de bases débouchent sur la mise en œuvre de 12 principes :
- Prioriser la satisfaction du client.
La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement de nouvelles fonctionnalités à grande valeur ajoutée. Et pour savoir si le client est satisfait, le mieux est de l’impliquer activement et constamment dans le processus de développement. - Accepter et intégrer les changements.
il y a lieu de considérer les changements commes des alliés et plus commes des ennemis ou des obstacles. Il faut donc accueillir et intégrer positivement les changements de besoins, même tard dans le projet et s’organiser afin de pouvoir les intégrer en permanence. Les processus agiles exploitent le changement pour donner un avantage compétitif au client et une plus haute valeur ajoutée au produit fini délivré. - Livrer en permanence de nouvelles versions opérationnelles et incrémentales du produit.
le développement du produit (le résultat du projet) se fera de façon progressive et incrémentale. Il faut donc livrer fréquemment un logiciel/produit opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts. Il est clair qu’au début, ces versions successives ne seront pas terminées et n’offrent qu’une partie des fonctionnalités visées. Mais cette approche permettra au client de voir très rapidement vers quoi le développement se dirige et permettra d’identifier au plus tôt les divergences d’opinions (de compréhension) ou l’évolution naturelle des besoins. - Assurer le plus souvent possible une coopération étroite entre l’équipe du projet et les gens du métier.
Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. ceci n’est que la conséquence mais aussi la condition de la mise en oeuvre des trois principes précédents. - Construire les projets avec et autour de personnes motivées.
les équipe de projet et les représentant des utilisateurs doivent impérativement être des personnes motivées. En effet, l’interaction entre les deux mondes (développeurs / utilisateurs) étant permanente, le travail sera intense, rempli de remises en question et de réorientations. Fournissez-leur l’environnement et le soutien dont elles ont besoin et faites-leur confiance pour atteindre les objectifs fixés. - Favoriser le dialogue direct.
La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face. De même la méthode la plus efficace de savoir et comprendre ce que l’utilisateur désire réellement est d’en discuter régulièrement directement avec eux. - Mesurer l’avancement du projet en fonction de l’opérationnalité du produit.
Le développement étant progressif et incrémental, le logiciel/produit et sa partie déjà opérationnelle opérationnel est la principale mesure d’avancement du projet. - Adopter un rythme constant et soutenable par tous les intervenants du projet.
Le développement « agile » demande un énorme investissement des deux parties impliquées (développeurs et utilisateurs). On parle d’ailleurs de « sprints » … Il faut donc éviter des rythme trop intense qui risque de s’essouffler l’une ou les deux parties. Les processus agiles encouragent donc un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment et naturellement un rythme constant. - Contrôler continuellement l’excellence de la conception et la bonne qualité technique.
Une attention continue conduit à l’excellence technique et à une bonne conception renforce l’agilité. -
Privilégier la simplicité en évitant le travail inutile.
La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle. Les principes universels « KISS » et « Pareto » seront en permanence rappelés. -
Auto-organiser et responsabiliser les équipes.
Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées. -
Développer l’amélioration continue.
À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
Le développement agile, appelé aussi développement adaptatif, se caractérise donc par un style de conduite de projet :
- souple,fortement itératif et incrémental,
- centré sur le client/utilisateur,
- préconisant l’autonomie et la souplesse vis-à-vis des changements rencontrés et
- produisant une application intégrée et testée en continu (méthode agile).
Il se caractérise donc par une amélioration et un affinement continu et itératif du besoin « client » (et de sa compréhension) ainsi qu’une capacité accrues à s’adapter aux changements fonctionnels, organisationnels, technologiques, structurels, sociétaux ou autres…
Le tout débouchant plus rapidement sur un produit fini correspondant mieux aux besoins réels du clients.
Personnellement, en matière de gestion de projet, personnellement, je préconise une approche hybride entre le mode « cascade » pur et le mode « Agile « pur » en essayant que les qualités spécifiques de la « nouvelle » approche gomment les inconvénients incontestables de l’ancienne (qui globalement conserve toute sa pertinence de par son approche plus complète, globale et surtout plus holistique).
L’agilité aura toute sa pertinence principalement dans les phases « Planification et « Exécution » pendant lesquelles le classique principe PDCA (PLAN – DO – CHECK – ACT) sera fortement accéléré et institutionnalisé et dans lequel le client /utilisateur sera constamment impliqué.
Donc, si vous ne vous sentez pas prêts et mûrs pour appliquer une méthodologie 100 % « agile » (ou si votre organisation ne l’est pas :-)), commencez à appliquer à vos projets classiques une philosophie mettant en oeuvre les valeurs et les principes énoncés ci-dessus.Ce sera déjà un très bon début …
En effet, je suis convaincu que l’agilité est avant tout une attitude et une philosophie de développement plus que des méthodes bien précises.
