Introduction à l'agilité numélink - 24 mai 2012 - #3 Etapes Projet

1. Numélink - 24 mai 2012
Etapes du projet
Introduction
à l'agilité
@Agnes_Crepet
@GuillaumeEhret
@AlfredAlmendra

2. Les jeux et les étapes du projet
Extrait du calendrier du CARA Lyon (OUI, c'est de la PUB !)

3. La vision produit = le cadre du projet
Justifie l'existence du produit
... et celle du projet
Ciblée, valeur ajoutée... l'utilisateur, ses besoins
Simple, concise
... fonctionnalités clé
L'essentiel : enjeu, objectifs
... besoins / attentes / résultat
Une projection du futur... mais sans aucune certitude
Permet de garder le focus ... aller vite ... mais bien !

4. La vision produit : fédératrice et partagée

5. Exemple de Roman Pichler

6. Quand et comment ?
Le test de l'ascenceur (elevator statement)
POUR (les utilisateurs finaux du produit)
QUI SOUHAITENT (leurs besoins)
NOTRE PRODUIT EST (un résumé du produit)
QUI (le bénéfice majeur et l’utilité du produit)
A LA DIFFÉRENCE DE (produits concurrents)
PERMET DE (éléments différenciateurs majeurs)

7. Vision produit
C'est l'étape la plus souvent oubliée,
ou plutôt la moins souvent partagée
Elevator statement
Mindmap
Jeu de la product box
"I think every project should be
considered to produce a product"
Jim Highsmith

8. Des exemples ?
Source: http://www.agilex.fr/

9. Vision
But But But
Personna Personna Les personnas viennent de l'UX
Epic 1 Epic 2
US 1 US 1 Vision vers Epic
US 2 US 2 (~ fonction / UC)
US 3 US 3

10. Qu'est-ce qu'une User Story ?
Chef produit Client
Marketing
Commercial
Ne pas oublier les
critères d'acceptation !
Développeur

11. User Story Mapping
• Le backbone de l’application est la liste des
activités essentielles que l’application supporte
• Le “walking skeleton” est le logiciel que nous
construisons qui supporte le nombre minimum et
suffisant de tâches nécessaires sur le panel de
fonctionnalités
The backbone
tim
e
The walking skeleton
neces
sity
© 2006-2008 Jeff Patton, All rights reserved, www.agileproductdesign.com

12. User Story Mapping
time
necessary
less
first release
optional
second release
optionality
more third release
optional

13. Story mapping

14. Qu'est-ce que le backlog produit ?

15. Les stories du backlog
Chaque post-it doit être discuté avec tout le monde
Repérer les doublons
Si l’attente n’est pas tangible, il faut la rediscuter
= formuler des critères d'acceptation (Criteria of Done)
Possibilité d'automatiser les tests d'acceptations
Behavior Driven Development
Ne pas hésiter à réécrire les post-its
Amaigrir le produit le plus possible

16. Valoriser et prioriser
MoSCoW
• M - MUST have this
• S - SHOULD have this if at all possible
• C - COULD have this if it does not effect anything else
• W - WON'T have this time but would like in the future
Kano
Questions fonctionnelles et dysfonctionnelles
– Attractif
– Une dimension linéaire
– Obligatoire
– Indifférent
– Pénalisant

17. Kano
Chaque question est posée sous les 2 formes :
Que pensez-vous ou comment vous sentez-vous ... ?
Formulation fonctionnelle :
... si cette fonctionnalité est présente (et fonctionne bien)
Formulation dysfonctionnelle :
... si cette fonctionnalité n'est pas présente ou ne fonctionne pas bien (ou pas du tout)
1. J'aime bien http://socious.com/
2. C'est la base, le minimum
3. Sans avis, neutre
4. Je peux vivre avec (ou sans)
5. Je n'aime pas

18. http://cbigot.net/kano

19. Prune the product tree
Façonner plutôt que couper
Au début du projet, mais aussi en début de sprint / release
"Livrer quelque chose de cohérent"
Photo de effectiveagiledev.com

20. Estimation
Le budget n'est pas une somme d'estimation
Estimation relative par comparaison
• consensuelle, durable
Exemples de techniques de collaboration :
• Consensus du groupe
• Répartition de tâches
• Combinaison des estimations individuelles
Exemples de jeux
• Planning poker (1, 2, 3, 5, 8, 13, 20, 40, 100) (fibonacci)
• T-Shirt sizing (XS, S, M, L, XL)
• Zoo points (férocité), poids des chiens,...

21. Estimation
• Fourchettes pour les estimations. Nombres pour les faits
• Toujours demander à quoi les estimations sont destinées
• Une estimation n'est pas un engagement
• Mesurer, compter et calculer avant d'estimer
• Agréger les estimations indépendantes
• Utiliser la loi des grands nombres (grand nombre de stories,
nombre constant de personnes qui estiment)
• Calibrer les estimations avec les autres vélocités standards
• Ne jamais négocier les estimations
• Ne jamais négocier les engagements
• Résoudre les problèmes ensemble

22. Estimation
Quelques exemples d'utilisation :
• planification d'itération
• ré-estimation : traduction en moyenne d'heures à partir de la
vélocité (Scrum), voire en fonction du profil de la personne
• gestion du risque sur le périmètre fonctionnel d'un sprint,
d'une release
Agile Grenoble 2011 : Stéphane Hanser (@tourix)
Complexité / flou / niveau de connaissance / expérience

23. Planification
Les itérations : de quelques jours, semaines à 2 mois max
Les releases : toutes les X itérations
Idéalement toutes les itérations
Maximum : toutes les 3
Scrum : périmètre figé du sprint en cours
Kanban : pérmiètre flexible
Gestion du risque, suivi et arbitrage au quotidien : daily meetings
++ estimation du reste à faire
-- passer trop de temps sur un chiffrage trop fin

24. Retropective
Bilan des itérations
Objectif : s'améliorer et non juger!
Toute l'équipe participe à la réunion
En entrée
• le plan d'actions de la rétrospective précédente
• le backlog de problèmes
Etapes
• Créer un environnement propice à l'expression
• Collecter les informations relatives au processus
• Définir les priorités
• Planifier des actions d'amélioration