Scrum. ... pour des projets informatiques agiles. Pascal Lando Certified Scrum product owner

Transcription

1 Scrum... pour des projets informatiques agiles Pascal Lando Certified Scrum product owner e-merchant Laboratoire Mis IUP Miage d Amiens pascal.lando@u-picardie.fr 2 octobre 2013

2 Ceci n est pas un cours de gestion de projet! 2 / 171

3 Plan du cours 1 Les fondements 2 Scrum : présentation d ensemble 3 Sprint! 4 Retours d expérience

4 Plan 1 Les fondements 2 Scrum : présentation d ensemble 3 Sprint! 4 Retours d expérience 4 / 171

5 Pourquoi l agilité? Avant il y avait... Les méthodes traditionnelles! Cycle en V, processus en cascade... Une idée prédominante : on prévoit, et ensuite on réalise (méthodes prédictives) Ces méthodes ont fait leurs preuves mais les temps ont changé (un peu) 5 / 171

9 Pourquoi l agilité? Qu est-ce que l agilité? En 2001, des spécialistes et méthodologistes de la gestion de projets informatiques se regroupent pour expliciter des pratiques déjà existantes. Les individus et leurs interactions plus que les processus et les outils Des logiciels opérationnels plus qu une documentation exhaustive La collaboration avec les clients plus que la négociation contractuelle L adaptation au changement plus que le suivi d un plan 9 / 171

13 Pourquoi l agilité? Qu est-ce que l agilité? En 2001, des spécialistes et méthodologistes de la gestion de projets informatiques se regroupent pour expliciter des pratiques déjà existantes. Les individus et leurs interactions plus que les processus et les outils Des logiciels opérationnels plus qu une documentation exhaustive La collaboration avec les clients plus que la négociation contractuelle L adaptation au changement plus que le suivi d un plan Pointeur intéressant 13 / 171

14 Des processus vraiment incrémentaux Livrer souvent pour se tromper moins Le système est conçu et construit par éléments successifs de petite taille. Chaque élément est montrable et testable. Dès qu un élément est terminé, il est livré. Ainsi, le logiciel est toujours prêt (en principe... ). 14 / 171

18 Des processus vraiment incrémentaux Livrer souvent pour se tromper moins Le système est conçu et construit par éléments successifs de petite taille. Chaque élément est montrable et testable. Dès qu un élément est terminé, il est livré. Ainsi, le logiciel est toujours prêt (en principe... ). Pourquoi? Plus on livre souvent, plus on minimise l ampleur des erreurs (et plus on implique son client dans le processus). 18 / 171

19 Créer des choses utiles Des choses vraiment utiles... i.e. des choses rentables! Notion de business value : chaque fonctionnalité candidate doit avoir une valeur business suffisamment grande pour être réalisée. Maîtrise des coûts, optimisation de la valeur créée. 19 / 171

22 Créer des choses utiles Des choses vraiment utiles... i.e. des choses rentables! Notion de business value : chaque fonctionnalité candidate doit avoir une valeur business suffisamment grande pour être réalisée. Maîtrise des coûts, optimisation de la valeur créée. Et si ce n est pas le cas? Règle 1 Si une fonctionnalité est intéressante, mais a une business value faible, alors... elle n est pas intéressante. Règle 2 Si un fonctionnalité n est pas intéressante, on ne s y intéresse pas. 22 / 171

23 Créer des choses utiles Des choses vraiment utiles... i.e. des choses rentables! Notion de business value : chaque fonctionnalité candidate doit avoir une valeur business suffisamment grande pour être réalisée. Maîtrise des coûts, optimisation de la valeur créée. Et si ce n est pas le cas? Règle 1 Si une fonctionnalité est intéressante, mais a une business value faible, alors... elle n est pas intéressante. Règle 2 Si un fonctionnalité n est pas intéressante, on ne s y intéresse pas. 23 / 171

24 Les fondements Scrum : pre sentation d ensemble Sprint! Retours d expe rience Cre er des choses utiles 24 / 171

25 Il n y a que les imbéciles qui ne changent pas d avis Le client a le droit de changer d avis Être agile, c est aussi être souple. Le client est soumis aux fluctuations de son marché : ses besoins peuvent changer entre le début du projet et sa fin. Dans un projet agile, on accepte de remettre en cause certaines choses en cours de route! 25 / 171

28 Il n y a que les imbéciles qui ne changent pas d avis Le client a le droit de changer d avis Être agile, c est aussi être souple. Le client est soumis aux fluctuations de son marché : ses besoins peuvent changer entre le début du projet et sa fin. Dans un projet agile, on accepte de remettre en cause certaines choses en cours de route! En connaissance de cause... Changer d avis a un prix : s il était prévu de faire A et que tu veux maintenant faire B... il te faudra accepter d attendre que B soit terminé avant d avoir A. 28 / 171

29 Mieux communiquer pour être plus efficace Qu est-ce qu y dit? Hein, qu est-ce qu y dit? Il dit que le chef a dit qu il fallait faire ça. Mieux on communique, plus on est efficace. On communique moins bien entre chef et subordonnés qu entre équipiers, dans des équipes mixtes à taille humaine. Management par facilitation. 29 / 171

33 Mieux communiquer pour être plus efficace Qu est-ce qu y dit? Hein, qu est-ce qu y dit? Il dit que le chef a dit qu il fallait faire ça. Mieux on communique, plus on est efficace. On communique moins bien entre chef et subordonnés qu entre équipiers, dans des équipes mixtes à taille humaine. Management par facilitation. Les équipes agiles sont de vraies équipes On se parle, on fait des plans, on conçoit des solutions, on les implémente et on les assume. Ensemble. 33 / 171

34 Une culture du changement Changer, pour mieux! On peut toujours faire mieux. Changer n est pas forcément une contrainte.... y compris dans un projet informatique! Le tout est de fixer une finalité commune clairement établie, à court terme, et de s approprier le changement. 34 / 171

39 39 / 171

40 Histoire Une méthode... sportive! Scrum = mêlée de rugby Initialement présentée à la conférence OOPSLA en 1995, par Jeff Sutherland et Ken Schwaber (fondée sur des pratiques émergeant depuis une dizaine d année auparavant) 2001 : publication du livre Agile Software Development With Scrum 40 / 171

43 Philosophie Pas une méthode, en fait! Scrum n est pas une méthodologie, c est un cadre. Ken Schwaber, co-auteur de Scrum 43 / 171

44 Philosophie En quelques mots-clés... Un état d esprit : faire des choses utiles, simplement, correctement, et de manière disciplinée mais flexible Des rôles : product owner, scrum master, équipe de développement, stakeholders Des artefacts : backlog, user stories, sprints 44 / 171

47 Le backlog de produit Qu est-ce qu un backlog? Une liste d exigences métier (une sorte de todo list), mais pas une liste de solutions Une vision du futur Priorisée Par le product owner 47 / 171

51 Le backlog de produit Qu est-ce qu un backlog? Une liste d exigences métier (une sorte de todo list), mais pas une liste de solutions Une vision du futur Priorisée Par le product owner Partir en courses et revenir avec une super affaire imprévue Le backlog n est pas immuable : il faut accepter que le périmètre fonctionnel ne soit pas complètement figé au début du projet. 51 / 171

52 Le backlog de produit Comment s organise le backlog? Un tableau comportant (généralement) les colonnes suivantes : ID Nom Importance (pas priorité) Estimation initiale How to demo Acceptance tests Notes 52 / 171

60 Le backlog de produit Exemple de backlog 60 / 171

61 Les acteurs Le product owner Aka PO, voire (probablement à tort) directeur de produit Représentant des clients et utilisateurs En charge de la tenue du backlog produit Son rôle est de dire ce qui doit être fait. Jamais comment ça doit être fait. 61 / 171

65 Les acteurs Le product owner Aka PO, voire (probablement à tort) directeur de produit Représentant des clients et utilisateurs En charge de la tenue du backlog produit Son rôle est de dire ce qui doit être fait. Jamais comment ça doit être fait. Une grosse responsabilité C est le rôle le plus difficile dans Scrum. Du reste, le PO est au yeux de beaucoup de gens le responsable du succès (ou de l échec) du projet. 65 / 171

66 Les acteurs Le scrum master Aka SM (hum... ) Le facilitateur de l équipe technique (mais pas un lead tech) : en charge de lever les obstacles au travail de l équipe L alter ego du product owner Pas un chef de projet (pas un chef tout court) S assure que le processus Scrum est correctement exécuté 66 / 171

71 Les acteurs L équipe de dévelopement L équipe est idéalement constituée de 5 à 10 personnes. Elle construit elle-même son planning sur la base des priorités fixées par le PO. Elle est autonome, s organise comme elle le souhaite. Elle répartit elle-même le travail entre les membres. Elle s auto-contrôle, s auto-évalue. 71 / 171

76 Les acteurs L équipe de dévelopement L équipe est idéalement constituée de 5 à 10 personnes. Elle construit elle-même son planning sur la base des priorités fixées par le PO. Elle est autonome, s organise comme elle le souhaite. Elle répartit elle-même le travail entre les membres. Elle s auto-contrôle, s auto-évalue. Les maçons L équipe de développement dans un projet informatique, c est l équipe de maçons dans un projet BTP. Si les parpaings sont mal posés, l immeuble s écroule. 76 / 171

77 Les itérations Le sprint Un sprint est une itération. L équipe s engage à produire quelque chose pour la fin du sprint. C est tout (et c est déjà pas mal). Les autres personnes s engagent à laisser l équipe tranquille pendant ce temps là (ce qui est généralement assez difficile, en pratique)! Un sprint dure généralement 2 à 4 semaines, parfois plus, parfois moins. 77 / 171

81 Les user stories Les user stories Une user story est la description d un besoin du client. C est la description d un use case. C est une ligne dans le backlog produit. C est quelque chose de compréhensible par tous, et de compris par tous. 81 / 171

85 Les user stories Exemple de user story EN TANT QUE feeds manager JE SOUHAITE disposer d un écran listant l ensemble des feeds liés à un des sites que je gère, avec filtrage multi-critère possible par pays, champ de recherche et type de source DANS LE BUT d accéder efficacement à un feed donné et de réaliser les actions nécessaires sur ce feed, et ainsi être réactif aux exigences de mes partenaires 85 / 171

88 Les user stories Exemple de user story (2) 88 / 171

89 Le tableau blanc (ou tableau de bord) Le tableau et les fameux posts-it... Le tableau est un lieu de rassemblement, de discussion. On y écrit le backlog de sprint, sur des post-its ou des fiches. 89 / 171

90 Le tableau blanc (ou tableau de bord) Le tableau et les fameux posts-it... Le tableau est un lieu de rassemblement, de discussion. On y écrit le backlog de sprint, sur des post-its ou des fiches. 90 / 171

91 Le tableau blanc (ou tableau de bord) Le backlog de sprint À faire En cours Terminé 91 / 171

92 Le tableau blanc (ou tableau de bord) Le backlog de sprint À faire En cours Terminé + Burndown chart + Tâches non planifiées 92 / 171

93 Le tableau blanc (ou tableau de bord) Zoom sur le burndown chart Estimation du travail restant vs. date Figure tirée de Scrum and XP from the trenches 93 / 171

95 Le sprint planning Le sprint planning Le sprint planning est une réunion importante pendant laquelle l équipe se met d accord sur ce qui va être réalisé pendant le sprint. Avant cette réunion, le PO met en ordre le backlog de produit : il écrit les user stories, les comprend et les priorise! Objectifs : Un but pour le sprint Un backlog de sprint Une date pour la démo Un responsable de l achat des croissants le jour de la démo 95 / 171

102 Le sprint planning Qui y assiste? Le PO (c est important!) L équipe, bien sûr 102 / 171

103 Le sprint planning Qui y assiste? Le PO (c est important!) L équipe, bien sûr 103 / 171

104 Le sprint planning Qu est-ce qu on y fait concrètement Le PO présente le but du sprint et décrit les user stories présentes en haut du backlog. L équipe estime ces user stories, en leur attribuant un nombre de points (généralement, 1 point = 1 jour/homme idéal, parfois des unités plus abstraites). L équipe sélectionne les user stories à inclure dans le backlog, en fonction de sa vélocité (et de son intuition) : elle en fait un sprint backlog. Les éléments du backlog sont divisés en tâches unitaires distinctes, n excédant pas une demi journée de travail. 104 / 171

108 Le sprint planning Au sujet de la vélocité La vélocité d une équipe, c est la quantité de travail qu elle peut réaliser durant un sprint. On la mesure à la fin de chaque sprint : combien de points a-t-on réussi à faire passer? Au bout de quelques itérations, on a donc une idée de la vélocité de l équipe!... à condition d estimer rigoureusement, avec une valeur de point constante. 108 / 171

112 Le sprint planning L estimation par poker planning Une manière d estimer la complexité des fonctionnalité à développer Ludique! Utilisation de la suite de Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, 55, 89) : plus la user story est grosse, moins l évaluation est précise... S appuie sur le consensus de groupe. 112 / 171

Montrer encore