Scrum

ité du logiciel.

Sommaire [masquer]

1 Historique

2 Caractéristiques

3 Quelques rappels sur les méthodes agiles

3.1 Origine

3.2 Grands principes

3.2.1 Individus et interactions contre processus et outils

3.2.2 Logiciel qui fonctionne contre documentation exhaustive

3.2.3 Collaboration du client contre négociation de contrat

3.2.4 Réponse au changement contre suivi d'un plan prédéfini

3.3 Idées clé

4 Rôles

4.1 Directeur de produit

4.2 Équipe

4.3 Facilitateur / Animateur

4.4 Intervenants

5 Planification

5.1 Sprints

5.2 Releases

5.3 Quotidien

6 Gestion des besoins

6.1 Backlog de produit

6.2 Backlog de sprint

7 Estimations

7.1 Items de backlog de produit

7.2 Calcul de vélocité

7.3 Items de backlog de sprint

8 Déroulement d'un sprint

8.1 Réunion de planification

8.2 Au quotidien

9 Revue de sprint

9.1 Rétrospective du sprint

10 Compléments

10.1 Lancement du projet

10.2 Vue globale

10.3 Burndown Charts

10.3.1 Sprint Burndown Chart

10.3.2 Release Burndown Chart

10.3.3 Interprétation

10.4 Qualité de l'environnement de travail

10.5 Risques de la méthodologie

10.5.1 Un Scrum Master directif

10.5.2 La communication constructive laisse la place aux reproches

10.6 Documentation de projet

10.7 Outils pour Scrum

10.7.1 Papier et crayon / tableur

10.7.2 Outils libres

10.7.3 Outils propriétaires

10.7.4 Autres outils

11 Conclusion

11.1 Scrum

11.2 Mise en garde

12 Glossaire

13 Voir aussi

13.1 Articles connexes

13.2 Liens externes

14 Notes et références

Historique[modifier]

En 1986, Hirotaka Takeuchi et Ikujiro Nonaka décrivent une nouvelle approche holistique qui augmenterait la vitesse et la flexibilité dans le développement de nouveaux produits3. Dans celle-ci les phases se chevauchent fortement et l'ensemble du processus est réalisé par une équipe aux compétences croisées à travers différentes phases. Ils ont comparé cette nouvelle approche au rugby à XV, où l'équipe essaye d'avancer unie, en faisant circuler la balle (« tries to go to the distance as a unit, passing the ball back and forth »). A part la métaphore de mélée (Scrum)de rugby, cette référence est étonnante car la méthode Scrum interdit formellement les lotissements, les phases et leurs chevauchements.

En 1991, DeGrace et Stahl, dans "Wicked problems, righteous solutions"4, font référence à cette approche sous l'appellation « Scrum » (mêlée, en anglais), un terme de rugby mentionné dans l'article de Takeuchi et Nonaka. Dans le début des années 1990, Ken Schwaber a utilisé une approche qui a conduit à Scrum au sein de son entreprise, Advanced Development Methods. En même temps, Jeff Sutherland, John Scumniotales et Jeff McKenna développent une approche similaire à Easel Corporation et sont les premiers à appeler cela Scrum5.

En 1995, Sutherland et Schwaber ont présenté conjointement un document décrivant Scrum à l'OOPSLA, à Austin, ÉUA. Schwaber et Sutherland ont collaboré au cours des années suivantes pour fusionner les publications, leurs expériences et les meilleures pratiques du secteur en ce qui est maintenant connu comme Scrum. En 2001, Schwaber fait équipe avec Mike Beedle pour décrire la méthode dans le livre « Agile Software Development With Scrum ». En France, le premier livre français entièrement consacré à Scrum est publié en février 2010 : « SCRUM : Le guide pratique de la méthode agile la plus populaire »6.

Caractéristiques[modifier]

Le terme Scrum est emprunté au rugby à XV et signifie mêlée. Ce processus s'articule en effet autour d'une équipe soudée, qui cherche à atteindre un but, comme c'est le cas en rugby pour avancer avec le ballon pendant une mêlée.

Le principe de base de Scrum est de focaliser l'équipe sur une partie limitée et maîtrisable des fonctionnalités à réaliser. Ces incréments se réalisent successivement lors de périodes de durée fixe de une à quatre semaines, appelées sprints. Chaque sprint possède, préalablement à son exécution, un but à atteindre, défini par le directeur de produit, à partir duquel sont choisies les fonctionnalités à implémenter dans cet incrément. Un sprint aboutit toujours à la livraison d'un produit partiel fonctionnel. Pendant ce temps, le ScrumMaster a la charge de minimiser les perturbations extérieures et de résoudre les problèmes non techniques de l'équipe.

Un principe fort en Scrum est la participation active du client pour définir les priorités dans les fonctionnalités du logiciel et pour choisir celles qui seront réalisées dans chaque sprint. Il peut à tout moment compléter ou modifier la liste des fonctionnalités à produire, mais jamais celles qui sont en cours de réalisation pendant un sprint. Cette interdiction va formellement à l'encontre du principe d'itération (revenir sur les caractéristiques de la fonctionnalité en cours de développement que le concept de "présence de l'utilisateur sur le site" permettrait de favoriser) et d'adaptabilité immédiate, telle la notion de conception émergente basée sur le feedback issu du travail en cours qui représente une des bases de l'Extrême Programming). En résumé, la notion d'incrément est une valeur facilitant le contrôle de pilotage du projet et la notion d'itération (Méthode itérative) est une valeur conduisant à l'adaptabilité ainsi qu'à la qualité fonctionnelle ou technique. Ces points représentent les principes fondamentaux d'une Méthode agile appliquée à la complexité de l'Ingénierie du logiciel.

Quelques rappels sur les méthodes agiles[modifier]

Article détaillé : Méthode agile.

Origine[modifier]

En 2001, 17 représentants des méthodes légères alternatives aux processus lourds traditionnels se sont réunis pour trouver les points communs à leurs méthodes "to find common ground". De cette réunion de quelques jours est né le Manifeste Agile7 : un texte bref énonçant des grands concepts, simples, mais qui proposent une nouvelle façon de penser un projet de développement informatique. Si certains dénoncent une certaine évidence de ces concepts, il n'en est pas moins que ce manifeste a pour lui le mérite de les formaliser et surtout de les structurer en un tout homogène et cohérent, par opposition aux pratiques semblables mais complètement hétérogènes d'une entreprise à l'autre et d'un projet à l'autre.

Grands principes[modifier]

Le manifeste agile résume sa philosophie en quatre oppositions entre les concepts traditionnels et les concepts proposés.

Individus et interactions contre processus et outils[modifier]

Ce sont les individus qui font la valeur du travail accompli, ce sont donc eux que l’on doit privilégier. Sans l’artisan, les meilleurs outils ne servent à rien. Les processus qui définissent ce que doit faire chaque personne brident le potentiel caché derrière chacun : faire interagir les gens au maximum est bien plus fructueux et permet d'améliorer grandement l'efficacité et la qualité du travail fourni, en rassemblant des visions différentes d'un même problème.

Logiciel qui fonctionne contre documentation exhaustive[modifier]

Les processus lourds génèrent une documentation qui se veut exhaustive avec tous ses inconvénients : ambigüité du langage, coût de la rédaction, coût du maintien en accord avec