Projet de 4A, Janvier 2020 Kick-off meeting - 06.01.20, Philippe Collet & Anne-Marie Pinna
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
pictures: sxc.hu Projet de 4A, Janvier 2020 06.01.20, Philippe Collet & Anne-Marie Pinna- Dery (avec beaucoup de slides de Sébastien Mosser) Kick-off meeting pictures: sxc.hu, pexels, pixabay
Objectifs Présenter les spécialisations de 5A mobiliser les compétences acquises Appliquer des principes d’agilité
Inspiré d’ "Il était une fois Une formule "agile" la vie d’un product Owner" http://www.youtube.com/watch?v=c0RZsewej88
Henrik Kniberg
http://agilemanifesto.org/iso/fr/
" Une équipe qui s’améliore et s’organise dans un environnement complexe pour délivrer en continu de la valeur à ses utilisateurs, en toute simplicité … — Romain Couturier
Équipe " We’re all in this together — Mike Cohn 15
S’améliore et s’organise Prévu Fait 10 9 8 7 6 5 4 3 2 1 0 #1 #2 #3 #4 Paper plane factory Yesterday’s weather 16
Simplicité " Art de minimiser la quantité de travail inutile 17
Utilisateur ➙ Clients Utilisateur final Autre développeur La personne qui a acheté le logiciel 19
Valeur Insiste sur le "quoi", pas sur le "comment" Qu’est-ce que je saurais faire demain que je ne savais pas déjà faire aujourd’hui ? 20
Délivrer en continu Développement Rétrospective Planification continue D D D D é é é é m m m m o o o o 21
Et notre logiciel dans tout ça ?
Logiciel "vision" Produit
Exigences fonctionnelles: ce que fait le produit Exigences non-fonctionnelles: racines du produit
Exigences : User stories Spécification & Estimation
Visible Valeur Bugs ? Valeur Négative Positive Dette Choix NF (Non Fonctionnels) Invisible
User Story!
User Story ? Description d’une valeur ajoutée pour un persona ⊕ Critères d’acceptations ⊕ Tests
" Description En tant qu’utilisateur de Gégémail, je veux me connecter à ma boîte mail afin de gérer mes mails de façon sécurisée — PODOJO, USTA
" Critères d’acceptation • Sur la page d’accueil, je saisis mon login / mot de passe • Si le login saisi n’existe pas, message d’erreur • Si le mot de passe ne correspond pas au login, message d’erreur • Si le login existe et que le mot de passe correspond au login, j’accède à ma boîte de réception — PODOJO, USTA
" Test d’acceptation • Initialisation : Je vais sur la page d’accueil de Gégémail • Action : Je saisis un login qui n’existe pas et un mot de passe • Résultat attendu : Message d’erreur — PODOJO, USTA
Given … When … Then …
Vous Les critères d’acceptation
I ndépendante N égociable Une story est V alorisée un INVESTissement E stimable S imple ~ small T estable
En apportant de la valeur, une story VERTICALE est par nature
Front-End Middle-Tier DB
" A user story is to a use case as a gazelle is to a gazebo. - Alistair Cockburn
" A user story is the title of one scenario, where a use case is the contents of multiple scenarios - Alistair Cockburn
Cumulative value small stories 100 75 big stories 50 25 0 waterfall 41
Planification? risque élevé Euh? simplifier Courage peu de Beaucoup de valeur valeur Easy Métier risque faible
Prioriser le backlog Maximiser la valeur client par rapport à l’effort de l’équipe sur 1 Sprint
Estimation Business Value, Story Points, Planning Poker…
Quel est le poids moyen d’un berger des Pyrénées adulte en bonne santé ?
Berger ? Berger ?
Berger des Pyrénées Westie Chihuahua Absolu ≠ Relatif
Estimer en Story Point(s) pas en jours / heures Jamais Sérieusement. Jamais.
Estimer la valeur Estimer l’effort
Quelle est l’effort nécéssaire à la réalisation de la story #42 ?
? ? ? ?
min max Discussions
? ? ? ?
Bien choisir la première story d’une estimation Ni trop grande, ni trop petite
Estimer la valeur client: Plein (trop) de techniques… The Periodic Table of Product Prioritization Techniques https://foldingburritos.com/product-prioritization-techniques/
Estimer la valeur client ? Simple, basique… Priority Poker avec le Product Owner et les utilisateurs/clients
MoSCoW?
MoSCoW Présenter les stories en temps contraint (comme les meetings du mercredi…) et catégoriser en: Mo: Must have (vital): doit être fait S: Should have (essentiel): à faire dans la mesure du possible Co: Could have (confort): pourrait être fait si cela n’impacte pas les autres tâches W: Won’t have (luxe) : pourrait être fait dans une version future Problème si le client place systématiquement en MUST de nouvelles features
Organisation et Logistique
Organisation L Ma Me J V S D #0 D Itération #1 Coaching É Entretiens spécifique M techniques Itération #2 O Sout Atelier Exceptionnellement démo jeudi matin Coaching suivant dispo du resp. de majeure
Toute communication avec le staff passe par le chan #si4-projet-janvier-ps7
Vous travaillez en équipe et dans l’école
Tenez à jour la liste de localisation (ref sur le slack)
Coaching Mardi - jeudi : Créneaux déterminés le matin en 0+106 Au début (mardi aprem, mercredi aprem, vendredi…) et ensuite à la demande -> dans vos salles
Homework
Delivery 06.01.20 12:59am 06.01.20 14:59am pour ceux qui sont en atelier à 10h Choix des 2 axes Publication par réponse au message slack correspondant
Projet kanban Repo git Vous êtes « admin » sur les repos Lien d’invitation Classroom sur le slack Nom de votre équipe à réutiliser (ex: AL-IHM1)
Configurer votre projet Github et les issues Automated Kanban Nouvelle issue automatiquement en Todo commit avec fix #21 ferme l’issue #21 Labels personnalisés pour story et priorisation MoSCoW Milestone pour sprint Story points dans la description des stories
8h30 Daily meeting avec le staff O+106 - 15 à 30 mins
1 membre par équipe
Itération #0: 06.01 ➤ 08.01 Stories ⊕ Constitution du Critères backlog dans github ⊕ Tests Planification Itération #1 74
Démo #0: 08 janvier Présentation du backlog à vos clients Acceptation ou rejet Discussions / Feedback Timebox: 30 mins 75
Itération #1: 09.01 ➤ 15.01 Rétrospective Version initiale Développement des stories Scénario Vidéo Planification Itération #2 76
Démo #1 : 15 janvier Présentation de la version actuelle du produit au client Acceptation ou rejet Discussions / Feedback Timebox: 30 mins 77
Itération #2: 16.01 ➤ 22.01 Rétrospective Version finale Développement des stories Vidéo de présentation 78
Démo #2 : 22 janvier Présentation de la version actuelle du produit au client Acceptation ou rejet Discussions / Feedback Timebox: 30 mins 79
Grand final 24.01 ➤26.01 Soutenance Rapport Factuel Présentation (12’) Synthétique Q & A (12’) Analytique 80
Evaluation (sujet à modification) Backlog + Vidéo (26.01 20h) 20% Rapport (25.01 20h) 40% Soutenance (24.01) 20% Technique (16 et 17.01) 20% 81
Présentation: Orientée "Valeur" Comment les axes choisis interagissent ? Quelles sont les fonctionnalités disponibles dans le produit ? Pourquoi sont-ils techniquement bien réalisés? 82
Rapport : Orienté "Science" Problématiques scientifiques des axes Analyse critique de votre solution Positionnement par rapport à 4 matières Problématique Réalisation Analyse 83
Repository: Orienté « Opérationnel" Projet GitHub à jour (passé, présent et futur) = sprints et backlog cohérents Repo Github à jour = tags des sprints, référence des commits aux issues, master propre 84
Signalez les problèmes ! photo : Damien Pollet
Common Ne pas poser de questions Pitfalls Ne pas demander d’aide Se focaliser trop sur les axes Se focaliser trop sur le centre du produit
Questions?
Dans la journée Let’s play!
Références & Remerciements • Sébastien Mosser !!! • "Il était une fois la vie d’un Product Owner", Romain Couturier, 10.2013 • https://www.youtube.com/watch?v=c0RZsewej88 • "Agile Estimating and Planning", Mike Cohn, 2005 • Communauté "Agile Playground Sophia Antipolis" (http://www.meetup.com/fr/Agile-Play-Ground/) • Communauté PO-Dojo, Atelier USTA, 2013, http://bit.ly/podojo • Discussions avec Mireille Blay-Fornarino, Guilhem Molines, Pierrick Perret, Anne-Marie Pinna-Déry, Pascal Poizat, Marc Rougé, Nicolas Verdot, Viviane Morelle, Jean-Michel Bruel, Jean-Marc Jézequel et Isabelle Blasquez. 89
Vous pouvez aussi lire