[Total : 0    Moyenne : 0/5]

L’agilité est un ensemble d’outils de gestion de projet qui permettent aux entreprises d’être plus flexibles et d’apporter plus de valeur aux clients.

Introduction

Les méthodes agiles sont des outils de gestion de projets plus pragmatiques que les méthodes traditionnelles, souvent très lourdes. En impliquant le client au plus tôt, ces outils permettent une grande réactivité, pour garantir la satisfaction réelle du besoin du client, et non uniquement répondre aux termes le contratL’indicateur clé de l’agilité, la Velocity représente la vitesse moyenne  pou effectuer une tâche.

L’indicateur clé de l’agilité: LA VÉLOCITÉ

selon l’étude du Standish group 2011

Les outils Agiles ont été développés dans les années 1990, notamment à la suite du Chaos Report du Standish Group, qui fournissait une étude sur le succès des projets. Ces rapports nous donnent les chiffres suivants :

Le manifeste Agile

La méthode a évolué au cours des années 90 sur la base du courant Lean . Mais ce sera en 2001, que l’Agilité trouvera son nom dans la publication du Manifeste Agile1 par 17 développeurs reconnus (dont Ward Cunningham, l’inventeur du principe Wiki pour ne nommer que le plus connu).

Moins structuré que les principes de Lean Way, nous trouvons beaucoup de corrélations que nous présentons ci-dessous.

Les 4 valeurs

Valeur 1 : Interagir avec les gens plutôt que les processus et les outils.

La cohésion d’une équipe est plus importante que le suivi des conventions. Cette phrase met l’accent sur la qualité des personnes impliquées et l’esprit de collaboration au sein de l’équipe. Cela reflète la synergie et la motivation qui doivent laisser au second plan, la rigidité des processus et la complexité des outils. L’élitisme est laissé de côté, souvent lié aux connaissances techniques, aux compétences interpersonnelles et à la motivation.

Valeur 2 : Un produit opérationnel plutôt qu’une pléthore de documentation.

Un logiciel partiellement fonctionnel a toujours plus de valeur qu’une documentation soignée.

Le but d’un développement logiciel est de produire un logiciel, la documentation doit être considérée comme un soutien complémentaire à sa compréhension. Il est préférable de se concentrer sur le produit plutôt que sur les éléments qui le décrivent.

Valeur 3 : Collaboration avec le client plutôt que négociation contractuelle.

Le client et le fournisseur sont des partenaires qui partagent un risque. L’agilité concerne la collaboration entre les deux parties afin d’atteindre un objectif commun. Le client doit s’impliquer et diriger l’équipe dans les étapes de réalisation. Il doit s’approprier l’évolution de son produit.

L’agilité évite le gaspillage des négociations et des demandes de changement. Elle propose d’investir ses efforts de manière constructive.

Value 4 : Réactivité au changement plutôt que le suivi d’un plan.

L’Agilité reconnaît l’apprentissage effectué au cours d’un projet. Que tout ne soit pas connu d’avance et que les adaptations sont inévitables. Le changement est intégré au modèle de développement. La planification initiale ne doit pas être trop détaillée, car certains aspects ne seront probablement jamais réalisés. Cela évite de détailler inutilement des éléments trop tôt dans le projet.

Les 12 principes

Principe 1 : Notre première priorité est de satisfaire le client en fournissant des logiciels utiles tôt et régulièrement.

Mettre rapidement le logiciel à l’épreuve du client est la première recommandation des méthodes Agiles. Grâce à ces retours, nous connaîtrons les ajustements nécessaires dans les meilleurs délais.

Nous trouvons ici l’idée du Milkrun.

Principe 2 : Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement en tant qu’avantage concurrentiel pour le client.

Les méthodes agiles intègrent la gestion du changement dans leur mode de fonctionnement. Les modifications sont intégrées lors de la planification d’une nouvelle itération.

Pour établir un parallèle avec l’état d’esprit Lean, nous sommes ici « accueillir positivement les problèmes ».

Principe 3 : Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.

Nous rejoignons l’idée du premier principe. Augmentons notre réactivité et notre flexibilité en livrant le client le plus souvent possible (Milkrun). Cela réduit considérablement les risques et permet de s’adapter plus facilement aux changements. De plus, ces livraisons fréquentes motivent l’équipe et aident à maintenir un bon rythme de travail.

Principe 4 : Les gestionnaires et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

C’est l’une des valeurs de minimiser les “ papiers” et la revue permanente des termes du contrat. Des réunions fréquentes avec le responsable sont là pour éviter les problèmes et répondre aux questions.

Dans L’état d’esprit Lean, travailler avec le client, les fournisseurs et tous les partenaires de la chaîne de valeur est “normal”.

Principe 5 : Construisez le projet autour de personnes motivées. Donnez-leur l’environnement et le soutien dont ils ont besoin et croyez en leur capacité à faire le travail.

La qualité d’un projet passe par la motivation et l’implication de l’équipe. Les managers doivent leur faire confiance et laisser l’autonomie leur permettant de faire ce travail.

Principe 6 : La méthode la plus efficace pour transmettre des informations au sein d’une équipe est la conversation face à face..

L’échange direct est le moyen le plus efficace de décider, de partager … On retrouve ici la philosophie Gemba.

Principe 7 : un logiciel fonctionnel est la meilleure unité de mesure de l’avancée du projet.

Ce sont les éléments qui ont pu être testé et validé le client qui constituent la meilleure preuve du bon déroulement du projet et de son avancement. L’idée est de sortir d’une planification trop lourde et de mettre en œuvre la culture Gemba.

Principe 8 : Les processus agiles favorisent un rythme de développement soutenable. Les sponsors, les développeurs et les utilisateurs sont en mesure de maintenir indéfiniment un rythme constant.

La charge de travail ne doit pas mettre trop importante sur les équipes car elle provoque une fatigue anormale. La charge doit être lissé dans le temps, pour éviter les à-coups.

En faisant le corollaire avec Lean, ce principe traduit l’idée de Heijunka, pour assurer une charge constante et lissée dans le temps.

Principe 9 : Une attention continue est portée à l’excellence technique et à la qualité de la conception.

Une bonne conception facilite les modifications du système et la maintenabilité. Il faut donc accorder une attention particulière à la qualité de la programmation.

Ici nous trouvons l’idée de management en amont des problèmes et the Pilar 5 of TPM.

Principe 10 : La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est essentielle.

La simplicité et la minimisation sont des facettes les plus importantes de l’agilité. Nous parlons ici de la notion de Muda, philosophie fondamentale de Lean. Le défi consiste à éviter toute action ou fonction inutile, générant du travail et des problèmes supplémentaires.

Principe 11 : Les meilleures architectures, spécifications et conceptions proviennent d’équipes auto-organisées.

L’équipe doit prendre les décisions techniques car elle est la mieux placée pour les prendre. Les compétences technologiques doivent leur permettre l’autonomie requise pour optimiser les résultats. Les développeurs sont souvent fiers de leur travail et recherchent l’excellence technique.

C’est l’idée de  Unité Autonome de Production : équipes multifonctionnelles (maintenance, production, achat …) pour piloter les ateliers de production.

Principe 12 : À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficaces, puis donne et ajuste son comportement dans ce sens.

La remise en question des processus de travail et un fondement de l’agilité. À intervalles réguliers, les équipes doivent se rencontrer et consacrer du temps pour revoir leur façon de faire et savoir comment faire mieux..

Ce principe reflète l’idée de Kaizen, à l’origine Lean.

Les Users Stories au centre des préoccupations

Au centre de L’agilité, la satisfaction des besoins du client. Nous arrivons ici à la même philosophie que Lean souhaitant créer le maximum de valeur ajoutée pour le client,  ou que le 6 Sigma visant à cibler la Voice of Customer.L’agilité parle de User Stories.

Une « user story » est une exigence formulée en une ou plusieurs phrases. Ils sont utilisés comme spécifications et représentent les critères lors des tests de réception.

L’utilisation de User Story incite à ne pas entrer dans les détails tant que cela n’est pas nécessaire. Ron Jeffries 2 propose une règle 3C pour traiter User Story :

  • Card : L’histoire est écrite sur une carte assez petite. Ces cartes peuvent être annotées avec des estimations de temps…
  • Conversation : Les détails de l’histoire seront exprimés lors d’une conversation avec le Product Owner. Nous allons utiliser la structure de conversation suivante : En que « Rôle », je peux « besoin » de façon à « bénéfice ». Exemple : En tant que visiteur, je peux cliquer sur le bouton enregistrez-vous pour parvenir au formulaire d’enregistrement
  • Confirmation : Elle définit clairement les critères d’acceptation.

Une bonne User Story est définie selon l’anagramme INVEST3 :

  • Independant : Chaque user story exprime une fonction différente des autres.
  • Negociable : Elle peut toujours être revue et réécrite de manière itérative. 
  • Valuable : Apporte une valeur vis-à-vis de l’utilisateur. 
  • Estimable : Nous sommes en mesure d’estimer le temps et le coût de la mise en œuvre.
  • Sized to fit : Elle définie des possibilités limitées pour une meilleure compréhension. 
  • Testable : Elle permet d’indiquer un ou plusieurs critères d’acceptation de l’histoire.

Les outils de l’agilité

Les méthodes agiles ont été développées en réponse à l’inefficacité et à la lourdeur des approches traditionnelles 4 . Ces projets sont planifiés et visent à prédire leur déroulement via le respect de tout un ensemble de normes de programmation. A l’opposé, les méthodes agiles préfèrent s’adapter au cours du projet. Pour cette raison, les outils de l’agilité sont classés selon un continuum Adaptif – Normatif 5 cdont voici une proposition.

 

← Normatif ———————————————- Adaptivf →

Méthode relativement lourde et précisant beaucoup de pratiques et de règles de développement

Méthode très légère s’adaptant au contexte et dénué de règles et pratiques de développement

RUP – DSDM / RAD – XP / ASD / FDD – SCRUM / LD / Crystal  Clear – Kanban

 

Dans l’esprit Agile, le défi consiste à combiner les différentes techniques et outils disponibles. Ainsi, il sera avantageux de combiner la simplicité du SCRUM avec certaines règles de conception du RUP par exemple.

The legend of Musashi

Musashi Miyamoto est un célèbre samurai du XVII èmesiècle. Il a conçu une technique de combat basée sur 2 sabres (Bokken). Il disait alors : “Ne vous liez pas à une seule arme ou à un seul style de combat“.

Lean et Agilité

L’agilité est dans la même veine que Lean. Développé plus récemment, elle repose sur des principes similaires de satisfaction du client, d’efficacité des processus, de flexibilité des équipes et de respect. Elle voit l’adaptation de certains outils, tels que Kanban, utilisé comme outil de gestion de projet. Le tableau ci-dessous propose une correspondance entre les principes de Toyota et le Manifeste Agile.

Les sections du Toyotisme

Les 14 principes de Toyota

Les principe Agile

Les valeurs de l’aAgilité

Philosophie Long Terme

1

1

Collaboration avec le client plutôt que négociation contractuelle

Le bon procédé (processus) produit le bon résultat

2, 3, 4, 5, 6, 7, 8

2, 3, 4, 7, 8, 9, 10

Un produit opérationnel plutôt qu’une pléthore de documentation

Ajouter de la valeur à l’organisation en développant les gens et les partenaires

9, 10, 11

5, 11

Interagir avec les gens plutôt que les processus et les outils.

La résolution de problèmes en continu comme moteur d’apprentissage pour l’organisation

12, 13, 14

6, 12

Réactivité au changement plutôt que le suivi d’un plan

Source

1 – http://agilemanifesto.org

2 – R. Jeffries (2000) – Extreme programming installed

3 – B. Wastes (2003) – Invest in good stories, and smart tasks

4 – M. Fowler (2005) – The new methodology

5 – B. Boehm, R. Turner (2004) – Balancing agility and discipline : a guide for the perplexed

D. Millington, J. Stapleton (1995) – Special report : developing RAD standard

N. R. Bodje N’Kauh, V. Balaji (2012) – Evaluation of the most used Agile methods

R. Medina (2013) – Petit guide de management Lean à l’usage des équipes agiles

Share This