Symposium scrum

SCRUM et méthodes agiles
1. Philosophie
2. Les rôles
3. Les items
4. Déroulement d’un projet agile
5. Outils de suivi de projets agiles
6. Les outils de support
7. Problèmes fréquents et solutions
8. Encore plus d’agilité

Le manifeste agile
● Rédigé en Février 2001
● Issu d’une réunion entre 17 experts du développement logiciel
● Défini le noyau commun aux différentes méthodes agiles
● Composé de 4 valeurs et 12 principes

Les 4 valeurs
● Les individus et leurs interactions plus que les processus et les outils
● Du logiciel qui fonctionne 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.

Les 12 principes (1)
● Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur
ajoutée.
● Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le
changement pour donner un avantage compétitif au client.
● Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour
les plus courts.
● Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du
projet.
● Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-
leur confiance pour atteindre les objectifs fixés.
● La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de
celle-ci est le dialogue en face à face.
● Un logiciel opérationnel est la principale mesure d’avancement.

Les 12 principes (2)
● Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les
développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
● Une attention continue à l'excellence technique et à une bonne conception renforce l’agilité.
● La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
● Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.
● À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en
conséquence.

Les fondamentaux
● Développement itératif et incrémental
● Autonomie des ressources
● Implication de l’utilisateur final (client) dans l’équipe projet
● Equipe projet avec pouvoir de décision
● Recherche continue d’amélioration

Les avantages attendus
● Suppression de l’effet tunnel
● Concentration des efforts sur la valeur métier
● Réactivité et acceptation du changement
● Amélioration de la productivité
● Amélioration du Time To Market
● Meilleure satisfaction des équipes
● Amélioration de la qualité

Product owner
● Fait partie intégrante de l’équipe
● Représente les clients et les utilisateurs
● Est responsable de l’aspect fonctionnel du projet
● Défini et explique les User story (fonctionnalités)
● Priorise les User story
● Est responsable du Backlog produit
● Valide ce qui est réalisé

ScrumMaster
● Est responsable de la compréhension et de l’application de la méthode
● Joue un rôle de facilitateur
● Elimine les obstacles pouvant nuire à l’efficacité de l’équipe
● Protège l’équipe des perturbations

Equipe de développement
● Est autonome
● Implémente les besoins exprimé par le PO
● Contient toutes les compétences nécessaire à la réalisation d’un sprint
● Veille à la cohérence de l’architecture logicielle

Organisation
ScrumMaster PO
Utilisateurs stakeholders
Equipe Scrum

User story
● Traduit une fonctionnalité du produit
● Se présente sous la forme “En tant que <rôle> je souhaite <action> afin de
<objectif>
● Comprend les conditions d’acceptation (Si <précondition>, lorsque
<événement>, alors <résultat>)
● Est pondérée par la valeur métier apportée
● Est initialisée avec des points d’effort

User story
● Il existe 4 types de User stories :
○ la Story fonctionnelle (apporte de la valeur)
○ la Story technique (apporte de la valeur)
○ le bug fix (rétablit la valeur perdue)
○ le refactoring (rétablit la valeur perdue)
● Doit être INVEST (Indépendante, Négociable, Valorisable, Estimable, Small,
Testable

Backlog produit
● Est une liste ordonnée de toutes les User stories du produit
● Est la source unique d’exigence portant sur le produit
● Est dynamique, il évolue en fonction de l’environnement du produit
● Est trié par valeur métier (on implémente la plus haute valeur métier d’
abord)

Backlog de sprint
● Définit un but pour le sprint
● Contient toutes les User stories à implémenter dans un sprint
● Les User stories sont découpées en tâches
● Les tâches sont estimées en heure (pas toujours)
● Dans l’idéal, une tâche ne devrait pas excéder une journée de travail
● Il définit également la “notion de fini” qui doit être partagée par l’équipe

Articulation des backlogs
Backlog produit
Backlog Sprint
User story #2
Tache 1
User
Story #1
User
story #2
User
story #3
User
Story #1
User
story #2
User story #2
Tache 2
User story #2
Tache 3
User story #1
Tache 1
User story #1
Tache 2
Tâches

Radiateur d’information
● Chaque post-it représente une tâche du sprint
● Les colonnes représentent les différents états
● Le but du sprint et les indicateurs sont affichés
● Le plan d’action relatif au sprint en cours est affiché
● Il est mis à jour durant le Scrum meeting
Attention aux femmes de ménage et aux Post-it qui se décollent
Il est recommandé de le prendre en photo tous les jours

Radiateur d’information
A FAIRE A FINIR FINI
User story #1
User story #2
User story #3
Tâche 3
Tâche 4 Tâche 2Tâche 1 Tâche 5
User story #4 Tâche 1
Tâche 2
Tâche 1 Tâche 2
Tâche 3
Tâche 4
Tâche 1
Tâche 2
Tâche 3
BUT : Implémenter la création d’un client
Définition de prêt
Définition de fini
Plan d’action
1 1 1
1 1

Sprint 0
● Initialisation du projet agile
● Préparation du backlog (estimation, priorisation, …)
● Installation de l’infrastructure
● Installation de l’équipe
● Présentation du produit à l’équipe (contexte, enjeux, …)

Réunion de planification de sprint
● Toute l’équipe doit être présente
● Le PO doit avoir préparé les User stories les plus prioritaires
● Sélection des User stories à implémenter dans le sprint à venir
● Affinage de l’estimation des User stories en point d’effort
● Décomposition des User stories en tâches
● Estimation des tâches en heure
● Préparation du backlog de sprint et du radiateur

Sprint
● Limité dans le temps (time boxing)
● Durée de 1 à 4 semaines
● Le résultat doit être démontrable
● Le backlog de sprint ne peut être modifié durant le sprint
● Les sprints s’enchaînent sans intérruption
● Doit avoir un but. L’engagement de l’équipe porte sur ce but

Scrum meeting
● 15 minutes maximum
● Articulé autour de 3 question :
○ Qu’ai-je fais la veille
○ Que vais-je faire aujourd’hui
○ Quels problèmes j’ai rencontré

Revue de sprint
● Toute l’équipe doit être présente ainsi que les stakeholders concernés
● 4H maximum
● Le Product owner présente le produit du sprint aux utilisateurs
● C’est aussi l’occasion d’échanger avec les parties prenantes du projet
(collecte de feedback)
● Le backlog produit est ensuite mis à jour

Rétrospective de sprint
● Dédiée à l'amélioration continue
● L’équipe étudie les résultats des précédents plans d’action
● L’équipe analyse ce qui a bien fonctionné durant le sprint, ce qui n’a pas
fonctionné et ce qui peut être amélioré
● A l’issue de cette réunion, un plan d’action est défini pour application durant
le sprint suivant

SCRUM et méthodes agiles
1. Philosophie
2. Les rôles
3. Les items
4. Déroulement d’un projet agile
5. Outils de suivi de projets agiles
6. Les outils de support
7. Les points clé pour réussir son projet agile
8. Encore plus d’agilité

Les indicateurs (1)
● La vélocité : représente le nombre de points d’efforts qu’une équipe peut
absorber en un sprint
● Le temps de cycle : mesure, pour chaque type de tâche, le temps moyen de
réalisation (permet de détecter l’accumulation de dette technique)
● Le diagramme de flux cumulé

Les indicateurs (2)
Jours
Tâches
Temps de cycle
WIP
Diagramme de flux cumulés

Les indicateurs (3)
● Le burndown chart : représente le RAF théorique (en points d’effort) par
rapport au RAF réel

Les indicateurs (4)
● Le Niko-Niko : mesure l’état d’esprit et l’enthousiasme de l’équipe :
● Les indicateurs standards de qualité (code, anomalies, …)
:)
:|
:(

Outils de support
● Intégration continue
● Contrôle de qualité (sonar)
● Automatisation des test (techniques et fonctionnels)
○ Le patrimoine de tests automatisés est déroulé régulièrement afin de
vérifier la non régression
● Outils de travail collaboratif

Problèmes fréquents (1)
● Accumulation de dette technique
○ Les développeurs doivent être confirmés
○ Utilisation de standards reconnu
○ Utilisation de composants réutilisables
○ Référentiel de solutions
○ Sprint de refactoring réguliers

● Manque de disponibilité du PO
○ Anticipation et fractionnement des revues de planification de sprint
○ Essayer de tendre les flux pour fluidifier le processus
○ Evangélisation sur la méthode agile (ScrumMaster)
● Chaîne de décision trop longue
○ Implication des stakeholders
○ Mise à disposition d’un bac à sable

● Backlog trop fourni
○ Création d’une roadmap produit et plan de release
○ Un Backlog produit correspondant à une release = 50 User stories
● User stories mal détaillées ou mal comprises
○ Le ScrumMaster doit s’assurer que les User stories sont bien comprises
de l’équipe avant le sprint
○ Anticipation et fractionnement des revues de planification de sprint

● Réunion trop longues et pas assez productives
○ Se tenir à l’ordre du jour de chaque réunion (organiser des réunions
séparées pour traiter d'éventuels problèmes)
○ Si les estimations sont trop chronophages, les User stories ne sont pas
claires
● Goulots d’étranglement
○ Limiter le nombre de tâches en cours par état

● Problèmes de qualité
○ Adoption de normes partagées (architecture, codage)
○ Pour quelques sprints, fixer le but sur des questions de qualité
○ Responsabiliser les développeurs
● Mini cycle en V sur un sprint
○ Découper les User stories de manière verticale et non en couches
○ Bien définir la notion de fini
○ Limiter le nombre de tâches en parallèle par développeur

Scrum best practices
● Laisser les développeurs choisir leurs tâches (volontariat)
● Garder un rythme soutenable sur le long terme (ne pas dépasser 80% de la
vélocité maximale de l’équipe)
● Coder les tests avant la fonctionnalité
● Multiplier les POC pour les problèmes ardus afin de minimiser les risques
techniques (simple design for complex problems)
● Travailler le collective ownership : chaque développeur est co-résponsable
de la totalité du code

Scrum best practices (2)
● Limiter autant que possible le multi-tâche (cf jeu du prénom)

Scrum best practices (2)
● Être TOUJOURS transparent vis à vis de tous les acteurs
● Intégrer au minimum à chaque fin de sprint (éviter l’intégration big bang qui
prend un sprint)
● INNOVER. L’amélioration continue ne s’arrête pas à l’adoption de bonnes
pratiques, il faut tester, mesurer, vérifier

Méthodes hybrides
● Garder les fondamentaux agiles
● Intégrer d’autres méthodologies en fonction de l’environnement et de la
maturité de l’équipe
● Permet de gagner en productivité ou de respecter des normes d’entreprise
(CMMI, TOGAF, ITIL, ISO, ...)
● Le changement est progressif et incrémental.
● L’impact de chaque pratique introduite est mesuré lors de la rétrospective

ScrumBan => agilité +
● Introduit des pratiques Kanban à Scrum
● Permet de passer à un modèle en flux tiré
● Introduit la notion de limitation des travaux en cours par état (WIP)
● Permet de traiter les urgences plus rapidement
● Diminuer la complexité doit rester un objectif

A FAIRE A FINIR FINI
priorité
Tâche 1
Tâche 3
urgence
Tâche 2
Limite WIP = 4
Tâche 5
Tâche 4
Limite WIP = 2
Tâche 8
Tâche 10
Tâche 9
Tâche 11
Tâche 6 Tâche 7

● Démonstration par la théorie des files d’attente (loi de Little) :
○ WIP = Vélocité * Temps de cycle moyen
○ Temps de cycle moyen = WIP / Vélocité
● Pour réduire le temps de cycle (Time To Market), il faut donc diminuer le
WIP ou augmenter la vélocité
● Pour régler la limite de WIP :
○ WIP Max = Temps de cycle moyen souhaité * vélocité

Scrum et Lean => agilité ++
● Principes Lean
○ Se focaliser sur la qualité (favoriser l’automatisation des tâches
récurrentes, TDD, ...) et sur le time to Market
○ Se concentrer sur la valeur créée
○ Éliminer les gaspillages (Muda)
○ Intégrer le Knowledge Management
○ Prendre des décisions le plus tard possible
○ Optimiser la chaîne de valeur en permanence (Kaizen)
kaizen :
Amélioration continue
kai :
Changement
zen :
meilleur

● Exemple de modélisation de la chaîne de valeur
Demande d’
évolution
Création d’une
User story
Attente de
formalisation
Ajout au
backlog produit
2 jours
Attente de fin
de sprint
5 jours
Ajout au
backlog sprint
Attente prise
en compte
tâche
3 jours
Implémentation
Attente de fin
de sprint
4 jours
Livraison
Attente de
déploiement
2 jours
Mise en prod
0,5 jour 0,5 jour 0,5 jour
3 jour 1 jour 1 jour
temps à valeur ajoutée (6,5 jours)
temps total (22,5)
= 29 %Taux de Rendement Global =

● Les 7 sources de gaspillage appliquées à l’ingénierie logicielle :
Attente Attente de réponse/décision, libération des ressources
Transports/transferts Communication inefficace, manque de partage de l’information
Processus excessif Compétences inadéquates, fonctionnalités inutiles, documentation excessive
Stock Goulot d'étranglement, variabilité excessive, capacité saturée, multitâche
Mouvement Manque d’accès direct à des ressources, chasse à l’information
Non qualité Bugs, réinvention, pas d’appropriation collective du code, manque de standardisation
Surproduction Manque d’automatisation, mauvaise priorisation

● Trouver et éliminer les causes de gaspillage
○ Diagramme de causes à effet
■ 5 axes : les 5 M
○ Diagramme de Pareto
■ 20% des causes produisent
80% des effets

● Estimation et planification
○ De plus en plus considéré comme une tâche sans valeur ajoutée(
mouvement #noEstimate)
○ Traditionnellement basée sur des approximations
■ Règle du *2 + 10%
○ Souvent source de conflit entre le PO et le reste de l’équipe
○ De moins en moins fiable au fil du temps (cumul de dérives)
○ Reste nécessaire dans beaucoup de projets

Tâches
+/- 2σ
=
95%
+/- 3σ
=
99,7%
Tempsdecycle

● Placer le processus sous contrôle statistique
● Se baser sur des faits mesurés
● Améliorer la prédictibilité du processus
● La prévision s’améliore avec le temps
● Permet de détecter les anomalies dans le processus au plus tôt

● Production en flux tendus (tendance à privilégier le flux continu par rapport
aux sprints)
● Elimination des tâches sans valeur ajoutée
● Passe en mode processus contrôlé
● Facilite le travail entre équipe très spécialisées
● Augmente le feedback via une mise en place systématique de boucle
● Capitalise sur les connaissances acquises
● Gain de productivité de 20 à 40 % (étude McKinsey)

Symposium scrum

Contenu connexe

Tendances

Similaire à Symposium scrum

Symposium scrum