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
Ceci n est pas un cours de gestion de projet! 2 / 171
Plan du cours 1 Les fondements 2 Scrum : présentation d ensemble 3 Sprint! 4 Retours d expérience
Plan 1 Les fondements 2 Scrum : présentation d ensemble 3 Sprint! 4 Retours d expérience 4 / 171
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
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) 6 / 171
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) 7 / 171
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) 8 / 171
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
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 10 / 171
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 11 / 171
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 12 / 171
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 http://agilemanifesto.org/iso/fr/ 13 / 171
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
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... ). 15 / 171
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... ). 16 / 171
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... ). 17 / 171
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
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
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. 20 / 171
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. 21 / 171
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
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
Les fondements Scrum : pre sentation d ensemble Sprint! Retours d expe rience Cre er des choses utiles 24 / 171
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
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! 26 / 171
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! 27 / 171
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
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
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. 30 / 171
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. 31 / 171
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. 32 / 171
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
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
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. 35 / 171
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. 36 / 171
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. 37 / 171
Plan 1 Les fondements 2 Scrum : présentation d ensemble 3 Sprint! 4 Retours d expérience 38 / 171
39 / 171
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
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 41 / 171
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 42 / 171
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
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
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 45 / 171
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 46 / 171
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
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 48 / 171
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 49 / 171
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 50 / 171
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
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
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 53 / 171
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 54 / 171
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 55 / 171
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 56 / 171
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 57 / 171
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 58 / 171
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 59 / 171
Le backlog de produit Exemple de backlog 60 / 171
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
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. 62 / 171
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. 63 / 171
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. 64 / 171
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
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
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é 67 / 171
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é 68 / 171
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é 69 / 171
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é 70 / 171
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
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. 72 / 171
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. 73 / 171
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. 74 / 171
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. 75 / 171
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
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
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. 78 / 171
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. 79 / 171
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. 80 / 171
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
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. 82 / 171
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. 83 / 171
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. 84 / 171
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
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 86 / 171
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 87 / 171
Les user stories Exemple de user story (2) 88 / 171
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
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
Le tableau blanc (ou tableau de bord) Le backlog de sprint À faire En cours Terminé 91 / 171
Le tableau blanc (ou tableau de bord) Le backlog de sprint À faire En cours Terminé + Burndown chart + Tâches non planifiées 92 / 171
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
Plan 1 Les fondements 2 Scrum : présentation d ensemble 3 Sprint! 4 Retours d expérience 94 / 171
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
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 96 / 171
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 97 / 171
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 98 / 171
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 99 / 171
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 100 / 171
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 101 / 171
Le sprint planning Qui y assiste? Le PO (c est important!) L équipe, bien sûr 102 / 171
Le sprint planning Qui y assiste? Le PO (c est important!) L équipe, bien sûr 103 / 171
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
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. 105 / 171
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. 106 / 171
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. 107 / 171
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
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. 109 / 171
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. 110 / 171
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. 111 / 171
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
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. 113 / 171
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. 114 / 171
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. 115 / 171
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. 116 / 171
Les daily meetings (mêlée quotidienne) Tous les matins, l équipe se réunit 10 minutes, debout (stand-up meeting) Qu as-tu fait hier? Que vas-tu faire aujourd hui? Quels sont les points de blocage éventuels? Le product owner ne parle pas (hum... ) 117 / 171
Les daily meetings (mêlée quotidienne) Tous les matins, l équipe se réunit 10 minutes, debout (stand-up meeting) Qu as-tu fait hier? Que vas-tu faire aujourd hui? Quels sont les points de blocage éventuels? Le product owner ne parle pas (hum... ) 118 / 171
Les daily meetings (mêlée quotidienne) Tous les matins, l équipe se réunit 10 minutes, debout (stand-up meeting) Qu as-tu fait hier? Que vas-tu faire aujourd hui? Quels sont les points de blocage éventuels? Le product owner ne parle pas (hum... ) 119 / 171
Les daily meetings (mêlée quotidienne) Tous les matins, l équipe se réunit 10 minutes, debout (stand-up meeting) Qu as-tu fait hier? Que vas-tu faire aujourd hui? Quels sont les points de blocage éventuels? Le product owner ne parle pas (hum... ) 120 / 171
Les daily meetings (mêlée quotidienne) Tous les matins, l équipe se réunit 10 minutes, debout (stand-up meeting) Qu as-tu fait hier? Que vas-tu faire aujourd hui? Quels sont les points de blocage éventuels? Le product owner ne parle pas (hum... ) 121 / 171
Les daily meetings (mêlée quotidienne) Pas de daily meetings à ralonge Dans la vraie vie, même les Scrum masters les plus aguéris ont énormément de mal à ne pas dépasser le quart d heure. Un daily meeting à rallonge est le signe d un problème. Le daily meeting n est pas une pause café. Comment faire? Écourter. 122 / 171
Les daily meetings (mêlée quotidienne) Pas de daily meetings à ralonge Dans la vraie vie, même les Scrum masters les plus aguéris ont énormément de mal à ne pas dépasser le quart d heure. Un daily meeting à rallonge est le signe d un problème. Le daily meeting n est pas une pause café. Comment faire? Écourter. 123 / 171
Les daily meetings (mêlée quotidienne) Pas de daily meetings à ralonge Dans la vraie vie, même les Scrum masters les plus aguéris ont énormément de mal à ne pas dépasser le quart d heure. Un daily meeting à rallonge est le signe d un problème. Le daily meeting n est pas une pause café. Comment faire? Écourter. 124 / 171
Les daily meetings (mêlée quotidienne) Pas de daily meetings à ralonge Dans la vraie vie, même les Scrum masters les plus aguéris ont énormément de mal à ne pas dépasser le quart d heure. Un daily meeting à rallonge est le signe d un problème. Le daily meeting n est pas une pause café. Comment faire? Écourter. 125 / 171
La démo de sprint Tous les bons sprints ont une démo! Dès la réunion de sprint planning, il faut convenir d une date pour la démo. C est généralement une bonne chose de fixer une date récurrente pour la démo (chaque vendredi de fin de sprint?). Tout est démontrable. Oui, tout est démontrable. 126 / 171
La démo de sprint Tous les bons sprints ont une démo! Dès la réunion de sprint planning, il faut convenir d une date pour la démo. C est généralement une bonne chose de fixer une date récurrente pour la démo (chaque vendredi de fin de sprint?). Tout est démontrable. Oui, tout est démontrable. 127 / 171
La démo de sprint Tous les bons sprints ont une démo! Dès la réunion de sprint planning, il faut convenir d une date pour la démo. C est généralement une bonne chose de fixer une date récurrente pour la démo (chaque vendredi de fin de sprint?). Tout est démontrable. Oui, tout est démontrable. 128 / 171
La démo de sprint Tous les bons sprints ont une démo! Dès la réunion de sprint planning, il faut convenir d une date pour la démo. C est généralement une bonne chose de fixer une date récurrente pour la démo (chaque vendredi de fin de sprint?). Tout est démontrable. Oui, tout est démontrable. 129 / 171
La démo de sprint Tout est démontrable Une user story orientée métier est facilement démontrable. AS A Customer I WANT TO Be able to log into the website SO THAT I can process an order. Lors de la démo, le développeur accède à l interface de connexion, se connecte, et prouve qu il est connecté. 130 / 171
La démo de sprint Tout est démontrable Une user story orientée métier est facilement démontrable. AS A Customer I WANT TO Be able to log into the website SO THAT I can process an order. Lors de la démo, le développeur accède à l interface de connexion, se connecte, et prouve qu il est connecté. 131 / 171
La démo de sprint Tout est démontrable Une user story orientée métier est facilement démontrable. AS A Customer I WANT TO Be able to log into the website SO THAT I can process an order. Lors de la démo, le développeur accède à l interface de connexion, se connecte, et prouve qu il est connecté. 132 / 171
La démo de sprint Tout est démontrable Une user story orientée métier est facilement démontrable. AS A Customer I WANT TO Be able to log into the website SO THAT I can process an order. Lors de la démo, le développeur accède à l interface de connexion, se connecte, et prouve qu il est connecté. Une user story technique est aussi démontrable. Il faut aujouter des indexes sur la table des commandes Euh, oui, pourquoi? EN TANT QUE Responsable service client JE VEUX Pouvoir trouver plus rapidement les commandes d un client DANS LE BUT DE optimiser mon travail de traitement de ces commandes. Lors de la démo, le développeur réalise une requête avec indexes et sans indexes, et prouve que les performances sont meilleures. 133 / 171
La démo de sprint Tout est démontrable Une user story orientée métier est facilement démontrable. AS A Customer I WANT TO Be able to log into the website SO THAT I can process an order. Lors de la démo, le développeur accède à l interface de connexion, se connecte, et prouve qu il est connecté. Une user story technique est aussi démontrable. Il faut aujouter des indexes sur la table des commandes Euh, oui, pourquoi? EN TANT QUE Responsable service client JE VEUX Pouvoir trouver plus rapidement les commandes d un client DANS LE BUT DE optimiser mon travail de traitement de ces commandes. Lors de la démo, le développeur réalise une requête avec indexes et sans indexes, et prouve que les performances sont meilleures. 134 / 171
La démo de sprint Tout est démontrable Une user story orientée métier est facilement démontrable. AS A Customer I WANT TO Be able to log into the website SO THAT I can process an order. Lors de la démo, le développeur accède à l interface de connexion, se connecte, et prouve qu il est connecté. Une user story technique est aussi démontrable. Il faut aujouter des indexes sur la table des commandes Euh, oui, pourquoi? EN TANT QUE Responsable service client JE VEUX Pouvoir trouver plus rapidement les commandes d un client DANS LE BUT DE optimiser mon travail de traitement de ces commandes. Lors de la démo, le développeur réalise une requête avec indexes et sans indexes, et prouve que les performances sont meilleures. 135 / 171
La démo de sprint Tout est démontrable Une user story orientée métier est facilement démontrable. AS A Customer I WANT TO Be able to log into the website SO THAT I can process an order. Lors de la démo, le développeur accède à l interface de connexion, se connecte, et prouve qu il est connecté. Une user story technique est aussi démontrable. Il faut aujouter des indexes sur la table des commandes Euh, oui, pourquoi? EN TANT QUE Responsable service client JE VEUX Pouvoir trouver plus rapidement les commandes d un client DANS LE BUT DE optimiser mon travail de traitement de ces commandes. Lors de la démo, le développeur réalise une requête avec indexes et sans indexes, et prouve que les performances sont meilleures. 136 / 171
La démo de sprint Tout est démontrable Une user story orientée métier est facilement démontrable. AS A Customer I WANT TO Be able to log into the website SO THAT I can process an order. Lors de la démo, le développeur accède à l interface de connexion, se connecte, et prouve qu il est connecté. Une user story technique est aussi démontrable. Il faut aujouter des indexes sur la table des commandes Euh, oui, pourquoi? EN TANT QUE Responsable service client JE VEUX Pouvoir trouver plus rapidement les commandes d un client DANS LE BUT DE optimiser mon travail de traitement de ces commandes. Lors de la démo, le développeur réalise une requête avec indexes et sans indexes, et prouve que les performances sont meilleures. 137 / 171
La rétrospective de sprint La rétrospective de sprint À la fin de chaque sprint (après la démo), l équipe se réunit pour faire le point. Généralement l équipe s isole pour cette réunion, pour pouvoir parler librement de tous les sujets. Chacun peut exprimer ses problèmes, craintes... et satisfactions 138 / 171
La rétrospective de sprint La rétrospective de sprint À la fin de chaque sprint (après la démo), l équipe se réunit pour faire le point. Généralement l équipe s isole pour cette réunion, pour pouvoir parler librement de tous les sujets. Chacun peut exprimer ses problèmes, craintes... et satisfactions 139 / 171
La rétrospective de sprint La rétrospective de sprint À la fin de chaque sprint (après la démo), l équipe se réunit pour faire le point. Généralement l équipe s isole pour cette réunion, pour pouvoir parler librement de tous les sujets. Chacun peut exprimer ses problèmes, craintes... et satisfactions 140 / 171
La rétrospective de sprint La rétrospective de sprint À la fin de chaque sprint (après la démo), l équipe se réunit pour faire le point. Généralement l équipe s isole pour cette réunion, pour pouvoir parler librement de tous les sujets. Chacun peut exprimer ses problèmes, craintes... et satisfactions Un plan d action Il est important d établir, à la fin de chaque rétrospective, un plan d action pour le sprint suivant... et de s y confronter lors de la prochaine rétrospective! 141 / 171
Plan 1 Les fondements 2 Scrum : présentation d ensemble 3 Sprint! 4 Retours d expérience 142 / 171
Definition of done Definition of done n est pas le titre d un film hollywoodien À la fin du sprint, l équipe doit être en mesure de livrer une fonctionnalité terminée. Mais ça veut dire quoi, terminé? Testable sur la dev d un équipier? Releasé en environnement de test? Unitairement testé? Intégré? 143 / 171
Definition of done Definition of done n est pas le titre d un film hollywoodien À la fin du sprint, l équipe doit être en mesure de livrer une fonctionnalité terminée. Mais ça veut dire quoi, terminé? Testable sur la dev d un équipier? Releasé en environnement de test? Unitairement testé? Intégré? 144 / 171
Definition of done Definition of done n est pas le titre d un film hollywoodien À la fin du sprint, l équipe doit être en mesure de livrer une fonctionnalité terminée. Mais ça veut dire quoi, terminé? Testable sur la dev d un équipier? Releasé en environnement de test? Unitairement testé? Intégré? 145 / 171
Definition of done Definition of done n est pas le titre d un film hollywoodien À la fin du sprint, l équipe doit être en mesure de livrer une fonctionnalité terminée. Mais ça veut dire quoi, terminé? Testable sur la dev d un équipier? Releasé en environnement de test? Unitairement testé? Intégré? Une définition à trouver ensemble La definition of done doit être explicite entre les participants au projet. Une bonne solution : done = développé, testé unitairement, testé en intégration, releasé en environnement de test. 146 / 171
Quelques astuces pour faire échouer un projet avec Scrum Quelques astuces pour faire échouer un projet avec Scrum Attention! Les constats et affirmations mentionnés dans les pages à venir sont inspirés de faits réels. Âmes sensibles s abstenir. 147 / 171
Quelques astuces pour faire échouer un projet avec Scrum La difficulté du métier... persiste! Le folklore ne remplace pas l expertise. Le product owner est un concepteur fonctionnel, pas un public relations guy! Concevoir, développer, déployer, tester des logiciels restent des tâches qui requièrent une expertise avancée, qui ne s improvise pas. 148 / 171
Quelques astuces pour faire échouer un projet avec Scrum La difficulté du métier... persiste! Le folklore ne remplace pas l expertise. Le product owner est un concepteur fonctionnel, pas un public relations guy! Concevoir, développer, déployer, tester des logiciels restent des tâches qui requièrent une expertise avancée, qui ne s improvise pas. 149 / 171
Quelques astuces pour faire échouer un projet avec Scrum La difficulté du métier... persiste! Le folklore ne remplace pas l expertise. Le product owner est un concepteur fonctionnel, pas un public relations guy! Concevoir, développer, déployer, tester des logiciels restent des tâches qui requièrent une expertise avancée, qui ne s improvise pas. 150 / 171
Quelques astuces pour faire échouer un projet avec Scrum L invitation à la médiocrité Scrum protège les équipes de développement. Scrum peut du coup être un bouclier pour ceux qui ne veulent rien (ou peu) faire. Hum, cette story ne rentre pas dans le sprint 151 / 171
Quelques astuces pour faire échouer un projet avec Scrum L invitation à la médiocrité Scrum protège les équipes de développement. Scrum peut du coup être un bouclier pour ceux qui ne veulent rien (ou peu) faire. Hum, cette story ne rentre pas dans le sprint 152 / 171
Quelques astuces pour faire échouer un projet avec Scrum L invitation à la médiocrité Scrum protège les équipes de développement. Scrum peut du coup être un bouclier pour ceux qui ne veulent rien (ou peu) faire. Hum, cette story ne rentre pas dans le sprint 153 / 171
Quelques astuces pour faire échouer un projet avec Scrum L arnaque des story points Un dev : Moi j estime cette fonctionnalité à 14 points Un autre dev : Moi j estime cette fonctionnalité à 4 points Le PO : Mais ça vaut quoi un point? Un dev : Bah, on peut pas relier ça à du temps Un autre dev : 1 point c est environ le temps qu il faut pour réaliser la plus petite tâche, comme coder un formulaire simple 154 / 171
Quelques astuces pour faire échouer un projet avec Scrum L arnaque des story points Un dev : Moi j estime cette fonctionnalité à 14 points Un autre dev : Moi j estime cette fonctionnalité à 4 points Le PO : Mais ça vaut quoi un point? Un dev : Bah, on peut pas relier ça à du temps Un autre dev : 1 point c est environ le temps qu il faut pour réaliser la plus petite tâche, comme coder un formulaire simple 155 / 171
Quelques astuces pour faire échouer un projet avec Scrum L arnaque des story points Un dev : Moi j estime cette fonctionnalité à 14 points Un autre dev : Moi j estime cette fonctionnalité à 4 points Le PO : Mais ça vaut quoi un point? Un dev : Bah, on peut pas relier ça à du temps Un autre dev : 1 point c est environ le temps qu il faut pour réaliser la plus petite tâche, comme coder un formulaire simple 156 / 171
Quelques astuces pour faire échouer un projet avec Scrum L arnaque des story points Un dev : Moi j estime cette fonctionnalité à 14 points Un autre dev : Moi j estime cette fonctionnalité à 4 points Le PO : Mais ça vaut quoi un point? Un dev : Bah, on peut pas relier ça à du temps Un autre dev : 1 point c est environ le temps qu il faut pour réaliser la plus petite tâche, comme coder un formulaire simple 157 / 171
Quelques astuces pour faire échouer un projet avec Scrum L arnaque des story points Un dev : Moi j estime cette fonctionnalité à 14 points Un autre dev : Moi j estime cette fonctionnalité à 4 points Le PO : Mais ça vaut quoi un point? Un dev : Bah, on peut pas relier ça à du temps Un autre dev : 1 point c est environ le temps qu il faut pour réaliser la plus petite tâche, comme coder un formulaire simple 158 / 171
Quelques astuces pour faire échouer un projet avec Scrum L arnaque des story points Un dev : Moi j estime cette fonctionnalité à 14 points Un autre dev : Moi j estime cette fonctionnalité à 4 points Le PO : Mais ça vaut quoi un point? Un dev : Bah, on peut pas relier ça à du temps Un autre dev : 1 point c est environ le temps qu il faut pour réaliser la plus petite tâche, comme coder un formulaire simple Non! Scrum, c est cool. Mais le PO s engage auprès de son client. On ne s engage pas sur du vent. 159 / 171
Quelques astuces pour faire échouer un projet avec Scrum Une équipe de branquignols auto-gérée, c est dangereux Scrum préconise l auto gestion des équipes, l émulation, l esprit de responsabilité collective. Avez-vous déjà placé 4 mauvais développeurs dans le coin d un open space avec pour mission de livrer une fonctionnalité importante? Scrum a des pré-requis : de bons développeurs, autonomes, qui savent tester. Un PO qui sait concevoir. 160 / 171
Quelques astuces pour faire échouer un projet avec Scrum Une équipe de branquignols auto-gérée, c est dangereux Scrum préconise l auto gestion des équipes, l émulation, l esprit de responsabilité collective. Avez-vous déjà placé 4 mauvais développeurs dans le coin d un open space avec pour mission de livrer une fonctionnalité importante? Scrum a des pré-requis : de bons développeurs, autonomes, qui savent tester. Un PO qui sait concevoir. 161 / 171
Quelques astuces pour faire échouer un projet avec Scrum Une équipe de branquignols auto-gérée, c est dangereux Scrum préconise l auto gestion des équipes, l émulation, l esprit de responsabilité collective. Avez-vous déjà placé 4 mauvais développeurs dans le coin d un open space avec pour mission de livrer une fonctionnalité importante? Scrum a des pré-requis : de bons développeurs, autonomes, qui savent tester. Un PO qui sait concevoir. 162 / 171
Quelques astuces pour faire échouer un projet avec Scrum Une équipe de branquignols auto-gérée, c est dangereux Scrum préconise l auto gestion des équipes, l émulation, l esprit de responsabilité collective. Avez-vous déjà placé 4 mauvais développeurs dans le coin d un open space avec pour mission de livrer une fonctionnalité importante? Scrum a des pré-requis : de bons développeurs, autonomes, qui savent tester. Un PO qui sait concevoir. Prérequis Scrum n est pas une méthode miracle : si vous avez de mauvais développeurs, vous collerez de jolis posts-it mais livrerez aussi des logiciels dont vos clients ne voudront pas. 163 / 171
Quelques astuces pour faire échouer un projet avec Scrum Les lois de Parkinson Tout travail augmente jusqu à occuper entièrement le temps qui lui est affecté. On s engage à faire les tâches A, B et C pendant le sprint de 2 semaines à venir. On ne fera que A, B et C dans le sprint à venir. Même si on a fini au bout de 3 jours. 164 / 171
Quelques astuces pour faire échouer un projet avec Scrum Les lois de Parkinson Tout travail augmente jusqu à occuper entièrement le temps qui lui est affecté. On s engage à faire les tâches A, B et C pendant le sprint de 2 semaines à venir. On ne fera que A, B et C dans le sprint à venir. Même si on a fini au bout de 3 jours. 165 / 171
Quelques astuces pour faire échouer un projet avec Scrum Les lois de Parkinson Tout travail augmente jusqu à occuper entièrement le temps qui lui est affecté. On s engage à faire les tâches A, B et C pendant le sprint de 2 semaines à venir. On ne fera que A, B et C dans le sprint à venir. Même si on a fini au bout de 3 jours. 166 / 171
Quelques astuces pour faire échouer un projet avec Scrum Les lois de Parkinson Tout travail augmente jusqu à occuper entièrement le temps qui lui est affecté. On s engage à faire les tâches A, B et C pendant le sprint de 2 semaines à venir. On ne fera que A, B et C dans le sprint à venir. Même si on a fini au bout de 3 jours. 167 / 171
Quelques astuces pour faire échouer un projet avec Scrum La sous-estimation du management Avec Scrum, il n y a plus de chef de projet. C est cool. Mais tous les problèmes RH ne s envolent pas pour autant : développeur démotivé, développeur mauvais, problèmes relationnels, PO qui n a jamais conçu un logiciel, etc. L un des pièges de Scrum est de sous-estimer le management : le PO n est pas le directeur produit, le SM n est pas le chef d équipe, mais il faut des managers externes à l équipe pour régler les problèmes de management. 168 / 171
Quelques astuces pour faire échouer un projet avec Scrum La sous-estimation du management Avec Scrum, il n y a plus de chef de projet. C est cool. Mais tous les problèmes RH ne s envolent pas pour autant : développeur démotivé, développeur mauvais, problèmes relationnels, PO qui n a jamais conçu un logiciel, etc. L un des pièges de Scrum est de sous-estimer le management : le PO n est pas le directeur produit, le SM n est pas le chef d équipe, mais il faut des managers externes à l équipe pour régler les problèmes de management. 169 / 171
Quelques astuces pour faire échouer un projet avec Scrum La sous-estimation du management Avec Scrum, il n y a plus de chef de projet. C est cool. Mais tous les problèmes RH ne s envolent pas pour autant : développeur démotivé, développeur mauvais, problèmes relationnels, PO qui n a jamais conçu un logiciel, etc. L un des pièges de Scrum est de sous-estimer le management : le PO n est pas le directeur produit, le SM n est pas le chef d équipe, mais il faut des managers externes à l équipe pour régler les problèmes de management. 170 / 171
Lectures Lectures conseillées À lire absolument Scrum and XP from the Trenches (PDF) Scrum et XP depuis les Tranchées (version française, PDF) À voir en complément Manifeste agile (site web) Scrum Alliance (site web) 171 / 171