4 Ce que Scrum n’est pas : - Une méthode Ce qu’est Scrum - Un processus - Cadre (framework) - Une voie à suivre (path) - Un outil
Release (version) : produite par une série d’itérations (sprints)
5 • La transparence garantie que les indicateurs relatifs à l’état du développement sont visibles par ceux qui sont intéressés par le produit. Elle pousse à la visibilité et à la compréhension. • Les différentes facettes du développement doivent être inspectées suffisamment pour que des variations excessives dans les indicateurs puissent être détectées à temps.
Trois points d’inspection :
• Scrum quotidien : inspecter la progression par rapport au but du sprint et faire des adaptations qui optimisent la valeur du travail du jours suivant • Planification et revue de sprint : inspecter l’avancement du développement par rapport au but de la release et faire des adaptations sur le contenu du produit pour le prochain sprint. • Rétrospective : incite l’équipe à revenir sur sa façon de travailler dans le sprint afin de déterminer les améliorations du processus pour le prochain sprint.
6 Transformation idée de départ en quelque chose d’assimilable par l’équipe de développement - Ce que fait le produit - Quels sont les fonctions attendues - Quel est le comportement souhaité
• Le backlog ne doit pas comporter trop d’élément : moins d’une cinquantaine est conseillé • Les stories finies ne font plus partie du backlog mais ils sont souvent conserver pour garder une trace. • Attention : la partie du backlog sur lequel l’équipe travaille pendant un sprint est gelé • Gestions de backlog avec des cartes (fiches bristol) rangés par priorité, ou post-it virtuels, tableur etc. • Nettoyer le backlog à la fin d’une release de préférence : suppression des stories au fond du backlog (pas utiles ou mal identifiées) et des doublons
Comment estimer l’effort?
7 Communication face à face : - Tout n’est pas écrit dans le backlog - Permet de fait passer de l’esprit du product owner à celui du développeur, tout en laissant à ce dernier une marge de manœuvre pour sa réalisation.
8 On peut aussi avoir : - l’estimation de sa valeur ajoutée - Le créateur et la date de création - Une estimation de sa fréquence d’exécution sur le produit déployé (plusieurs fois par jours ou par semaine) - Le rôle associé : utilisateur qui est à l’initiative de la story - Critères permettant de considérer que la stories est finie : correspond à un cas de test qui peut être décrit de façon plus ou moins formelle (un formalisme de haut niveau facilite l’autonomisation des tests d’acceptation)
User story : correspond au comportement visible pour les utilisateurs et leur apporte de la valeur ou de l’utilité Story technique : Visible uniquement pour l’équipe de développement. Nécessaire pour pouvoir développer certaines user stories, son utilité est indirecte Défaut (bug) : répartitif au comportement visible mais qui enlève de la valeur au produit. Peut être un bug ou une demande d’évolution du produit (indifféremment appelé bug)
Cycle de vie : - Proposé par quelqu’un qui a une idée - Examiné par le product owner puis accepté
9 - Estimé par l’équipe qui évalue l’effort de développement nécessaire (taille) - Prêt lorsqu’elle est suffisamment comprise pour être réalisée dans un sprint. - En cours de développement dans un sprint - Fini à la fin du sprint
- Effort de développement : Reflété par la valeur de l’attribut taille
- Elément prioritaire, en tête de liste : va bientôt être développé, suffisamment détaillé -> petite taille - Elément au milieu du backlog : sera développé dans quelques sprint, moyennement détaillé, -> taille moyenne (peut être décomposé) - Elément en fin de liste : sera développé plus tard -> grande taille (sera décomposé ultérieurement)
9 • L’incertitude sur des besoins utilisateurs qu’elle fera diminuer : quand un utilisateur désire une fonctionnalité mais ne sais pas de quelle façon le service doit être rendu, la solution est de lui montrer rapidement une version simple pour obtenir rapidement un feedback. • La qualité à laquelle elle contribuera : Exemple, si une rétrospective a mis en évidence la nécessité d’automatiser les test, la story correspondant aura une priorité élevée.
Un story nouvellement ajouté ne se place pas forcément en dernier, il faut lui donner un priorité par rapport aux autres : Changer l’ordre des priorité pour les raisons suivantes : - Meilleure connaissance d’une story - Découverte d’un bug ou besoin d’une étude - Estimation de l’effort pour la développer - Son utilité potentiel peut changer au fil du temps - La planification d’un sprint peut changer les priorités pour ajuster le périmètre à l’engagement de l’équipe
10 11 Jalon mineur : fin du sprint Jalon majeur : production de la release
12 • Spécification fonctionnelle : Recueil des besoins et analyse • Architecture générale : conception • Les activités ne se font pas forcément successivement : on produit plusieurs versions intermédiaires pendant le sprint (utilisés par l’équipe et le product owner), chacune ajoutant un micro-incrément à la précédente. On fait de l’intégration continue.
Avantages : - Tests précoces (dès le premier sprint) - Approche réaliste et pragmatique
Produit : incrément potentiellement livrable (pas potentiellement utilisable) au moins a
des utilisateurs privilégiés, avec si nécessaire de la documentation. Utilisation du produit : • Utilisation interne : uniquement par l’équipe (souvent au début du développement) • Utilisation pour feedback par des utilisateurs sélectionnés : permet de réduire les risques portant sur l’ergonomie et aux utilisateurs de prendre la main, de retours permettent d’alimenter le backlog • Mise en production : pas généralement faisable, nécessite beaucoup de temps pour les test de recette sur tout le système, déployer l’environnement de production, écrire les manuels utilisateurs, préparer et donner les formations aux utilisateurs…
13 • Une release dure environs trois mois avec des sprints de 2 ou 3 semaines • Possibilité d’arrêter un sprint en cours en cas de problème majeur (impossibilité de présenter quelque chose à la fin du sprint) mais idéal d’attendre la fin normale et de tirer les enseignements lors de la rétrospective. • Rythme soutenable du manifeste agile
14 Le début de release nécessite plus de temps si le projet s’appuie sur une nouvelle technologie Ne pas démarrer les sprints trop vite avant que la planification de release ne soit élaborée
Release : produit livrable, fourni à ses utilisateurs.
Rendre le produit robuste à chaque sprint plutôt qu’à la fin du release
15 Durée du sprint : - Initialement 30 jours - Actuellement 2 semaines en moyenne
16 17 Représente dans l’équipe toutes les personnes qui utilisent ou qui vont utiliser le produit
18 Une seule personne • Parler d’une seule voix : il est préférable qu’il soit présent lorsqu’il fait intervenir d’autres personnes ( difficulté à s’approprier le produit) • Ne pas déléguer trop de responsabilités (Product Owner Proxy) à cause de l’indisponibilité • Un groupe de PO doit avoir un responsable : grand projet, connaissance disséminée, manque de temps (donne la vision globale et arbitre en cas de conflit d’intérêt)
19 Responsabilités stratégiques : sont d’habitude du ressort de la direction du projet ou des comités de pilotage Responsabilités tactiques : il prend les décisions qui sont habituellement prises par l’équipe de développement faute d’implication des clients
Fournir une vision globale et partagée : doit avoir une bonne vision du produit (quoi et pourquoi) • Objectif visé par le produit (Ex : énoncé du problème à résoudre) • Position du produit claire pour tout le monde • Liste de fonctionnalités essentielles
Définir le produit : S’occupe du backlog du produit
• Identifie les fonctionnalités requises collectées dans un liste • Fournit les conditions de satisfaction qui permettront de s’assurer que ce qu’il demande est bien réalisé (impliqué dans les tests d’acceptation)
Planifier la vie du produit
• Alimente l’équipe avec les fonctionnalités à développer, selon ses priorités • Définit l’objectif d’une release, son contenu et sa date de mise à disposition
Il a une grande influence sur le produit
20 Ne doit pas imposer ses choix
20 Bonne connaissance du domaine • Domaine métier = cœur de métier : domaine de connaissance en relation avec le quoi ( ce que doit faire le produit) et le pourquoi (la justification de l’existence du produit) du produit • Ne pas forcément tout connaître; peut s’appuyer sur les bonnes personnes si nécessaire
Maitriser des techniques de définition de produit
• Maîtrise les techniques de collecte des besoins et de leur transformation en éléments (user stories ou use cases) du backlog de produit
Capacité à prendre des décisions rapidement
• Décider et fédérer les points de vue en cas d’avis contradictoires des intervenants
Capacité à détailler au bon moment :
• Anticiper en se basant sur les priorités : ce qui est plus prioritaire doit être prêt en premier • Décompose et détaille, au bon moment le contenu du produit
Esprit ouvert au changement
• S’adapte
21 • Prend compte des feedbacks • Mettre à jour le backlog • Ajuster la vision • Solliciter des idées de changement auprès des utilisateurs et de l’équipe • Ne doit pas être une girouette (changer tout le temps)
Aptitude à la négociation • Rencontrer souvent l’équipe : venir au scrum quotidien et rester discuter les développeurs • Faire un binôme avec un développeur pour connaitre l’environnement de développement et le fonctionnement d’une story • Négocier fréquemment avec l’équipe et être convaincant pour justifier ses prises de position
21 Plus la fin de release se rapproche, plus le temps que le product owner devrait consacrer au projet augmente : • Priorités difficiles à décider • Tests à passer plus nombreux • Etc.
22 Une grande partie du travail du chef de projet (projet traditionnel) est dévolue au Product Owner, une autre partie est laissée à l’équipe. Les membres de l’équipe s’organisent eux même et n’ont pas besoin d’un chef qui leur assigne des tâches.
23 24 Bonne connaissance de Scrum : • De préférence, avoir une expérience dans la mise en œuvre de Scrum (afin de pouvoir adapter Scrum au contexte) • Connaître les valeurs et les principes du manifeste agile
Aptitude à comprendre les aspects techniques
• Avoir une expérience dans le métier : facilite la communication avec le Product Owner et permet de mieux impliquer l’équipe dans la recherche de la valeur pour le produit
Facilité à communiquer • Obtenir la confiance des membres de l’équipe • Faire de sorte que les réunion du cérémonial se déroulent efficacement
Capacité à guider • Meneur d’hommes • Motive l’équipe pour arriver aux résultats
Talent de médiateur • Ne pas prendre systématiquement partie contre le Product Owner • Peut proposer une mesure plus radicale en cas de désaccord (changer une personne
25 de l’équipe)
Ténacité • Poursuivre sa quête sans relâche • Etre convaincant • N’abandonne pas à la première adversité
Inclination à la transparence • S’assure de la communication des productions de l’équipe (graphiques, rapports d’avancement, etc.) • Mettre en évidence les dysfonctionnements au plus tôt
Goût à être au service de l’équipe
• Soutient la résolution des conflit • Encourage la prise d’autonomie vers plus d’auto-organisation
Eviter qu’une personne soit :
• Le scrumMaster de plusieurs équipes • En même temps ScrumMaster et Product Owner
La personne qui joue le rôle de ScrumMaster peut changer à chaque sprints ou au bout de quelques sprints • Communique avec l’équipe et le management
