7. REX sur deux grands projets
Refonte d'un site e-commerce Refonte du front office d'une
de vêtement de mode société financière bruxelloise
5 pays 5 webapps
23 Sprints 25 Sprints
2750 JH 3300 JH
7
mercredi 28 mars 12
11. Utiliser le
business value mapping
• Identifier les objectifs : humain, financier,
organisationnel
• Identifier les relations entre les
objectifs
Augmente Diminue
Source : Pascal Vancauwenberghe - Business Value Game - http://www.slideshare.net/agilecoachnet/business-value-by-systems-thinking
11
mercredi 28 mars 12
12. Exemple :
Modèle de la valeur AGILE
Amélioration
en continue Gaspillages
Cadre SCRUM
Qualité Dysfonctions
Délais de
Collaboration Efficacité des
mise en
efficace projets
marché
Opportunités
d'affaires
Satisfaction
Concentration
client
sur la valeur Pertinence
des solutions
Source : EFIDEV - Business Value Mapping de la valeur agile
Augmente Diminue
12
mercredi 28 mars 12
13. Modèle de la valeur
d'une refonte
Intelligent
sécurisé
système LEAN
autonomie de
décision
ergonomique
dette
TCO
technique
fiable orienté client
qualité
Source : Pascal Vancauwenberghe - Business Value Game - http://www.slideshare.net/agilecoachnet/business-value-by-systems-thinking
13
mercredi 28 mars 12
14. 1ère étape de mise en oeuvre
Traduire la vision
dans un backlog
14
mercredi 28 mars 12
15. Intervenants
Peut-il
travailler
seul ?
ScrumMaster Product owner
Client / Utilisateur / Management
15
mercredi 28 mars 12
16. Constituer
la core Team du PO
Qu'est-ce qu'une
bonne équipe ?
16
mercredi 28 mars 12
17. Vision
Intelligent
sécurisé
système LEAN
autonomie de
décision
ergonomique
Cône d’incertitude
dette
TCO
technique
fiable orienté client
qualité
Stratégie
Objectifs
Projet
Releases
Scénarios 17
mercredi 28 mars 12
18. Comment démarrer ?
Inventaire des Dépendances
thèmes à traiter
ous-thèmes
SSous-thèmes
Sous-thèmes
Sous-thèmes 1 couleur par
thème
18
mercredi 28 mars 12
20. Assembler le backlog
Intelligent
sécurisé
système LEAN
de
autonomie de
décision
ergonomique
dette
TCO
technique
itu
fiable orienté client
qualité
e rt
'i nc
d
ne
Cô
20
mercredi 28 mars 12
21. OPPORTUNISTE ?
L'agilité d'une organisation
dépendant directement de sa
capacité à saisir les
opportunités
21
mercredi 28 mars 12
22. Opportunités = releases
Release 1 : monter, valider et étudier un dossier Release 2 :
Sprint 1 Sprint 2 Sprint 3
22
mercredi 28 mars 12
23. Légende des
couleurs de
thème
Dépendances
datées
Sous-thèmes à
traiter dans le Sprint
mercredi 28 mars 12
24. Coordonner le travail
Concentrer ensemble en JIT
Release 1 : monter, valider et étudier un dossier Release 2 :
Sprint 1 Sprint 2 Sprint 3
I I L
L
O
U
O
24
mercredi 28 mars 12
25. Coordonner l'action
avec I L U O
En préparation du backlog
IGNORE Non démarré
LEARN Analyse métier
USE Sketching d'interface
OWN Scénario prêt
25
mercredi 28 mars 12
31. La loi des 80/20
100
Temps en gestion traditionnelle
Temps selon loi des 80/20
75
50
Dérapage moyen selon
le Standish Group
+170%
25
0
0 40% 80% 120% 160% 200% 240% 280%
31
mercredi 28 mars 12
32. Backlog global du projet
Coût du Effort Budget Budget Con
Vélocité Priorité
report (points) (JH) (points) (p
2,5 400 2040 5100
Gestion des vendeurs 33 30 1,10 153 383
Gestion des produits et tarifs 50 100 0,50 510 1275
CMS de publication des messages 3 20 0,15 102 255
Scoring en ligne 70 50 1,40 255 638
Formulaire 100 80 1,25 408 1020
Consultation du fichier positif BNB 100 100 1,00 510 1275
Assurance qualité 13 20 0,65 102 255
source : Dean Leffingwell - http://scalingsoftwareagilityblog.com/a-lean-economic-approach-to-prioritizing-work/
32
mercredi 28 mars 12
37. Ne laisser jamais l'IT
refondre seul !
>Telnet
Le voir pour
croire !
telnet>open towel.blinkenlights.nl
le
37
mercredi 28 mars 12
38. Grand principe d'une refonte
Utiliser le meilleur code !
Pas de
Pas de// meilleur code coût
bug
Pas de Pas de CPU
dev POURQUOI ?
Pas de Pas de
maintenance mémoire
38
mercredi 28 mars 12
39. En résumé
RELEASES PLAN
BACKLOG
OPPORTUNITES DO
Travail sur Réalisation
la valeur en sprints
THEMES CHECK
PRODUIT
FINI
VISION ACT
Consolidation
39
mercredi 28 mars 12
40. Une idée à retenir
Définir un besoin n'est pas y répondre !
Un besoin est le point d'entrée d'un travail
collaboratif de conception entre le PO, des
représentants des utilisateurs et l'IT.
40
mercredi 28 mars 12