Introduction à l'agilité numélink - 24 mai 2012 - #3 etapes proj

552 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
552
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Il faut se concentrer dessus et ne pas s'éparpiller. Un bon exemple : votre CV La vision produit permet de se concentrer sur l'utilisation du produit, sa perception d'un point de vue utilisateur, de voir quelle est la définition du succès
  • Perception de la vision produit  La vision produit est ce que doit percevoir l'utilisateur 1 nom et 1 définition En dire plus c'est en dire trop : l'utilisateur s'y perd et ne comprend pas le produit Qui recherche quoi ? Pour quel usage ? Pour qui ? Quelle stratégie ?
  • Toute l'équipe projet participe : métiers, utilisateurs, développeurs, décisionnaire, chef de projet, commercial, ...   En phase amont d'un projet (exploration) visant à créer ou améliorer un produit.   Il faut se projeter dans l'utilisation future du produit (à défaut de pouvoir l'utiliser dès maintenant)    Elevator statement  : Geoffrey More  http://www.amazon.com/exec/obidos/ASIN/0066620023/cutterinformatco POUR (les utilisateurs finaux du produit) QUI SOUHAITENT (leurs besoins) NOTRE PRODUIT EST (le 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érentiateurs majeurs)
  • Réalisées par 5 PME après 2 mois de pratique de Scrum
  • Approche équitable/comparable
  • Introduction à l'agilité numélink - 24 mai 2012 - #3 etapes proj

    1. 1. Numélink - 24 mai 2012  Etapes du projet Introduction  à lagilité@Agnes_Crepet@GuillaumeEhret @AlfredAlmendra
    2. 2. Les jeux et les étapes du projetExtrait du calendrier du CARA Lyon (OUI, cest de la PUB !) 
    3. 3. La vision produit = le cadre du projet Justifie lexistence du produit ... et celle du projet     Ciblée, valeur ajoutée... lutilisateur, ses besoins    Simple, concise ... fonctionnalités clé   Lessentiel : enjeu, objectifs ... besoins / attentes / résultat   Une projection du futur... mais sans aucune certitude   Permet de garder le focus ... aller vite ... mais bien !
    4. 4. La vision produit : fédératrice et partagée  
    5. 5. Exemple de Roman Pichler
    6. 6. Quand et comment ? Le test de lascenceur (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. 7. Vision produitCest létape la plus souvent oubliée, ou plutôt la moins souvent partagéeElevator statementMindmapJeu de la product box"I think every project should beconsidered to produce a product"Jim Highsmith
    8. 8. Des exemples ?    Source: http://www.agilex.fr/
    9. 9. Vision But But ButPersonna Personna Les personnas viennent de lUX Epic 1 Epic 2 US 1 US 1 Vision vers Epic US 2 US 2 (~ fonction / UC) US 3 US 3
    10. 10. Quest-ce quune User Story ? Chef produit ClientMarketing Commercial Ne pas oublier les  critères dacceptation ! Développeur
    11. 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. 12. User Story Mapping time necessary less first release optional second release optionality more third release optional
    13. 13. Story mapping
    14. 14. Quest-ce que le backlog produit ?
    15. 15. Les stories du backlogChaque post-it doit être discuté avec tout le mondeRepérer les doublonsSi l’attente n’est pas tangible, il faut la rediscuter= formuler des critères dacceptation (Criteria of Done)Possibilité dautomatiser les tests dacceptations    Behavior Driven DevelopmentNe pas hésiter à réécrire les post-itsAmaigrir le produit le plus possible
    16. 16. Valoriser et prioriserMoSCoW• M - MUST have this• S - SHOULD have this if at all possible• C - COULD have this if it does not effect anything else• W - WONT have this time but would like in the futureKanoQuestions fonctionnelles et dysfonctionnelles– Attractif– Une dimension linéaire– Obligatoire– Indifférent– Pénalisant
    17. 17. KanoChaque 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é nest pas présente ou ne fonctionne pas bien (ou pas du tout)1. Jaime bien http://socious.com/ 2. Cest la base, le minimum3. Sans avis, neutre4. Je peux vivre avec (ou sans)5. Je naime pas
    18. 18. http://cbigot.net/kano 
    19. 19. Prune the product treeFaçonner plutôt que couperAu début du projet, mais aussi en début de sprint / release"Livrer quelque chose de cohérent"Photo de effectiveagiledev.com
    20. 20. EstimationLe budget nest pas une somme destimationEstimation relative par comparaison• consensuelle, durableExemples de techniques de collaboration :• Consensus du groupe• Répartition de tâches• Combinaison des estimations individuellesExemples 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. 21. Estimation• Fourchettes pour les estimations. Nombres pour les faits• Toujours demander à quoi les estimations sont destinées• Une estimation nest pas un engagement• Mesurer, compter et calculer avant destimer• 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. 22. EstimationQuelques exemples dutilisation :• planification ditération• ré-estimation : traduction en moyenne dheures à partir de la  vélocité (Scrum), voire en fonction du profil de la personne• gestion du risque sur le périmètre fonctionnel dun sprint,  dune releaseAgile Grenoble 2011 : Stéphane Hanser (@tourix)Complexité / flou / niveau de connaissance / expérience
    23. 23. PlanificationLes itérations : de quelques jours, semaines à 2 mois maxLes releases : toutes les X itérations    Idéalement toutes les itérations    Maximum : toutes les 3Scrum : périmètre figé du sprint en coursKanban : 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. 24. RetropectiveBilan des itérationsObjectif : saméliorer et non juger!  Toute léquipe participe à la réunion En entrée  • le plan dactions de la rétrospective précédente • le backlog de problèmes Etapes • Créer un environnement propice à lexpression • Collecter les informations relatives au processus • Définir les priorités • Planifier des actions damélioration 

    ×