Methodologies agiles

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

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…).

Planiﬁcation

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 ﬁxé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 ﬂexibilité

Risques importants de déception des clients si la réalisation ne
correspond pas ﬁnalement 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

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 diﬃcile de ﬁxer 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 proﬁls très
diﬀé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 Jeﬀ 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 diﬃciles
à mettre en oeuvre car ils nous demandent d’agir sur notre
comportement.

Scrum
!20
https://unsplash.com/photos/txDt77eRGrM

!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 ﬁn 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 clariﬁer 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 codiﬁé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

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
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
aﬁn 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

Conﬁrmation : 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
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-ﬂatlay
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
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
!38
planningpoker.com Mobile apps

!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 planiﬁé 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
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

!46
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.

!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/

!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 eﬃcace, les colonne du Kanban doivent
s’adapter à la réalité du terrain (exit Todo/Doing/Done).

• Le ﬂux Kanban peut changer n’importe quand et les
éléments peuvent être ajoutés ou supprimés en
fonction des priorités.

!59
L’écriture des user stories doit être bien maitrisée. Une story qui est mal
écrite est diﬃcile à 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

!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

Methodologies agiles

Recommandé

Recommandé

Contenu connexe

Similaire à Methodologies agiles

Similaire à Methodologies agiles (20)

Dernier

Dernier (20)

Methodologies agiles