4. Fiche d’identité
• Cabinet de conseil en système d’information
• Création : juin 2000
• Basé à Paris – 8ème et Casablanca
• 50 consultants
– Consultants SI
– Architectes
– Experts
• Quelques chiffres :
– 4,3 M€ en 2011
5. et l’agilité
• Une culture Agile et Lean interne forte
• Une pratique concrète chez nos clients depuis plusieurs années sur
d’importants projets (ex: Plateforme de prise de paris en ligne du PMU)
• Un accompagnement de nos clients sur l’adoption, la généralisation et
l’amélioration des pratiques
• Une vaste politique de certification SCRUM : « ScrumMaster » et « Product
Owner »
• Speaker aux évènements nationaux (ex: Agile Tour, XP Days)
• Une reconnaissance de nos clients : de la part des praticiens IT et des
bénéficiaires métiers
• Sponsor du Scrum User Group France
• Membre et co-fondateur de l’institut Agile
6. Introduction / Contexte
• Projet « stratégiques » ?
– Enjeux pour l’entreprise
– Implication des décideurs
• Objectifs annoncés du Plan de release
– Fournir de la visibilité : Quoi ? Quand ? Combien ?
– Permettre la prise de décision : Go / NoGo
– Délai réduit : 15 jours à 1 mois
• 2 contextes possibles :
– Projet « neuf »
– Projet existant en phase d’«attente »
7. Kesako ?
• La conception du Plan de release d’un projet consiste à
projeter sur une échelle de temps les fonctionnalités métiers
du système cible telles qu’elles seront réalisées.
• La répartition des différentes fonctionnalités sur l’échelle de
temps décomposées en Releases et en Itérations dépend de
plusieurs facteurs combinés :
– L’importance de la fonctionnalité dans le système,
– Son coût de réalisation,
– Sa dépendance à d’autres fonctionnalités.
8. Objectifs poursuivis ?
La conception du plan de Release poursuit plusieurs objectifs :
1. Disposer d’une vision métier du projet partagée par l’ensemble des acteurs
métier, pilotage, équipes de réalisation, d’intégration, de tests, partenaires, …
2. Segmenter le projet en sous-ensemble fonctionnels « complets » (domaines
fonctionnels / fonctionnalités) de taille adaptée à une estimation de charges
réaliste.
3. Dégager un consensus sur les estimations de charges nécessaires à la réalisation
des grandes fonctionnalités du système en s’adressant aux experts fonctionnels et
techniques concernés.
4. Dimensionner le dispositif opérationnel projet en fonction des estimations
réalisées et des objectifs de release retenus.
5. Coordonner les acteurs du projet.
6. Suivre l’avancement / le reste à faire du projet.
7. Effectuer les arbitrages et mener les re-planifications nécessaires.
10. 1 - Découverte des fonctionnalités
cas 1 : projet « neuf »
• Sous la forme d’un atelier
Animateur
– 3 ou 4 « experts métier »
– 1 ou 2 « décideurs » Expert
Manage métier
– 1 animateur + 1 rapporteur r
Manage
r
Expert
métier
Expert
métier
Expert
métier
Rapporteur
11. Game #1 – invention des fonctionnalités (1h)
• Pendant 20 minutes, chacun écrit autant de
fonctionnalités qu’il le souhaite ou le peut :
une par Post’it.
• A tour de rôle, chacun vient présenter ses
fonctionnalités au groupe en les positionnant
sur un tableau.
• On peut ajouter des fonctionnalités en cours
de jeu.
• Les managers parlent en dernier !
13. Game #2 – Regroupement (20’)
• Regroupement des fonctionnalités par
catégories : domaine fonctionnel, sous-
domaine, epics, …
• Emergence d’un vocabulaire métier du projet
• Prolongement « naturel » du jeu #1
• Eclaircissement, réécriture, suppression des
Post’it devenus inutiles
15. Game #3 – Classement horizontal (5’)
• « dot voting »
• Chacun dispose de 5 votes qu’il positionne à
sa guise sur les catégories
• On peut voter plusieurs fois sur la même
catégorie, voire mettre tous ses votes sur une
seule
19. Game #4 – Classement vertical (1/2h)
• A l’intérieur de chaque catégorie, l’équipe
classe verticalement les fonctionnalités des
plus importantes en haut au plus accessoires
en bas,
• Il est possible de réécrire, de fusionner et de
dissocier des fonctionnalités,
• Au passage, on peut utiliser le modèle de
Kano pour tagguer les fonctionnalités (must have
/ the more the better / delighter).
20. Fin de la phase 1 « 1er Backlog »
• Un périmètre fonctionnel complet avec un
niveau de détail de « macro » à « moyen »
• Un découpage en domaine et sous-domaine
fonctionnel
• Un début de « vocabulaire projet »
• Plusieurs indicateurs de priorisation global /
par domaine / sur différents plans (client, …)
21. Quelques conseils …
• La rapporteur de l’atelier peut tracer les résultats
des différents jeux ainsi que la « substance des
échanges » avec un outil léger tel Scrumdo.com,
• Excel (ou Google Spreadsheet) reste encore bien
utile pour croiser et trier les données collectées
lors de l’atelier (votes, …)
• De 1 atelier sur une journée à 3 ateliers d’une
demi-journée espacés de quelques jours.
• Nous avons aussi essayé : « buy a feature », « be
my shadow », ..
22. 1’- Découverte des fonctionnalités
cas 2 : projet « existant »
• Analyse de l’existant documentaire en équipe
de 2 à 4.
• Construction d’un 1er backlog sans
intervention du client/des métiers.
• Présentation du 1er Backlog dans le cadre d’un
« atelier de travail » ...
… et utilisation des techniques du « cas 1 ».
23. 2 - Estimation du backlog
• Sous la forme d’un atelier
Animateur
– 3 ou 4 « experts technique »
– 1 ou 2 « experts métiers » Expert
Expert tech.
– 1 animateur + 1 rapporteur métier
Expert
métier
Expert
tech.
Expert
tech.
Expert
tech.
Rapporteur
25. Préparation de l’estimation (1-2h)
• Présentation du périmètre fonctionnel à
l’équipe technique : échange et
approfondissement.
• Présentation du socle technique
– Cas 1 : connu et maîtrisé
– Cas 2 : mal connu et/ou non maîtrisé
• Hypothèses retenues pour les estimations
26. Game #5 « Planning Poker » (1-2h)
• Le planning poker ne sert qu’à « étalonner »
les stories (ou epics) pour la suite de
l’estimation.
• Sélection de 4 ou 5 stories représentatives
• Décomposition en activités pour l’équipe
• Validation des hypothèses d’implémentation
qui impacteront l’estimation de la complexité
• Utilisation de l’échelle « tailles de tee shirts » :
XS, S, M, L, XL
27. Game #6 « La roue »
• Estimez et positionner les
stories sur la roue Yyzuyi
• Utilisez les story étalons pour
zeiy
Yyzuyi
zeiy
positionner les nouvelles XS XL
stories comparativement Yyzuyi
zeiy
• Dégagez un consensus entre Yyzuyi
zeiy
Yyzuyi
zeiy
Yyzuyi
Yyzuyi
zeiy
Yyzuyi
zeiy
les participants ou utilisez
zeiy Yyzuyi
S Yyzuyi
L zeiy
l’estimation supérieure. zeiy
Yyzuyi
zeiy
Yyzuyi
zeiy
• Estimez dans l’ordre des M
macro-priorités de la phase 1
• Entre 30 et 50 stories en une
demi-journée
28. Fin de la phase 2 « Backlog estimé »
• Finalisation de l’estimation des stories hors atelier
et/ou nouvel atelier « la roue » en fonction de la
profondeur du backlog.
• Backlog estimé de manière macro sur l’ensemble du
périmètre et selon des hypothèses d’estimation
connues.
• Liste des hypothèses fonctionnelles et techniques à
valider avant d’entérinner le plan de release.
• Liste des epic/stories a retravailler (L et XL)
30. Plan de release v0 ?
• Fixer une échelle de temps et un niveau de
ressources (équipe, vélocité)
• Faire simple !
– Echelle linéaire dans un premier temps
– Business value first !
• Communiquez visuellement : afficher le PR 0 !
• Faites des hypothèses pour passer des « tailles
de tee shirts » aux « story points »
31. Plan de release v0 linéaire
Release #1 R. #2 R. #3
#0* #1 #2 #n
Fonctionnalités
32. Présentation du plan de release
• Sous la forme d’un atelier de 2h
– 2 ou 3 « managers / décideurs clients » Animateur
– 1 « experts métiers » Expert
Expert tech.
– 1 « experts technique » métier
– 1 animateur + 1 rapporteur Expert
métier
Expert
tech.
Expert
tech.
Expert
tech.
Rapporteur
33. • Discutez des options stratégiques
• Arbitrez entre must have / nice to have / delighters
• Arbitrez entre court-terme / moyen-terme / long-
terme
• Les estimations ne sont pas négociables … sans
contre-parties !
• Adressez les dimensions fonctionnelles /
opérationnelles /techniques sur le même plan.
34. Plan de release v1 ?
• Valider le consensus :
– Choix stratégiques
– Plan de ressources
– Priorités du projet (fonctionnalités, jalons, qualité)
• Itérez !
• Proposez aux managers présents d’intégrer le
processus plus tôt la prochaine fois.
35. Release #1
#0 #1 #2 #n
Equipe A
Equipe B
Equipe intégration
#0 + #1 #2 + #n