SlideShare une entreprise Scribd logo
SCRUM et méthodes agiles
SCRUM et méthodes agiles
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é
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é
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
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é
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
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é
Schéma général
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
● Toute l’équipe doit être présente
● 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
● Toute l’équipe doit être présente
● 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, …)
:)
:|
:(
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é
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
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é
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
Problèmes fréquents (2)
● 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
Problèmes fréquents (3)
● 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
Problèmes fréquents (4)
● 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 fréquents (5)
● 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
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é
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
ScrumBan => agilité +
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
ScrumBan => agilité +
● 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
Scrum et Lean => agilité ++
● 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 =
Scrum et Lean => agilité ++
● 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
Scrum et Lean => agilité ++
● 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
Scrum et Lean => agilité ++
● 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
Scrum et Lean => agilité ++
Tâches
+/- 2σ
=
95%
+/- 3σ
=
99,7%
Tempsdecycle
Scrum et Lean => agilité ++
● 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
Scrum et Lean => agilité ++
● 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)
Résultat
Questions / réponses
The end

Contenu connexe

Tendances

XebiCon'17 : Monitoring et métrologie pour les conteneurs - Jean-Pascal Thie...
XebiCon'17 : Monitoring et métrologie pour les conteneurs - Jean-Pascal Thie...XebiCon'17 : Monitoring et métrologie pour les conteneurs - Jean-Pascal Thie...
XebiCon'17 : Monitoring et métrologie pour les conteneurs - Jean-Pascal Thie...
Publicis Sapient Engineering
 
XebiCon'17 : La refonte d'applications natives from scratch, un pari gagnant ...
XebiCon'17 : La refonte d'applications natives from scratch, un pari gagnant ...XebiCon'17 : La refonte d'applications natives from scratch, un pari gagnant ...
XebiCon'17 : La refonte d'applications natives from scratch, un pari gagnant ...
Publicis Sapient Engineering
 
Patterns pour porter son code SharePoint vers Office 365 (SharePoint Saturday...
Patterns pour porter son code SharePoint vers Office 365 (SharePoint Saturday...Patterns pour porter son code SharePoint vers Office 365 (SharePoint Saturday...
Patterns pour porter son code SharePoint vers Office 365 (SharePoint Saturday...
serge luca
 
XebiCon'17 : Déploiement continu de modèle de Machine Learning - Loïc Divad
XebiCon'17 : Déploiement continu de modèle de Machine Learning - Loïc DivadXebiCon'17 : Déploiement continu de modèle de Machine Learning - Loïc Divad
XebiCon'17 : Déploiement continu de modèle de Machine Learning - Loïc Divad
Publicis Sapient Engineering
 
Integrons en mode continu
Integrons en mode continuIntegrons en mode continu
Integrons en mode continu
neuros
 
Puppet, la philosophie DevOps
Puppet, la philosophie DevOpsPuppet, la philosophie DevOps
Puppet, la philosophie DevOps
Jeoffrey Bauvin
 
Au secours, mon chef m'a demandé de passer au DevOps
Au secours, mon chef m'a demandé de passer au DevOpsAu secours, mon chef m'a demandé de passer au DevOps
Au secours, mon chef m'a demandé de passer au DevOps
antony_guilloteau
 
[Codeur en seine] Les Pipelines Jenkins dans la vraie vie
[Codeur en seine] Les Pipelines Jenkins dans la vraie vie[Codeur en seine] Les Pipelines Jenkins dans la vraie vie
[Codeur en seine] Les Pipelines Jenkins dans la vraie vie
Jean-Philippe Briend
 
l'Industrialisation (avec PHP) @MMIConnect
l'Industrialisation (avec PHP) @MMIConnectl'Industrialisation (avec PHP) @MMIConnect
l'Industrialisation (avec PHP) @MMIConnect
Florent DENIS
 
XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...
XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...
XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...
Publicis Sapient Engineering
 
Realworld cd pipelines
Realworld cd pipelines Realworld cd pipelines
Realworld cd pipelines
TREEPTIK
 
Trouver le chemin des bonnes pratiques
Trouver le chemin des bonnes pratiquesTrouver le chemin des bonnes pratiques
Trouver le chemin des bonnes pratiques
Gauthier Delamarre
 
Symfony et Sonata Project chez Canal+
Symfony et Sonata Project chez Canal+ Symfony et Sonata Project chez Canal+
Symfony et Sonata Project chez Canal+
ekino
 
Intégration de SonarQube dans GitLab ci
Intégration de SonarQube dans GitLab ciIntégration de SonarQube dans GitLab ci
Intégration de SonarQube dans GitLab ci
wiemfourati
 
Jenkins - perdre du temps pour en gagner
Jenkins - perdre du temps pour en gagnerJenkins - perdre du temps pour en gagner
Jenkins - perdre du temps pour en gagner
Geeks Anonymes
 

Tendances (15)

XebiCon'17 : Monitoring et métrologie pour les conteneurs - Jean-Pascal Thie...
XebiCon'17 : Monitoring et métrologie pour les conteneurs - Jean-Pascal Thie...XebiCon'17 : Monitoring et métrologie pour les conteneurs - Jean-Pascal Thie...
XebiCon'17 : Monitoring et métrologie pour les conteneurs - Jean-Pascal Thie...
 
XebiCon'17 : La refonte d'applications natives from scratch, un pari gagnant ...
XebiCon'17 : La refonte d'applications natives from scratch, un pari gagnant ...XebiCon'17 : La refonte d'applications natives from scratch, un pari gagnant ...
XebiCon'17 : La refonte d'applications natives from scratch, un pari gagnant ...
 
Patterns pour porter son code SharePoint vers Office 365 (SharePoint Saturday...
Patterns pour porter son code SharePoint vers Office 365 (SharePoint Saturday...Patterns pour porter son code SharePoint vers Office 365 (SharePoint Saturday...
Patterns pour porter son code SharePoint vers Office 365 (SharePoint Saturday...
 
XebiCon'17 : Déploiement continu de modèle de Machine Learning - Loïc Divad
XebiCon'17 : Déploiement continu de modèle de Machine Learning - Loïc DivadXebiCon'17 : Déploiement continu de modèle de Machine Learning - Loïc Divad
XebiCon'17 : Déploiement continu de modèle de Machine Learning - Loïc Divad
 
Integrons en mode continu
Integrons en mode continuIntegrons en mode continu
Integrons en mode continu
 
Puppet, la philosophie DevOps
Puppet, la philosophie DevOpsPuppet, la philosophie DevOps
Puppet, la philosophie DevOps
 
Au secours, mon chef m'a demandé de passer au DevOps
Au secours, mon chef m'a demandé de passer au DevOpsAu secours, mon chef m'a demandé de passer au DevOps
Au secours, mon chef m'a demandé de passer au DevOps
 
[Codeur en seine] Les Pipelines Jenkins dans la vraie vie
[Codeur en seine] Les Pipelines Jenkins dans la vraie vie[Codeur en seine] Les Pipelines Jenkins dans la vraie vie
[Codeur en seine] Les Pipelines Jenkins dans la vraie vie
 
l'Industrialisation (avec PHP) @MMIConnect
l'Industrialisation (avec PHP) @MMIConnectl'Industrialisation (avec PHP) @MMIConnect
l'Industrialisation (avec PHP) @MMIConnect
 
XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...
XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...
XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...
 
Realworld cd pipelines
Realworld cd pipelines Realworld cd pipelines
Realworld cd pipelines
 
Trouver le chemin des bonnes pratiques
Trouver le chemin des bonnes pratiquesTrouver le chemin des bonnes pratiques
Trouver le chemin des bonnes pratiques
 
Symfony et Sonata Project chez Canal+
Symfony et Sonata Project chez Canal+ Symfony et Sonata Project chez Canal+
Symfony et Sonata Project chez Canal+
 
Intégration de SonarQube dans GitLab ci
Intégration de SonarQube dans GitLab ciIntégration de SonarQube dans GitLab ci
Intégration de SonarQube dans GitLab ci
 
Jenkins - perdre du temps pour en gagner
Jenkins - perdre du temps pour en gagnerJenkins - perdre du temps pour en gagner
Jenkins - perdre du temps pour en gagner
 

Similaire à Symposium scrum

Module 3 - Seance 1 - Scrum.pptx
Module 3 - Seance 1 - Scrum.pptxModule 3 - Seance 1 - Scrum.pptx
Module 3 - Seance 1 - Scrum.pptx
testuser715939
 
Scrum course
Scrum courseScrum course
Scrum course
Lhouceine OUHAMZA
 
intelco Méthodes agiles - Scrum_2021.pdf
intelco Méthodes agiles - Scrum_2021.pdfintelco Méthodes agiles - Scrum_2021.pdf
intelco Méthodes agiles - Scrum_2021.pdf
SteevePaladin
 
1.pdf
1.pdf1.pdf
1.pdf
DabiYonko
 
Methodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XPMethodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XP
Nicolas Perriault
 
Scrum les principes de base
Scrum les principes de base Scrum les principes de base
Scrum les principes de base
Sirine Barguaoui
 
Présentation.pptx
Présentation.pptxPrésentation.pptx
Présentation.pptx
medziedhaddar
 
Evenements scrum
Evenements scrumEvenements scrum
Evenements scrum
MICHRAFY MUSTAFA
 
books_Agile.pdf
books_Agile.pdfbooks_Agile.pdf
books_Agile.pdf
Axiome1
 
Mon cours Agile scrum.ppt
Mon cours Agile scrum.pptMon cours Agile scrum.ppt
Mon cours Agile scrum.ppt
amani75494
 
Les Z'ApéroTech Toulouse #2 - Présentation de l'agilité à l'échelle
Les Z'ApéroTech Toulouse #2 - Présentation de l'agilité à l'échelleLes Z'ApéroTech Toulouse #2 - Présentation de l'agilité à l'échelle
Les Z'ApéroTech Toulouse #2 - Présentation de l'agilité à l'échelle
DocDoku
 
Les principales méthodes de gestion de projets
Les principales méthodes de gestion de projetsLes principales méthodes de gestion de projets
Les principales méthodes de gestion de projets
Laurence Genty
 
Introduction à l'agilité iut lyon 1 sept2013
Introduction à l'agilité   iut lyon 1 sept2013Introduction à l'agilité   iut lyon 1 sept2013
Introduction à l'agilité iut lyon 1 sept2013
agnes_crepet
 
Introduction à l'agilité ensmse
Introduction à l'agilité   ensmseIntroduction à l'agilité   ensmse
Introduction à l'agilité ensmse
agnes_crepet
 
Initiation Scrum
Initiation ScrumInitiation Scrum
Initiation Scrum
Frantz Degrigny
 
Scrum 2020 : concepts et principes
Scrum 2020 : concepts et principesScrum 2020 : concepts et principes
Scrum 2020 : concepts et principes
MICHRAFY MUSTAFA
 
Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010
Dominic Danis
 
Scrum cook and go, les astuces de Rémy
Scrum cook and go, les astuces de RémyScrum cook and go, les astuces de Rémy
Scrum cook and go, les astuces de Rémy
antony_guilloteau
 
Drupal, scrum et l'agilité - Drupalcamp Paris 2013
Drupal, scrum et l'agilité - Drupalcamp Paris 2013Drupal, scrum et l'agilité - Drupalcamp Paris 2013
Drupal, scrum et l'agilité - Drupalcamp Paris 2013
Artusamak
 

Similaire à Symposium scrum (20)

Module 3 - Seance 1 - Scrum.pptx
Module 3 - Seance 1 - Scrum.pptxModule 3 - Seance 1 - Scrum.pptx
Module 3 - Seance 1 - Scrum.pptx
 
Scrum course
Scrum courseScrum course
Scrum course
 
intelco Méthodes agiles - Scrum_2021.pdf
intelco Méthodes agiles - Scrum_2021.pdfintelco Méthodes agiles - Scrum_2021.pdf
intelco Méthodes agiles - Scrum_2021.pdf
 
1.pdf
1.pdf1.pdf
1.pdf
 
Methodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XPMethodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XP
 
Scrum les principes de base
Scrum les principes de base Scrum les principes de base
Scrum les principes de base
 
Présentation.pptx
Présentation.pptxPrésentation.pptx
Présentation.pptx
 
Evenements scrum
Evenements scrumEvenements scrum
Evenements scrum
 
books_Agile.pdf
books_Agile.pdfbooks_Agile.pdf
books_Agile.pdf
 
Mon cours Agile scrum.ppt
Mon cours Agile scrum.pptMon cours Agile scrum.ppt
Mon cours Agile scrum.ppt
 
Introduction scrum
Introduction scrumIntroduction scrum
Introduction scrum
 
Les Z'ApéroTech Toulouse #2 - Présentation de l'agilité à l'échelle
Les Z'ApéroTech Toulouse #2 - Présentation de l'agilité à l'échelleLes Z'ApéroTech Toulouse #2 - Présentation de l'agilité à l'échelle
Les Z'ApéroTech Toulouse #2 - Présentation de l'agilité à l'échelle
 
Les principales méthodes de gestion de projets
Les principales méthodes de gestion de projetsLes principales méthodes de gestion de projets
Les principales méthodes de gestion de projets
 
Introduction à l'agilité iut lyon 1 sept2013
Introduction à l'agilité   iut lyon 1 sept2013Introduction à l'agilité   iut lyon 1 sept2013
Introduction à l'agilité iut lyon 1 sept2013
 
Introduction à l'agilité ensmse
Introduction à l'agilité   ensmseIntroduction à l'agilité   ensmse
Introduction à l'agilité ensmse
 
Initiation Scrum
Initiation ScrumInitiation Scrum
Initiation Scrum
 
Scrum 2020 : concepts et principes
Scrum 2020 : concepts et principesScrum 2020 : concepts et principes
Scrum 2020 : concepts et principes
 
Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010
 
Scrum cook and go, les astuces de Rémy
Scrum cook and go, les astuces de RémyScrum cook and go, les astuces de Rémy
Scrum cook and go, les astuces de Rémy
 
Drupal, scrum et l'agilité - Drupalcamp Paris 2013
Drupal, scrum et l'agilité - Drupalcamp Paris 2013Drupal, scrum et l'agilité - Drupalcamp Paris 2013
Drupal, scrum et l'agilité - Drupalcamp Paris 2013
 

Symposium scrum

  • 3. 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é
  • 4. 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
  • 5. 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.
  • 6. 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.
  • 7. 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.
  • 8. 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
  • 9. 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é
  • 10. 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é
  • 11. 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é
  • 12. 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
  • 13. 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
  • 15. 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é
  • 16. 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
  • 17. 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
  • 18. 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)
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. 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é
  • 25. 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, …)
  • 26. 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
  • 27. 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
  • 28. Scrum meeting ● Toute l’équipe doit être présente ● 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é
  • 29. 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
  • 30. Rétrospective de sprint ● Toute l’équipe doit être présente ● 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
  • 31. 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é
  • 32. 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é
  • 33. Les indicateurs (2) Jours Tâches Temps de cycle WIP Diagramme de flux cumulés
  • 34. Les indicateurs (3) ● Le burndown chart : représente le RAF théorique (en points d’effort) par rapport au RAF réel
  • 35. Les indicateurs (4) ● Le Niko-Niko : mesure l’état d’esprit et l’enthousiasme de l’équipe : ● Les indicateurs standards de qualité (code, anomalies, …) :) :| :(
  • 36. 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é
  • 37. 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
  • 38. 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é
  • 39. 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
  • 40. Problèmes fréquents (2) ● 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
  • 41. Problèmes fréquents (3) ● 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
  • 42. Problèmes fréquents (4) ● 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
  • 43. Problèmes fréquents (5) ● 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
  • 44. 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
  • 45. Scrum best practices (2) ● Limiter autant que possible le multi-tâche (cf jeu du prénom)
  • 46. 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
  • 47. 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é
  • 48. 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
  • 49. 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
  • 50. ScrumBan => agilité + 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
  • 51. ScrumBan => agilité + ● 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é
  • 52. 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
  • 53. Scrum et Lean => agilité ++ ● 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 =
  • 54. Scrum et Lean => agilité ++ ● 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
  • 55. Scrum et Lean => agilité ++ ● 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
  • 56. Scrum et Lean => agilité ++ ● 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
  • 57. Scrum et Lean => agilité ++ Tâches +/- 2σ = 95% +/- 3σ = 99,7% Tempsdecycle
  • 58. Scrum et Lean => agilité ++ ● 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
  • 59. Scrum et Lean => agilité ++ ● 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)