Crédit photo : magia3e

Dans les universités américaines, 101 fait référence au premier niveau de formation sur une discipline, le niveau d’introduction. Dans cet article, nous ferons la synthèse d’une session de formation dispensée en interne, sur le sujet des méthodes agiles.

Manque de visibilité pour le client, dépassement des délais, coût exponentiel des bugs, stress des équipes : les approches traditionnelles en matière de développement logiciel ont montré leurs limites.

Les approches traditionnelles et leurs limites

Le modèle en cascade a été formalisé dans les années 70 par Winston Royce. Il consiste à décomposer un projet en différentes étapes, chaque étape étant prise en charge par une équipe différente : besoins, design, implémentation, tests, intégration, maintenance. Citons également le modèle en V, une variante qui consiste à ajouter une phase de test à chaque phase descendante. Par exemple, l’analyse des besoins est testée au moment de la recette finale. Et si le besoin ne correspond plus aux spécifications ? Trop tard !

Les problèmes générés par les modèles classiques

C’est principalement le facteur temps, notamment en terme de feedback, qui est en cause dans ces approches. Les équipes travaillent longtemps avant de tester le bon fonctionnement, le client ne voit pas ce qui se passe avant la fin du projet (parfois 6, 12 ou 18 mois). Le manque d’échanges avec le client peut aussi conduire à une mauvaise interprétation des besoins : il y a une vraie différence entre l’énonciation du besoin et son interprétation par les différentes équipes. D’autant plus qu’au moment de la livraison, les besoins ont le plus souvent changé. Ces modèles ne permettent ni d’anticiper les problèmes, ni l’évolution des besoins.

Or, parce que l’environnement évolue très rapidement, le client doit pouvoir changer d’avis ; le projet doit pouvoir s’adapter aux besoins. Dans une approche traditionnelle, il faudrait alors repasser par une longue phase de spécifications. Et toutes les phases suivantes !

Derrière tous ces écueils, les enjeux financiers sont importants. La mise en place tardive des tests pèse lourdement sur les budgets : plus tôt les bugs sont découverts, moins ils coûtent cher. Ainsi, un bug découvert en phase de design coûtera 5 fois plus cher que lors des spécifications.

Les approches agiles

Un panel de nouvelles approches et pratiques permettent de contourner ces problématiques, et mettre les équipes dans une nouvelle dynamique. Les approches agiles sont pour l’entreprise une façon de s’adapter rapidement au changement :

Ce n’est pas la plus forte des espèces qui survit, ni la plus intelligente, mais celle qui s’adapte le mieux

Charles Darwin

Aujourd’hui par exemple, de nombreuses start-ups vont très vite à l’essentiel, pour éprouver et tester leur business plan, et pouvoir l’adapter rapidement le cas échéant.

L’ agilité est l’habilité de créer et de répondre au changement dans le but d’avoir du succès dans un environnement d’affaires turbulent.

Jim Highsmith

Ce changement de paradigme n’est pourtant pas simple à mettre en œuvre. L’approche classique est pilotée par le plan initial : on établit l’objectif, et on adapte le planning et le budget en fonction. En mode agile, on inverse le triangle : quelle fonctionnalité business puis-je livrer dans 2 semaines ? Dans un mois ? Avec un objectif plus réduit, le budget est également plus cadré. L’objectif évolue en fonction du temps : en travaillant sur de plus petits lots, on gagne du temps et on peut alors intégrer de nouvelles fonctionnalités.

Source : PMI

Les 4 valeurs essentielles du monde agile

Fluidifier les relations, développer l’adaptabilité, faire évoluer la relation entre client et fournisseur…les valeurs du monde agile posent les conditions de base du succès du projet. On privilégiera ainsi l’équipe sur les outils, le bon fonctionnement de l’application plutôt que l’établissement d’une documentation technique. Il ne s’agit pas d’oublier la documentation, mais de la mettre à disposition ailleurs : dans le code, par exemple. Enfin, mettre en oeuvre la flexibilité permet de réagir facilement à l’évolution de la demande, qui sera également facilitée par l’implication du client dans le développement.

Source : Manifeste Agile

Les 12 principes de l’agilité  :

• 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 choses 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 de devenir plus efficace.

Construire une voiture en mode agile

Preuve que l’agilité n’est pas réservée au monde du développement logiciel, Joe Justice a un jour fait le rêve d’une voiture de course consommant 2,3 litres aux 100, capable de passer de 0 à 100 km/h en moins de 5 secondes, qui réponde aux conditions du concours Automotive X Prize, le tout avec un budget limité.

Joe a soumis l’idée sur Internet et lancé ce projet collaboratif en utilisant les méthodes Scrum et Kanban. Des internautes du monde entier ont ainsi collaboré via Skype, Dropbox, etc. A peine trois mois plus tard, un premier prototype fonctionnel était produit. Inimaginable dans l’industrie automobile !

Source : Ouishare.net

Conçu grâce à une approche modulaire, le véhicule est composé de 8 modules facilement interchangeables, et qui respectent une certaine API. C’est ce qui a permis à son créateur de présenter rapidement un prototype beaucoup plus design, après avoir étudié trois jours durant la construction de coques de navire en fibre de carbone : la nouvelle carrosserie, avec son budget de 800 dollars, a suscité l’intérêt des constructeurs. Aujourd’hui le projet continue, et le bolide ne cesse d’être amélioré. Cette histoire illustre bien les 12 principes cités plus haut : excellence technique, simplicité, amélioration continue…et démontre les possibilités d’application des méthodes agiles à d’autres domaines que le développement informatique.

Les différentes méthodes agiles

Si dans le cas de ce projet, ce sont essentiellement les méthodes Scrum et Kanban qui ont été utilisées, on trouve de nombreux autres courants dans le monde agile. Ils se démarquent par leurs particularités dans l’implémentation. Lean est ainsi inspiré de l’industrie automobile ; il en existe même une variante dédiée aux start-ups.

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 ? On commence souvent par donner une visibilité physique au projet : par exemple un tableau de post-its, sur lequel tous les acteurs construisent le projet ensemble et découpent les étapes en sous-tâches. Le tableau est visible de tous et évolue tous les jours : l’effet est à la fois ludique et psychologique. Cependant les approches agiles ne se limitent pas à cet aspect. On peut ainsi citer un certain nombre de bonnes pratiques, comme le daily standup où chacun explique ce qu’il a fait la veille, ce qu’il va faire aujourd’hui, et les difficultés rencontrées ; ou le planning d’itération, qui consiste à planifier ce qui sera fait dans les semaines suivantes, et ce qui sera livré. Dans l’approche Scrum, on parle alors de « sprint ». A l’issue du sprint, on revient sur ce qui s’est passé.

La méthode Scrum

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

Mode itératif

Mode incrémental

Source : Agile Product Design

Le succès de cette méthode repose sur la transparence : les posts-it sont là pour montrer exactement où chacun en est. Cela implique également de parler des difficultés rencontrées, ce qui n’est pas toujours simple à mettre en œuvre dans les structures pyramidales classiques.

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. En d’autres termes, il représente le client. 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, constituée de 5 à 9 personnes, 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. On comprend qu’une équipe Scrum qui fonctionne est capable de faire des miracles, ou presque. Cette équipe fonctionne suivant les principes évoqués plus haut : point quotidien, planning de sprint, rétrospective…

This is how my team rocks a sprint planning meeting! #scrum #SprintPlanning pic.twitter.com/Jm3QOeuJma

— Stephen Coulson (@sdcoulson) April 10, 2014

Scrum dans le détail

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 horaire. Cette estimation horaire est la base du burndown chart, qui montre la quantité de travail restant sur la durée du sprint.

Cliquer pour agrandir

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…Surtout, elles doivent apporter de la valeur. Ce vocabulaire spécifique permet de créer un langage commun entre les équipes métiers et les équipes IT.

Une évolution permanente

Cadres méthodologiques ouverts, les pratiques agiles évoluent régulièrement en fonction des retours d’expérience. La communauté Scrum française s’est d’ailleurs réunie début avril 2014 dans le cadre du Scrum Day 2014. A cette occasion, Alain Buzzacaro, directeur technique de FTVEN, a présenté son expérience de mise en place d’une transformation Agile chez France Télévisions Editions Numériques

Conclusion

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; ludiques par essence, leur acquisition se fait assez naturellement. Lors d’un prochain article, nous reviendrons sur la séance de formation suivante, consacrée à l’apprentissage des pratiques Scrum par le jeu.

Remerciements : Yacine Abid, notre coach agile!

Automatisation, Big Data, DevOps, Désautomatisation… tous ces sujets seront abordés lors du TIAD 2O16. Rejoignez-nous !