Le Manifeste Agile, ses 4 valeurs et 12 principes, sont la conséquence de la frustration des entreprises dans les années 1990 sur le laps de temps entre l’expression des besoins de l’entreprise et la livraison technologique de la solution. Les besoins business et métier évoluent pendant cette période et le produit final ne répond jamais aux besoins du moment qui ont changé.
“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.”
les 12 Principes Agile inclus dans l’Agile Manifesto décrivent une culture dans laquelle le changement est bien accueilli et le client est au centre du projet.
Selon une étude de 2017 réalisée par VersionOne « State of Agile Report », 94% des organisations font de l’agilité.
Mais qu’est réellement Agile et qu’est ce que la méthodologie Agile ?
Le mot “Agile” fait référence à un groupe de différentes méthodologies et de cadres de travail basés sur le développement itératif, la livraison incrémentale, la planification continue, l’apprentissage continu et les équipes pluridisciplinaires auto-organisées.
Ce groupe de méthodologies Agile et de cadres de travail ont en commun les 12 principes Agiles fondamentaux décrits dans le Manifeste Agile. Le principal avantage pour les organisations adoptant une méthodologie Agile est la capacité de « s’adapter au changement », de le valoriser et de l’apprécier à sa juste valeur.
Certaines méthodologies Agile se concentrent clairement sur la livraison et le développement de logiciels, d’autres sont plus axées sur les projets de toutes sortes et peuvent être utilisées comme des méthodes de gestion de projet.
Agile : Signification et Définition
Agile est un « terme générique » pour plusieurs méthodologies de développement (de logiciels) itératives et incrémentales. Ce qui est important dans les méthodologies agiles, c’est qu’elles sont toutes axées sur l’habilitation des personnes à collaborer et à prendre des décisions ensemble. Rapidement et efficacement.
La gestion de projet Agile décrit une approche itérative de la planification et de l’orientation des processus de projet. Cependant, Agile est un état d’esprit. Il n’existe pas une unique approche de gestion de projet Agile qui fonctionne dans toutes les situations; le terme général « Agile » représente plutôt une variété de méthodes et de pratiques qui s’alignent sur les valeurs présentes dans le manifeste Agile. Agile consiste à créer une culture dans laquelle les équipes Agile coopèrent et collaborent pour générer de la valeur.
Comme il n’existe PAS de solution universelle pour adopter ou mettre en œuvre une approche agile, il existe plusieurs types de méthodes Agiles (souvent appelées «cadres» ou « frameworks ») pour répondre aux besoins variés des différentes organisations et équipes.
DantotsuPM.com 
Voyons la différence en diverses langues dans l’expression du principe 4 parmi les 12 principes associés au manifeste agile « Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet » (que je traduis en Anglais pour raison de comparaison) : “Business people and developers must work together daily throughout the project”
French: « users or their representatives and developers »
German: « specialists and developers »
Italian: « clients and developers »
English: « business people and developers »
Spanish: « business managers and developers »
Dutch: « business people and developers »
Swedish: « business people and developers »
Finnish: « business representatives and software developers »
Turkish: « owners of business processes and software »
Croat: “business people and development engineers”
Polish: « business and development teams »
Russian: « developers and business »
Chinese: « business people and developers »
Japanese: « business people and developers »
Ces différences sont elles significatives dans la manière d’aborder l’agilité ? Par rapport à mon expérience personnelle, je crois que la réponse est « oui ». Nous avons ainsi des versions différentes de l’agilité en fonction de la langue utilisée.
J’aimeJ’aime
En effet Ian, certaines différences peuvent faire justement ne grosse différence ! Comme user or their representeratives CS business people!
J’aimeJ’aime
Bonjour Ian, puis-je faire ton commentaire un article du blog. Je suis certain qu’il retiendra l’attention de nombreuses personnes.
J’aimeJ’aime
Oui, bien sûr, Michel. Ian
J’aimeJ’aime
Je fais volontairement ce que l’on appelle en coaching de la dissonance cognitive. Je ne suis pas un expert des méthodes Agile mais je me suis intéressé à l’épistémologie de ces méthodes.
Les conclusions auxquelles je suis arrivé sont que les méthodes Agile sont de méthodes de développement de produit et non de gestion de projet. Le PMBOK est clair sur ce point. Il y a des cycles de vie de projet et des cycles de développement de produit qui s’articulent dans les WBS.
Vous pouvez aussi regarder les sites SDLC.com et coleyconsulting.com. Vous y trouverez la généalogie des méthodes antérieures à Agile. Vous verrez qu’Agile n’est autre qu’une association des cycles de développement incrémentiel et itératif.
Les méthodes Agile sont ce qu’il sont mais ce n’est pas révolutionnaire. J’ai eu l’opportunité de travailler sur un chantier BTP comme ingénieur planning. Un projet BTP est géré en Agile. Tous les jours il y a une réunion le matin entre les chefs de chantiers et leurs compagnons. Toutes les semaines, il y a une réunion de chantier où l’on travaille sur un planning glissant sur quatre semaines. On a bien des mélées, des scum masters, des sprint, un product owner. Sur une base vie, il y a toujours un représentant du client avec qui on peut discuter de clarifications / modifications. Il fait aussi des descentes sur le terrain pour inspecter ce qui est fait. Vous verrez d’ailleurs avec les sites que je viens de vous communiquer que la méthode waterfall des années 50 et 60 est un copier / coller des méthodes du BTP.
Deux questions pour terminer aux pesonnes qui font de l’Agile :
– Est-ce que le client vous paie à la fin de chaque sprint ? Si non, c’est que votre sprint est inclus dans un environnement plus large qui n’est pas celui du produit au sens de livrable mais du projet avec toutes les contraintes d’un projet, référence de base, risque, qualité, parties prenantes).
– Un retour d’expérience m’a été donné il y a quelques temps : dans un sprint de trois semaines, il s’est avéré que seulement 70% de ce qui devait être fait a été fait. Comment sur trois semaines peut-on faire seulement 70%? En sus, avez-vous calculé le coût final du sprint. Si dans un sprint vous devez faire 100 pour un coût de 100€. Si vous ne faites du 70%, quel est le coût de ce que vous avez fait ? Simple 100 / 70 = 1.428. Soit un dérapage de près de 43% sur le coût du sprint. Ne faudrait-il pas remettre un peu de gestion de projet comme la gestion des risques ou la valeur acquise ?
J’aimeJ’aime
Merci Thierry pour tes commentaires et questionnement. Puis-je reprendre ton texte pour en faire un billet et voir s’il suscite des réponses ?
J’aimeJ’aime