I. Introduction

Ce document est un rapide mémento des termes utilisés dans la méthodologie Scrum. Il n'a pas vocation à être exhaustif et encore moins d'expliquer en détails ce qu'est Scrum.

Vous pouvez télécharger une version PDF de ce mémento, à imprimer recto-verso, puis à plier pour avoir une brochure en trois volets : memento-scrum-equipe.pdf ou ici ou même ici si le premier lien ne fonctionne plus.

Image non disponible
Mémento en 3 volets, à télécharger
Image non disponible
Recto du mémento
Image non disponible
Verso du mémento

I-A. Scrum en quelques mots

Scrum est la méthodologie agile la plus en vogue actuellement. Elle offre un processus itératif à la gestion de projet et permet de livrer une application fonctionnelle vite et fréquemment. Cela est possible via quelques principes proposés par Scrum :

  • auto-organisation ;
  • transparence ;
  • amélioration continue.

Ces principes s'expriment via le cadre qu'offre Scrum (rôles, rituels, artefacts) que nous allons détailler.

Pour en savoir un peu plus à propos de Scrum, je vous invite à consulter l'article de Michel Dirix sur Developpez.com.

I-B. À propos

Ce document est une retranscription du mémento proposé en téléchargement (cf. plus haut) par Hing Chan. Le mémento a initialement été publié sur le blog "Scrum et Agile avec des bonhommes"

Mais pourquoi avoir fait un mémento ? Tout simplement car nous travaillons avec des équipes, et plus généralement des personnes, qui ne sont pas (encore) formées à Scrum. Dans une équipe de dix personnes (PO, SM, ect. inclus), il n'est pas si rare que trois ou quatre membres ne maîtrisent pas complètement la méthode et en mélange les termes.

Nous avons donc cherché des mémentos gratuits ou payants sur Internet (Google, Amazon, etc.) sans trouver notre bonheur. Du coup, nous avons réalisé nous même un mémento Scrum à destination de l'équipe.

Et maintenant qu'il existe et qu'il reçoit de bons retours, nous avons décidé de le partager gracieusement avec la communauté. Ce mémento vous est offert sous licence "Creative Commons". Vous êtes libre de partager (reproduire, distribuer et communiquer) cette œuvre. Nous ne vendons rien. Nous n'avons pas de formation à vous proposer. Ce n'est pas de la publicité. C'est un cadeau pour lequel nous ne demandons aucune contrepartie. Toutefois, si vous appréciez ce mémento, et si vous l'utilisez/distribuez, ça nous fera plaisir de le savoir.

La licence "Creative Commons" vous demande de respecter trois points : attribution, pas d'utilisation commerciale et pas d'œuvre dérivée. Si vous souhaitez modifier ce mémento, par exemple pour l'utiliser dans une de vos plaquettes ou pour ajouter votre logo, il vous suffit de nous contacter et nous aurons le plaisir de vous accompagner et de vous offrir (gratuitement) une version utilisable et plus pratique.

Nous sommes également à la recherche d'un partenaire qui pourrait prendre en charge l'impression d'une v2 de ce mémento sous forme de brochure, avec éventuellement plus de pages (volets) et plus de détails.

I-C. Mises-à-jour

16 janvier 2013 : Version v1.1 du mémento, avec des images plus jolies ; le burndown ne bave plus à l'impression.

28 octobre 2012 : Création.

N'hésitez pas à nous faire part de vos remarques afin d'améliorer ce mémento.

II. Mémento Scrum

Image non disponible
Le cycle Scrum

II-A. Rôles

Scrum définit trois rôles au sein d'un projet. Il est important de noter que pour UN projet, nous avons UN product owner, UN scrum master et UNE équipe.

II-A-1. Product Owner (P.O)

Personne représentant le client et l'utilisateur auprès du Scrum Master et de l'équipe de développement. Il définit le produit et priorise les fonctionnalités voulues.

II-A-2. Scrum Master

C'est le facilitateur, le garant du processus agile. Il n'est PAS un chef de projet mais un leveur d'obstacles qui empêcheraient l'équipe de développement d'avancer. Il protège et guide l'équipe des interférences extérieures pendant le sprint.

II-A-3. Team Members (équipe de développement)

Autogérée et multidisciplinaire (développeurs, testeurs, architectes, etc.), les membres travaillent idéalement dans une seule et même pièce. Elle livre un produit utilisable à la fin de chaque sprint.

II-B. Concepts

II-B-1. Story points (points d'histoire)

Outil d'estimation de l'effort nécessaire pour développer des fonctionnalités. Les points d'histoire permettent de se soustraire du concept de jour/homme. Les points sont attribués à une user story relativement à d'autres user stories. Par exemple, une user story estimée à deux points demandera deux fois plus d'effort pour la terminer qu'une user story estimée à un point, ceci sans indication de la durée en jour.

II-B-2. Velocity

L'effort, exprimé en nombre de points d'histoire, que l'équipe de développement peut fournir dans un sprint. La valorisation en points des user stories permet de déterminer le panier de fonctionnalités absorbable par l'équipe de développement en un sprint.

II-B-3. User Story (U.S)

Description d'une fonctionnalité du point de vue utilisateur. Elle prend le formalisme "En tant que... Je veux... afin de...". Une user story peut être divisée en tâches si elle est complexe. Ci-dessous un exemple de représentation d'une user story sur une carte.

Image non disponible

II-B-4. Definition of Done (Fini)

La "définition de fini" est la liste de critères qu'une user story doit remplir pour être considérée comme ayant l'état "fini", donc livrable. Cette liste de critères peut inclure, par exemple, une couverture de test minimum, une revue de code d'un autre membre de l'équipe, une javadoc suffisante, etc. Il est important d'avoir une "DoD" déterminée de façon claire et conjointe entre l'équipe de développement et le Product Owner. Ce dernier exprime son acceptation d'une user story via des tests d'acceptation.

II-C. Rituels

II-C-1. Sprint

Période de 2 à 4 semaines dédiée au développement des user stories du backlog, et permettant d'avoir un produit potentiellement livrable à la fin de celle-ci.

II-C-2. Daily standup

Réunion faite debout pour ne pas durer trop longtemps et à heure fixe (généralement le matin), lors de laquelle chaque participant répond aux trois questions :

  • qu'ai-je fait hier ?
  • que vais-je faire aujourd'hui ?
  • ai-je un point de blocage ?
Image non disponible

II-C-3. Sprint review (démonstration de fin de sprint)

Réunion tenue en fin de sprint durant laquelle l'équipe de développement montre le travail accompli pendant le sprint (i.e. les fonctionnalités, les user stories demandées par le Product owner).

II-C-4. Planning poker

Séance d'estimation menée par l'équipe de développement qui évaluent ensemble l'effort nécessaire pour traiter les user stories du backlog. Pour cela, ils utilisent chacun un jeu de carte sur lesquelles sont inscrit des nombres de points d'histoires dont les valeurs suivent généralement la suite de Fibonacci : 0, 1, 2, 3, 5, 8, 13...

Les estimations sont faites face cachée et dévoilées en même temps pour éviter d'influencer les autres membres de l'équipe.

II-C-5. Rétrospective

Réunion permettant à l'équipe de faire un bilan du sprint qui vient de se terminer. On y note ce qui fait avancer le projet et ce qui le ralentit. Dans ce dernier cas, l'équipe cherche des actions pour lever les obstacles. Elle est généralement menée par le Scrum Master et s'organise en 5 étapes :

  • "set the stage" : prendre la température des participants via un vote (de confiance et/ou d'itération) ;
  • "gather data" : liste le ressenti de l'équipe, les problèmes, les points positifs, les émotions qui l'ont marquée pendant le sprint qui vient de se terminer ;
  • "generate insights" : permet une réflexion de groupe sur la perception et les causes des obstacles évoqués précédemment ;
  • "decide what to do" : est l'étape qui permet de générer des actions à appliquer lors du sprint suivant pour tenter de lever les obstacles évoqués ;
  • "close the retrospective" : marque la fin de cette réunion. On y fait en général un vote nommé ROTI (Return On Time Invested) pour indiquer le degré de satisfaction sur le temps consacré à la rétrospective.

II-D. Artefacts

II-D-1. Product backlog

Ensemble des caractéristiques (fonctionnalités ou besoins techniques) qui constituent le produit souhaité. Il doit être priorisé pour permettre de développer les éléments de plus haute importance en premier.

II-D-2. Sprint backlog

Sous-ensemble des éléments du backlog de produit. Les éléments constituent les user stories à développer au cours du sprint et sont préalablement détaillés pour pouvoir être estimés par l'équipe de développement. Il est également priorisé.

II-D-3. Task board (tableau des tâches)

Tableau physique ou logiciel reprenant les éléments du backlog de sprint. Il possède plusieurs colonnes (ex. à faire, en cours, à valider, validée) permettant de suivre l'avancement des user stories affichées via des post-it ou des cartes.

Image non disponible
Image non disponible

II-D-4. Burn down chart

Graphique permettant de suivre le "reste à faire" (RAF) durant le sprint. Il possède en abscisse le temps et en ordonnée les points d'histoire. La courbe indique le nombre de points d'histoire abattus pendant le sprint. Elles sont mises à jour en continu. Cela permet d'anticiper les dérives et les ruptures de charge. L'idéal étant bien sûr d'arriver à zéro point le dernier jour du sprint.

Image non disponible

III. Conclusion

Il y a finalement assez peu de termes Scrum à connaître. Mais connaître les mots ne suffit pas pour connaître (et surtout maîtriser) la méthode. Toutefois ça aide et c'est donc bien utile d'avoir un mémento sous la main. 20 commentaires Donner une note à l'article (5)

Vos retours nous aident à améliorer nos publications. N'hésitez donc pas à commenter cet article sur le forum :

IV. Remerciements

J'adresse un grand merci à Hing Chan, auteur du blog "Scrum et Agile avec des bonhommes" qui a gracieusement accepté de publier ce mémento sur Developpez.com.

Je tiens à remercier, en tant qu'auteur de tutoriel, toutes les personnes qui m'ont aidé et soutenu. Je pense tout d'abord à mes collègues qui subissent mes questions au quotidien mais aussi à mes contacts et amis du Web, dans le domaine de l'informatique ou non, qui m'ont fait part de leurs remarques et critiques. Bien entendu, je n'oublie pas l'équipe de Developpez.com qui m'a guidé dans la rédaction de cet article et m'a aidé à le corriger et le faire évoluer, principalement sur le forum.

Plus particulièrement j'adresse mes remerciements à Michel Dirix (michel.di), Sébastien Germez (FirePrawn), Mickael BARON (keulkeul), Maxime Gault (_Max_), et Idriss Neumann (ok.Idriss).

Image non disponible

V. Annexes

V-A. Liens

V-B. Liens personnels

Blog "Scrum et Agile avec des bonhommes" : http://hingchanscrum.blogspot.fr/

Article "Les Tests en Trois Temps (3T) en pratique" (mini roman utilisant Scrum dans les tests) : http://thierry-leriche-dessirier.developpez.com/tutoriels/java/3t-en-pratique/

Retrouvez mes autres articles sur Developpez.com à l'adresse http://thierry-leriche-dessirier.developpez.com/#page_articlesTutoriels

V-C. FAQ

V-C-1. Licence Creative Commons

Ce mémento vous est offert sous licence "Creative Commons" qui vous demande de respecter trois points essentiels :

  • attribution : vous devez attribuer l'œuvre de la manière indiquée par l'auteur de l'œuvre ou le titulaire des droits (mais pas d'une manière qui suggérerait qu'ils vous approuvent, vous ou votre utilisation de l'œuvre) ;
  • pas d'Utilisation Commerciale : vous n'avez pas le droit d'utiliser cette œuvre à des fins commerciales ;
  • pas d'œuvres dérivées : vous n'avez pas le droit de modifier, de transformer ou d'adapter cette œuvre.

Retrouvez les termes précis de la licence "Creative Commons" sur l'Internet : http://creativecommons.org/licenses/by-nc-nd/2.0/fr/