SlideShare une entreprise Scribd logo
1  sur  69
Télécharger pour lire hors ligne
Méthodologies agiles
17/10/2018 UCL
!1
Ronan GUILLAMET
ronan@meziant.biz
• Consultant en architecture IT et en développement depuis 14 ans.

• Agiliste convaincu, pratiquant la méthode Scrum et Kanban.

• 7 ans d’expérience dans le secteur de l’énergie.
!2
Disclaimers
• Vocabulaire Français / Anglais

• Outils présentés
Agenda
La conception logicielle

Du waterfall aux méthodes agiles

Scrum 

Kanban

Antipatterns agiles

Vers l’organisation agile
!3
La conception
logicielle
!4
!5
Quelques statistiques
!6
Source : PMI's Pulse of the profession study « Capturing the value of project management » 2015
Sur 3000 organisations (petites, grandes, tous secteurs, tous pays)

39% des projets aboutissent (livrés dans les délais dans le respect du
budget et des fonctionnalités requises).

43% des projets sont livrés en rencontrant des problèmes

18% échouent (abandonnés ou non utilisés)
Les grandes étapes
Cahier des charges.

Comprendre les exigeances métiers et les analyser en terme de fonctionnalités.

Proposer une architecture répondant aux besoins fonctionnels (métiers) et non fonctionnels (sécurité,
performance…).

Planification

Réalisation

Tests

Déploiement

Maintenance
!7
La méthodologie Waterfall
!8
Source : https://unsplash.com/@billy_huy
Waterfall
• Approche séquentielle et systématique. 

• Pas ou peu d’intéractions avec le clients qui
réceptionnera le projet à date fixée par le
contrat.

• Tout doit être prévu dans les moindres détails.
Ainsi, le client doit savoir exactement ce qu’il
veut.

• Ne prend pas en compte les changements de
périmètres qui pourraient intervenir en cours
de réalisation.
!9
Points positifs
Convient pour les projets long terme évoluant dans
un marché stable comme

La fabrication de composants électroniques

La fabrication de voitures

L’industrie du jeux video

Simple a mettre en oeuvre, logique, intuitif et
structuré

Facilite (théoriquement) l’estimation du budget, du
temps et des ressources nécessaires
!10
https://unsplash.com/photos/FG1h_fj9WHc
Points négatifs
Manque de flexibilité

Risques importants de déception des clients si la réalisation ne
correspond pas finalement aux besoins réels.

Risque important de dépassement des coûts. Chaque changement
peut remettre en cause le planning puisque chaque étape est
concerné par le moindre changement.
!11
Les challenges actuels
!12
Aujourd’hui, la réalité de nombreux marchés…
!13
Les sociétés doivent s’adapter de plus en plus vite à la réalité des
marchés.

Les sociétés doivent s’adapter rapidement aux changements de
législation. 

Dans beaucoup de secteurs très concurrentiels, la notion de Time to
Market est essentielle : être présent avant les autres.

Dans ces conditions, les clients ne savent pas exactement ce qu’ils
veulent parce qu’ils explorent de nouvelles manières d’aborder leurs
marchés grâce à l’essort de la tech (data driven, machine learning, AI).
Le triangle du projet
Budget Périmètre (fonctionalités)
Temps
Un projet consiste à développer
des fonctionnalités dans une
limite de temps et de budget.

Sur le terrain, on s’aperçoit qu’il
est très difficile de fixer ces 3
paramètres.
!14
Business IT
• On a tendance souvent à opposer “Business” et “IT”…

• “Le Business” désigne les personnes qui ont la connaissance métier et
“l’IT” désigne les informaticiens qui réalise la solution.

• C’est vrai que sur le terrain, ce sont des gens qui ont des profils très
différents, qui n’ont pas les mêmes motivations.
!15
Ce sont souvent les incompréhensions et le manque de communication
entre ces personnes qui sont a l’origine de leurs échecs
On a besoin d’une approche
différente
!16
2001, le manifeste agile
!17
http://agilemanifesto.org/
Historique
• 1886 - Première utilisation de la métaphore de la mêlée dans une publication intitulée The
New Product Development Game par Hirotaka Takeuchi et Ikujira Nonaka.

• 1991 - La méthode RAD : amène pour la première fois les notions itératif, incrémental et
adaptatif.

• 1995 - Ken Schwaber et Jeff Sutherland présente les grands principes de la méthodologie
Scrum

• 1999 - Extreme Programming (XP) : met en avant des pratiques de développement et non
organisationnelles.

• 2001 - Sortie du Manifeste agile, texte rédigé par 17 experts en développement logiciel
estimant que la méthode Waterfall n’était plus en phase avec les exigences de beaucoup
d’organisations.

• 2002 - La méthodologie Scrum est décrite en détails dans le livre Agile Software Development
with Scrum par Ken Schwaber et Mike Beedle
!18
Facile à comprendre et intuitif, non ?
!19
Mais en pratique, au quotidien ce sont des principes difficiles
à mettre en oeuvre car ils nous demandent d’agir sur notre
comportement.
Scrum
!20
https://unsplash.com/photos/txDt77eRGrM
!21
Les principaux rôles
!22
!23
Scrum master
Est le liant entre tous les membres de l’équipe. C’est un facilitateur, un coach
pour les membres de son équipe pour les guider dans leurs rôles respectifs.

C’est lui qui représente l’équipe auprès des autres équipes et de la hiérarchie. 

A une autorité sur l’application de la méthodologie Scrum

N’est pas un manager!

C’est un “servant leader” : Il se met à la disposition de l’équipe pour 

organiser les rituels et maintenir les délivrables

garantir que l’équipe puisse avancer sereinement sans pressions externes

de maintenir une vélocité optimale en taclant les points de blocages
!24
Equipe de développement
L’équipe de développement est auto-organisée et choisi la
façon d’accomplir le travail.

L’équipe est pluri-disciplinaire

Composée de 3 à 7 développeurs

L’équipe s’engage a délivrer un produit en fin de sprint
!25
Product Owner (PO)
C’est la voix du client, en capturant ses besoins et ses attentes.

Il est responsable de traduire les besoins du clients en fonctionnalités
claires que l’équipe de développement peut estimer et tester : les user
stories.

Le PO se met au service de l’équipe de développement pour clarifier la
teneur des User Stories
!26
Key users
Ce sont des utilisateurs sélectionnés et qui vont représenter l’ensemble
des utilisateurs.

Leur implication est essentielle dans la phase de capture des besoins
mais aussi lorsqu’un incrément (le produit d’un sprint) doit être
démontré.
Les rituels Scrum
!27
• Ce sont des rencontres codifiées entres tous les intervenants d’un projet. 

• Chaque rituel a un objectif précis et produit un ou plusieurs délivrables

• Les rituels Scrum sont :

Le sprint planning meeting

Le daily standup

La revue de sprint

La retrospective
Chronologie d’un Sprint
!28
Avant le sprint
!29
!30
Le PO a la charge d’établir un product backlog
!31
https://unsplash.com/photos/mh0j74mGeco
• Le product backlog garde tous les
besoins clients exprimés au PO.

• Le PO a la responsabilité de prioriser
le product backlog.

• Seules les stories “complète”
intégreront le sprint.
Les stories
Les stories représentent les fonctionnalités
qui doivent être développées. Elles expriment
une idée et répondent à un besoin du client.
!32
https://unsplash.com/photos/mh0j74mGeco
Les stories contiennent les informations
minimales pour que la charge de travail soit
raisonnablement estimées par l’équipe.
“En tant que client, je veux suivre ma consommation
afin de maitriser mon budget”
!33
Critères I.N.V.E.S.T d’une story :

Independent

Negociable

Valuable

Estimable

Small

Testable
Critères 3C d’une story :

Card : la story est écrite
sur une carte

Conversation : Le détail
de la story est discutée

Confirmation : des critères
d’acceptation sont
formulés.
Qui et Quand ?

Tout le monde est
légitime pour écrire une
story qui alimentera le
product backlog. Le PO
valide sa pertinence.

N’importe quand
!34
https://unsplash.com/photos/mh0j74mGeco
DOR - Definition Of Ready

Quels sont les critères
permettant d’affirmer qu’une
“user story” est prête à être
développée.

DOD - Definition Of Done

Quels sont les critères
permettant d’affirmer qu’une
“user story” est réalisée.
Délivrable de l’équipe
!35
https://burst.shopify.com/photos/tech-group-meeting-flatlay
Sprint planning
• Marque le début d’un sprint.

• Organisé par le Scrum master

• Le PO a la responsabilité d’alimenter le
contenu du sprint (sprint backlog)

• Dialogue entre le PO et l’équipe pour estimer
au mieux les stories.

• L’estimation des stories est réalisée en Story
Points.

• Tout le monde doit être d’accord sur les
estimations avant de commencer le sprint.
!36
https://unsplash.com/photos/mh0j74mGeco
Le sprint backlog
• Le sprint backlog accueille toutes les User
stories qui seront réalisées lors d’un
sprint.

• Il est créé à l’occasion du Sprint planning
meeting.

• La taille du Sprint backlog est négocié
avec l’équipe en fonction du nombre de
story points que l’équipe est capable de
traiter sur la durée d’un sprint.

• Dès que le sprint commence, le Sprint
backlog ne doit plus changer.
Les outils
!37
Les outils
!38
planningpoker.com Mobile apps
En cours de sprint
!39
!40
!41
https://unsplash.com/photos/r6FbzziRN88
Daily standup
• C’est le rituel le plus connu de Scrum

• 3 questions pour chaque membre :

Qu’est ce que j’ai réalisé depuis le dernier standup
meeting ?

Qu’est ce que j’ai planifié jusqu’au prochain standup
meeting ?

Y a t’il quelque chose qui ralenti ou bloque ma
progression ?

• Debout

• 15 minutes max! 

• Seuls le SM et les développeurs peuvent prendre la
parole
!42
https://unsplash.com/photos/r6FbzziRN88
Scrum board physique
Les outils
Scrum board virtuel
!43
https://unsplash.com/photos/mh0j74mGeco
L’équipe a pris l’engagement à
l’issue du sprint de délivrer un
produit, le product increment.

L’équipe s’engage à tenir à jour les
scrum boards (physique et virtuel).
Ainsi n’importe qui de l’organisation
peut constater l’avancement du
Sprint.
Délivrables de l’équipe
A la fin du sprint
!44
!45
!46
https://unsplash.com/photos/mh0j74mGeco
C’est le résultat du développement
du sprint.

Il est mis à disposition du PO et est
déployé dans un environnement où
peuvent être démontrées les
fonctionnalités aux clients.
Le product incrément
!47
https://unsplash.com/photos/bzdhc5b3Bxs
La revue de sprint (shippable product)
• C’est un moment de démonstration des
fonctionnalités développées pendant le Sprint.

• L’audience est idéalement composée du
sponsor, des utilisateurs clés, et de toute
personne concernée par le produit.

• Le PO rappel le contexte et l’objectif du Sprint

• Le Scrum Master fait le point sur le déroulement
du Sprint en présentant le burndown chart.

• Les membres de l’équipe réalisent la démo. Si
la démonstration n’est pas satisfaisante, la
story doit être réouverte.
Le burndown chart
!48
!49
La revue de sprint
• Jira pour présenter les stories
à démontrer et présenter le
burndown chart

• La démonstration se réalise
sur le produit en live (pas de
slides ppt!)

Les outils
!50
Story points

Estimation

Réalisation

Sprints
Le velocity chart
1
2
3
4
!51
Vélocité et planification
• Le calcul de la vélocité et l’activité de product backlog grooming
permettent au PO de planifier les sprints à venir.

• Le product backlog grooming est une activité récurrente consitant
à affiner, séparer, (re)prioritiser, nettoyer, estimer (grossièrement)
les user stories.

• Si une équipe est capable de traiter 50 story points, alors le PO
peut planifier des sprints d’une capacité de 50 story points.
!52
La rétrospective
Chaque membre s’exprime sur ce
qui a été et ce qui n’a pas été
durant le sprint.

C’est un rituel qui ne concerne que
l’équipe. C’est un moment qui peut
être émotionnel mais toujours dans
un esprit constructif.

C’est l’opportunité pour l’équipe
d’améliorer sa vélocité pour les
prochains sprints.
!53
La rétrospective
Tableau physique
Les outils
Tableau virtuel : https://funretro.io/
Kanban
!54
!55
!56
Le problème du multitasking
Kanban
!57
https://www.atlassian.com/agile/kanban/boards
• Kanban est une méthodologie qui s’applique aux
développements continus.

• Kanban est moins prescriptif que Scrum

• La notion de WIP (Work In Progress) Limit est centrale.

• La métrique importante est le Cycle time = temps
moyen entre la première colonne et la dernière colonne.

• Pour être efficace, les colonne du Kanban doivent
s’adapter à la réalité du terrain (exit Todo/Doing/Done).

• Le flux Kanban peut changer n’importe quand et les
éléments peuvent être ajoutés ou supprimés en
fonction des priorités.
Antipatterns agiles
!58
!59
L’écriture des user stories doit être bien maitrisée. Une story qui est mal
écrite est difficile à estimer et à réaliser.

Les standup ne doivent pas durer plus de 15 minutes.

Attention l’agilité requiert une équipe stable. Si la composition de l’équipe
change d’un sprint à l’autre, le Scrum mater ne pourra jamais mesurer la
vélocité.

Lorsqu’un sprint a commencé, tout doit être mis en oeuvre pour ne pas en
changer son contenu. 

Souvent les équipes ne font pas de rétrospectives. C’est une occasion
manquée d’amélioration des sprints suivants.

Un board Kanban sans WIP limit n’a pas d’intérêt.
!60
Le “terrain” applicatif doit être favorable
Project A
Application
monolithique
Project B
Project C
Vers l’organisation agile
!61
!62
Les niveaux de maturité de l’agilité d’une organisation
Adopter une méthodologie
Coaching
Appliquer les principes agiles aux objectifs personnels
Adopter une stratégie d’entreprise agile
Utilisation de
techniques agiles.
L’agilité est seulement
présente dans certaines
parties de l’organisation.
Suivi et application des
principes agiles pour toutes
les initiatives de l’entreprise
Suivi et application des
principes agiles pour toutes
les initiatives de l’entreprise
Suivi et application des
principes agiles pour toutes
les initiatives de l’entreprise
!63
Une équipe, un produit… facile!
!64
Comment s’organiser lorqu’on multiplie les équipes et
les produits ?
Scrum of Scrum
!65
Team level
Program level
Portfolio level
SAFe - Scaled Agile Framework
https://www.youtube.com/watch?v=tmJ_mJw8xec
!66
https://www.youtube.com/watch?v=4GK1NDTWbkY
!67
Quelques livres de chevet
!68
Merci!
!69

Contenu connexe

Similaire à Methodologies agiles

Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)David VALLAT
 
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 sept2013agnes_crepet
 
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 XPNicolas Perriault
 
Méthodologie projet, historique et innovation
Méthodologie projet, historique et innovationMéthodologie projet, historique et innovation
Méthodologie projet, historique et innovation2le
 
Aborder la transition vers l'agilité
Aborder la transition vers l'agilitéAborder la transition vers l'agilité
Aborder la transition vers l'agilitéChristophe Addinquy
 
Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)
Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)
Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)Taoufik Fekhar
 
Le Design Sprint du Géant agile
Le Design Sprint du Géant agileLe Design Sprint du Géant agile
Le Design Sprint du Géant agileRachel Jolin Dubois
 
Presentation sa fe 2 zoom sur pi planning safe v1.0
Presentation sa fe 2 zoom sur pi planning safe v1.0Presentation sa fe 2 zoom sur pi planning safe v1.0
Presentation sa fe 2 zoom sur pi planning safe v1.0Pierre Medina
 
Le Burn-Out Agile - Devoxx MA
Le Burn-Out Agile - Devoxx MALe Burn-Out Agile - Devoxx MA
Le Burn-Out Agile - Devoxx MACedric Moulard
 
Du Manifeste Agile à Scrum
Du Manifeste Agile à ScrumDu Manifeste Agile à Scrum
Du Manifeste Agile à ScrumXavier Warzee
 
Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...
Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...
Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...French Scrum User Group
 
Formation agilité dans les projets et dans les structures
Formation agilité dans les projets et dans les structuresFormation agilité dans les projets et dans les structures
Formation agilité dans les projets et dans les structuresMed Chab
 

Similaire à Methodologies agiles (20)

Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
 
XP+Scrum+DevOps
XP+Scrum+DevOpsXP+Scrum+DevOps
XP+Scrum+DevOps
 
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
 
Présentation.pptx
Présentation.pptxPrésentation.pptx
Présentation.pptx
 
12 agile
12 agile12 agile
12 agile
 
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
 
Agile - Que le choc commence !
Agile - Que le choc commence !Agile - Que le choc commence !
Agile - Que le choc commence !
 
Méthodologie projet, historique et innovation
Méthodologie projet, historique et innovationMéthodologie projet, historique et innovation
Méthodologie projet, historique et innovation
 
Aborder la transition vers l'agilité
Aborder la transition vers l'agilitéAborder la transition vers l'agilité
Aborder la transition vers l'agilité
 
Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)
Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)
Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)
 
Agile
AgileAgile
Agile
 
Le Design Sprint du Géant agile
Le Design Sprint du Géant agileLe Design Sprint du Géant agile
Le Design Sprint du Géant agile
 
Méthodes agile
Méthodes agileMéthodes agile
Méthodes agile
 
Brochure Vers l'entreprise Agile
Brochure Vers l'entreprise AgileBrochure Vers l'entreprise Agile
Brochure Vers l'entreprise Agile
 
Presentation sa fe 2 zoom sur pi planning safe v1.0
Presentation sa fe 2 zoom sur pi planning safe v1.0Presentation sa fe 2 zoom sur pi planning safe v1.0
Presentation sa fe 2 zoom sur pi planning safe v1.0
 
Le Burn-Out Agile - Devoxx MA
Le Burn-Out Agile - Devoxx MALe Burn-Out Agile - Devoxx MA
Le Burn-Out Agile - Devoxx MA
 
Du Manifeste Agile à Scrum
Du Manifeste Agile à ScrumDu Manifeste Agile à Scrum
Du Manifeste Agile à Scrum
 
Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...
Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...
Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...
 
Formation agilité dans les projets et dans les structures
Formation agilité dans les projets et dans les structuresFormation agilité dans les projets et dans les structures
Formation agilité dans les projets et dans les structures
 

Methodologies agiles

  • 2. Ronan GUILLAMET ronan@meziant.biz • Consultant en architecture IT et en développement depuis 14 ans. • Agiliste convaincu, pratiquant la méthode Scrum et Kanban. • 7 ans d’expérience dans le secteur de l’énergie. !2 Disclaimers • Vocabulaire Français / Anglais • Outils présentés
  • 3. Agenda La conception logicielle Du waterfall aux méthodes agiles Scrum Kanban Antipatterns agiles Vers l’organisation agile !3
  • 5. !5
  • 6. Quelques statistiques !6 Source : PMI's Pulse of the profession study « Capturing the value of project management » 2015 Sur 3000 organisations (petites, grandes, tous secteurs, tous pays) 39% des projets aboutissent (livrés dans les délais dans le respect du budget et des fonctionnalités requises). 43% des projets sont livrés en rencontrant des problèmes 18% échouent (abandonnés ou non utilisés)
  • 7. Les grandes étapes Cahier des charges. Comprendre les exigeances métiers et les analyser en terme de fonctionnalités. Proposer une architecture répondant aux besoins fonctionnels (métiers) et non fonctionnels (sécurité, performance…). Planification Réalisation Tests Déploiement Maintenance !7
  • 8. La méthodologie Waterfall !8 Source : https://unsplash.com/@billy_huy
  • 9. Waterfall • Approche séquentielle et systématique. • Pas ou peu d’intéractions avec le clients qui réceptionnera le projet à date fixée par le contrat. • Tout doit être prévu dans les moindres détails. Ainsi, le client doit savoir exactement ce qu’il veut. • Ne prend pas en compte les changements de périmètres qui pourraient intervenir en cours de réalisation. !9
  • 10. Points positifs Convient pour les projets long terme évoluant dans un marché stable comme La fabrication de composants électroniques La fabrication de voitures L’industrie du jeux video Simple a mettre en oeuvre, logique, intuitif et structuré Facilite (théoriquement) l’estimation du budget, du temps et des ressources nécessaires !10 https://unsplash.com/photos/FG1h_fj9WHc
  • 11. Points négatifs Manque de flexibilité Risques importants de déception des clients si la réalisation ne correspond pas finalement aux besoins réels. Risque important de dépassement des coûts. Chaque changement peut remettre en cause le planning puisque chaque étape est concerné par le moindre changement. !11
  • 13. Aujourd’hui, la réalité de nombreux marchés… !13 Les sociétés doivent s’adapter de plus en plus vite à la réalité des marchés. Les sociétés doivent s’adapter rapidement aux changements de législation. Dans beaucoup de secteurs très concurrentiels, la notion de Time to Market est essentielle : être présent avant les autres. Dans ces conditions, les clients ne savent pas exactement ce qu’ils veulent parce qu’ils explorent de nouvelles manières d’aborder leurs marchés grâce à l’essort de la tech (data driven, machine learning, AI).
  • 14. Le triangle du projet Budget Périmètre (fonctionalités) Temps Un projet consiste à développer des fonctionnalités dans une limite de temps et de budget. Sur le terrain, on s’aperçoit qu’il est très difficile de fixer ces 3 paramètres. !14
  • 15. Business IT • On a tendance souvent à opposer “Business” et “IT”… • “Le Business” désigne les personnes qui ont la connaissance métier et “l’IT” désigne les informaticiens qui réalise la solution. • C’est vrai que sur le terrain, ce sont des gens qui ont des profils très différents, qui n’ont pas les mêmes motivations. !15 Ce sont souvent les incompréhensions et le manque de communication entre ces personnes qui sont a l’origine de leurs échecs
  • 16. On a besoin d’une approche différente !16
  • 17. 2001, le manifeste agile !17 http://agilemanifesto.org/
  • 18. Historique • 1886 - Première utilisation de la métaphore de la mêlée dans une publication intitulée The New Product Development Game par Hirotaka Takeuchi et Ikujira Nonaka. • 1991 - La méthode RAD : amène pour la première fois les notions itératif, incrémental et adaptatif. • 1995 - Ken Schwaber et Jeff Sutherland présente les grands principes de la méthodologie Scrum • 1999 - Extreme Programming (XP) : met en avant des pratiques de développement et non organisationnelles. • 2001 - Sortie du Manifeste agile, texte rédigé par 17 experts en développement logiciel estimant que la méthode Waterfall n’était plus en phase avec les exigences de beaucoup d’organisations. • 2002 - La méthodologie Scrum est décrite en détails dans le livre Agile Software Development with Scrum par Ken Schwaber et Mike Beedle !18
  • 19. Facile à comprendre et intuitif, non ? !19 Mais en pratique, au quotidien ce sont des principes difficiles à mettre en oeuvre car ils nous demandent d’agir sur notre comportement.
  • 21. !21
  • 23. !23 Scrum master Est le liant entre tous les membres de l’équipe. C’est un facilitateur, un coach pour les membres de son équipe pour les guider dans leurs rôles respectifs. C’est lui qui représente l’équipe auprès des autres équipes et de la hiérarchie. A une autorité sur l’application de la méthodologie Scrum N’est pas un manager! C’est un “servant leader” : Il se met à la disposition de l’équipe pour organiser les rituels et maintenir les délivrables garantir que l’équipe puisse avancer sereinement sans pressions externes de maintenir une vélocité optimale en taclant les points de blocages
  • 24. !24 Equipe de développement L’équipe de développement est auto-organisée et choisi la façon d’accomplir le travail. L’équipe est pluri-disciplinaire Composée de 3 à 7 développeurs L’équipe s’engage a délivrer un produit en fin de sprint
  • 25. !25 Product Owner (PO) C’est la voix du client, en capturant ses besoins et ses attentes. Il est responsable de traduire les besoins du clients en fonctionnalités claires que l’équipe de développement peut estimer et tester : les user stories. Le PO se met au service de l’équipe de développement pour clarifier la teneur des User Stories
  • 26. !26 Key users Ce sont des utilisateurs sélectionnés et qui vont représenter l’ensemble des utilisateurs. Leur implication est essentielle dans la phase de capture des besoins mais aussi lorsqu’un incrément (le produit d’un sprint) doit être démontré.
  • 27. Les rituels Scrum !27 • Ce sont des rencontres codifiées entres tous les intervenants d’un projet. • Chaque rituel a un objectif précis et produit un ou plusieurs délivrables • Les rituels Scrum sont : Le sprint planning meeting Le daily standup La revue de sprint La retrospective
  • 30. !30
  • 31. Le PO a la charge d’établir un product backlog !31 https://unsplash.com/photos/mh0j74mGeco • Le product backlog garde tous les besoins clients exprimés au PO. • Le PO a la responsabilité de prioriser le product backlog. • Seules les stories “complète” intégreront le sprint.
  • 32. Les stories Les stories représentent les fonctionnalités qui doivent être développées. Elles expriment une idée et répondent à un besoin du client. !32 https://unsplash.com/photos/mh0j74mGeco Les stories contiennent les informations minimales pour que la charge de travail soit raisonnablement estimées par l’équipe.
  • 33. “En tant que client, je veux suivre ma consommation afin de maitriser mon budget” !33 Critères I.N.V.E.S.T d’une story : Independent Negociable Valuable Estimable Small Testable Critères 3C d’une story : Card : la story est écrite sur une carte Conversation : Le détail de la story est discutée Confirmation : des critères d’acceptation sont formulés. Qui et Quand ? Tout le monde est légitime pour écrire une story qui alimentera le product backlog. Le PO valide sa pertinence. N’importe quand
  • 34. !34 https://unsplash.com/photos/mh0j74mGeco DOR - Definition Of Ready Quels sont les critères permettant d’affirmer qu’une “user story” est prête à être développée. DOD - Definition Of Done Quels sont les critères permettant d’affirmer qu’une “user story” est réalisée. Délivrable de l’équipe
  • 35. !35 https://burst.shopify.com/photos/tech-group-meeting-flatlay Sprint planning • Marque le début d’un sprint. • Organisé par le Scrum master • Le PO a la responsabilité d’alimenter le contenu du sprint (sprint backlog) • Dialogue entre le PO et l’équipe pour estimer au mieux les stories. • L’estimation des stories est réalisée en Story Points. • Tout le monde doit être d’accord sur les estimations avant de commencer le sprint.
  • 36. !36 https://unsplash.com/photos/mh0j74mGeco Le sprint backlog • Le sprint backlog accueille toutes les User stories qui seront réalisées lors d’un sprint. • Il est créé à l’occasion du Sprint planning meeting. • La taille du Sprint backlog est négocié avec l’équipe en fonction du nombre de story points que l’équipe est capable de traiter sur la durée d’un sprint. • Dès que le sprint commence, le Sprint backlog ne doit plus changer.
  • 39. En cours de sprint !39
  • 40. !40
  • 41. !41 https://unsplash.com/photos/r6FbzziRN88 Daily standup • C’est le rituel le plus connu de Scrum • 3 questions pour chaque membre : Qu’est ce que j’ai réalisé depuis le dernier standup meeting ? Qu’est ce que j’ai planifié jusqu’au prochain standup meeting ? Y a t’il quelque chose qui ralenti ou bloque ma progression ? • Debout • 15 minutes max! • Seuls le SM et les développeurs peuvent prendre la parole
  • 43. !43 https://unsplash.com/photos/mh0j74mGeco L’équipe a pris l’engagement à l’issue du sprint de délivrer un produit, le product increment. L’équipe s’engage à tenir à jour les scrum boards (physique et virtuel). Ainsi n’importe qui de l’organisation peut constater l’avancement du Sprint. Délivrables de l’équipe
  • 44. A la fin du sprint !44
  • 45. !45
  • 46. !46 https://unsplash.com/photos/mh0j74mGeco C’est le résultat du développement du sprint. Il est mis à disposition du PO et est déployé dans un environnement où peuvent être démontrées les fonctionnalités aux clients. Le product incrément
  • 47. !47 https://unsplash.com/photos/bzdhc5b3Bxs La revue de sprint (shippable product) • C’est un moment de démonstration des fonctionnalités développées pendant le Sprint. • L’audience est idéalement composée du sponsor, des utilisateurs clés, et de toute personne concernée par le produit. • Le PO rappel le contexte et l’objectif du Sprint • Le Scrum Master fait le point sur le déroulement du Sprint en présentant le burndown chart. • Les membres de l’équipe réalisent la démo. Si la démonstration n’est pas satisfaisante, la story doit être réouverte.
  • 49. !49 La revue de sprint • Jira pour présenter les stories à démontrer et présenter le burndown chart • La démonstration se réalise sur le produit en live (pas de slides ppt!) Les outils
  • 51. !51 Vélocité et planification • Le calcul de la vélocité et l’activité de product backlog grooming permettent au PO de planifier les sprints à venir. • Le product backlog grooming est une activité récurrente consitant à affiner, séparer, (re)prioritiser, nettoyer, estimer (grossièrement) les user stories. • Si une équipe est capable de traiter 50 story points, alors le PO peut planifier des sprints d’une capacité de 50 story points.
  • 52. !52 La rétrospective Chaque membre s’exprime sur ce qui a été et ce qui n’a pas été durant le sprint. C’est un rituel qui ne concerne que l’équipe. C’est un moment qui peut être émotionnel mais toujours dans un esprit constructif. C’est l’opportunité pour l’équipe d’améliorer sa vélocité pour les prochains sprints.
  • 53. !53 La rétrospective Tableau physique Les outils Tableau virtuel : https://funretro.io/
  • 55. !55
  • 56. !56 Le problème du multitasking
  • 57. Kanban !57 https://www.atlassian.com/agile/kanban/boards • Kanban est une méthodologie qui s’applique aux développements continus. • Kanban est moins prescriptif que Scrum • La notion de WIP (Work In Progress) Limit est centrale. • La métrique importante est le Cycle time = temps moyen entre la première colonne et la dernière colonne. • Pour être efficace, les colonne du Kanban doivent s’adapter à la réalité du terrain (exit Todo/Doing/Done). • Le flux Kanban peut changer n’importe quand et les éléments peuvent être ajoutés ou supprimés en fonction des priorités.
  • 59. !59 L’écriture des user stories doit être bien maitrisée. Une story qui est mal écrite est difficile à estimer et à réaliser. Les standup ne doivent pas durer plus de 15 minutes. Attention l’agilité requiert une équipe stable. Si la composition de l’équipe change d’un sprint à l’autre, le Scrum mater ne pourra jamais mesurer la vélocité. Lorsqu’un sprint a commencé, tout doit être mis en oeuvre pour ne pas en changer son contenu. Souvent les équipes ne font pas de rétrospectives. C’est une occasion manquée d’amélioration des sprints suivants. Un board Kanban sans WIP limit n’a pas d’intérêt.
  • 60. !60 Le “terrain” applicatif doit être favorable Project A Application monolithique Project B Project C
  • 62. !62 Les niveaux de maturité de l’agilité d’une organisation Adopter une méthodologie Coaching Appliquer les principes agiles aux objectifs personnels Adopter une stratégie d’entreprise agile Utilisation de techniques agiles. L’agilité est seulement présente dans certaines parties de l’organisation. Suivi et application des principes agiles pour toutes les initiatives de l’entreprise Suivi et application des principes agiles pour toutes les initiatives de l’entreprise Suivi et application des principes agiles pour toutes les initiatives de l’entreprise
  • 63. !63 Une équipe, un produit… facile!
  • 64. !64 Comment s’organiser lorqu’on multiplie les équipes et les produits ? Scrum of Scrum
  • 65. !65 Team level Program level Portfolio level SAFe - Scaled Agile Framework https://www.youtube.com/watch?v=tmJ_mJw8xec
  • 68. !68