Réalisé par Istace Emmanuel (Manu404) pour la communauté Hackbbs
Document sous license GFDL (Licence de documentation libre GNU) : http://www.gnu.org/licenses/licenses.fr.html
Table des matières
1. Avant Propos; p 3
2. Qu’est-ce q’une méthodologie; p 3
3. Qu’est-ce que Scrum; p 3
4. Qu’est-ce que une méthodologie Agile; p 3
5. Principes de Scrum; p 4
6. Plannification par Sprint; p 4
7. Structure d’un Process; p 5
8. Les roles dans une équipe; p 6
9. Exemple et mise en oeuvre; p 7
12. Ressources, sources et liens; p 8
11. Conclusion; p 9
1. Avant propos
J’ai écrit ce cours dans le but de donné une vue d’ensemble de cette méthodologie. Il en existe bien d’autre, avec chacune leurs avantages et inconvénients. Ce cours est écrit dans le cadre de la création futur d’une section projet dont les informations vous parviendrons bientôt. Ceci impliquera que des groupes de membres se rassemblerons autour de projet afin de mener a bien leur développement. Oui mais, développer un projet c’est toute une aventure, et le faire correctement c’est un véritable défis ! C’est pourquoi je tiens à vous donner toutes les clefs de la réussite afin de pouvoir mener correctement un projet de groupe. Je ne cherche pas a démontré que Scrum est la meilleur solution ou la seul qui marche. Si vous possédez déja une autre méthodologie qui fonctionne bien, gardez-la.
2. Qu’est-ce qu’une méthodologie ?
Un méthodologie est un modèle contenant un ensemble de méthode permettant d’atteindre des objectifs fixés au début de la réalisation du projet. Par exemple : concevoir un Forum.
Cet exemple sera utilisé durant tout le cours sur Scrum.
3. Qu’est ce que Scrum ?
Scrum est une méthodologie initialement dédié a la gestion et conception d’un projet informatique.
Cette méthodologie a été adapté avec succès a d’autres secteurs d’activités (cfr : Toyota, Aribus, Société générale, MusicStore, Microsoft, Adobe, …)
Scrum permet de maximiser les ROI des projets de développements.
Scrum est une implémentation de méthode dites “Agile”.
4. Qu’est ce qu’une méthodologie Agile ?
Vous expliquer en détail le fonctionnement théorique d’un méthodologie Agile serait long et sans grande utilisé dans le cadre de ce cours. Ces méthodes permettent de gérer la conception de projet et de l’équipe qui la prend en charge. Cette méthode se base également sur un constat : Lors de la réalisation d’un projet, les délais et les couts sont rarement respecté. Ceci dit, Agile met l’accent sur les points suivant :
– Individus et interactions
Privilégié les interactions entre les membres de l’équipe et maximiser la communication entre-eux
– Logiciel qui fonctionne
Obtenir le plus vite possible un livrable prêt a être déployer/implémenter même si il n’est pas complet (développement par module) plutôt que de développer une application pendant 10 mois et croiser les doigts à la fin.
– Collaboration du client
Maximiser les interactions entre l’équipe et le client.
– Réaction au changement
Privilégié un maximum la liberté de chacun face a des situation imprévue sans pour autant mettre le travail des autres en péril (dépendances pas exemples) et appliquer les feedback de manière optimal
Pour toutes les informations concernant les méthodologies Agile: www.agilmanifesto.com
5. Principes de Scrum :
– Équipe soudée
L’équipe doit adopter une attitude la plus pro-active possible.
– But a atteindre avec un engagement de réussite par l’équipe
Avec Scrum, il n’y a pas de “Chef de projet” a proprement dit. Le Chef c’est l’équipe, et c’est l’équipe qui s’engage a atteindre ses objectifs et qui les négocie.
– Livraisons périodiques
Scrum encourage la livraison de release de manière régulière afin de pouvoir faire les changements appropriés a la release donné, donner le plus vite possible un livrable utilisable, gérer les “risques projets”, permettre une validation progressive du livrable final.
– Implication forte du client
Les feedback provenant du clients vers l’équipe sont a encourager au maximum afin de faire progresser le plus vite possible le livrable final.
L’orientation principal de Scrum est une orientation engagement/résultat et non pas délais ou couts. Ce qui compte c’est de fournir le livrable final et uniquement cela !!!
6. Planification par Sprint
-Un Sprint permet de limiter les dépassement de délais, optimiser les feedback, rendre les feedback opérationnels le plus vite possible et éviter le maximum d’erreur
– Un sprint est itératif et ne dépasse jamais 30 jours
Un sprint est donc une période de temps définie, marqué par certaines étapes, avec un début et une fin, qui est répété jusqu’à la fin de la réalisation du livrable final.
-Possède un but
Le but peut être la réalisation d’un importante fonctionnalité ou la release d’un livrable. Le but doit être parfaitement défini au début du sprint et clair pour toute l’équipe
– Le But du Sprint est liés a un liste de petites fonctionnalités (items dans le Sprint Backlog)
Au début du sprint, un sélectionne un certains nombres de fonctionnalités devant être développer, qui se nomment items et se place dans le Sprint Backlog qui est un tableau contenant toutes les fonctionnalités devant être finies pour la fin du Sprint
– L’équipe peut casser le Sprint si il est infaisable
Si l’équipe juge que les objectifs fixés et que les engagements pris sont infaisables, alors le Sprint peut-être cassé, puis renégocié, et recommence dés le lendemain.
7. Structure d’un Process
Shema :
Le process commence par la négociation avec le client afin de sélectionner les Items du Product Backlog (liste des fonctionnalités nécessaire au programme) afin de les placer dans le Sprint Backlog (les fonctionnalités qui seront réalisé durant le sprint) et définir une priorité dans laquel ils doivent être livrés. Ensuite on découpe chaque fonctionnalité en sous-tâches afin de faciliter le développement de l’application en passant par des modules Par exemple : Gestion des utilisateur : Db/liste des utilisateurs, panneau de login, panneau d’édition des utilisateurs et un script d’authentification. Ce qui donne 4 module bien défini qui formeront la fonctionnalité : Gestion des utilisateurs. Le Sprint peux alors commencer. Durant la période définie. Il y aura chaque jours une rencontre de 15minutes appelé Scrum(“mêlée” sur le shema) dans lequel chaque membre de l’équipe fera part aux autres de :
1. Ce qui a été fait.
2. Ce qui sera fait pour le prochain Scrum .
3. Les difficultés rencontrées afin de se faire aider par les autres membres.
4. Demande au développeur de l’estimation du temps nécessaire a la tache qu’il réalise pour le moment par le ScrumMaster
50% du process et de la méthodologie repose sur cette rencontre. Elle doit être la plus courte et précise possible.
A la fin du sprint, il y a une demo qui sera publié afin de présenter le travail réalisé. Sa peux être une interface, un système de gestion ou simplement un log de DB. A la fin de cette demo et après réception des feedback du client, un débriefing privé de l’équipe est réalisé afin de faire le point sur les points positifs et négatifs du Sprint qui viens de se conclure
8. Les rôles dans une équipe Scrum
1. Le Scrum Master
C’est un membre de l’équipe qui a pour but de détecter les problèmes et les résoudre, il permet de résoudre les soucis de l’équipe afin qu’elle parvienne seul a sa productivité optimale. C’est également lui qui vas gérer le temps de parole lors de rencontres quotidiennes Il n’est pas le chef et ne peux donc pas donner d’ordre au reste de l’équipe.
2. Product Owner
Le product Owner sera le client ou le User du livrable. Il négocie avec l’équipe les différents fonctionnalités qui seront développer pour la fin du Sprint, il répond au question de l’équipe chaque fois que nécessaire et fait de feedback aux tests demandés par l’équipe. C’est avec lui qu’on sélectionne les Items du Product Backlog que l’on fera passer dans le Sprint Backlog. Une fois la négociation terminé, le Product Owner se retire jusqu’à la prochaine demande de test ou la fin du Sprint pour la présentation de la release.
3. Équipe
Les différents développeurs, codeurs, architectes, etc…
Elle est auto-géré, il n’y a pas de chef. Chaque membre sélectionne lui-même l’item qu’il souhaite développer suite a l’ordre de priorité de l’item fixé lors de la négociation en début de Sprint.
4. StakeHolder
Investisseur ou sponsor
Il n’y a pas d’autre rôles ! Toute autre personne est considéré comme extérieur au Scrum !
9. Exemple et mise en oeuvre
Bon un petit exemple pratique concernant la mise en pratique du Process sur l’exemple du forum:
Définition des rôles et de l’équipe :
L’équipe :Manu404(développeur php, Db-a), Skorm(graphiste, déploiement), Hackangel (développeur pp)
Le ScrumMaster : Gioia_motherlode (testeur)
Product Owner : Korigan
Stake Holder : ?
Les Sprint durent 1semaine
Le process :
Création du Product Backlog :
– système d’authentification/inscription ; priorité : 5/5
– gestion d’envoi des messages ; priorité : 3/5
– gestion de l’affichage des messages ; priorité : 3/5
– interface graphique ; priorité : 2/5
– …
Demande du Product Owner pour la fin du Sprint:
– interface graphique
– système d’auth/inscri
Création du Sprint Backlog avec le resultat de la négociation :
– système d’auth/inscri
Division des tâches :
– DB user
– script d’inscription
– script de connexion
– panneau d’administration des user
– style provisoire du forum
Début du Sprint
Manu404 : Db User, script inscription
HackAngel : script de connexion, panneau admin
Skorm : Création de la Charte graphique provisoire
durant un des Scrum quotidien Manu404 fait la demande d’un framework pour Oracle a une des rencontres au ScrumMaster pour gérer la DB User. Le ScrumMaster étudie la demande, et l’accepte. Il modifie le Spring Backlog et y rajoute :
– Installation du framework php <=> Oracle
A la fin de la semaine, avant la demo, Gioia_motherlode test le livrable, Skorm créé un déploiement et l’équipe réalise la demo au ProductOwner (Korigan), le Product Owner est satisfait mais désire que les utilisateurs puissent s’authentifier via leur adresse e-mail. Le débriefing à lieu, rien de particulier a dire.
Un nouveau Process peux commencer, la demande de Korigan concernant l’authentification est rajouté dans le Product Backlog avec une priorité de 5 sur 5
10. Ressources, sources et liens
Il existe des logiciels afin de gerer les développement en Scrum et de planifier les tâches (Product Backlog, Sprint Backlog, Scrum, Sprint, Livrablles, Decoupe des fonctions, dépendances,…)
Voici une liste des produits libre :
– Wilos : http://wilos.sourceforge.net/
– Ice Scrum : http://www.icescrum.org/
– EPF (pour EDI Eclipse) : http://www.eclipse.org/epf
– OpenERP (inclus un module Scrum) : http://www.openerp.com/
Ressources diverse :
– Site Officiel Scrum : http://www.controlchaos.com/
– La Scrum alliance : http://www.scrumalliance.org/resources/
– La Agile alliance : http://www.agilealliance.org/
– User Group Français sur Scrum : http://www.frenchsug.org/display/FRSUG/French+Scrum+User+Group/
Sources :
– Wikipedia (shema du point 7) : http://fr.wikipedia.org/wiki/Scrum
– Le développement Agile, Editions O’Reilly
– Mettez du Scrum dans vos projets, Edition Eyrolles
Le PDF a été généré avec l’outil PDF Créator
11. Conclusion
Nous l’avons vus, Scrum est donc une méthodologie simple a mettre en oeuvre et très éfficace. Cependant, n’oubliez jamais que le projet passe AVANT la méthodologie. Si il est absolument nécésaire de contourner la méthodologie pour résoudre un soucis lors du développement, alors cessez le Sprint ! Votre but n’est pas de suivre des procédures de développement, mais de développer en se basant sur ces procédures ! Scrum est parfait pour gerer des équipes de 3-8 personnes, au dessus de 8 personnes, il est préférables de créé plusieurs équipes. Donc pour un développement comptant 20 membres, on va créé 3 équipes, chacune avec un Scrum Master. Les rencontres se déroulent normalement en équipe, et on rajoute une rencontre de 1H/jours dans lesquels les 3 Scrum Master se feront les messagers vers les autres équipes.
Alors bonne chance dans vos projets et bons Scrums
Istace Emmanuel (Manu404)
Attention aux fautes d’orthographes.
Bonjour,
Merci beaucoup pour cet article, cela me fait penser à un article que l’un de mes collègues a écrit. Il revisite les 12 principes du manifeste agile, on voit bien la réalité entre ce qu’il faudrait faire et ce qu’il se passe en réalité.
L’article est ici si ça vous intéresse :
http://www.softfluent.fr/blog/expertise/2017/05/17/Les-12-principes-du-manifeste-agile