Fondateur d Agile Impulse [email protected]. Support disponible sur agileimpulse.com/formation/scrumssii2j.

Transcription

1 SCRUM AU QUOTIDIEN EN SSII Nicolas Hennion Fondateur d [email protected] 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

2 A PROPOS! Nicolas Hennion ! linkedin.com/in/nhennion!! 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

3 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

4 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

5 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

6 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

7 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

8 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

9 LOI DE PARETO Valeur Ajoutée 80% 20% Temps 20% 80% 17 ADDICTIONS L TUE l efficacité 18

10 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

11 ATELIER INTERRUPTIONS 1. Estimez le nombre d interruptions par jour :!! Nombre d s 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

12 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

13 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

14 L ESSENTIEL : ANTI-INTERRUPTIONS! Faites savoir ce que ces interruptions vous coutent! Stand-ups cadencés avec les interlocuteurs récurrents! Consultez vos s 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

15 CYCLE EN V 29 source : wikipedia Christophe Moustier ANALYSE DES BESOINS : PAR QUI? expert métier source : wikipedia Christophe Moustier utilisateur final 30

16 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

17 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

18 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

19 CODE 1/2! Le tunnel flickr.com/photos/robertosena/ flickr.com/photos/kh /! 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

20 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

21 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

22 COMITÉ DE PILOTAGE 43 AUTOUR DU PROJET! Qui est le responsable?! Indicateurs! Contractualisation! Evolutions et maintenance! Documentation 44

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 AGILE MANIFESTO 73 AGILE MANIFESTO Priorité aux personnes et aux interactions plutôt qu aux processus, modèles et outils slideshare.net/vaidasa 74

38 AGILE MANIFESTO Focus sur le logiciel à développer plutôt que sur la documentation slideshare.net/vaidasa 75 AGILE MANIFESTO Collaboration avec le client plutôt que négociation et suivi du contrat 76

39 AGILE MANIFESTO 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

40 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

41 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

42 LEAN EN ACTION : SERVICES ASSOCIÉS À FREE MOBILE 83 DETTE = 84

43 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

44 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

45 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

46 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?

47 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

48 SCRUM?! Juste un framework de gestion de projet pour développer des logiciels! 95 SCRUM? 96

49 COMMUNAUTÉ 97 COMMUNAUTÉ 98

50 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

51 ROUE DE DEMING Feedback Planifier Tester Réaliser 101 ROUE DE DEMING : PROJET CLASSIQUE Planifier Temps Réaliser Tester Feedback 102

52 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

53 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

54 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

55 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

56 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

57 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 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

58 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

59 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

60 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

61 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

62 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

63 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

64 ELABORATION DU BACKLOG DE PRODUIT 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

65 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

66 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

67 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)

68 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

69 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

70 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

71 GRANULARITÉ? VS flickr.com/photos/partage2photos/ 141 DESSINEZ!!! balsamiq.com 142

72 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

73 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 " sprint 10 " sprint 10 " sprint 10 = RELEASE

74 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

75 «"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

76 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

77 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

78 ESTIMER L EFFORT! Suite de Fibonacci ESTIMER L EFFORT : PLANNING POKER bit.ly/pokercards 156

79 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

80 LE PIRE DU SPRINT PLANNING! Le product owner n est pas là ou arrive en retard! product owner pas clair sur son besoin ou ses priorités! product owner a élaboré son besoin tout seul dans son bureau! Le product owner a produit trop ou trop peu de user stories! Les user stories ne tiennent pas l échange 159 LE MEILLEUR DU SPRINT PLANNING! L équipe harcèle le product owner de questions! L équipe joue le jeu du planning poker et est transparente sur l ampleur de son incertitude! L équipe dit «"plus tard"» au moins une fois! La réunion commence et termine à l heure ( ) La méthode la plus efficace pour transmettre l'information est une conversation en face à face 160

81 UNE ÉQUIPE, PLUSIEURS PROJETS tâche projet 1 tâche projet 1 tâche projet 1 tâche projet 1! Alterner les sprints tâche projet 1 tâche projet 1 tâche projet 1 tâche projet 1 tâche projet 1! tâche projet 2 tâche projet 2 tâche projet 1 tâche projet 1 tâche projet 2 tâche projet 2 tâche projet 2 tâche projet 2 tâche projet 2 tâche projet 2 tâche projet 2! Mélanger les sprints tâche projet 1 tâche projet 2 tâche projet 2 tâche projet 1 tâche projet 2 tâche projet L ESSENTIEL : PLANIFICATION D UN SPRINT! Planification macro! Réunion de planning de sprint! Minuteur, ROTI! Planning poker! Engagement de l équipe! Backlog de sprint! Chacun a le devoir de challenger le besoin 162

82 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 163 PENDANT LE SPRINT 2 164

83 TACHES! 4 ou 5 tâches par story! 1 tâche = quelques heures de travail! tâches de tests! tâches de code! tâches de doc technique 165 LE TABLEAU! visualiser le projet en un coup d œil! Utilisable par tous! 166

84 LE TABLEAU DE SUIVI A FAIRE En cours Terminé! Stories Tâches En tant que Code Doc Code Code Code 8 Remi Jean Jean Test intégration Test intégration Test unitaire Test unitaire Test unitaire Flo Nico Jean En tant que Code Code 5 Remi Test Doc Code Flo Flo Interfacer Code Test 3 Remi 167 LE TABLEAU DE SUIVI ( VARIANTE) A FAIRE En cours Terminé! Stories Tâches Intégration En tant que Code Doc Code Code Code 8 Remi Jean Jean Test intégration Test intégration Test unitaire Test unitaire Test unitaire Flo Nico Jean En tant que Code Code 5 Remi Test Doc Code Flo Flo Interfacer Code Test 3 Remi 168

85 VARIANTE TMA PLANIFICATION VISUELLE KANBAN 1/3! Votre succession de tâches est une ligne de production to do code test unitaire recette doc terminé! Objectif : enchainer les tâches au plus tôt 169 VARIANTE TMA PLANIFICATION VISUELLE KANBAN 2/3! Votre succession de tâches est une ligne de production to do code test unitaire recette doc terminé ok ok ok ok! Chacun pioche dans le stock de tâches précédent 170

86 VARIANTE TMA PLANIFICATION VISUELLE KANBAN 3/3! Limiter l en cours pour ne pas noyer les acteurs successifs to do code test unitaire recette doc terminé ok ok ok 3 ok 171 PLANIFICATION VISUELLE KANBAN : RÈGLES DU JEU! Une colonne par tâche de votre définition de «"terminé"»! L outil permet d enchainer les tâches au plus tôt sans besoin de coordinateur! Le client peut changer l ordre des tickets de la colonne todo à tout moment! Une fois lancé, un ticket parcourt la chaine au plus vite! Voie rapide : ticket de couleur à traiter en haut de chaque colonne ( bug bloquant, etc)! Mise à jour par chaque acteur! Visuel : tout le monde sait ce qu il se passe instantanément! Limitez la taille de chaque colonne pour réduire le temps de cycle d un ticket! Le tableau est un excellent support de réunion quotidienne 172

87 QUI FAIT QUOI DANS L ÉQUIPE? Auto-organisation!! Chaque membre de l équipe choisit les tâches qu il souhaite réaliser! Si certaines tâches restent au bout du compte, l équipe se les répartit. 173 TESTS & BUGS! Ecrire les tests dès le début du projet! Prévoir du temps dans le sprint pour corriger les bugs! Corriger les tests à l intérieur du sprint! Automatiser les tests autant que possible! test unitaires! tests d intégration! Intégration continue flickr.com/photos/urtica/ 174

88 DOCUMENTATION & ÉCRIT! Juste documentation = juste mémoire pour le projet! Maintenant, ou jamais.! Trop peu de documentation technique! Beaucoup trop de documentation fonctionnelle 175 BURN DOWN CHART! visualiser en un coup d œil le déroulement du sprint! un pour le sprint (et un pour la release) 176

89 BURN DOWN CHART 177 BURN DOWN CHART!"#$%&' H40B6I2#:J)03 D/0123#'#N#B4#%-L%'#)4#<%L%' %;' %''?' A' ;' ' %-L%'L%% %?L%'L%% %,L%'L%% ;'L%'L%% ;%L%'L%% ;AL%'L%% ;>L%'L%% ;-L%'L%% ;?L%'L%% <%L%'L%% H40B6I2#3JF601K4+#L#5640 H40B6I2#/G)21M1F#L#0+&&640:+& (61B&#363)G#3+0E12F (61B&#B+&#CD#3+0E12F+&#:+#5640 H402B6I2#0F+G!"#$%#&'"()*+,&-,-./(01&'&02#*+32454&0#&0#$% : ; < = >? 7@ 77!"#C3+)-#D 77.&/0123#&40#%%#5640&7 7=A7@A77 7>A7@A77 7?A7@A77 8@A7@A77 87A7@A77 8:A7@A77 8;A7@A77 8<A7@A77 8=A7@A77 8>A7@A77 97A7@A77 89#0+&&640:+& ' ; ; <=> < < < < < ; < %2(EE40F#D >9B H40B6I2#3JF601K4+#L#5640,-?- >? A, <, ;, %, %' ' H40B6I2#/G)21M1F#L#0+&&640:+&,-,%?A >< AA <A ;A %?? (61B&#B+&#CD#3+0E12F+&#:+#5640 ' %> %> %> %> %> %> %>./(01&'&02#D 7;B H402B6I2#0F+G,-,%,%???;?;?;?;?;?;?; G.H#$%#D <= 178 ()*+#%

90 SCRUM QUOTIDIEN / STANDUP MEETING! L équipe se retrouve chaque jour pour partager les avancées et les problèmes, et évacuer un maximum des interruptions potentielles de la journée.! Les avancées de la veille! Qui a un problème?! Qui peut aider?! Qui travaille sur quoi aujourd hui?! Quelles «"breaking news"» sur le projet? 179 LE PIRE DU SCRUM QUOTIDIEN! La réunion dure une heure.! On entend souvent «"il faudrait"».! Les problèmes persistent pendant plusieurs Scrum quotidiens! Pas de réponse claire sur un membre de l équipe qui appelle à l aide.! Il manque un membre de l équipe 180

91 LE MEILLEUR DU SCRUM QUOTIDIEN! Réunion debout.! 15 minutes suffisent largement! Ce qu on va faire aujourd hui! Qui a besoin de quoi? anti-interruptions pour le reste de la journée! Focus 181 CA EXISTE EN VRAI : PIVOTAL LABS slidesha.re/pivotal-nh 182

92 CA EXISTE EN VRAI : PIVOTAL LABS slidesha.re/pivotal-nh 183 CA EXISTE EN VRAI : PIVOTAL LABS slidesha.re/pivotal-nh 184

93 OUTILS INFORMATIQUES : BACKLOG MINIMALISTE! Listing en priorités relatives! Commentaires! Story fonctionnelle/bug/technique! Tags! Poids 185 OUTILS INFORMATIQUES : BACKLOG MINIMALISTE 186

94 L ESSENTIEL : DÉROULEMENT D UN SPRINT! Tableau de suivi! Auto-organisation : je choisis mes tâches! Burn down chart : caméra de surveillance! Stand up : évacuation des interruptions de la journée! Informatisation minimaliste : Pivotal Tracker! Que signifie «"terminé"»? 187 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 188 Conclusion

95 FIN DE SPRINT REVUE DE SPRINT! L équipe retrouve le product owner pour lui expliquer ce qui a été livré à l issue du sprint! C est la démo!! Voilà ce que l équipe a terminé! Regardez, ça marche.! Qu en pensez-vous? Feedback!!!! Mise à jour du backlog en live 190

96 LE PIRE DE LA REVUE DE SPRINT! «"Désolé, mais finalement "»! «"Nous manquons de ressources"»! «"Exceptionnellement, on a eu moins de temps pour les tests"»! «"Mais pourtant ça marchait ce matin sur ma machine"»! PO : «"je n ai pas le temps de tester maintenant"» 191 LE MEILLEUR DE LA REVUE DE SPRINT! Ne pas cacher les problèmes rencontrés, même si ils sont résolus! Montrer au product owner de quoi l équipe est fière! Réexpliquer le fonctionnement des stories mises en place! Réexpliquer les tests effectués, et ceux qui n ont pas été faits! Délimiter les risques de régression ( Un logiciel fonctionnel est la meilleure unité de mesure de la ) progression du projet 192

97 LA VÉLOCITÉ! C est l effort produit par l équipe pendant les différents sprints! Utilisable par l équipe, pour améliorer ses prévisions Bugs Stories techniques Stories fonctionnelles RÉTROSPECTIVE DE SPRINT! L équipe se retrouve pour voir comment améliorer son efficacité! Engagement tenu?! Qu est-ce qui nous gêne?! Qu est-ce qui nous aide?! Comment aller plus vite?! Comment en faire moins?! Comment perdre moins de temps?! Trouver les causes racines : Pourquoi? Pourquoi? Pourquoi? Pourquoi? Pourquoi? 194

98 TRAME DE RÉTROSPECTIVE : EXEMPLE! 30 minutes de réunion! Chacun propose des sujets!? / on / + / - / off! 5 minutes de préparation en silence! 1 sujet par post-it! Je lis, je colle : pas de débat! 10 votes par personne (feutre), sans débat! Retenir les 2-3 sujets les plus votés! Trouver ensemble :! soit une amélioration par sujet : simple et accessible! soit un outil visuel pour mesurer le problème! Mettre en place immédiatement 195 LE PIRE DE LA RÉTROSPECTIVE DE SPRINT! Fataliste : «"c est toujours comme ça"»! «"C est pas not faute "»! yaka-fokon à répétition! Un membre de l équipe est absent 196

99 LE MEILLEUR DE LA RÉTROSPECTIVE DE SPRINT! «"Désolé, j ai merdé "»! Améliorer l environnement! Concrètement, qu est-ce qu on change à la fin de la réunion?! Changer peu, mais changer réellement ( Les meilleures architectures, spécifications et conceptions sont ) issues d'équipes qui s'auto-organisent. ( À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus ) efficace, puis accorde et ajuste son comportement dans ce sens. 197 SCRUM EN 1 SLIDE 2 198

100 ATELIER SPRINTS! Désignez un scrum master!! Vous avez 2 sprints!! Réalisez le projet proposé!! Timing!! Cadrage : 4 min!! Planning : 4 min!! Sprint : 4 min!! Revue : 3 min!! Retro : 3 min! 199 ATELIER RÉTROSPECTIVE! choisissez un thème!! 4 minutes pour que chacun liste ses idées d amélioration!!? / ON /+ / - / OFF!! 1 idée par postit!! en lettres capitales!!! 4 minutes pour les afficher!! 2 minutes pour voter!! 10 minutes pour fixer 3 actions concrètes sur les deux sujets les plus votés!?! ON! +! -! OFF! Se mettre d accord sur! Commencer à! Faire plus! Faire moins.! Arrêter de! 200

101 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 201 ENVIRONNEMENT DE TRAVAIL slidesha.re/pivotal-nh 202

102 ENVIRONNEMENT DE TRAVAIL slidesha.re/pivotal-nh 203 ENVIRONNEMENT DE TRAVAIL slidesha.re/pivotal-nh 204

103 LA SALLE DE TRAVAIL! Ensemble! War room! Le lieu clef, ce sont les bureaux de l équipe, pas ceux du product owner! Détente oui, mais pas de parasitage sur le plateau! Utilisez les murs!! L administration technique ne doit pas être un problème ( Saas autant que possible) 205 PRESSION? CONTRÔLE?! Pression des pairs plus que pression d un chef! Chacun choisit son engagement! Chacun s engage devant les autres! Chacun connaît et assume sa valeur et celle des autres 206

104 L ESSENTIEL : ENVIRONNEMENT DE TRAVAIL! Rythme durable! L environnement de travail compte! Chacun donne son avis sur les outils utilisés.! Utilisez les murs! La pression des pairs est bien plus efficace que celle d un chef 207 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 208 Conclusion

105 INDICATEURS! Vélocité! Burndown chart de sprint et de release! C est tout 209 ( ITÉRATION ZÉRO )! Mettre en place le framework du projet! Peu ou pas de valeur fonctionnelle! sprint à part, ou stories techniques à intégrer petit à petit 210

106 ( AMÉLIORER LE CODE ) 211 PAIR PROGRAMMING! 2 développeurs travaillent ensemble sur le même code! Inconvénients! Ca semble coûter deux fois plus cher! Avantages! Conception et analyse fonctionnelle! Qualité du code! Mémoire fonctionnelle et technique du produit! Montée en compétence! Evaluation de recrutement! Concentration!! Testez-le sur des fonctionnalités critiques! 212

107 CA EXISTE EN VRAI : PIVOTAL LABS slidesha.re/pivotal-nh 213 CA EXISTE EN VRAI : PIVOTAL LABS slidesha.re/pivotal-nh 214

108 PRATIQUES EXTREME PROGRAMMING! Test Driven Development! Intégration continue! Tests automatisés! Fier d être geek 215 INTÉGRATION CONTINUE slidesha.re/pivotal-nh 216

109 INTÉGRATION CONTINUE slidesha.re/pivotal-nh 217 FIER D ÊTRE UN GEEK slidesha.re/pivotal-nh 218

110 ( /AMÉLIORER LE CODE ) 219 L ESSENTIEL : EXTREME PROGRAMMING! Revue de code! Pair programming! Test Driven Development! Intégration continue! Tests automatisés 220

111 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 221 ATELIER MISE EN PLACE Par binôme, avant d échanger avec le groupe!! Quelles sont les 3 pratiques les plus faciles à mettre en place dans notre entreprise?! # # # # # # #3 post-its!! Quelles sont les 3 plus difficiles?! # # # # # # #3 post-its!! Quels sont les 2 principaux atouts de notre entreprise dans la mise en place de l agilité?! # # # # # # #2 post-its!! Quelles sont les 2 principales faiblesses?! # # # # # # #2 post-its! 222

112 RÉCAPITULATIF DES OUTILS AGILES diminution des interruptions environnement de travail backlog Plus petit produit possible terminé product owner scrum master user stories auto-répartition des tâches vélocité burn down chart tableau de suivi de sprint intégration continue planning poker sprint planning de sprint stand-up meeting rétrospective revue de sprint Pair programming revue de code Test Driven Development tests automatiques 223 TARIF RÉDUIT? Attention aux équipes qui «"font leur marché"» dans le pool d outils!! un bon moyen pour faire échouer des projets! un bon moyen pour éviter de poser les questions qui fâchent! un bon moyen pour continuer à livrer en retard des produits peu utilisables.! un bon moyen pour enterrer définitivement l agilité 224

113 CONDUITE DU CHANGEMENT Ne sous-estimez pas les freins!! Les posts-its ne font pas tout! Egos en sourdine le temps de se caler! Identifier le projet pilote! Pas planté d avance! Pas déjà en retard! Pas qu avec des stagiaires! Faites intervenir un coach (2 à 5j)! Utilisez les méthodes agiles pour passer à l Agile! 225 A QUOI SERT UN COACH AGILE?! Faciliter la mise en place des outils, dans le respect de l état d esprit agile! Partager les droits et les devoirs de chacun! Initier le backlog! Amorcer la confiance dans la méthode! Amorcer la confiance entre les acteurs! Contenir les «"torpilleurs"»! Tenir le cap à la fin de «"l état de grâce"» 226

114 L ESSENTIEL : TRANSITION AGILE! Le bon sens n est pas si simple à mettre en place! Backlog de mise en place des outils agiles! Passez par un coach! Utilisez l énergie de toute l équipe! Agilité à la carte = danger 227 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 228 Conclusion

115 Ces méthodes ne sont pas une religion 229 Ce sont (juste) des outils utiles 230

116 qui s enrichiront au contact de votre quotidien 231 LE PRÉ-REQUIS POUR PASSER À L AGILITÉ? COURAGE C R_G_ 232

117 AGILE MANIFESTO Priorité aux personnes et aux interactions plutôt qu aux processus, modèles et outils Focus sur le logiciel à développer plutôt que sur la documentation Collaboration avec le client plutôt que négociation et suivi du contrat Réactivité au changement plutôt que le suivi d un planning initial 233! Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles! Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.! Livrer fréquemment une application fonctionnelle avec une tendance pour la période la plus courte! Les gens du métier et les développeurs doivent collaborer quotidiennement au projet! 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! La méthode la plus efficace pour transmettre l'information est une conversation en face à face! Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet! Les processus agiles promeuvent un rythme de développement durable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.! Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité.! La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.! Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'autoorganisent.! À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens. 234

118 POUR ALLER PLUS LOIN! Scrum day! Journées Agile France! Agile Tour! Meetups de la Scrum Alliance! Scrum user groups sur Linkedin 235 POUR ALLER PLUS LOIN 236

119 POUR ALLER PLUS LOIN 237 BIBLIOTHÈQUE D ÉQUIPE slidesha.re/pivotal-nh 238

120 ( ) Mieux, plus vite, avec les mêmes personnes. 239 MERCI! CA VOUS A PLU? PARLEZ-EN AUTOUR DE VOUS! NICOLAS HENNION [email protected] 240

121 ANNEXE 1 : ALLER PLUS LOIN EN XP 241 TEST DRIVEN DEVELOPMENT! Je code un test unitaire avant de coder la fonctionnalité! Inconvénients! Ca semble couter plus cher! Avantages! Le besoin est exprimé sous forme de tests simples! Je colle au plus près au besoin exprimé! Je code donc le moins possible! Les tests sont toujours faits! Je crée une bibliothèque de tests automatisés 242

122 INTÉGRATION CONTINUE ET DÉPLOIEMENT FRÉQUENT EN PRODUCTION! Je déploie plusieurs fois par jours sur la plateforme de tests, et potentiellement tous les jours en production! Inconvénients! Ca semble couter plus cher! Avantages! Les tests automatiques de non régression sont passés le plus tôt possible après chaque modification! La mise en production n est plus un psychodrame! Je crée une bibliothèque de tests automatisés 243 ANNEXE 2 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 244 Conclusion

123 L ESSENTIEL : ANTI-INTERRUPTIONS! Faites savoir ce que ces interruptions vous coutent! Stand-ups cadencés avec les interlocuteurs récurrents! Consultez vos s 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 245 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"» 246

124 L ESSENTIEL : ADN AGILE! Livrer souvent! Livrer utile! Simplicité! Parler! Prioriser! Engagement 247 L ESSENTIEL : LEAN SOFTWARE DEVELOPMENT! Quelle hypothèse produit/marché/business model?! Quel plus petit produit possible (MVP)?! Confronter au marché! Ecouter le marché! Pivoter! Simplifier le produit en permanence 248

125 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 249 L ESSENTIEL : ITÉRATIONS! Planifier > réaliser > tester > feedback! Time box = durée fixe! Ad vitam aeternam! 3 à 5 sprints = 1 release 250

126 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 251 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 252

127 L ESSENTIEL : PLANIFICATION D UN SPRINT! Planification macro! Réunion de planning de sprint! Minuteur, ROTI! Planning poker! Engagement de l équipe! Backlog de sprint! Chacun a le devoir de challenger le besoin 253 L ESSENTIEL : DÉROULEMENT D UN SPRINT! Tableau de suivi! Auto-organisation : je choisis mes tâches! Burn down chart : caméra de surveillance! Stand up : évacuation des interruptions de la journée! Informatisation minimaliste : Pivotal Tracker! Que signifie «"terminé"»? 254

128 L ESSENTIEL : CLOTURE D UN SPRINT! Revue de sprint : démonstration, ça marche, merci!! Feedback en live!! Rétrospective : amélioration peu, mais souvent! Vélocité : capacité de production de l équipe 255 L ESSENTIEL : ENVIRONNEMENT DE TRAVAIL! Rythme durable! L environnement de travail compte! Chacun donne son avis sur les outils utilisés.! Utilisez les murs! La pression des pairs est bien plus efficace que celle d un chef 256

129 L ESSENTIEL : TRANSITION AGILE! Le bon sens n est pas si simple à mettre en place! Backlog de mise en place des outils agiles! Passez par un coach! Utilisez l énergie de toute l équipe! Agilité à la carte = danger 257