Du manifeste aux méthodes agiles : tout comprendre à l'agilité

Par Jérémy le 10/09/2019 dans Articles

Expertise

10 minutes

Que signifie réellement « l’Agilité », ce terme tant galvaudé venu des Etats-Unis ? Familier aux start-ups qui sont nombreuses à avoir adopté ces nouvelles approches de gestion de projet ou de produit, il reste difficile à appréhender pour beaucoup de grands groupes. Commençons par définir les méthodes agiles par ce qu'elles ne sont pas : une solution en réaction aux difficultés rencontrées lors de l'application traditionnelle de gestion de projet au développement de produits numériques ?

Comment définir les approches traditionnelles de gestion de projet ?

On appelle “approches traditionnelles” les modèles en cascade ou en « cycle en V » qui ont été formalisées dans les années 70. Elles consistent à décomposer un projet en grandes étapes chronologiques. Chaque étape est réalisée par une équipe différente qui suit scrupuleusement le besoin initial détaillé dans un cahier des charges. Une fois le produit fini, il est testé puis mis sur le marché.

Prenons l’exemple de la construction d’un immeuble pour définir les différentes étapes :

  • La spécification des besoins : le client souhaite un immeuble d’habitation de X appartements, exposé de telle façon
  • Le design : l’architecte réalise les plans de chaque étage, de la façade, du toit…
  • La construction et l’implémentation : une fois les plans validés, les ouvriers construisent sous la direction des architectes
  • Les tests : les experts vérifient que l’isolation est conforme aux normes
  • La maintenance : un service de maintenance s’assure que l’immeuble est bien entretenu

La réponse aux besoins exprimés initialement par le client est donc testée une seule fois au cours de la construction : après l’assemblage final.

Dans le BTP, où les contrats sont signés des années avant la construction, le besoin change rarement du jour au lendemain.

Ainsi le constructeur doit s’engager sur trois grands facteurs :

  • Le périmètre fonctionnel : celui-ci est gravé dans le marbre à l’origine du projet et garanti par un contrat
  • Le coût : e prix est établi en amont. Pour maintenir sa marge, le constructeur doit également définir ses coûts en amont permettant de générer un budget
  • Le temps : le planning, construit à partir d’une estimation précise du temps requis dans chaque équipe, est fixé en amont

Cette méthode ne laisse aucune place au feedback ou à l’évolution de besoin en cours de chantier et le client ne voit pas ce qui se passe avant la fin du projet.

Les approches traditionnelles de gestion de projet

Pourquoi les méthodes traditionnelles ne peuvent-elles pas s’appliquer au développement de produits numériques ?

Le client du produit numérique est bien différent. Ses besoins changent régulièrement, il est en quête de rapidité voire d’instantanéité.

Dans ce contexte, l’équipe de développement du produit numérique ne peut s’engager sur un périmètre fonctionnel, un coût et un planning comme l’impose l’approche traditionnelle. En effet, le besoin du client et son feedback doivent être collectés le plus régulièrement possible afin que le produit réponde au mieux à son besoin. C’est à la suite de ce constat que l’agilité à fait son apparition.

Les principes de l’Agilité

Un panel de nouvelles approches et pratiques permettent de contourner les rigidités créées par les approches traditionnelles. Elles sont pour l’entreprise un moyen de s’adapter rapidement au changement. Spotify, Facebook, BlablaCar et beaucoup d’autres ont pu prouver leur efficacité.

L’Agilité a été définie dans le Manifeste Agile à travers 4 valeurs :

  1. Les individus et les interactions plutôt que les outils et les processus
  2. La qualité fonctionnelle plutôt que la réalisation de documentations techniques (il ne s’agit pas d’oublier la documentation, mais de la produire au fil de l’eau, lorsqu’elle est réellement nécessaire au développement)
  3. La collaboration avec le client plutôt que les négociations contractuelles
  4. La flexibilité permettant de réagir facilement à l’évolution de la demande, (qui sera facilitée par l’implication du client dans le développement) plutôt que le suivi d’un plan défini en amont

Et 12 principes :

  • Livrer régulièrement des fonctionnalités à forte valeur ajoutée
  • Accueillir positivement le changement de besoin
  • Livrer fréquemment un logiciel fonctionnel
  • Les acteurs du projet doivent travailler quotidiennement ensemble
  • Donner les moyens et les outils pour réussir aux membres de l’équipe
  • Transmettre l’information par le dialogue, en face à face
  • Le logiciel opérationnel marque l’avancement du projet
  • Le rythme de développement soutenable évite les montées de stress. Il est maintenu sur la longueur, avec des échéances plus fréquentes
  • Une attention continue à l’excellence technique
  • La simplicité est de rigueur. On commence par des tâches simples, que l’on fait évoluer ensuite
  • Les meilleures architectures viennent d’équipes auto-organisées
  • A intervalles réguliers, l’équipe réfléchit aux moyens pour devenir plus efficace

Meilleure visibilité, réduction des risques, réduction du time to market, capacité à changer rapidement de focus, meilleur moral des équipes…quelles sont les pratiques agiles qui amènent ces bénéfices ?

La diversité des méthodes agiles

Une fois qu’une organisation décide d’adopter une gestion de développement agile, il reste encore à choisir la méthodologie la plus adaptée à son projet. En effet, les méthodes agiles disponibles sont nombreuses et plus ou moins prescriptives. Chaque méthode nécessite d’être plus ou moins rigoureux sur le nombre de cérémonies, de process et d’artefacts à respecter.

La méthode Scrum

Approche la plus répandue, Scrum est très fortement orientée vers la collaboration d’équipe. De plus, c’est un cadre de travail qui permet d’agir à la fois de façon itérative et incrémentale.

Le succès de cette méthode repose sur la transparence qui se traduit notamment à travers le management visuel. Ainsi, les tâches de développement ou User Stories sont souvent matérialisées sur un tableau de post-it qui sert de référentiel à tous les acteurs du projet. Ce tableau est visible de tous et évolue tous les jours : l’effet est à la fois ludique et psychologique.

L’ensemble des besoins priorisés est appelé product backlog ; il est découpé en sous-ensembles, puis en sous-tâches dont on fait l’estimation du temps de développement. Cette estimation est la base du burndown chart, qui montre la quantité de travail restant sur la durée du sprint. Pour s’assurer du bon dimensionnement des tâches, on distingue les thématiques (Epic) des fonctionnalités (User Stories). Les User Stories sont indépendantes entre elles, elles doivent être estimables et testables. Elles doivent surtout apporter de la valeur. Ce vocabulaire spécifique permet de créer un langage commun entre les équipes métiers et les équipes IT.

On distingue différents rôles dans le cadre d’un projet mené en Scrum. Le Product Owner donne le cap du projet : il établit les priorités, prend les décisions concernant les fonctionnalités du produit. Le Scrum Master est à la fois le guide et le protecteur de l’équipe. Il est le garant du bon déroulement du processus, et il protège l’équipe des interruptions, filtre les perturbations …bref, il s’assure que l’équipe garde l’objectif bien en vue. L’équipe est multi-compétences et capable de livrer très régulièrement. Chaque membre peut aussi bien travailler sur les spécifications, le développement, le test, ou la livraison en production.

La vie de l’équipe (et du produit) est rythmée par les sprints de développement et les cérémonies agiles qui les encadrent :

  1. Le daily scrum meeting ou daily stand up meeting : chaque membre de l’équipe explique, devant le board (tableau de posts-its) ce qu’il a fait la veille et ce qu’il fera ce jour, il évoque ainsi ses difficultés et réussites
  2. Le planning de sprint : c’est l’exposition de la planification du sprint suivant en détaillant les User Stories qui seront développées par l’équipe
  3. La démo : c’est la démonstration des fonctionnalités mises en production à toutes les parties prenantes du produit (clients / responsables hiérarchiques / facilitateurs techniques ou opérationnels…)
  4. La rétrospective : en fin de sprint, l’équipe se rassemble pour évoquer les éléments qui ont bien fonctionnés et qu’il faut garder pour le prochain sprint de développement, ceux qu’il faut abandonner et ceux qu’il faut initier. C’est l’occasion de revoir les processus pour améliorer le fonctionnement de l’équipe

La méthode Kanban

Le terme Kanban signifie « panneau » en japonais. Les principes fondamentaux de cette technique sont les suivants :

  • La visualisation : le Kanban est un tableau blanc alimenté de post-it décrivant des tâches à effectuer. On place chaque post-it (ou tâche) dans la colonne appropriée pour spécifier son état d’avancement. Notons qu’un Kanban peut aussi être virtuel grâce à des outils tels que Kanbanize, Trello, etc. même s’il est plutôt conseillé de privilégier le tableau physique. L’objectif principal du Kanban est de permettre de visualiser l’ensemble des tâches et leur statut en un coup d’œil. La visualisation est très importante. Sans compter que c’est une réelle satisfaction de voir nos post-it passer une à une dans la colonne « Terminé » !
  • La limitation du travail en cours : des listes de tâches à effectuer, nous en faisons tous. Mais, le principal problème de ces listes est qu’on en voit jamais la fin ! En limitant le nombre de tâches dans chaque colonne du Kanban, on divise une liste qui serait interminable en une série construite de listes réduites. En décomposant le travail, et en limitant le nombre de tâches de chaque colonne, on favorise l’accomplissement de celles-ci.
  • L’amélioration continue : le Kanban est une application de la méthode Kaizen (fusion des mots japonais « kai » et « zen » qui signifient « changement » et « bon »). Il invite à l’analyse et à la contribution des membres de l’équipe afin de suggérer des améliorations et des ajustements tout au long du projet pour une conduite plus efficace et plus productive.

La méthode XP

XP eXtreme Programming est une méthode de développement agile, orientée projet informatique et dont les ressources sont régulièrement actualisées. Cette méthode est destinée à accélérer drastiquement la réalisation des projets de type flexible. Elle a été conçue à l’origine par Kent Beck alors qu’il intervenait en pompier sur un projet de gestion de paye écrit en smalltalk chez Chrysler.

Une règle fondamentale de la méthode : le client ou un représentant avisé participe au développement.

Principes de la programmation XP :

  • L’étroite communication entre tous les acteurs du projet est un principe fondamental auquel aucune méthode de type agile ne saurait déroger
  • Une planification très souple à court horizon est le garant d’une parfaite maîtrise entre le réalisé et les attendus des clients décisionnaires
  • L’estimation des coûts est bien plus simple et plus précise autant pour le confort des développeurs que des clients
  • La livraison rapide de prototype permet l’évaluation des fonctionnalités réalisées et l’opportunité des futurs développements
  • Remarque : Un prototype n’est pas une maquette. Une maquette est statique, un prototype est opérationnel
  • Le XP programming préconise le B.A BA de tout programmeur digne de ce nom : produire du code simple et aisément lisible. Selon les promoteurs de l’eXtreme Programming, le travail en binôme facilite cette qualité essentielle caractérisant une programmation professionnelle

La méthode SAFe

Le Scaled Agile Framework (SAFe) est un cadre agile qui tente de répondre aux nombreux défis auxquels doit faire face une grande entreprise lors d’une transition agile. SAFe est un cadre éprouvé depuis plusieurs années par M. Dean Leffingwell lors de ses expériences avec des centaines d’équipes auprès d’entreprises telles que John Deere et Nokia.

Ce framework est conçu pour fonctionner avec un minimum de 50 personnes. Il est donc inutile de tenter de le mettre en place sans l’adapter pour 3 équipes représentant 20 personnes.

Ce framework est composé de 4 blocs qui représentent les différents niveaux de gestion du produit :

  • Team : on retrouve ici les équipes qui travaillent en Scrum, Kanban et/ou XP.
  • Program : il s’agit du niveau supérieur qui va aider le “bloc team” à travailler sur les mêmes sujets. On va trouver des System architecture qui vont gérer les tech de chaque équipe, des Product Manager qui vont travailler avec les Product Owner et enfin des Release Train Engineer (RTE) qui vont accompagner les Scrum Master.
  • Large solution et Portfolio : plus rarement déployés dans l’état, ces deux derniers blocs font appel à des niveaux plus macros et stratégiques du produit.

Pour conclure, exit les approches traditionnelles quand elles ne fonctionnent pas, place à l’Agilité ! Qu’il s’agisse de développement logiciel, de construction automobile, ou même d’un projet personnel, les approches agiles révolutionnent les méthodologies de gestion de projet. De par leur nature, elles sont appelées à évoluer très rapidement et ludiques par essence, leur acquisition se fait assez naturellement.

A retenir

  1. L’Agilité regroupe de nombreuses méthodes qui devront être choisies en fonction des besoins et de la composition de l’entreprise. Ces méthodes devront être adaptées pour pouvoir être intégrées plus facilement dans les équipes selon leur maturité.
  2. Les méthodes agiles viennent challenger les méthodes traditionnelles qui ne sont plus adaptées à des rythmes soutenus de développement inhérents aux produits digitaux.
  3. La méthode Scrum est celle dont on entend le plus parler et qui est la plus déployée dans les entreprises. C’est une première brique permettant de dé-siloter les équipes et d’accélérer les processus de développement.
Card image cap
Jérémy

Coach