Cette présentation a été donnée dans le cadre du Drupalcamp Paris 2013 du 21 au 23 juin (http://paris2013.drupalcamp.fr/programme-paris).
Présentation par Julien Dubois (https://twitter.com/artusamak)
Les méthodes agiles ont de plus en plus le vent en poupe et Scrum devient de plus en plus répandu.
Drupal continue également de croitre et ses qualités intrinsèques le rendent très compatible avec les concepts de sprint, d'itérations et de livraison continue.
* Votre dernier projet en cycle en V a échoué et vous avez envie d'essayer autre chose ?
* Vous ne savez pas ce que sont les méthodes agiles et/ou Scrum ?
* Vous vous demandez comment tirer partie des capacités de prototypage de Drupal ?
Nous allons (re)voir au cours de cette session ce que sont les méthodes agiles, en quoi elles divergent de la gestion de projet dite "traditionnelle" avec un focus sur Scrum, puis vous présenterai comment Drupal et Scrum peuvent s'entendre et devenir les meilleurs amis du monde dans votre intérêt et celui de votre client.
12. Manifeste agile
12 principes
Valeur ajoutée
Accepterle changement
Livrer régulièrement
Echangesquotidiens
Face à face
Pragmatisme
Rythme pérenne
13. Manifeste agile
12 principes
Valeur ajoutée
Accepterle changement
Livrer régulièrement
Echangesquotidiens
Face à face
Pragmatisme
Rythme pérenne
Payersa dette
14. Manifeste agile
12 principes
Valeur ajoutée
Accepterle changement
Livrer régulièrement
Echangesquotidiens
Face à face
Pragmatisme
Rythme pérenne
Payersa dette
Simple VS parfait
15. Manifeste agile
12 principes
Valeur ajoutée
Accepterle changement
Livrer régulièrement
Echangesquotidiens
Face à face
Pragmatisme
Rythme pérenne
Payersa dette
Simple VS parfait
Equipe motivée
16. Manifeste agile
12 principes
Valeur ajoutée
Accepterle changement
Livrer régulièrement
Echangesquotidiens
Face à face
Pragmatisme
Rythme pérenne
Payersa dette
Simple VS parfait
Equipe motivée
Equipe autogérée
17. Manifeste agile
12 principes
Valeur ajoutée
Accepterle changement
Livrer régulièrement
Echangesquotidiens
Face à face
Pragmatisme
Rythme pérenne
Payersa dette
Simple VS parfait
Equipe motivée
Equipe autogérée
Améliorationcontinue
18. Manifeste agile
12 principes
Valeur ajoutée
Accepterle changement
Livrer régulièrement
Echangesquotidiens
Face à face
Pragmatisme
Rythme pérenne
Payersa dette
Simple VS parfait
Equipe motivée
Equipe autogérée
Améliorationcontinue
4 valeurs
19. Manifeste agile
12 principes
Valeur ajoutée
Accepterle changement
Livrer régulièrement
Echangesquotidiens
Face à face
Pragmatisme
Rythme pérenne
Payersa dette
Simple VS parfait
Equipe motivée
Equipe autogérée
Améliorationcontinue
4 valeurs
Personneset interactions >
outils et processus
20. Manifeste agile
12 principes
Valeur ajoutée
Accepterle changement
Livrer régulièrement
Echangesquotidiens
Face à face
Pragmatisme
Rythme pérenne
Payersa dette
Simple VS parfait
Equipe motivée
Equipe autogérée
Améliorationcontinue
4 valeurs
Personneset interactions >
outils et processus
Logicielfonctionnel>
documentation
21. Manifeste agile
12 principes
Valeur ajoutée
Accepterle changement
Livrer régulièrement
Echangesquotidiens
Face à face
Pragmatisme
Rythme pérenne
Payersa dette
Simple VS parfait
Equipe motivée
Equipe autogérée
Améliorationcontinue
4 valeurs
Personneset interactions >
outils et processus
Logicielfonctionnel>
documentation
Collaboration client>
négociationcontractuelle
22. Manifeste agile
12 principes
Valeur ajoutée
Accepterle changement
Livrer régulièrement
Echangesquotidiens
Face à face
Pragmatisme
Rythme pérenne
Payersa dette
Simple VS parfait
Equipe motivée
Equipe autogérée
Améliorationcontinue
4 valeurs
Personneset interactions >
outils et processus
Logicielfonctionnel>
documentation
Collaboration client>
négociationcontractuelle
Adaptationauchangement
> suivi d’un plan
23. Concepts à retenir
> Itérations
> Client au cœur du projet
> Equipeauto organisée
> Améliorationcontinue
24. Plusieurs candidats
Scrum > Auto organisation
XP > Binômage
Lean > Chasse au gaspillage
Crystal > Petits projets
26. Concepts – Vue d’avion
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Release
Itérations de 2 à 4 semaines
Une successiond’itérationsdonne lieu à une release
Une livraison à la fin de chaque sprint
28. Concepts – Découpage d’un sprint
Sprint définition
(0,5-1j)
Développement
(8j)
Démo
(0,5j)
Rétro
(0,5j)
1) Constitutiondu backlog de sprint, dimensionnementdes stories, engagement sur
nombre de points de complexité
2) Implémentationdes user stories et technicalstories,discussionsrégulièresvia le
scrum quotidien(Qu’as-tu fait hier / demain / pointsbloquants)
3) Présentationdes fonctionnalitésimplémentéesdurant le sprint & collectedes retours
4) Analyse du sprint écoulé, identificationblocages& réussites,pistesd’améliorations
1 2 3 4
29. SprintBacklog
• User story A
• Technical story A
• User story B
• User story C
• Technical story B
Productbacklog
• User story D
• User story E
• Technical story C
• Technical story D
Concepts – Les backlogs
Priorité
Les storiesreprésententles fonctionnalitésà réaliser
Toutes les stories ont une taille – « Planning poker »
Toutes les stories ont une définitionde « terminé »
Les storiesdevraient être triée par priorité de valeur ajoutée
30. Rituels : la sprint définition
Sprint définition
(0,5-1j)
* Le backlog est préparé
* Les storiessont découpéesen taches
* Les arbitrages sont faits
* Les storiessont dimensionnées
* L’équipe définisont engagement pour le sprint en s’appuyantsur sa vélocité
1
31. Rituels : le scrum quotidien
Développement
(8j)
* L’équipe implémenteles storiespar ordre de priorité
* Chaque membre choisiles stories qu’il s’affecte
* Tous les jours un point est fait avec l’équipeafin d’identifierles pointsde blocage
* Des taches doivent se fermer tous les jours
2
32. Rituels : la démonstration
Démo
(0,5j)
* Des membres extérieurs peuvent être invités
* Chaque membre de l’équipe présenteson travail
* On ne présenteque des choses terminées
* On collecteles retours et les demandes d’ajustement
3
33. Rituels : la rétrospective
Rétro
(0,5j)
* Collecte de la vélocité
* Passage en revue du sprint écoulé
* Occasionde donner la parole à chacun
* Améliorationdu travail de l’équipe
4
34. Métriques – La vélocité
Le burnup(Complexitécumulée sur durée) Le burndown(Complexitérestantà fairesur durée)
40. Quelques inconvénients tout de même
Nécessite un product owner disponible~1h par jour
Besoin d’un product owner avec un pouvoir de décision
Accompagnementpour une transition depuisle cycle en V
Besoin d’une équipe composéede personnes proactives
Tailled’équipe +/- 6
Définitionde « fini » pas toujours assez claire
CMS + testabilité=
41. …mais que d’avantages
Beaucoup plus d’interactionsavec le client
Des retours sur le produit en cours de production
Concentrationdes efforts sur les fonctionnalitésà valeur ajoutée
Equipeauto gérée = meilleureambiance
Rythme soutenablegrâce au suivi de la vélocité
Prédictibilitésur la fin du projet