Vous êtes sur la page 1sur 32

1

2
3
Shippable=livrable

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

25
26
27
28

Vous aimerez peut-être aussi