I. Késako▲
Scrum est un processus Agile qui permet de produire une grande valeur métier dans la durée la plus courte. Il tire son nom du Rugby. En effet, Scrum signifie « mêlée » en anglais.
Pourquoi ce nom ? Car le principe de Scrum est de procéder à des « mêlées » quotidiennes appelées Daily Scrum, renforçant l'esprit d'équipe, cherchant à atteindre un but.
Scrum est le fruit d'une réflexion entre Ken Schwaber et Jeff Sutherland en 1995 dévoilée lors de l'ACM conférence (Object-Oriented Programming, Systems, Languages and Applications), mais ce n'est qu'en 1996 que naquit officiellement Scrum avec la publication du premier articlearticle définissant cette méthode.
Pour les fondateurs, Scrum « is not a process or a methodology, but a path ». Ce qui signifie que Scrum n'est pas un processus ou une méthode, mais une voie à suivre.
Parmi les entreprises utilisatrices de cette méthode, de grands noms apparaissent comme Microsoft, Yahoo, Google, Electronic Arts, Nokia…
Voilà pour ce qui est de la partie historique de Scrum. Voyons maintenant comment cette méthode fonctionne.
II. Fonctionnement▲
Les fonctionnalités à implementer sont contenues dans le backlog du produit. Au début de chaque sprint, des fonctionnalités sont ajoutées dans le backlog du sprint, fonctions qui devront être réalisées dans une durée fixe allant de 2 à 4 semaines. Tous les jours auront lieu des mêlées quotidiennes afin de voir l'état d'avancement de chacun.
À la fin de chaque sprint, une version du produit, utilisable peut-être fournie au client. Toutes ces notions sont expliquées plus en détail par la suite.
II-A. Sprints/Releases▲
Les sprints sont des itérations de durées fixes de une à quatre semaines. Chaque sprint représentant des fonctions à réaliser.
L'esprit de Scrum est la participation forte du client (le responsable du produit) afin qu'il définisse la priorité de chaque fonctionnalité et choisisse celles qui seront réalisées durant un sprint. De plus, il peut compléter ou modifier la liste des fonctionnalités à venir, mais pas celles en cours.
Ceci signifie qu'à la fin de chaque sprint, une version de l'application peut-être montrée au client. Il voit ainsi l'évolution de l'application et ne la découvre pas à quelques jours de la deadline. Le produit fourni à la fin de chaque Sprint est codé et testé !
Les releases sont en fait un regroupement d'itérations afin de mieux identifier les versions du produit. Une release permet d'aboutir à une version livrable et dont la mise en exploitation est possible.
II-B. Backlog du produit▲
Le backlog produit est un catalogue de toutes les fonctionnalités. Chaque item de ce catalogue possède deux attributs. Le premier étant une estimation en Points Relatifs, ce qui signifie que l'estimation n'est pas faite en nombre de jours, mais en termes de complexité. La complexité a généralement comme valeur un nombre de la suite de Fibonacci ( 1 2 3 5 8 13 21 34 55 89 144 233 377 610…). C'est l'équipe qui détermine la complexité de l'item. Pour cela, l'équipe se réunit lors de ce que l'on appelle le Planning Poker, et chaque personne écrit la complexité qu'il juge sur un bout de papier que tout le monde abat en même temps. Suite à cela, l'équipe débat sur ces valeurs et chaque personne argumente. L'estimation se reproduit jusqu'à ce que la plupart soit d'accord. Les items sont bien quant à eux estimés en points.
Une fois tous les éléments du backlog de produit estimés, on attribue à chaque sprint une partie de ces éléments. Ainsi, une fois un sprint terminé, on sait combien de points ont été réalisés et on peut calculer ainsi la vélocité de l'équipe, c'est-à-dire le nombre de points réalisés en un sprint. À partir de cette vélocité et du total de points à réaliser, on peut définir le nombre de sprints qui seront nécessaires pour terminer le projet (ou la release en cours). Au fur et à mesure de l'avancement du projet, on a une vision de plus en plus fiable de la date d'aboutissement du projet, tout en permettant l'ajout de nouveaux items dans le backlog du produit en cours de route.
Le second attribut est la valeur client qui est définie par le directeur du produit (rôle détaillé par la suite) et qui correspond à la priorité de l'item. Cette valeur peut-être changée à n'importe quel moment.
II-C. Backlog du sprint▲
Lors du démarrage d'un sprint, des items du backlog du produit sont choisis afin de constituer ce sprint. Chaque item est alors divisé en petites tâches constituant ainsi le backlog du sprint. Chaque tâche étant estimée en nombre d'heures et ne pouvant pas dépasser deux jours. Celles-ci sont prises au fur et à mesure par les membres de l'équipe, elles ne sont pas attribuées dès le départ du sprint. Le backlog est ainsi mis régulièrement à jour avec les éléments restant à faire.
III. Rôles▲
III-A. ScrumMaster▲
III-A-1. Description▲
Le ScrumMaster est l'animateur de l'équipe faisant appliquer Scrum. Il s'agit aussi d'un facilitateur, il est chargé de protéger l'équipe des éléments perturbateurs et de résoudre les problèmes non techniques tels que la partie administrative par exemple. Tout ceci afin de ne pas ralentir l'équipe qui ne s'occupe ainsi que du développement.
Étant l'animateur, il doit mettre en place et animer les réunions telles que les mêlées quotidiennes où l'équipe fait part de ses difficultés et de son avancement sur le sprint en cours.
Le ScrumMaster n'est en aucun cas un chef de projet. Dans Scrum, ce poste n'existe plus, chaque membre est impliqué au même niveau et chaque développeur peut faire part de sa créativité.
Le ScrumMaster a un lien étroit avec le responsable du produit afin de réaliser les éléments du Backlog et le modifier en conséquence si nécessaire. Le projet est ainsi toujours conforme aux demandes du client, une modification coûtant moins cher si elle est traitée tout de suite.
III-A-2. Qualités nécessaires▲
- Bonne communication.
- Savoir résoudre des conflits et des problèmes afin de ne pas gêner l'équipe par rapport aux éléments extérieurs.
- Savoir mener sans imposer ses idées puisque chaque décision relève de l'équipe complète.
III-B. Directeur de produit ou Product Owner▲
III-B-1. Description▲
Le directeur de produit ou Product Owner représente les clients ou le représentant du client et les utilisateurs finaux. Il définit l'importance de chaque fonctionnalité afin de définir le contenu des sprints à venir.
Il donne son avis sur divers aspects du logiciel comme l'allure de l'interface graphique, son utilisation…
La configuration idéale est que le responsable du produit travaille dans la même pièce que l'équipe pour une meilleure réactivité sur le projet.
III-B-2. Qualités nécessaires▲
- Bonne communication.
- Savoir exprimer ses besoins sans ambiguïté.
III-C. Équipe▲
III-C-1. Description▲
L'équipe n'a de rôles précis, elle est autogérée. Toutes les décisions sont prises au nom de l'équipe. Il n'y a pas de chef de projet qui « impose » la façon de procéder.
L'équipe est en relation directe avec le directeur de produit. Elle montre le plus souvent l'application afin d'ajuste l'ergonomie le directeur peut ainsi modifier rapidement le backlog du produit selon ses nouveaux besoins.
III-C-2. Qualités nécessaires▲
- Savoir communiquer avec le reste de l'équipe et le directeur de produit.
- Ne pas s'imposer au sein de l'équipe. Tout le monde est au même niveau.
IV. Manifeste Agile▲
Scrum s'inscrit dans l'idée du Manifeste Agile dont les principes sont les suivants :
- Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles ;
- Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client ;
- Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte ;
- Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet ;
- Bâtissez le projet autour de personnes motivées. Donnez-leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail ;
- La méthode la plus efficace pour transmettre l'information est une conversation en face à face ;
- Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet ;
- Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment ;
- Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité ;
- La simplicité – l'art de maximiser la quantité de travail à ne pas faire – est essentielle ;
- Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'autoorganisent ;
- À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.
Détaillons ainsi chaque point :
« Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles. »
« Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte. »
« Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet. »
« À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens » .
Grâce à ces itérations courtes, le client peut-être livré toutes les une à quatre semaines avec à chaque fois une nouvelle fonctionnalité
« Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client. »
La forte participation du client permet de réagir rapidement aux demandes du client et de les prendre en compte dès le sprint suivant.
« Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet. »
« La méthode la plus efficace pour transmettre l'information est une conversation en face à face. »
Les mêlées quotidiennes permettent à toute l'équipe de faire part des difficultés et de l'avancement afin d'être le plus réactif possible et ainsi chaque développeur ne code pas dans son coin sans savoir ce que font les autres.
« Bâtissez le projet autour de personnes motivées. Donnez-leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail. »
Le rôle du ScrumMaster !
« Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment. »
« La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle. »
Le ScrumMaster protégeant l'équipe de tout élément perturbateur, l'équipe peut se concentrer sur le développement et rien que le développement et ceci permet de perdre moins de temps sur des problèmes extérieurs et le travail à effectuer se retrouve ainsi diminué.
« Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité. »
« Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'autoorganisent. »
L'équipe s'autogère et chaque développeur laisse libre cours à sa créativité et chacun choisit les fonctions qu'il veut implémenter. Ces deux conditions sont donc bien réunies.
Scrum s'inscrit donc bien dans le cadre des méthodes agiles en respectant tous ses principes.
V. Mise en place▲
V-A. Matériel▲
L'idéal est un open space afin de faciliter la communication au sein de l'équipe. Un tableau blanc est utilisé afin d'avoir une vue sur les items du sprint en cours, restants, effectués, chaque histoire étant écrite sur un postit!.
En plus du tableau blanc pour le sprint en cours, il faut tout de même avoir une vue sur le projet. Des outils sont donc nécessaires pour le suivi du projet, mais aussi pour que l'équipe puisse s'organiser et suivre l'évolution de tout le travail.
V-B. Burndowns▲
V-B-1. Sprint Burndown Chart▲
Ces Burndowns indiquent le nombre d'heures restantes à faire avant la fin du Sprint. Ils permettent d'avoir une vue globale sur l'avancement du Sprint.
V-B-2. Release Burndown Chart▲
Les Burndowns montrent ce qu'il reste à faire en terme d'estimation en nombre d'histoire à réaliser sur la release.
Ce burndown montre qu'il y a 200 histoires (fonctionnalités) à réaliser. Au fur et à mesure du temps, on voit le nombre baisser, mais il peut augmenter si de nouvelles fonctionnalités ont été ajoutées.
V-C. Outils libres▲
V-D. Outils propriétaires▲
- ScrumDesk (gratuit pour cinq utilisateurs maximum).ScrumDesk
- Intra'Know PROJET (cette solution collaborative intègre les grands principes de la méthode AGILE).Intra's Know PROJET
- ScrumWorks (gratuit sous conditions).ScrumWorks
- VersionOne (gratuit sous conditions).VersionOne
- RallyDev.RallyDev
- GreenHopper.GreenHopper
- Microsoft eScrum Version 1.0 pour Visual Studio Team Foundation Server.Microsoft eScrum Version 1.0 pour Visual Studio Team Foundation Server
- Scrumy (Démonstration en ligne gratuite)Scrumy
- Serena Agile On Demand Entièrement en mode SAAS. Aucune installation nécessaire. Essai gratuit 60 jours.Serena Agile On Demand
- Plugin for TFS web Access (Essai gratuit 30 jours).TFS web access
Nous voyons donc qu'il ne faut pas grand-chose pour pouvoir utiliser Scrum.
VI. Journée type▲
9h : Arrivée au bureau de toute l'équipe.
9h05 : Premier café de la journée !
9h15 : Daily Scrum : mêlée quotidienne où trois questions sont posées à chaque membre :
- Qu'est-ce que j'ai fait hier ?
- Qu'est-ce que je compte faire aujourd'hui ?
- Quelles difficultés est-ce que je rencontre ?
Reste de la journée : alternance entre écriture des tests et code permettant de faire passer ceux-ci. Puisque l'équipe a décidé de jumeler Scrum et XP, le développement se fait en TDD (Test Driven Development) afin de fournir à chaque livraison du code testé et fonctionnel.
La mêlée quotidienne ne doit durer que 15 minutes et doit avoir lieu debout (pour être sûr de ne pas dépasser les 15 minutes), pour faire un tour rapide de l'équipe et la synchroniser. Ceci ne signifie pas qu'il ne peut pas y voir de discussions en dehors pour éclaircir certains points avec le ScrumMaster ou le responsable du produit. Mais cette réunion n'est en aucun cas un compte-rendu fait au ScrumMaster, elle doit juste servir de synchronisation.
VII. Technique complémentaire : Podomoro▲
Le Podomoro est une technique inventée par Francesco Cirillo. Ce principe repose sur des itérations courtes fixes suivies d'une petite pause, ce qui permet de mieux concentrer sur une tâche. Pendant ce temps, la personne se consacre uniquement au développement en coupant sa boite mail. Elle ne doit pas être dérangée.
Les tâches du backlog de sprint sont donc maintenant exprimées en Podomori avec cette technique et très rapidement on peut estimer le nombre de Podomori nécessaires pour réaliser une tâche à partir de sa complexité. Cette technique force donc à se changer les idées régulièrement afin de garder assez de recul sur le projet, permettant ainsi d'avoir l'esprit frais et de mieux voir les erreurs réalisées.
VIII. Mise en garde▲
Anecdote
C'est un poulet qui discute avec son ami le cochon.
Poulet : Mon ami le cochon, j'ai une idée, si on ouvrait un restaurant ?
Cochon : Et qu'est qu'on y mangerait dans ce restaurant ?
Poulet : Des omelettes aux jambons ! Évidemment.
Cochon : Ça me semble injuste, tu n'y risques que tes œufs alors que moi j'y risque mes jambonneaux !
La morale de cette histoire est que vis-à-vis d'un projet nous n'avons pas tous le même niveau d'investissement.
À cause de cette histoire, on appelle souvent pig les gens qui participent réellement au projet et qui s'y investissent et chicken les personnes qui interagissent avec le projet, mais qui ne sont pas réellement investies dans sa réalisation. Pour que le projet soit réussi, il faut que tout le monde participe avec le même degré d'implication. Le ScrumMaster doit donc veiller à ceci.
De nombreuses entreprises disent utiliser des méthodes agiles, mais beaucoup ne l'utilisent que parce qu'elles estiment que ces méthodes sont à la mode et bien vues. Or, pour réussir, il faut toute une organisation particulière autour à commencer par réorganiser les locaux, car rares sont les entreprises fonctionnant en open space.
L'idéal pour tout projet serait de ne pas donner dès le départ un budget et une deadline précise, mais plutôt un ordre de grandeur. Voir la contractualisation Agile icicontractualisation agile
IX. Conclusion▲
Scrum est une méthode Agile idéale sur de petites équipes. Cette méthode ne peut s'appliquer qu'en partie, elle demande un investissement total de la part de toute l'équipe et même de toute l'entreprise, personne ne doit être chicken !
La mise en place de Scrum se révèle assez simple et ne demande pas beaucoup de ressources, un tableau, un logiciel de suivi et c'est parti.
Scrum couplé à XP devient une méthode très efficace limitant le risque d'échec sur un projet.
X. Sources▲
- Scrum sur Wikipédia.http://fr.wikipedia.org/wiki/Scrum
- Rôle du ScrumMaster.http://www.aubryconseil.com/post/2007/01/07/148-le-role-de-scrummaster
- Podomoro.http://www.aubryconseil.com/post/Un-pomodoro%2C-des-pomodori#c906
- Présentation de Thomas Recloux ( consultant IT chez Norsys ) lors de l'Agile Tour 2009 à Lille.
- Mes cours de Génie Logiciel
- Article sur Scrum.http://www.scrumdesk.com/Features/Scrum.html
- Planning Poker.Planning Poker