Les méthodes agiles
Introduction à SCRUM
Blackbird est une agence de développement web spécialisée
dans l’accompagnement et le développement de projets e-
commerce...
Sommaire
● Introduction
● Les principes fondamentaux
● Présentation des Users Stories
● 6 stratégies pour rédiger des US e...
1980 1990 2000 2010
Gantt / PERT : Cascade ( Waterfall, V Model, etc.)
Méthodes Agiles
Origines des méthodes Agiles
195019...
Des outils plus ou moins normatifs
RUP XP SCRUM KANBAN
Faites ce que
vous voulez
120+ 13 9 3 0
plusnormatif
plusadaptatif
...
Les principales différences entre
cycle en V et méthodes agiles
Personnes et interactions
Logiciel qui fonctionne
Collabor...
Le paradoxe
de la gestion de projet
Capacité d’action
Temps
Connaissance du projet
Pourquoi ?
● Faciliter l’expression des besoins
● Aider à l’acceptation du changement
Comment ?
● Organiser l’expression d...
Quels
projets
favoriser ?
● Besoin rapide de mise à disposition du produit
● Imprévisibilité des besoins du client
● Néces...
● Indisponibilité du client ou de l'utilisateur
● Dispersion géographique des ressources
humaines
● Inertie des acteurs du...
Les principes
fondamentaux
Les 4 valeurs fondamentales
L'équipe
« Les individus et leurs interactions, plus que
les processus et les outils »
L'appli...
Les 12 principes
généraux
User
Focus
1. La plus haute priorité est de satisfaire le
client (l’utilisateur final du produit) en livrant
rapidement et...
Un modèle
itératif
2. La livraison s’applique à une application
fonctionnelle, toutes les deux semaines à deux
mois, avec ...
Un modèle
Collaboratif
5. Le projet doit impliquer des personnes
motivées. Donnez-leur l'environnement et le
soutien dont ...
Focus on
quality
9. Les processus agiles promeuvent un rythme de
développement soutenable
10. Les processus agiles recomma...
Structure opérationnelle et
pratique du développement agile
… là on parle de SCRUM
Les rôles
Product Owner Scrum Master Team
Démarche itérative
Produit
Release 1 Release 2
Sprint 1 Sprint 2 Sprint 3
Story
Story
Story
Itérations Release
Chaque fin de release apporte de nouvelles fonctionnalités
pour les utilisateurs
ROADMAP
Release 1 Rele...
Itérations Sprint
Chaque fin de sprint apporte de nouvelles fonctionnalités
pour les Product Owner
RELEASE
Sprint 1 Sprint...
Itérations Stories
Chaque fin de Story est une nouvelle liste de tâches
terminées pour la team
SPRINT
Story 1 Story 2 ...
Planning
ROADMAP
RELEASE ...
SPRINT SPRINT SPRINT
Story Story
Story Story
Sprint review Sprint review Sprint review
Sprint...
Le process Scrum
Le Backlog
an accumulation of something
Définition
du Backlog
Une liste des fonctionnalités à réaliser
Chaque fonctionnalité est décrite par une Story
Le backlog ...
Backlog et planification
Backlog
Sprint 1
Sprint 2
Produit partiel
Produit partiel
Story Story
StoryStory
StoryStory
Story...
Les Users Stories
Tout projet est un ensemble de belles histoires
En tant qu’utilisateur je
veux ajouter un produit
à mes favoris afin de
pour le retrouver
facilement plus tard
User Story
...
Pourquoi User ? Pourquoi Story ?
Pourquoi pas simplement une tâche ?
Format engageant du
"Story Telling"
L’information est...
Le format “User Voice”
En tant que < Rôle d’utilisateur >,
Je veux < But >,
Afin de < Justification >
Le format « User Voi...
Attributs d’une U.S.
Libellé court de la fonction. Une phrase d’
action à l’infinitif.
Exemples : «Voir les commandes», «C...
Attributs d’une U.S.
User (administrateur, utilisateur, etc.) ou
Technique (vue développeur, bug, etc.)
Créee, Acceptée, E...
INVEST’ir
dans une bonne histoire
Indépendante | éviter les dépendances
Négociable | elle peut être discutée avec l’
équip...
Quelques exemples
Bon ? pas bon ?
Je suis un client,
je veux payer avec
ma MasterCard ...
INVEST ? not INVEST ?
Je suis un client, je veux
payer en ligne …
...
Une boîte de dialogue permet aux
utilisateurs d’éditer la liste des
imprimantes. La boîte de dialogue
permet aux utilisate...
De la valeur pour le client
Je suis RH, je veux Qualifier la liste
des candidats afin de la réduire et y
retrouver facilem...
Non estimable, le
développeur ne maîtrise
pas le domaine technique
EPIC !
Non estimable, le
développeur ne maîtrise
pas le...
EPIC !
Je suis vendeur je
veux gérer mes
objets en vente ...
INVEST ? not INVEST ?
Découper en données
opérationnelles
Je ...
Détailler en données
opérationnelles
EPIC !
Je suis Joueur je
veux jouer en ligne
contre un max d’
autres joueurs
INVEST ?...
Rédiger des informations
Vérifiables
Je suis
utilisateur et je
ne veux pas
attendre ...
INVEST ? not INVEST ?
En tant qu’u...
6 stratégies
Pour avoir des User Stories efficaces
1.)
Par étapes d’
un Workflow
L’utilisateur accomplit une tâche selon un workflow
bien établi. On découpe les stories par ...
2.)
Par scénarios
On obtient une User Story pour le scénario
principal, le cas où tout se passe bien, on en a d’
autres po...
3.)
Par
opérations
Souvent le mode de décomposition le plus évident
… Le CRUD (create, Retrieve, Update, Delete) est un
bo...
4.)
Par Format ou
type de
données
On joue sur le type d’objet (ex : compte titres,
devises, images, messages en français, ...
5.)
Par type d’
entrée, de
sortie ou de
configuration
Des variations d’un point de vue matériel ou non,
selon les configur...
6.)
Par persona
Cette fois-ci, on décompose les user stories en
fonction du rôle et de celui qui va utiliser le produit,
l...
Évaluer la taille
Comment juger de la compléxité d’une User Story
(avant de les plannifier)
Taille et répartition
Pour planifier les sprint, il faudra
répartir l’effort nécessaire à la
production en fonction de la
...
La taille
Elle est exprimée en Story Point.
C’est une valeur arbitraire qui
permet de calculer l’effort à fournir
pour la ...
Une mesure relative ...
Pour démarrer :● Prendre une User Story de référence, depréférence petite et connue ou déjàexpérim...
… et exponentielle !
Nous cherchons à évaluer un ordre
de complexité. plus le scénario est
gros, moins l'évaluation est
pr...
La méthode d’évaluation ...
Problème : le premier qui parle influence les autres ...
Je suis RH, je veux
Qualifier la list...
… version Planning Pocker !
En utilisant des cartes, sorties en même temps,
chacun donne librement sa propre estimation, b...
ce qui permet la discussion
Si les écarts sont trop importants, on lance un débat autour des extrèmes pour comprendre les
...
Prioriser
Ordonner les Users Stories (avant de les plannifier)
Fixer les priorités
Fixer les priorités consiste généralement à classer les Users Stories selon la
valeur apportée au proj...
Critères objectifs de priorité
13 5
1313
Même taille
Valeur différente
Taille différente
Même Valeur
Priorité
Plannifier
Enfin ! Lancer la production des sprints
1. Définir la durée d’un sprint
Les sprints doivent avoir une durée
fixe.
La durée est définie en fonction :
- de vos beso...
2. Définir la taille d’un sprint
La taille est déterminée en Story points
et dépend de la capacité de
production de l’équi...
3. Créer le plan de Sprint
3 5
8
SPRINT 1 - 16 pts
5
32
SPRINT 2 - 15 pts
5
SPRINT 3 - 13 pts
85
2
Cette US dépasse la
cap...
Les cérémonies
Un rythme qui “force” la communication...
Rythme des sprints
SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4
Sprint backlog
Démo
Rétrospective
Production
Daily meeting
Daily meeting
Une réunion courte, en début de journée
(pendant le café ?), de préférence debout
(appellée aussi standing m...
Sprint Review (démo)
Une réunion importante puisqu’elle
consiste à présenter le produit partiel
réalisé pendant le sprint....
Rétrospective
Cette réunion, en équipe uniquement,
permet de faire le point sur le Backlog des
problèmes rencontrés durant...
Mesurer
Connaître la vélocité pour améliorer
sa capacité à anticiper l’avenir
Estimation de la vélocité
92
80
64
48
32
16
s1 s2 s3 s4 s5 s6 s7A faire
Storypoints
Sprints
Vélocité idéale
Mesure de la vélocité
92
80
64
48
32
16
s1 s2 s3 s4 s5 s6 s7A faire
Storypoints
Sprints
Vélocité réelle
Plus lent
Plus rap...
Déroulement
d’un sprint
Le backlog de sprint
Début du
sprint
TODO PROGRESS DONE :o)
5
3
3
1
8
5
2
5
1
5
5
5
ADMIN11
FRONT16MIGRATION
1 2 3 4 5
Sprint 3
Objectif : Prés...
Sprint en
cours
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8
...
Fin du
Sprint
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8
5
...
Les signaux d’alerte
Comprendre le Scrum Board
Trop de
tâches
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8
5...
Trop d’
imprévus
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8...
Manque
de tâches
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8...
Respect
des
priorités
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
...
Vous avez 10 projets ?
Peut-on travailler sur plusieurs projets en simultané ?
Oui !
Pour le backlog, aucun soucis : Mais attention : il faudra calculer de
manière plus précise votre facteur
de focalis...
Exemple multi-projets
SPRINT 1 (44 points) SPRINT 2 (44 points) SPRINT 3 (44 points) SPRINT 4
Sprint backlog
Démo
Rétrospe...
Et les contrats ?
Est-ce que les méthodes agiles sont adaptées
aux prestataires de services ?
Les 2 types de contrats :
Au forfait
Le forfait est par nature antinomique avec les
méthodes agiles … mais rien n’empêche ...
Paradoxes des contrats
En régie : plus le projet avance, moins la valeur perçue par le
client est forte. Le développement ...
Découpage par lots
C’est une alternative ...
En définissant des
budgets par lots on
peut lier anticipation et
engagement a...
Merci !
That’s all Folks
Des concepts pour aller plus loin
Le Story Mapping :
Il s’agit d’une représentation à 2 dimensions et plus riche de
celle ...
RESSOURCES
Les méthodes Agiles expliquées
www.qualitystreet.fr/
www.agiliste.fr/
henrik-kniberg.developpez.com/livre/scrum...
15 minutes
pour
comprendre
SCRUM
Prochain SlideShare
Chargement dans…5
×

Introduction à Scrum et aux méthodes agiles (v1.0)

1 880 vues

Publié le

Les méthodes agiles sont de formidables outils de production. Cette présentation est une synthèse permettant d'aborder la méthode Scrum dans ses grandes lignes fondamentales.

Publié dans : Internet
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 880
Sur SlideShare
0
Issues des intégrations
0
Intégrations
13
Actions
Partages
0
Téléchargements
90
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Introduction à Scrum et aux méthodes agiles (v1.0)

  1. 1. Les méthodes agiles Introduction à SCRUM
  2. 2. Blackbird est une agence de développement web spécialisée dans l’accompagnement et le développement de projets e- commerce sur la solution Magento. http://black.bird.eu About
  3. 3. Sommaire ● Introduction ● Les principes fondamentaux ● Présentation des Users Stories ● 6 stratégies pour rédiger des US efficaces ● Évaluer la taille des Users Stories ● Prioriser les Users Stories ● Plannifier les Sprints ● Les cérémonies : des outils pour communiquer ● Mesurer la vélocité de la production ● Déroulement d’un sprint ● Les signaux d’alertes, savoir interpréter le tableau de sprint ● Traiter plusieurs projets en simultané ● Aspects contractuels ● Concepts et ressources pour aller plus loin
  4. 4. 1980 1990 2000 2010 Gantt / PERT : Cascade ( Waterfall, V Model, etc.) Méthodes Agiles Origines des méthodes Agiles 19501900 Taylorisme Lean Toyota Production System Process focus People focus
  5. 5. Des outils plus ou moins normatifs RUP XP SCRUM KANBAN Faites ce que vous voulez 120+ 13 9 3 0 plusnormatif plusadaptatif RUP est assez normatif - avec plus de 30 rôles, plus de 20 activités et plus de 70 artefacts; une énorme quantité de choses à apprendre. XP (eXtreme Programming) inclut une majorité des règles de Scrum plus un ensemble de pratiques d'ingénierie bien spécifiques comme le développement piloté par les tests et la programmation en binôme. Scrum est moins normatif que XP puisqu'il ne recommande aucune pratique d'ingénierie particulière. Scrum est plus normatif que Kanban cependant, car il impose des choses comme les itérations et les équipes multidisciplinaires. Kanban laisse tout ouvert. Les seules contraintes sont de Visualiser Votre Workflow et de Limiter Votre TAF. Tout près du "Faire N'importe Quoi", mais étonnamment puissant. source : http://henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban/
  6. 6. Les principales différences entre cycle en V et méthodes agiles Personnes et interactions Logiciel qui fonctionne Collaboration avec le client Adaptation au changement Processus et outils Documentation Négociation sur le contrat Suivi d’un plan pré-établi vs vs vs vs Agile Cycle V
  7. 7. Le paradoxe de la gestion de projet Capacité d’action Temps Connaissance du projet
  8. 8. Pourquoi ? ● Faciliter l’expression des besoins ● Aider à l’acceptation du changement Comment ? ● Organiser l’expression des besoins ● Intégrer le client ● Démarche itérative Le modèle Agile
  9. 9. Quels projets favoriser ? ● Besoin rapide de mise à disposition du produit ● Imprévisibilité des besoins du client ● Nécessité de changements fréquents ● Besoin de visibilité du client sur l'avancement des développements ● Présence de l'utilisateur assurant un feedback immédiat
  10. 10. ● Indisponibilité du client ou de l'utilisateur ● Dispersion géographique des ressources humaines ● Inertie des acteurs du projet ou refus des changements ● Gouvernance complexe de la DSI Quels projets éviter ?
  11. 11. Les principes fondamentaux
  12. 12. Les 4 valeurs fondamentales L'équipe « Les individus et leurs interactions, plus que les processus et les outils » L'application « Des logiciels opérationnels, plus qu'une documentation exhaustive » L'acceptation du changement « L'adaptation au changement, plus que le suivi d'un plan » La collaboration « La collaboration avec les clients, plus que la négociation contractuelle » source : Wikipedia
  13. 13. Les 12 principes généraux
  14. 14. User Focus 1. La plus haute priorité est de satisfaire le client (l’utilisateur final du produit) en livrant rapidement et régulièrement des fonctionnalités à forte valeur ajoutée. source : Wikipedia
  15. 15. Un modèle itératif 2. La livraison s’applique à une application fonctionnelle, toutes les deux semaines à deux mois, avec une préférence pour la période la plus courte. 3. L’unité de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut de comptabiliser les fonctions non formellement achevées). 4. Le changement est accepté, même tardivement dans le développement, car les processus agiles exploitent le changement comme avantage concurrentiel pour le client source : Wikipedia
  16. 16. Un modèle Collaboratif 5. Le projet doit impliquer des personnes motivées. Donnez-leur l'environnement et le soutien dont elles ont besoin et faites leur confiance quant au respect des objectifs. 6. Le métier et les développeurs doivent collaborer régulièrement et de préférence quotidiennement au projet. 7. La méthode la plus efficace pour transmettre l'information est une conversation en face à face. 8. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son processus de travail en conséquence. source : Wikipedia
  17. 17. Focus on quality 9. Les processus agiles promeuvent un rythme de développement soutenable 10. Les processus agiles recommandent une attention continue à l'excellence technique et à la qualité de la conception. 11. La simplicité et l'art de minimiser les tâches parasites, sont appliqués comme principes essentiels. 12. Les équipes s'auto-organisent afin de faire émerger les meilleures architectures, spécifications et conceptions. source : Wikipedia
  18. 18. Structure opérationnelle et pratique du développement agile … là on parle de SCRUM
  19. 19. Les rôles Product Owner Scrum Master Team
  20. 20. Démarche itérative Produit Release 1 Release 2 Sprint 1 Sprint 2 Sprint 3 Story Story Story
  21. 21. Itérations Release Chaque fin de release apporte de nouvelles fonctionnalités pour les utilisateurs ROADMAP Release 1 Release 2 ...
  22. 22. Itérations Sprint Chaque fin de sprint apporte de nouvelles fonctionnalités pour les Product Owner RELEASE Sprint 1 Sprint 2 ...
  23. 23. Itérations Stories Chaque fin de Story est une nouvelle liste de tâches terminées pour la team SPRINT Story 1 Story 2 ...
  24. 24. Planning ROADMAP RELEASE ... SPRINT SPRINT SPRINT Story Story Story Story Sprint review Sprint review Sprint review Sprint planning Sprint planning Release review
  25. 25. Le process Scrum
  26. 26. Le Backlog an accumulation of something
  27. 27. Définition du Backlog Une liste des fonctionnalités à réaliser Chaque fonctionnalité est décrite par une Story Le backlog est défini en amont du projet puis actualisé tout au long du projet Les stories y sont priorisées en fonction de leur taille (plus petites en premier) et de leur valeur (plus grande valeur en premier)
  28. 28. Backlog et planification Backlog Sprint 1 Sprint 2 Produit partiel Produit partiel Story Story StoryStory StoryStory StoryStory StoryStory Story Sprint 3 ... Produit partiel Story ... Actualisation du backlog
  29. 29. Les Users Stories Tout projet est un ensemble de belles histoires
  30. 30. En tant qu’utilisateur je veux ajouter un produit à mes favoris afin de pour le retrouver facilement plus tard User Story En tant qu’utilisateur jeveux ajouter un produità mes favoris afin depour le retrouverfacilement plus tard En tant que Sylvianne, je veux ajouter un produit à mes favoris afin de le retrouver facilement plus tard Une user story est un élément fonctionnel qui apporte une valeur et qui peut être développée au cours d’un sprint.
  31. 31. Pourquoi User ? Pourquoi Story ? Pourquoi pas simplement une tâche ? Format engageant du "Story Telling" L’information est spécifique concise et précise. L’accent est mis sur les buts et les comportements. L’utilisateur est clairement défini, c’est le héro des petites "histoires". Ce n’est pas un panel (“80% des femmes,“ “entre 25 et 35 ans“, etc.) Ouvre au dialogue, à l’échange.
  32. 32. Le format “User Voice” En tant que < Rôle d’utilisateur >, Je veux < But >, Afin de < Justification > Le format « User Voice » donne du sens à la fonctionnalité… pour qui et pourquoi l’équipe va la développer Il permet de se rapprocher d’une démarche expérience utilisateur, donne une vision concrète, réaliste et partagée de l’utilisateur final. Il est clairement orienté ACTION et BUT (démarche de conception le plus efficace). La valeur Business représente les bénéfices qui se dégagent de l’ action : Il justifie toutes les fonctionnalités d’un point de vue Business, et oblige le Product Owner et les équipes à s’interroger systématiquement sur la valeur de chaque fonctionnalité
  33. 33. Attributs d’une U.S. Libellé court de la fonction. Une phrase d’ action à l’infinitif. Exemples : «Voir les commandes», «Choisir un produit», «imprimer les factures», ... etc. Numéro d’identification unique Description libre ou structurée (“User Voice” ou liste d’actions élémentaires) Titre ID Description Type Etat Taille Priorité
  34. 34. Attributs d’une U.S. User (administrateur, utilisateur, etc.) ou Technique (vue développeur, bug, etc.) Créee, Acceptée, Estimée, Planifiée, En cours, Terminée Selon l’évaluation faîte lors du planning pocker Classement selon taille / valeur Titre ID Description Type Etat Taille Priorité
  35. 35. INVEST’ir dans une bonne histoire Indépendante | éviter les dépendances Négociable | elle peut être discutée avec l’ équipe chargée de la réalisation. Il n’est pas nécessaire d’inclure tous les détails Valeur | elle est source de valeur pour le client ou l’utilisateur. Estimable | elle peut être estimée par l’ équipe de réalisation avec un risque d’erreur faible. Size (Taille) | Des petites histoires qui peuvent se combiner. Elle doit pouvoir être conçue, développée et testée au sein d’une itération. Testable | Un test démontre que l’histoire correspond bien aux besoins du client
  36. 36. Quelques exemples Bon ? pas bon ?
  37. 37. Je suis un client, je veux payer avec ma MasterCard ... INVEST ? not INVEST ? Je suis un client, je veux payer en ligne … ◻ avec ma CB (Mastercard, Visa, etc.) ◻ avec Paypal N’est pas Indépendante
  38. 38. Une boîte de dialogue permet aux utilisateurs d’éditer la liste des imprimantes. La boîte de dialogue permet aux utilisateurs d’ajouter ou de supprimer des imprimantes. Un utilisateur peut ajouter une imprimante par une recherche automatique ou manuelle par le biais d’ une adresse DNS ou d’une adresse IP. Une recherche avancée optionnelle permet de filtrer les imprimantes par adresse IP ou par le masque de réseau INVEST ? not INVEST ? Je suis un utilisateur, je peux ajouter une imprimante afin d’y avoir accès depuis n’importe quel logiciel de mon système ◻ Recherche automatique ◻ Recherche manuelle (IP ou DNS) ◻ Autres solutions ? Difficilement négociable, manque de flexibilité
  39. 39. De la valeur pour le client Je suis RH, je veux Qualifier la liste des candidats afin de la réduire et y retrouver facilement les profils correspondants à différents critères ◻ Attribuer une note ◻ Associer un tag ◻ Marquer l’état (à conserver, rejetté, entretien, etc.) De la valeur pour l’utilisateur Je suis demandeur d’ emploi, je veux rechercher un emploi par poste et par région afin de trouver une offre correspondant à mes besoins. INVEST ? not INVEST ?
  40. 40. Non estimable, le développeur ne maîtrise pas le domaine technique EPIC ! Non estimable, le développeur ne maîtrise pas le domaine fonctionnel Je suis Commercial, je veux suivre la marge net mensuelle de mes ventes afin de ... INVEST ? not INVEST ? Je suis Médecin, je veux accéder aux informations de mon patient sur DXCARE Je suis Chômeur, je recherche un emploi ...
  41. 41. EPIC ! Je suis vendeur je veux gérer mes objets en vente ... INVEST ? not INVEST ? Découper en données opérationnelles Je suis vendeur, je veux créer une fiche produit afin de vendre un objet Je suis vendeur, je peux ajouter plusieurs photos afin d’améliorer la visibilité de mon produit Je suis vendeur, je veux supprimer ma fiche afin de neplus être contacté une fois ma venteeffectuée.
  42. 42. Détailler en données opérationnelles EPIC ! Je suis Joueur je veux jouer en ligne contre un max d’ autres joueurs INVEST ? not INVEST ? Je suis joueur, je veux lister les rooms multiplayeurs et voir le nombre de joueurs connectés afin de rejoindre la room la plus fréquentée
  43. 43. Rédiger des informations Vérifiables Je suis utilisateur et je ne veux pas attendre ... INVEST ? not INVEST ? En tant qu’utilisateur je veux recharger la page en moins de 1 seconde 95% du temps
  44. 44. 6 stratégies Pour avoir des User Stories efficaces
  45. 45. 1.) Par étapes d’ un Workflow L’utilisateur accomplit une tâche selon un workflow bien établi. On découpe les stories par étapes qui seront développées de façon incrémentale. source : http://www.qualitystreet.fr/
  46. 46. 2.) Par scénarios On obtient une User Story pour le scénario principal, le cas où tout se passe bien, on en a d’ autres pour les cas d’erreurs ou les scénarios alternatifs : quand il se passe A ; quand il se passe B source : http://www.qualitystreet.fr/
  47. 47. 3.) Par opérations Souvent le mode de décomposition le plus évident … Le CRUD (create, Retrieve, Update, Delete) est un bon exemple ; il est souvent utile de découper ou d’ en faire deux en même temps…créer un compte, le consulter, le modifier et le supprimer. source : http://www.qualitystreet.fr/
  48. 48. 4.) Par Format ou type de données On joue sur le type d’objet (ex : compte titres, devises, images, messages en français, anglais, espagnol…) source : http://www.qualitystreet.fr/
  49. 49. 5.) Par type d’ entrée, de sortie ou de configuration Des variations d’un point de vue matériel ou non, selon les configurations mais aussi en termes de moyens de saisie. Cela peut se jouer aussi au niveau de l’interface… source : http://www.qualitystreet.fr/
  50. 50. 6.) Par persona Cette fois-ci, on décompose les user stories en fonction du rôle et de celui qui va utiliser le produit, le fameux « en tant que… ». Pour cela, on peut s’ appuyer le user story mapping, une activité menée au début du projet pour définir le backlog de produit et la roadmap produit. source : http://www.qualitystreet.fr/
  51. 51. Évaluer la taille Comment juger de la compléxité d’une User Story (avant de les plannifier)
  52. 52. Taille et répartition Pour planifier les sprint, il faudra répartir l’effort nécessaire à la production en fonction de la capacité de l’équipe Il faut donc connaître la taille de l’ effort nécessaire pour chaque User Story "Ça dépend"... Oui, ça évidemment, on vous demande de répondre par OUI ou par NON, alors forcement : "ça dépend", ça dépasse !
  53. 53. La taille Elle est exprimée en Story Point. C’est une valeur arbitraire qui permet de calculer l’effort à fournir pour la réaliser et non le temps nécessaire à sa réalisation Pour aller de Rome à Paris, la question de la durée du voyage va dépendre de la vélocité du moyen de transport choisi ... la distance, elle, ne change pas.
  54. 54. Une mesure relative ... Pour démarrer :● Prendre une User Story de référence, depréférence petite et connue ou déjàexpérimentée par les développeurs;● lui attribuer une valeur basse (1, 2 ou 3Story Point) ● Traiter les autres Users Stories enappliquant des valeurs relatives (-2, +1, etc.) Comme il s’agit de déterminer la compléxité d’une User Story, il est plus simple de la calculer en valeur relative : “beaucoup plus simple, plus facile, plus difficile, beaucoup plus difficile”
  55. 55. … et exponentielle ! Nous cherchons à évaluer un ordre de complexité. plus le scénario est gros, moins l'évaluation est précise. 0.5 1 2 3 5 8 13 20 40
  56. 56. La méthode d’évaluation ... Problème : le premier qui parle influence les autres ... Je suis RH, je veux Qualifier la liste des candidats afin de la réduire et y retrouver facilement les profils correspondants à différents critères Quelle taille ? 5 jours ! Ha oui, 5 c’est bien Pareil Pas mieux Peut-être 6 ... … pour être sûr
  57. 57. … version Planning Pocker ! En utilisant des cartes, sorties en même temps, chacun donne librement sa propre estimation, basée sur sa propre compréhension de la story Je suis RH, je veux Qualifier la liste des candidats afin de la réduire et y retrouver facilement les profils correspondants à différents critères Quelle taille ? 5 3 8 5 13
  58. 58. ce qui permet la discussion Si les écarts sont trop importants, on lance un débat autour des extrèmes pour comprendre les différents points de vu, puis un nouveau tour est lancé jusqu’au concensus. Je suis RH, je veux Qualifier la liste des candidats afin de la réduire et y retrouver facilement les profils correspondants à différents critères 3 et 13 : justifiez ! 5 3 8 5 13 Blah blah blah blah blah blah blah Blah blah blah blah blah blah blah
  59. 59. Prioriser Ordonner les Users Stories (avant de les plannifier)
  60. 60. Fixer les priorités Fixer les priorités consiste généralement à classer les Users Stories selon la valeur apportée au projet Nécessaire Souhaitable Si possible Priorité
  61. 61. Critères objectifs de priorité 13 5 1313 Même taille Valeur différente Taille différente Même Valeur Priorité
  62. 62. Plannifier Enfin ! Lancer la production des sprints
  63. 63. 1. Définir la durée d’un sprint Les sprints doivent avoir une durée fixe. La durée est définie en fonction : - de vos besoins en réactivité - des besoins en montée en puissance de l’équipe Les sprints peuvent avoir une durée de 1 à 5 semaines. Comment choisir ? les sprints courts sont bénéfiques. Ils autorisent l'entreprise à être “agile”, c'est-à-dire à changer souvent de direction. Sprint court = cycle de feedback court = des livraisons plus fréquentes = plus de feedback des clients = moins de temps passé à courir dans la mauvaise direction = apprendre et améliorer plus rapidement, etc. les longs sprints sont bien aussi. L'équipe a plus temps pour monter en puissance, ils ont plus de temps pour récupérer des problèmes et parvenir tout de même à atteindre le but du sprint, il y a moins de surcharge en terme de réunions de planning de sprint, de démonstrations, etc. Conclusion : il n’y a pas de règles. faîtes des tests au début.
  64. 64. 2. Définir la taille d’un sprint La taille est déterminée en Story points et dépend de la capacité de production de l’équipe pour la durée du sprint fixé. Ce calcul se résume ainsi : Jours-hommes disponibles multipliés par le facteur de focalisation (c’est à dire la capacité pleine de travail). Comment calculer ? Exemple : ● Durée des sprint : 3 semaines, soit 15 jours. ● Taille de l’équipe : 3 développeurs dont 1 à ⅔ temps , soit : 15+15+10 = 40 jours hommes. ● Facteur de focalisation : Des perturbations externes et des réunions sont prévues pendant ce sprint, soit une estimation de 40% de capacité pleine de travail Résultat : 40 Jours homme * 40% = 16 Jours
  65. 65. 3. Créer le plan de Sprint 3 5 8 SPRINT 1 - 16 pts 5 32 SPRINT 2 - 15 pts 5 SPRINT 3 - 13 pts 85 2 Cette US dépasse la capacité du sprint 1, elle est reportée au sprint suivant
  66. 66. Les cérémonies Un rythme qui “force” la communication...
  67. 67. Rythme des sprints SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4 Sprint backlog Démo Rétrospective Production Daily meeting
  68. 68. Daily meeting Une réunion courte, en début de journée (pendant le café ?), de préférence debout (appellée aussi standing meeting) ... c’est une réunion “informelle“ qui doit maintenir le lien au sein de l’équipe. Les membres de l’équipe ont la parole. L’ objectif est de soulever les éventuels obstacles rencontrés et de les consigner dans le Backlog des problèmes. Les 3 questions que chaque membre de l’équipe expose : - Qu’ai-je fait hier ? - Que vais-je faire aujourd’hui ? - Quels sont les obstacles que j’ai rencontré ?
  69. 69. Sprint Review (démo) Une réunion importante puisqu’elle consiste à présenter le produit partiel réalisé pendant le sprint. Déroulement : - Démo de ce qui a été fait (et fini) - Mise à jour du Backlog : revue des priorités, ce qui permettra de définir le contenu du prochain sprint L’équipe prépare la réunion et fait la présentation du produit au Product Owner Le scrumaster organise la mise à jour du Backlog
  70. 70. Rétrospective Cette réunion, en équipe uniquement, permet de faire le point sur le Backlog des problèmes rencontrés durant le sprint et de définir un plan d’action pour corriger ces problèmes. Objectif : Amélioration Continue Le backlog des problèmes est consolidé Un plan d’actions d’amélioration est défini et mis à jour
  71. 71. Mesurer Connaître la vélocité pour améliorer sa capacité à anticiper l’avenir
  72. 72. Estimation de la vélocité 92 80 64 48 32 16 s1 s2 s3 s4 s5 s6 s7A faire Storypoints Sprints Vélocité idéale
  73. 73. Mesure de la vélocité 92 80 64 48 32 16 s1 s2 s3 s4 s5 s6 s7A faire Storypoints Sprints Vélocité réelle Plus lent Plus rapide Projection réelle
  74. 74. Déroulement d’un sprint Le backlog de sprint
  75. 75. Début du sprint TODO PROGRESS DONE :o) 5 3 3 1 8 5 2 5 1 5 5 5 ADMIN11 FRONT16MIGRATION 1 2 3 4 5 Sprint 3 Objectif : Présenter la béta ! Non planifiés Suivants Story Tâches
  76. 76. Sprint en cours TODO PROGRESS DONE :o) 1 2 3 4 5 Sprint 3 Objectif : Présenter la béta ! Non planifiés Suivants 5 3 3 1 8 5 5 1 5 5 5 ADMIN11 FRONT16MIGRATION Les tâches, puis les stories migrent vers Done Certaines tâches peuvent être remises à plus tard De nouvelles tâches peuvent apparaître en cours de prod Le Burndown chart est mis à jour quotidiennement 5 2
  77. 77. Fin du Sprint TODO PROGRESS DONE :o) 1 2 3 4 5 Sprint 3 Objectif : Présenter la béta ! Non planifiés Suivants 5 3 3 1 8 5 5 1 5 5 5 ADMIN11 FRONT16 Cette Story n’est pas terminée, elle ne sera pas présentée lors de la démo 2 MIGRATION
  78. 78. Les signaux d’alerte Comprendre le Scrum Board
  79. 79. Trop de tâches TODO PROGRESS DONE :o) 1 2 3 4 5 Sprint 3 Objectif : Présenter la béta ! Non planifiés Suivants 5 3 3 1 8 5 5 1 5 5 5 ADMIN11 FRONT16MIGRATION 2 Besoin de supprimer des éléments du Sprint Backlog
  80. 80. Trop d’ imprévus TODO PROGRESS DONE :o) 1 2 3 4 5 Sprint 3 Objectif : Présenter la béta ! Non planifiés Suivants 5 3 3 1 8 5 5 1 5 5 5 ADMIN11 FRONT16MIGRATION 2 Attention : l’ accumulation de tâches non plannifiées peuvent tuer le Sprint
  81. 81. Manque de tâches TODO PROGRESS DONE :o) 1 2 3 4 5 Sprint 3 Objectif : Présenter la béta ! Non planifiés Suivants 5 3 3 1 8 5 5 1 5 5 5 ADMIN11 MIGRATION 2 Besoin d’ajouter des éléments du Sprint Backlog FRONT16
  82. 82. Respect des priorités TODO PROGRESS DONE :o) 1 2 3 4 5 Sprint 3 Objectif : Présenter la béta ! Non planifiés Suivants 5 3 3 1 8 5 5 1 5 5 5 ADMIN11 FRONT16 MIGRATION 2 Attention : L’équipe néglige les tâches prioritaires
  83. 83. Vous avez 10 projets ? Peut-on travailler sur plusieurs projets en simultané ?
  84. 84. Oui ! Pour le backlog, aucun soucis : Mais attention : il faudra calculer de manière plus précise votre facteur de focalisation pour chaque projet, imputé nécessairement par la production sur les autres projets au sein d’un même Sprint ! Projet 1 Projet 2 … etc.
  85. 85. Exemple multi-projets SPRINT 1 (44 points) SPRINT 2 (44 points) SPRINT 3 (44 points) SPRINT 4 Sprint backlog Démo Rétrospective Production Daily meeting Projet 1 Projet 2 Projet 3 Focus = 15 % Focus = 30 % Focus = 15 % Taille équipe : 3 développeurs Focus équipe : 60% Taille Sprint : 2 semaines Capacité Sprint = 30jh * 60% = 18 jours, soit : 9 + 4,5 + 4,5 SI 1 sp = 3h, la capacité est donc de 22 + 11 + 11, soit 44 SP par sprint CAPACITÉ : Planning :
  86. 86. Et les contrats ? Est-ce que les méthodes agiles sont adaptées aux prestataires de services ?
  87. 87. Les 2 types de contrats : Au forfait Le forfait est par nature antinomique avec les méthodes agiles … mais rien n’empêche de décomposer un forfait en lots, équivalent à vos incréments. Attention à bien définir le périmètre fonctionnel en amont pour garantir au fournisseur (le développeur) qu’il ne rognera pas sa marge. A la régie C’est la méthode la plus naturelle, mais qui nécessite une relation de confiance forte. Définir le périmètre peut également être une bonne idée pour garantir au client qu’il ne dépensera pas plus que nécessaire.
  88. 88. Paradoxes des contrats En régie : plus le projet avance, moins la valeur perçue par le client est forte. Le développement devrait donc prendre fin lorsque le coût dépasse la valeur marginale acquise. Avec le mode forfait, le coût est négocié d’avance. Ainsi, plus le développeur travaille (pour une valeur moindre), plus il rogne sa marge. source : http://blog.xebia.fr/
  89. 89. Découpage par lots C’est une alternative ... En définissant des budgets par lots on peut lier anticipation et engagement avec la flexibilité des méthodes agiles
  90. 90. Merci ! That’s all Folks
  91. 91. Des concepts pour aller plus loin Le Story Mapping : Il s’agit d’une représentation à 2 dimensions et plus riche de celle offerte par le Backlog de produit. En horizontal : les usages, en vertical : les priorités. Kanban : Un outil plus souple que SCRUM … et pourquoi ne pas le mélanger avec SCRUM ? Behaviour Driven Development : Compléter les stories en expliquant les comportements : Given When Then Les Personas : Rédaction de fiches utilisateurs précises et détaillées. Les personas évitent de parler en terme de “panel” et permettent une approche plus personnifier des fonctions. Definition of Done : Définition du “fini”, pour les stories, les sprint et les releases afin de s’assurer que toute l’équipe suive un même niveau de qualité.
  92. 92. RESSOURCES Les méthodes Agiles expliquées www.qualitystreet.fr/ www.agiliste.fr/ henrik-kniberg.developpez.com/livre/scrum-xp henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban La culture Agile http://blog.xebia.fr/category/agilite www.areyouagile.com/ Contrat Agile http://www.contrat-agile.org/ www.scrum.org
  93. 93. 15 minutes pour comprendre SCRUM

×