SCRUM AU QUOTIDIEN EN SSII Nicolas Hennion Fondateur d 06 29 95 14 53 nicolashennion@agileimpulse.com Support disponible sur agileimpulse.com/formation/scrumssii2j.pdf ( ) Il existe des projets informatiques qui se passent bien. Ces projets utilisent les méthodes Agiles. SCRUM est la plus populaire d entre elles. 2
A PROPOS! Nicolas Hennion 06 29 95 14 53! linkedin.com/in/nhennion!! nicolashennion@agileimpulse.com! Fondateur d ( conseil et formation) web entrepreneur : opportuner.com! blog : aucoudeacoude.typepad.com! 3 HORIZONS DU FORMATEUR Management visuel Management participatif Lean Gestion de projet classique Théorie des contraintes Lean startup Scrum Extreme Programming 4
5 PROGRAMME Introduction Etat d esprit Agile! Agilité vue d avion! Organisation personnelle! Limites du cycle en V! ADN : le manifeste Agile Scrum! Itérations! Rôles! Partager le besoin! Planification d un sprint + ateliers! + questions/réponses! + «not for us»! + pauses!! Lean software development! Alerte au buzz! Contractualisation Agile! Déroulement d un sprint! Clôture d un sprint! Environnement de travail! What else? Transition Agile Conclusion 6
PROGRAMME Introduction Etat d esprit Agile! Agilité vue d avion! Organisation personnelle! Limites du cycle en V! ADN : le manifeste Agile Scrum! Itérations! Rôles! Partager le besoin! Planification d un sprint! Lean software development! Alerte au buzz! Contractualisation Agile! Déroulement d un sprint! Clôture d un sprint! Environnement de travail! What else? Transition Agile Conclusion 7 L AGILITÉ, ÇA VOUS ÉVOQUE QUOI? Les bons côtés! Les limites! " # 8
AGILITÉ : ÇA PARLE DE QUOI?! Faire mieux, plus vite, avec les mêmes personnes.! Livrer souvent des produits fonctionnels à un interlocuteur capable de donner du feedback! Ecarter tout ce qui nous en empêche 9 AGILITÉ : LES TENDANCES Lean Scrum extreme Programming (Business) (Management) (qualité du code) 10
L AGILITÉ, ÇA PARLE DE QUOI? environnement de travail backlog product owner auto-organisation feedback équipe bon sens sprint scrum master intégration continue user stories extreme Programming post-it Scrum terminé confiance vélocité agilité revue de code Pair programming planning de sprint Test Driven Development stand-up meeting rétrospective revue de sprint tests automatiques 11 VOS MÉTHODES DE GESTION DE PROJET Ce qui vous plait! # # #3 post-its! " vs! Ce qui vous pèse! # # #3 post-its! # flickr.com/photos/flatcat/ 12
L AGILITÉ, ÇA VEUT RÉSOUDRE QUOI? côté développeurs côté chef de produit courbe de pression inconnues techniques modifications de périmètre bugs en production longueurs en amont manque de tests pompier effet tunnel cout d un bug dérapages en délais dérapages de coûts besoin d évolutions rapides livraison unique 13 manque de doc technique COÛT D UN BUG!!! 1000 flickr.com/photos/urtica/ 1 specs dev prod temps 14
PROGRAMME Introduction Etat d esprit Agile! Agilité vue d avion! Organisation personnelle! Limites du cycle en V! ADN : le manifeste Agile Scrum! Itérations! Rôles! Partager le besoin! Planification d un sprint! Lean software development! Alerte au buzz! Contractualisation Agile! Déroulement d un sprint! Clôture d un sprint! Environnement de travail! What else? Transition Agile Conclusion 15 ( Interruptions )! flickr.com/photos/-cavin-/ 16
LOI DE PARETO Valeur Ajoutée 80% 20% Temps 20% 80% 17 ADDICTIONS L email TUE l efficacité 18
ADDICTION MAIL! C est quoi votre fond d écran? Multi! tâches! 19 DÉSINTOXICATION! Désactivez le push mail sur votre ordinateur! Désactivez le push mail sur vote mobile! Dites à vos principaux expéditeurs :! «"Je ne regarde plus mes mails que 2 fois par jour pour me concentrer plus sur vos projets"»! Consultez votre boite mail à midi et à 17h! Fermez votre boite mail entre temps Objectif : 10 mails reçus par jour 20
ATELIER INTERRUPTIONS 1. Estimez le nombre d interruptions par jour :!! Nombre d emails reçus!! pour action!! pour information!! Nombre de coups de téléphones reçus!! Nombre de chats! 2. Listez les 3 personnes qui vous sollicitent le plus souvent.! 3. Proposez 3 réunions à cadence fixe pour canalyser ces interruptions.! 21 TODO LIST agileimpulse.com/formation/todo.xlsx Terminé le + prioritaire 22 le - prioritaire
TO-DO LIST PRIORISÉE! La priorité est relative! 1 seule liste / 1 seule colonne pour toutes mes tâches! Je suis le seul à écrire dedans! Partager ma todo = compliqué! Personne d autre n a besoin de la voir! Chaque nouvelle ligne entre à son niveau de priorité! J ai 5 minutes devant moi? je prends la tâche du haut! Quand une tâche est terminée : ok +données > trier! pas besoin de supprimer les lignes 23 téléchargez le fichier : agileimpulse.com/formation/todo.xlsx AVANT 10H! Avoir fait une action à forte valeur ajoutée avant 10h, tous les jours.! Lire ses mails n est pas une action à forte valeur ajoutée. 24
ANTI-INTERRUPTIONS : LA BASE! J identifie les 5 personnes qui génèrent le plus d interruptions dans ma journée! Je leur explique calmement le nombre d interruptions qu ils génèrent et le temps que ça me prend.! Nous nous mettons d accord sur une règle du jeu Bonnes pratiques! Un point systématique à jour/heure fixe de 5 minutes avec chaque personne! 2 à 3h par jour de black out mail et téléphone ( le matin) 25 ANTI-INTERRUPTIONS : LES FINITIONS! Je demande à mes voisins d activer leur messagerie vocale à plus de 2 sonneries! Je dis bonjour à la cantonade! Cartons jaunes aux plus bruyants 26
L ESSENTIEL : ANTI-INTERRUPTIONS! Faites savoir ce que ces interruptions vous coutent! Stand-ups cadencés avec les interlocuteurs récurrents! Consultez vos emails 2 fois par jour maximum! Utilisez votre répondeur téléphonique! Todo list priorisée! Une action à forte valeur ajoutée avant 10h! Black out 2h par jour! Réflexe management visuel 27 PROGRAMME Introduction Etat d esprit Agile! Agilité vue d avion! Organisation personnelle! Limites du cycle en V! ADN : le manifeste Agile Scrum! Itérations! Rôles! Partager le besoin! Planification d un sprint! Lean software development! Alerte au buzz! Contractualisation Agile! Déroulement d un sprint! Clôture d un sprint! Environnement de travail! What else? Transition Agile 28 Conclusion
CYCLE EN V 29 source : wikipedia Christophe Moustier ANALYSE DES BESOINS : PAR QUI? expert métier source : wikipedia Christophe Moustier utilisateur final 30
ANALYSE DES BESOINS : POUR QUAND? source : wikipedia Christophe Moustier flickr.com/photos/teachernz/ 31 SPÉCIFIER POUR DÉLIMITER! Impossible exhaustivité source : wikipedia Christophe Moustier 32
SPÉCIFIER POUR CONTRACTUALISER Trouver des financements! Le porte-à-faux de la MOA! Le juste besoin!!! + source : wikipedia Christophe Moustier Garantir un résultat! L assurance d un contrat! Que risque le porteur du projet? 33 flickr.com/photos/revdancatt/ SPÉCIFIER POUR COMMUNIQUER! Un mot pour un autre! Approche fonctionnelle ou objet? source : wikipedia Christophe Moustier 34
CONCEPTION ARCHITECTURALE! Quel besoin de souplesse pour un pont? source : wikipedia Christophe Moustier flickr.com/photos/alanenglish/ 35 CONCEPTION DÉTAILLÉE! Avoir fait le projet avant de commencer? source : wikipedia Christophe Moustier flickr.com/photos/paolorestifo/ 36
CODE 1/2! Le tunnel flickr.com/photos/robertosena/ flickr.com/photos/kh1234567890/! Pression, cocotte et soupape source : wikipedia Christophe Moustier 37 CODE 2/2! La petite fonctionnalité en plus La demande vs source : wikipedia Christophe Moustier Le livrable 38
TESTS! Plus le temps Le plan dev tests source : wikipedia Christophe Moustier La vraie vie dev tests 39 DOCUMENTATION! Plus du tout le temps il y a 6 mois, 14:01 dev tests doc Le plan dev tests La vraie vie 40
RECETTE! Qui fait la recette?! Le flux principal! et le reste 41 source : wikipedia Christophe Moustier DÉLAIS! Livré à l heure?! Mythe du planning! Macro chiffrage macro date? 42 source : wikipedia Christophe Moustier
COMITÉ DE PILOTAGE 43 AUTOUR DU PROJET! Qui est le responsable?! Indicateurs! Contractualisation! Evolutions et maintenance! Documentation 44
L AGILITÉ, ÇA VEUT RÉSOUDRE QUOI? côté développeurs côté marketing courbe de pression inconnues techniques modifications de périmètre bugs en production longueurs en amont manque de tests pompier effet tunnel cout d un bug dérapages en délais dérapages de coûts besoin d évolutions rapides livraison unique 45 manque de doc technique POURQUOI?! Pourquoi le cycle en V reste-t-il aussi présent?! Parce qu il est déjà là! Parce que tous les salariés sont formés comme ça?! Parce qu il dilue les responsabilités! Parce qu il donne une impression de contrôle 46
L ESSENTIEL : LIMITES DU CYCLE EN V! Le changement de besoin est vécu comme un problème! Effet tunnel! La petite étoile en plus! Délais impossibles à estimer et à tenir! Réduction mécanique du temps de tests et de documentation! Identification des problèmes trop tard! Pas assez de doc technique, trop de doc fonctionnelle! mais «"tout le monde fait comme ça"» 47 PROGRAMME Introduction Etat d esprit Agile! Agilité vue d avion! Organisation personnelle! Limites du cycle en V! ADN : le manifeste Agile Scrum! Itérations! Rôles! Partager le besoin! Planification d un sprint! Lean software development! Alerte au buzz! Contractualisation Agile! Déroulement d un sprint! Clôture d un sprint! Environnement de travail! What else? Transition Agile Conclusion 48
QUE SE PASSERAIT-IL si le «"client"» pouvait voir quelque chose avant la fin? 49 PRINCIPE #1 ( ) Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles 50
QUE SE PASSERAIT-IL si on donnait la possibilité au client de changer d avis? 51 PRINCIPE #2 ( ) Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client. 52
QUE SE PASSERAIT-IL Et si on livrait plus souvent? 53 PRINCIPE #3 ( ) Livrer fréquemment une application fonctionnelle avec une tendance pour la période la plus courte 54
QUE SE PASSERAIT-IL si le développeur et le client étaient dans le même bureau? 55 PRINCIPE #4 ( Les gens du métier et les développeurs doivent ) collaborer quotidiennement au projet 56
QUE SE PASSERAIT-IL si on faisait 100% confiance au développeur? 57 PRINCIPE #5 ( ) Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail 58
QUE SE PASSERAIT-IL si on se voyait pour en parler? 59 PRINCIPE #6 ( La méthode la plus efficace pour transmettre ) l'information est une conversation en face à face 60
QUE SE PASSERAIT-IL si on regardait plutôt ce qui a été fait que ce qui reste à faire? 61 PRINCIPE #7 ( Un logiciel fonctionnel est la meilleure unité de ) mesure de la progression du projet 62
QUE SE PASSERAIT-IL si on partait tous les jours à 18h? 63 PRINCIPE #8 ( ) Les processus agiles promeuvent un rythme de développement durable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment. 64
QUE SE PASSERAIT-IL si on codait à deux derrière le même écran? 65 PRINCIPE #9 ( Une attention continue à l'excellence technique ) et à la qualité de la conception améliore l'agilité. 66
QUE SE PASSERAIT-IL si on faisait tout pour en faire le moins possible? 67 PRINCIPE #10 ( La simplicité - l'art de maximiser la quantité de ) travail à ne pas faire - est essentielle. 68
QUE SE PASSERAIT-IL si on oubliait la hiérarchie dans l équipe? 69 PRINCIPE #11 ( Les meilleures architectures, spécifications et ) conceptions sont issues d'équipes qui s'auto-organisent. 70
QUE SE PASSERAIT-IL si on se regardait dans une glace? 71 PRINCIPE #12 ( ) À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens. 72
AGILE MANIFESTO 73 AGILE MANIFESTO www.agilemanifesto.org/ Priorité aux personnes et aux interactions plutôt qu aux processus, modèles et outils slideshare.net/vaidasa 74
AGILE MANIFESTO www.agilemanifesto.org/ Focus sur le logiciel à développer plutôt que sur la documentation slideshare.net/vaidasa 75 AGILE MANIFESTO www.agilemanifesto.org/ Collaboration avec le client plutôt que négociation et suivi du contrat 76
AGILE MANIFESTO www.agilemanifesto.org/ Réactivité au changement plutôt que le suivi d un planning initial flickr.com/photos/nationalzoo/ 77 L ESSENTIEL : ADN AGILE! Livrer souvent! Livrer utile! Simplicité! Parler! Prioriser! Engagement 78
PROGRAMME Introduction Etat d esprit Agile! Agilité vue d avion! Organisation personnelle! Limites du cycle en V! ADN : le manifeste Agile Scrum! Itérations! Rôles! Partager le besoin! Planification d un sprint! Lean software development! Alerte au buzz! Contractualisation Agile! Déroulement d un sprint! Clôture d un sprint! Environnement de travail! What else? Transition Agile Conclusion 79 PHILOSOPHIE LEAN Gaspillage! 80
VALEUR AJOUTÉE! Quelle est LA valeur ajoutée qui fera que ce produit sera utilisé? 81 MINIMUM VIABLE PRODUCT Lancer le plus vite possible le plus petit produit possible = MVP pour valider son hypothèse business 82
LEAN EN ACTION : SERVICES ASSOCIÉS À FREE MOBILE 83 DETTE = 84
L ESSENTIEL : LEAN SOFTWARE DEVELOPMENT! Quel plus petit produit possible (MVP)?! Impliquer les utilisateurs! Confronter le produit à la vraie vie! Pivoter! Simplifier le produit en permanence 85 PROGRAMME Introduction Etat d esprit Agile! Agilité vue d avion! Organisation personnelle! Limites du cycle en V! ADN : le manifeste Agile Scrum! Itérations! Rôles! Partager le besoin! Planification d un sprint! Lean software development! Alerte au buzz! Contractualisation Agile! Déroulement d un sprint! Clôture d un sprint! Environnement de travail! What else? Transition Agile 86 Conclusion
SIMPLE MAIS DIFFICILE! L Agilité c est sexy!! Personne ne préfère ouvertement les organisations rigides et procédurières! Scrum est simple car elle repose sur beaucoup de bon sens! Scrum est difficile car elle demande beaucoup de rigueur.! Ce ne sont pas les méthodes Agiles qui sont souples, ce sont les produits qu elles permettent de créer. 87 CE N EST PAS AGILE! Cow boy coding! Navigation à vue! Bourrage de planning! «"Pas de specs mais je poserai des questions"»! Lotissement par module On peut gagner de la vitesse à court terme. On gagne surement de la douleur à long terme... 88
PROGRAMME Introduction Etat d esprit Agile! Agilité vue d avion! Organisation personnelle! Limites du cycle en V! ADN : le manifeste Agile Scrum! Itérations! Rôles! Partager le besoin! Planification d un sprint! Lean software development! Alerte au buzz! Contractualisation Agile! Déroulement d un sprint! Clôture d un sprint! Environnement de travail! What else? Transition Agile 89 Conclusion ASSOUPLISSEZ LE CONTRAT! Peur de la régie vs rigidité du forfait! S engager sur un périmètre et une enveloppe! Ajouter une clause de modification de périmètre à isomacrochiffrage! Livrer très vite une première itération pour amorcer la confiance! Chiffrez juste : construisez le backlog dès l avant-vente!! Considérez les remises commerciales comme des dépenses marketing! La confiance fait signer plus d avenants que les incompréhensions 90
EDUQUEZ VOTRE AVANT-VENTE! Peu de commerciaux savent macro-chiffrer! Peu de commerciaux paient leurs erreurs d estimation! L Agilité commence en avant-vente! Les dates sont rarement fatidiques! Rien ne rassure plus un client que de voir le produit! Vendez la souplesse fonctionnelle! Ristournes : qui assume? 91 EDUQUEZ VOTRE CLIENT! Ne travaillez en Agile qu avec les clients en qui vous avez confiance! Peu de clients comprennent a priori les enjeux de l agilité! Eduquez-les / fixez les règles du jeu! Nous livrons souvent pour coller à votre besoin! Accompagnez-les! Rédaction des user stories, construction du backlog, etc! Donner le rythme! Sprints, réunions, etc! Identifiez les angoisses du client 92! Deadline?
L ESSENTIEL : CONTRACTUALISATION AGILE! Régie forfaitée! Détailler le besoin suffisamment pour macro chiffrer! Prioriser! Fixer l enveloppe budgétaire! Confronter le budget au besoin priorisé! Modifications de périmètre à iso budget par défaut! un besoin entre seulement si un autre sort de même chiffrage! Avenant sinon 93 PROGRAMME Introduction Etat d esprit Agile! Agilité vue d avion! Organisation personnelle! Limites du cycle en V! ADN : le manifeste Agile Scrum! Itérations! Rôles! Partager le besoin! Planification d un sprint! Lean software development! Alerte au buzz! Contractualisation Agile! Déroulement d un sprint! Clôture d un sprint! Environnement de travail! What else? Transition Agile 94 Conclusion
SCRUM?! Juste un framework de gestion de projet pour développer des logiciels! 95 SCRUM? 96
COMMUNAUTÉ 97 COMMUNAUTÉ 98
SCRUM EN 1 SLIDE 2 99 PROGRAMME Introduction Etat d esprit Agile! Agilité vue d avion! Organisation personnelle! Limites du cycle en V! ADN : le manifeste Agile Scrum! Itérations! Rôles! Partager le besoin! Planification d un sprint! Lean software development! Alerte au buzz! Contractualisation Agile! Déroulement d un sprint! Clôture d un sprint! Environnement de travail! What else? Transition Agile Conclusion 100
ROUE DE DEMING Feedback Planifier Tester Réaliser 101 ROUE DE DEMING : PROJET CLASSIQUE Planifier Temps Réaliser Tester Feedback 102
ROUE DE DEMING : PROJET AGILE Temps Planifier Réaliser Tester Feedback = une itération 103 ITÉRATIONS Temps Livraison Livraison Livraison Livraison Livraison Changement Changement Changement Changement 104
SPRINT! = Une itération! Juste taille en travail à faire! Time box : toujours la même durée RELEASE! Ensemble de quelque sprints! +/- = une «"version"» dans les méthodes classiques 105 LE MAUVAIS SPRINT! Pas «"durable"» : soir et/ou WE! Plein à craquer! Non priorisé! Plein de surprises! 2 mois! +2 j pour avoir le temps de terminer 106
LE BON SPRINT! Pas de durée type : faites votre expérience! Commencez par 2 semaines! Suffisamment long pour avoir un sens fonctionnel! Suffisamment court pour être planifiable de façon réaliste! Toujours la même durée pour cadencer les réunions ( ) Les processus agiles promeuvent un rythme de développement durable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment. 107 L ESSENTIEL : ITÉRATIONS! Planifier > réaliser > tester > feedback! Time box = durée fixe! Ad vitam aeternam! 3 à 5 sprints = 1 release 108
PROGRAMME Introduction Etat d esprit Agile! Agilité vue d avion! Organisation personnelle! Limites du cycle en V! ADN : le manifeste Agile Scrum! Itérations! Rôles! Partager le besoin! Planification d un sprint! Lean software development! Alerte au buzz! Contractualisation Agile! Déroulement d un sprint! Clôture d un sprint! Environnement de travail! What else? Transition Agile 109 Conclusion EVOLUTION DES RÔLES : CHEF DE PROJET?! Fonctionnel! MOA! MOE! Technique!! Cadrer le besoin! Distribuer les tâches! Relais du besoin fonctionnel! Reporting! Contrôle hiérarchique 110
LES ROLES : PRODUCT OWNER! = le client! Responsable de la valeur du projet 111 LES ROLES : L ÉQUIPE! s organise pour livrer au client un produit utile 112
LES ROLES : SCRUM MASTER! S assure que l équipe est fonctionnelle et productive : 1. Protège l équipe des perturbations extérieures 2. Facilite la résolution de problèmes dans l équipe + 113 EQUIPE : DES RÔLES QUI ÉVOLUENT, DES RÔLES À FAIRE TOURNER Parrain! Graphiste! Dev! Testeur + Lead dev Ambassadeur Intégrateur HTML Scrum master Facilitateur/Garant Scrum «"Cadreur"» fonctionnel Bloggeur? Testeur backup Quality Assurance Garant Méthodes XP 114
LES BONS ET LES TRUANDS! Product Owner! Scrum Master! Equipe 115 LE PIRE PRODUCT OWNER! Une girouette! Un parapluie! «"Je vais demander l autorisation "»! Trop minutieux! Deux personnes! N a jamais le temps! Laisse l équipe écrire le backlog à sa place! Laisse l équipe prioriser le backlog à sa place 116
LE MEILLEUR PRODUCT OWNER! Dort avec les développeurs! Sait expliquer ce qu il veut! Comprend les enjeux de ce que fait l équipe technique! Sait trancher! Sait prioriser 117 CA EXISTE EN VRAI : PIVOTAL LABS slidesha.re/pivotal-nh 118
LE PIRE SCRUM MASTER! Laisse les ressources quitter le projet! Craint de s imposer face à l extérieur! Craint de dire les choses en face en interne! Use de son pouvoir hiérarchique quand il en a un! Propose systématiquement les solutions! Pense que sans son énergie, pas de Scrum.! Se voit au-dessus de l équipe 119 LE BON SCRUM MASTER! Aide l équipe à trouver elle même les solutions à ses problèmes d organisation! Prend le rôle d un coach : facilite, sans couver ni décider! Est diplomate : il sait faire avancer les individus quand le groupe piétine! Enonce les problèmes mais se retient de proposer ses solutions immédiatement! Laisse l équipe faire ses propres erreurs! Veille à la priorisation permanente du backlog par le product owner sous l angle de la valeur ajoutée.! Veille à l efficacité des réunions Scrum 120
LA PIRE ÉQUIPE! Fait plus de 7-8 personnes! Attend qu on lui dise quoi faire! Remplit les placards de cadavres! Ne parle pas au product owner! Travaille tard! Dit oui à tout! Ecrit une ligne de plus que ce dont il y aurait besoin! Pense que Scrum se mettra en place malgré elle 121 LA BONNE ÉQUIPE! 4-5 personnes idéalement! A le sourire, parce qu elle le vaut bien! N a pas de cernes sous les yeux! Sait éduquer son product owner! Ne s intéresse pas qu au code! En fait le moins possible! N improvise que quand elle maitrise! N attend pas l énergie d un Scrum master pour avancer ( Une attention continue à l'excellence technique et à la qualité ) de la conception améliore l'agilité. 122
ATELIER RÔLE Par binôme, avant de partager avec le groupe! Identifiez deux personnes dans votre entreprise que vous verriez product owner! Pour chacun d eux :!! trouvez deux de ses qualités pour ce rôle!! trouvez deux points à travailler! Identifiez deux personnes dans votre entreprise que vous verriez ScrumMaster! Pour chacun d eux :!! trouvez deux de ses qualités pour ce rôle!! trouvez deux points à travailler! 123 ATELIER RÔLE Par binôme, avant de partager avec le groupe! Qui vous semble le plus à l aise dans quel rôle?!! 1 cadreur fonctionnel!! 1 scrum master!! 1 quality assurance!! 1 lead dev!! 1 testeur de backup!! 1 intégrateur!! 1 parrain des nouvelles recrues!! 1 ambassadeur extérieur! 124
L ESSENTIEL : RÔLES! Product owner : LE garant de la valeur business! Equipe : s engage face au product owner! Pas de «"chef de projet"»! Plusieurs rôles à se distribuer! Scrum master : garant de la méthode! Faire tourner les rôles dans l équipe 125 PROGRAMME Introduction Etat d esprit Agile! Agilité vue d avion! Organisation personnelle! Limites du cycle en V! ADN : le manifeste Agile Scrum! Itérations! Rôles! Partager le besoin! Planification d un sprint! Lean software development! Alerte au buzz! Contractualisation Agile! Déroulement d un sprint! Clôture d un sprint! Environnement de travail! What else? Transition Agile 126 Conclusion
ELABORATION DU BACKLOG DE PRODUIT 2 127 BACKLOG DE PRODUIT! Le backlog de produit est la liste priorisée de tout le travail à faire par l équipe :! exigences fonctionnelles du product owner! tâches techniques! corrections de bugs! Les exigences fonctionnelles sont des fragments de parcours utilisateurs priorisés en fonction de leur valeur ajoutée! Le backlog appartient au product owner 128
BACKLOG DE PRODUIT! stories fonctionnelles! stories techniques! bugs! + animation 129 UTILISATEURS/PERSONAS! Qui va utiliser l application?! Utilisateurs front, admin contenu et admin général! Cœurs de cible? cas particuliers?! Le product owner identifie les catégories! Le product owner identifie un vrai représentant de chacune de ces catégories! Le product owner fait intervenir ces représentants et tester le produit le plus tôt possible! 130
USER STORY En tant que, je fais pour En tant que client, j entre mon identifiant paypal pour payer mon panier 131 LA PIRE USER STORY! Représente plus de 5 jours de travail! Ne dit pas son utilisateur! Correspond à un module! Ne dit pas ses limites, ses cas de contrôle, etc.! Contient des mots parasites : le user «"peut"», «"doit pouvoir"», «"devra avoir la possibilité de"» LA MEILLEURE USER STORY! De 0,5j à 3 j de travail! tient en une ligne 132
LES YEUX DANS LES YEUX!! flickr.com/photos/knowhim/ flickr.com/photos/your_teacher/ 133 PARTAGER LE BESOIN : MÉTHODE Lister (tous) les différents types d utilisateurs du produit Dérouler (tous) les parcours de chacun de ces utilisateurs Prioriser les fragments de parcours les uns par rapport aux autres Ajouter les tâches techniques 134 ( serveurs, flux, etc)
PARTAGER LE BESOIN 135 BACKLOG DE PRODUIT : EXEMPLE! le product owner déroule les parcours par type utilisateur! Je suis product owner d une boutique type Vente-Privée à réaliser! J ai un premier fournisseur de hamacs (modèle unique) prêt à utiliser la plateforme! J ai un second fournisseur de hamacs (différentes tailles et coloris) en attente de signature pour le mois suivant! J ai un grosse opération de com planifiée dans 7 jours! Mon équipe de dév peut commencer aujourd hui! Elle me propose de faire des sprints d une journée 136
BACKLOG DE PRODUIT : EXEMPLE! le product owner déroule les parcours par type utilisateur 137 BACKLOG DE PRODUIT : EXEMPLE! le product owner priorise les stories 138
LE PIRE BACKLOG DE PRODUIT! est un document word! N utilise qu une vision modulaire et pas de parcours utilisateur! 5 lignes, ou 5000 lignes! Affiche des priorités absolues ( 1, 2, 3)! Se contente de maquettes Photoshop! est historisé/versionné en permanence! est entretenu par plusieurs personnes 139 LE MEILLEUR BACKLOG DE PRODUIT! est assez détaillé sur la partie haute pour pouvoir commencer à réaliser! est juste assez détaillé sur la partie basse pour macro-chiffrer le projet et pour anticiper la conception! contient les stories fonctionnelles ET techniques! est partagé dès que possible depuis l équipe jusqu aux utilisateurs finaux 140
GRANULARITÉ? VS flickr.com/photos/partage2photos/ 141 DESSINEZ!!! balsamiq.com 142
ATELIER RECUEIL DES BESOINS! Choisissez un projet de votre environnement!! Choisissez un product owner!! Choisissez un scrum master!! étape 1 : Qui sont les utilisateurs du produit?!! étape 2 : Quels sont les parcours des différents utilisateurs? 1 post-it par user story!! étape 3 : Classez les stories de la plus prioritaire à la moins prioritaire!! étape 4 : ajoutez les principales stories techniques! 143 L ESSENTIEL : PARTAGER LE BESOIN! Backlog : liste des besoins, priorisée à outrance! Users stories : parcours utilisateurs! Le backlog appartient au Product Owner! Stories fonctionnelles, techniques et bugs! Oublier la vision écran ou module! Détailler le plus tard possible, au niveau opportun 144
PROGRAMME Introduction Etat d esprit Agile! Agilité vue d avion! Organisation personnelle! Limites du cycle en V! ADN : le manifeste Agile Scrum! Itérations! Rôles! Partager le besoin! Planification d un sprint! Lean software development! Alerte au buzz! Contractualisation Agile! Déroulement d un sprint! Clôture d un sprint! Environnement de travail! What else? Transition Agile Conclusion 145 PLANNING?! Quelles sont les dates non modifiables?! Quel sont leurs enjeux?! Quelle sont les priorités d ici là?! Quand aura-t-on tout terminé? " sprint 1 nov " sprint 1 nov " sprint 1 " sprint 2 " sprint 3 " sprint 4 " sprint 5 dec jan " sprint 2 " sprint 3 salon ecommerce " sprint 4 " sprint 5 dec jan " sprint 2 " sprint 3 = RELEASE salon ecommerce " sprint 4 " sprint 5 " sprint 6 " sprint 7 fév " sprint 6 " sprint 7 fév " sprint 6 " sprint 7 = RELEASE " sprint 8 " sprint 9 mars " sprint 8 " sprint 9 mars " sprint 8 " sprint 9 146 " sprint 10 " sprint 10 " sprint 10 = RELEASE
CONCEPTION ARCHITECTURALE Vision claire du product owner + Dialogues intensifs en début de projet = Conception de grande qualité du premier coup! Pas de technique agile spécifique! Pas de miracle non plus! 147 PLANIFICATION D UN SPRINT 2 148
«"MEETINGS ARE TOXIC"»! Durée, horaires! Si vous n avez rien à y faire, sortez, et vite!! Préparation?.ppt?! Smartphone/ordinateur? RÉUNION AGILE?! Dates cadencées sur tout le projet! Ordre du jour général identique! Un minuteur surveillé de près (mi-temps)! Dérouler la réunion selon les priorités! ROTI ( Return on Time Investment) ROTI : quelle valeur ajoutée avezvous retiré par rapport au temps passé dans cette réunion? 149 BACKLOG DE PRODUIT VS BACKLOG DE SPRINT Backlog de produit Backlog de sprint 150
BACKLOG DE SPRINT! 3 à 5 stories/sprint/personne! dans le haut du backlog produit! stories fonctionnelles et techniques! correction de bugs 151 SIGNIFICATION DE «"TERMINÉ"»! «"Ca, c est terminé "»! C est le terme le plus flou sur un projet informatique A préciser dès le début du projet! Ca marche sur ma machine Documentation dans le code Tests unitaires Revue de code Tests d intégration Tests de charge Documentation technique 152
PRIORISER LES STORIES : EFFORT ET VALEUR AJOUTÉE 153 ESTIMER L EFFORT! Ancienne méthode! évaluer les stories en jours! évaluer les tâches en heures! Plus réaliste! évaluer les stories en difficulté relative ( poids)! compter le nombre de tâches 154
ESTIMER L EFFORT! Suite de Fibonacci 1 2 3 5 8 13 21 34 155 ESTIMER L EFFORT : PLANNING POKER bit.ly/pokercards 156
PLANNING POKER : ENJEUX ET CADENCE! Vision instantanée du niveau de consensus, par le product owner et par l équipe! Mise en lumière très rapide des stories à risque! Engagement de chacun sur son futur travail! L équipe et le product owner regardent en détail l équivalent de 2 sprints de stories! Un participant cadence le vote : il relit la story, puis toute l équipe vote en même temps! On ne perd pas de temps sur les stories consensuelles! Dans le doute, on prend le haut de la moyenne. 157 PLANNING DE SPRINT! L équipe se retrouve avec le product owner pour fixer le backlog du sprint à venir! Quels sont les derniers changements du backlog?! Que racontent les stories du haut du backlog?! Quelles sont leurs limites? leurs cas de tests?! Pourquoi faut-il les faire?! Quelle est leur valeur ajoutée?! Pourquoi sont-elles prioritaires?! Quelle est leur difficulté technique? ( planning poker) 158