Scrum
Mémoires Gratuits : Scrum. Rechercher de 53 000+ Dissertation Gratuites et Mémoiresité 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
...