Méthodes Agiles et Scrum

AMI

18/07/2009 - Ionut Milhalcea

Introduction

Le développement de logiciel est une entreprise très compliquée avec de fortes imbrications sociologiques et techniques. D’un point de vue social elle implique des interactions importantes entre les différents membres d’une équipe. Ces interactions sont la conséquence directe de la complexité des technologies employées et de la sophistication des systèmes informatiques à développer.

L’équipe de développement évolue dans un environnement changeant sur le plan des techniques et des exigences fonctionnelles. Pour faire face à toutes ces problématiques et réussir un projet de développement plusieurs facteurs primordiaux doivent être maitrisés :

• Ressources humaines et matérielles ;
• Coûts ;
• Délais ;
• Qualité.

Par leurs valeurs et leur philosophie, les méthodes agiles prennent en compte ces contraintes en considérant le changement comme une opportunité dans le processus de développement.

Il s’agit ici de prendre connaissance avec la « philosophie agile » en général et d’étudier les « outils » que Scrum met à notre disposition pour pouvoir mettre en application une méthodologie agile.

Commençons par une rapide rétrospective des méthodologies, en partant de la méthode d’ingénierie qui marqué les modes d’organisation et de production de l’industrie en général, à savoir le système de production de Toyota. Puis nous nous pencherons sur l’histoire de quelques méthodes qui ont marqué le management de projet dans note industrie. Ce regard rétrospectif nous permettra de mieux comprendre les méthodes agiles.

Rétrospective

Depuis 1950 Toyota Production System (TPS)

Dans les années 1950 Toyota doit faire face au manque de moyens financiers, au mauvais état général de l’industrie du Japon d’après guerre, et à une concurrence féroce menée sur le continent américain par Ford. Cette conjoncture défavorable pousse Toyota à développer un processus industriel innovant. Utilisé comme une véritable arme stratégique, le TPS lui a permis de s’imposer au fil du temps pour devenir aujourd’hui le premier constructeur mondial d’automobiles. Nous allons voir par la suite que les piliers de TPS (le souci de la qualité du produit, la satisfaction du client et l’attention accordée au travail en équipe) se retrouvent également dans les méthodes de développement de l’industrie informatique.

Le TPS se base sur quatre principes fondateurs :

Philosophie à long terme

• Fonder les décisions sur une philosophie à long terme, même au détriment des objectifs financiers à court terme ;

Processus : éliminer le gaspillage

• Créer un « flux » de processus pour mettre au jour les problèmes ;
• Utiliser des systèmes « tirés » pour éviter la surproduction ;
• Lisser la charge de travail ;
• Arrêter la fabrication en cas de problème de qualité ;
• Standardiser les tâches pour favoriser l’amélioration continue ;
• Utiliser le contrôle visuel pour que les problèmes ne passent pas inaperçus ;
• Utiliser uniquement des technologies fiables et éprouvées ;

Travail d’équipe : Respecter, mettre au défi et développer

• Former des responsables qui viennent de la philosophie ;
• Respecter, développer et mettre au défi les employés et les équipes ;
• Respecter, développer et aider les fournisseurs ;

Résolution de problème : Amélioration continue et apprentissage

• Apprentissage organisationnel continu ;
• Aller voir soi-même pour comprendre la situation ;
• Prendre le temps de décider, par consensus, en étudiant soigneusement toutes les options, puis mettre en œuvre rapidement ;

En qui concerne les méthodes employées en informatique le point de départ de la rétrospective sera la fin des années 80, au moment ou les premières méthodes de développement itératif ont vu le jour.

 

1988 - Spiral Model

Présenté par Barry Boehm dans son article de 1988 « A Spiral Model of Software Development and Enhancement », ce modèle n’est pas le premier à mettre en avant une approche itérative mais il a été le premier à démontrer que l’itération a une importance primordiale. Le modèle de Boehm est un modèle itératif qui permet l’obtention de la qualité par le prototypage et l’analyse des risques au niveau de chaque itération.

 

1991 – 1994 Rapid Application Development 1 & 2 (RAD)

Basé sur le principe itératif de Boehm, James Martin propose un modèle rapide de développement axé sur un principe adaptatif fondé sur la validation permanente des utilisateurs.

Jean-Pierre Vickoff en France, notamment avec le Processus RAD2 publié par le Gartner Group, et Jennifer Stapleton (avec Dynamic Systems Development Method) en Grande-Bretagne introduisirent des compléments tels que :

• la spécialisation des rôles ;
• l’instrumentation des communications ;
• l’organisation des divers types de réunions ;
• le groupe de facilitation et de rapport ;
• les « raccourcis méthodologiques » de modélisation ;
• l’architecture de réalisation (imbrication des itérations) ;
• la formalisation de processus légers de mise en œuvre.

 

1991 - Scrum

Jeff Sutherland et Ken Schwaber présentent conjointement la première publication présentant SCRUM à l’occasion de la conférence OOPSLA (Object-Oriented Programming, Systems, Languages & Applications). Les idées clé de Scrum sont :

• Le client au cœur du projet ;
• Esprit d’équipe ;
• La communication est la clé ;
• Simplicité, Efficacité, et Qualité ;
• Flexibilité aux changements ;
• Avancement basé sur le concret ;

 

1999 - eXtreme Programing (XP)

Inventée par Kent Beck, Ward Cunningham et Ron Jeffries, XP voit le jour officiellement à l’occasion de la publication du livre écrit Kent Beck : « Extreme Programming Explained ».

Les valeurs véhicules par XP sont :

La communication

• Facteur essentiel dans la réussite du projet ;
• La communication honnête et régulière permet de s’ajuster aux changements ;
• Le face à face est plus efficace que le e-mail ;

Le feedback

• Avoir un retour rapide sur ce qui à été produit ; 
• Favorise les ajustements et le changement au plus vite, donc à un moindre coût ;

La simplicité

• Développer uniquement le système nécessaire. Ce qui signifie, par analogie au TPS, éviter le gaspillage ;
• Le courage ;
• Le seul moyen de réparer une erreur est de l’admettre et de la corriger ;

 

2001 – Le Manifeste Agile

En Aout 2001 aux Etats Unis, 17 figures marquantes du développement logiciel (Kent Beck, Ward Cunningham, Ron Jeffries, Alistair Cockburn, Jeff Sutherland, Martin Fowler etc.) se sont réunies pour essayer de définir les valeurs et les principes des méthodes agiles. Le résultat de leur réunion est une charte nommée « Le Manifeste Agile » qui devient le dénominateur commun, l’élément unificateur des méthodes agiles.

Cette charte présente les quatre valeurs fondamentales de toute méthode agile :

Les interactions entre individus au dessus des processus et outils

• Travail en groupe, communication ;
• Responsabilité ;

Un système qui marche plutôt que la documentation complète

• Documenter l’essentiel et tenir cette documentation à jour ;
• Documentation permanente du code ;

Collaboration avec le client plutôt que la négociation permanente

• Associer le client à l’équipe de développement ;
• Feedback régulier du client ;
• Relation de confiance ;

Accepter le changement plutôt que suivre un plan

• Considérer le changement comme une opportunité ;
• Effectuer le changement au plus tôt donc à un moindre coût ;
• Se doter des outils qui permettent ou facilitent le changement : tests unitaires, tests d’acceptance, outils de refactoring ;

 

Scrum

Scrum est un « framework » de management de projet et non pas un processus prescriptif qui dicte toutes les opérations à suivre pendant le développement de logiciel. Scrum met à disposition quelques outils et principes fondamentaux et ensuite le processus de développement est dirigé par l’expérience. Le but principal de Scrum est de développer uniquement les fonctionnalités qui apportent une valeur ajoutée au produit, en toute transparence, avec le souci de la qualité et du respect des délais, avec un retour rapide de la part du client.

Le schéma suivant donne un très bon aperçu de la démarche itérative de Scrum et permet d’analyser par la suite les notions fondamentales de cette méthode.

 

 

Fondamentaux de Scrum

Rôles dans Scrum

Le Scrum Master

• S’assure que les principes et les valeurs de Scrum sont respectés ;
• Facilite la communication au sein de l’équipe ;
• Cherche à améliorer la productivité et le savoir faire de son équipe

L’équipe

• Pas de rôle bien déterminé : architecte, développeur, testeur
• Tous les membres de l’équipe apportent leur savoir faire pour accomplir les tâches
• Taille de 6 à 10 personnes en général et pouvant aller jusqu'à 200 personnes

Le Product Owner

• Expert métier, définit les spécifications fonctionnelles
• Etablit la priorité des fonctionnalités à développer ou corriger
• Valide les fonctionnalités développées
• Joue le rôle du client

 

Product Backlog

Le Product Backlog est le cœur de Scrum, là ou tout commence. Le Product Backlog est une liste priorisée contenant les exigences, les fonctionnalités à développer. Il ne doit pas nécessairement contenir toutes les fonctionnalités attendues dès le début du projet, il va évoluer durant le projet en parallèle des besoins du client. Les fonctionnalités décrites portent le nom de « User Stories » et sont décrites en employant la terminologie utilisée par le client.

Une « User Story » ou « Story » contient les informations suivantes :

• ID – un identifiant unique
• Nom – un nom court (2 - 10 mots), descriptif de la fonctionnalité attendue (ex. Export / Import Standard Sales Item). Le nom doit être suffisamment clair pour que les membres de l’équipe et le Product Owner comprennent de quelle fonction il s’agit. Le nom ne doit pas introduire d’ambigüités.
• Importance – un entier qui fixe la priorité des Stories. La priorité d’une story peut être changée en cours de réalisation du projet.
• Estimation – La quantité de travail nécessaire pour développer, tester, et valider la fonctionnalité. L’unité de mesure peut être un nombre de jours idéaux (jours à 100% dédiés à la fonctionnalité) ou un nombre de points. Les estimations se font en relatif en comparant les estimations des stories terminées avec la story à estimer.
• Demo – Un test relativement simple (ex : exporter un objet en XML puis l’effacer de la base, l’importer depuis le XML, à la fin l’objet doit être dans la base). Ce test constitue un test de validation.
• Notes – toute autre information : clarifications, références documentaires etc.…

 

Sprint

Scrum est basé sur une approche itérative et « Sprint » est le terme utilisé pour désigner une itération. Un  Sprint  doit ajouter de la valeur au produit en réalisant un certain nombre de stories décrites dans le Product Backlog. Un Sprint dure généralement de 3 à 4 semaines, il débute par réunion de planification appelée « Sprint planning » et finit par une réunion de clôture appelée « Sprint Review ». Durant le Sprint il très important que l’équipe ne soit pas perturbée avec de nouvelles demandes de développement, de cette manière elle pourra respecter les engagements pris au début du Sprint. Si à la fin du sprint des stories sont « en cours » de réalisation ou « à faire » elles seront intégrées sur le Sprint suivant.

Sprint Planning et Vélocité

Le Sprint Planning est une réunion très importante dans Scrum, dont le but principal est de donner à l’équipe suffisamment d’informations pour qu’elle puisse travailler pendant quelques semaines. Concrètement, à l’occasion de cette réunion on doit déterminer :

• Le but à atteindre;
• La liste de participants au Sprint;
• Le Sprint Backlog (la liste des User Stories à traiter);
• La date de démo;
• Le lieu de la réunion Scrum quotidienne.

A cette réunion participent le Product Owner, le Scrum Master et le reste de l’équipe. Le Product Owner établit les priorités parmi les fonctionnalités à développer et il répond aux questions fonctionnelles de l’équipe. Les Stories à introduire dans le Sprint Backlog sont choisies par l’équipe de développement en base du nombre de points de chaque story, et de sa capacité de travail ou vélocité.

La vélocité est estimée au début du premier Sprint et est ensuite ajustée à la fin chaque Sprint. Supposons la situation suivante :

La vélocité est un chiffre brut qui peut varier en fonction de beaucoup de facteurs (humains, matériels, etc.), elle doit être vue comme un indicateur qui au début du projet est flou et très instable, mais qui s’affine et devient de plus en plus précis au bout de quelque Sprints sous l’effet de l’expérience.

Sprint Backlog

Le Sprint Backlog est un sous-ensemble du Product Backlog et contient les stories à traiter durant un sprint.

Les stories du Sprint Backlog sont choisies durant le Sprint Planning et constituent un engagement de la part de l’équipe envers le Product Owner. C’est pourquoi il est très important que l’équipe et le Scrum Master soient ceux qui dimensionnent la taille du Sprint Backlog. Un exemple de Sprint Backlog pourrait être le tableau suivant :

Story	Points
Import/Export log application	3
Ajout historique des connexions	5
Ajout service synchrone Import/Export	2
Ajout service envoi automatique des erreurs	6

 

Pour améliorer la communication au sein de l’équipe il est préférable de publier sur un site intranet le contenu du Sprint Backlog, en précisant également le nom des intervenants et leur charge durant le sprint.

Chaque jour, après la réunion Scrum, le Scrum Master maintient un graphique appelé sprint burndown chart. Ce graphique donne une très bonne vision de ce qui a été fait et du rythme de travail de l’équipe. Il permet également d’anticiper si toutes les stories du Sprint Backlog seront terminées à la fin de l’itération ou non.

 

En cas d’un éventuel retard, le Product Owner doit être consulté et, en commun accord avec lui, des décisions d’ajustement peuvent être prises :

• Sortir une ou plusieurs stories du Sprint Backlog ;
• Réduire l’étendue d’une ou plusieurs stories;

Scrum Meeting

Durant le Sprint toutes les journées débutent avec une courte réunion (environ 15 min.) appelée « Scrum Meeting ». La réunion est conduite par le Scrum Master et toute l’équipe de développement y participe. Cette réunion n’a pas seulement un but purement informatif, mais aussi de stimuler l’esprit travail en équipe et le niveau d’engagement de chaque membre de l’équipe dans le projet. Durant la réunion chaque membre de l’équipe doit prendre la parole et présenter principalement les choses suivantes :

• Ce que j’ai fait hier et les éventuels problèmes rencontrés;
• Ce que je vais faire aujourd’hui ;
• Est ce que j’ai des difficultés pour continuer mon travail.
• En faisant cet exercice quotidiennement chaque membre de l’équipe est au courant de ce que font ses collègues et il peut coordonner son travail et aider ou se faire aider en cas de difficultés.

Le Scrum Meeting n’est pas une réunion pendant laquelle on cherche à résoudre les problèmes, mais uniquement à les identifier et les exprimer. Le Scrum Master a pour rôle d’apporter des solutions ou de déléguer à un autre membre de l’équipe la résolution des problèmes soulevés durant le Scrum Meeting. A la suite de cette réunion le Scrum Master met à jour le burndown chart.

Sprint Review

Le « Sprint Review » est la réunion de clôture d’un Sprint. A cette réunion participent le Scrum Master, le Product Owner, l’équipe de développement dans le but de présenter les fonctionnalités implémentées durant le Sprint.

Cette réunion est informelle, les présentations PowerPoint ou autres matériaux qui demandent beaucoup de temps de préparation sont strictement interdits. Les participants doivent porter leur attention uniquement à l’application et aux nouvelles fonctionnalités dans un but de validation. En quelque sorte on peut dire que le Sprint Review est le résultat du Sprint. Cette réunion est très importante car elle apporte le feed-back rapide du Product Owner en fin d’itération.

Conclusions

Les aspects méthodologiques sont souvent négligés voir même caricaturés par les techniciens car pour eux la réussite du projet passe avant tout par les outils et le savoir faire technique pur. Malheureusement malgré l’amélioration continue des outils de développement, et malgré le haut niveau d’études des intervenants, les projets informatiques connaissent encore un taux d’échec important.

Ce triste constat pousse à penser que la communication entre les individus et leurs capacités d’adaptation est quelque chose de primordial. Mettre en place une méthodologie de projet agile avec Scrum semble aller dans ce sens.

De part ses valeurs, Scrum prône l’adaptabilité, sous l’effet de l’expérience acquise et des spécificités du projet ce qui le rapproche de la méthode de production de Toyota.

Scrum, comme toute autre méthode de conduite projet, n’est pas le « saint Graal » qui garantit à coup sûr la réussite du projet, mais il a le mérite d’admettre ce fait, et il met à notre disposition une « boite à outils » et des bonnes pratiques. Appliquer Scrum tout en ayant à l’esprit les spécificités du projet et avoir une prise de recul permanente nous donne des bonnes chances de réussir le projet.

Comme nous l’avons vu précédemment, Scrum est orienté vers le management du projet et aide à dimensionner et piloter une équipe de développement. Cependant Scrum ne nous donne pas d’outils d’industrialisation du processus de développement. Les questions que l’on se pose souvent en tant que développeur sont :

• Comment dois-je faire les tests de manière efficace et le plus rapidement possible ?
• Comment puis-je modifier rapidement mon code pour mieux le structurer ou introduire une nouvelle fonctionnalité ?
• Comment puis-je m’assurer que je n’ai pas introduit une régression une fois que j’ai modifié le code ?
• Serais-je capable de modifier le code produit par mon collègue ?

Toutes ces questions importantes trouvent leur réponse dans les pratiques mises en avant par eXtreme Programming(XP) tels que Test Driven Development, le Refactoring, et l’Intégration Continue. Visual Studio Team System 2008 est un des meilleurs outils du marché permettant à la fois de mettre en place une méthodologie agile et la mise en œuvre des pratiques XP.

Nous montrerons dans des articles futurs comment paramétrer et utiliser Visual Studio Team System 2008 dans la mise en œuvre des pratiques décrites dans cet article.

 

Bibliographie

Agile Alliance. Manifesto for Agile Software Development. [Online] http://agilemanifesto.org/.

Boehm, Barry. 1988. A spiral model of software development and enhancement. s.l. : Institute of Electrical and Electronics Engineers, Inc, 1988. ISSN: 0018-9162.

Jeffreis, Ron. XProgramming.com - an Agile Software Development Resource. [Online] http://www.xprogramming.com.

Kniberg, Henrik. 2007. Scrum and XP from the Trenches. s.l. : C4Media, 2007. ISBN 978-1-4303-2264-1.

Liker, Jeffrey. 2006. Le Modèle Toyota : 14 principes qui feront la réusite de votre entreprise. Paris : Pearson Education France, 2006. ISBN 2-7440-6224-3.

Montain Goat Software . Developing Software with an Agille Process. Montain Goat Software. [Online] http://www.mountaingoatsoftware.com/scrum.

O'REILLY. 2005. Extreme Programming précis&concis. Paris : Editions O'REILLY, 2005. ISBN 2-84177-358-2.

Schwaber, Ken . SCRUM Development Process.

Sutherland, Jeff . www.jeffsutherland.com. [En ligne]

Commentaires