Sensibilisation à l'Agile

OCTO © 2018 - Reproduction interdite sans autorisation écrite préalable
Sensibilisation à l’agile
pour le cas #MarcelineByAccenture
Chaire ESEIA / SKEMA
Version 1.1 – 28 janvier 2020
1

THERE IS A BETTER WAY
Promesses et plus-value de l’agile
01
2

OCTO © 2018 - Reproduction interdite sans autorisation écrite préalable 3
Le jeu des nœuds
Complexe vs. compliqué

Pourquoi l’agilité ?
Une réponse face à la complexité croissante
Écart entre nos
plans et la réalité
des projets

Une réponse face à la complexité croissante (1/2)
Tester plus vite pour apprendre plus vite

Une réponse face à la complexité croissante (2/2)
Réaliser de façon itérative et incrémentale
Client
Je souhaite me
déplacer d’un
point A à un
point B

Quelques publications OCTO
Culture Code
Software
Craftmanship:
better places with
better code
A télécharger ici
Culture DevOps
Les ingrédients secrets
d’une organisation
DevOps équitable et
durable
A télécharger ici
Les géants du Web
Culture - Pratique -
Architecture
A télécharger ici
Culture Change
le Guide de Remise en
Forme de Votre
Organisation par
l'Agilité
A télécharger ici

SYNTHÈSE : PROMESSES ET PLUS-VALUE DE L’AGILE
L’agilité est une réponse face à la complexité croissante du monde actuel
Travailler en agile, c’est :
- répondre à une problématique client (un problème / un besoin vs. délivrer une
solution)
- en délivrant un produit (vs. un projet)
- de manière incrémentale → on réfléchit en termes de résultats (output) et en termes
de livrables / temps passé
Gare aux idées reçues ! L’agile c’est :
- agile = rigueur (et non “à l’arrache”) → L’agile demande des efforts et de l’implication
- un changement culturel
- prendre le temps de délivrer de la qualité (du code propre ! / clean code)

SYNTHÈSE : DU PROJET AU PRODUIT
PÉRIMÈTRE
TEMPS / COÛT
VALEUR
= Délivrer au
marché au bon
moment
= Délivrer la bonne
chose (“market fit”)
= Délivrer le
bon niveau
de qualité
QUALITÉ
= Quel problème cherche-t-on
à résoudre ?
Comment mesure-t-on la
valeur que l’on produit ?
Comment teste-t-on nos
hypothèses ?
VALEUR
On se concentre
avant tout sur la
valeur délivrée

Qu’est-ce que cela implique ? (1/2)
Des changements dans la manière de fonctionner et de s’organiser
Pour les équipes SCRUM
> Une répartition différentes des rôles et
des responsabilités
> Une nouvelle rigueur de travail,
cadencée par des rituels
Pour le management au sens large
> Une posture managériale différente :
davantage d’autonomie aux équipes
dans un cadre défini
> Une implication néanmoins plus
importante qu’en cycle en V,
notamment pour la participation aux
sprint review et la gestion des points de
blocages rencontrés par l’équipe

Qu’est-ce que cela implique ? (2/2)
Passer du mode projet au mode produit, de manière itérative et incrémentale
Mode projet : planification Mode produit : réactivité
◉ Pilotage par la valeur
◉ Prise en compte du
feedback
◉ Décisions rapides
◉ Planification itérative
◉ Approche budgétaire
◉ Suivi du plan projet
◉ Décisions anticipées
◉ Planification complète

Méthodes agiles ? Késako ?
02
12

Il n’existe pas une méthode agile, mais une galaxie
de méthodes !
13
Méthodes Agiles ?
Attention aux buzz word ! Quelques lumières pour s’y retrouver
Entre autres : SCRUM, XP (Extreme Programming), Crystal, DSDM,
Feature driven development, DevOps, Kanban…
Ces méthodes sont utilisées historiquement dans un contexte de
développement logiciel, mais trouvent aujourd’hui leur application
dans des domaines hors IT (RH, développement produit…)
SCRUM est le framework agile le plus répandu
94% des équipes agiles l’utilisent.
SCRUM a été formalisé en 1995 par Jeff Sutherland et Ken
Schwaber.
Méthode agile : une définition
« Une méthode agile est une approche
itérative et incrémentale, qui est menée
dans un esprit collaboratif avec juste ce
qu’il faut de formalisme. Elle génère un
produit de haute qualité tout en prenant
en compte l’évolution des besoins des
clients ».
Véronique Messager Rota,
Gestion de projet : Vers les méthodes agiles
Le Manifeste Agile (2001) formalise les dénominateurs
communs de ces méthodes : 4 principes et 12 valeurs

Le Manifeste Agile
4 valeurs agiles, déclinées en 12 principes, que nous avons classés
Donc, bien qu’il y ait de la valeur sur les parties de droite, nous accordons plus de
valeur aux parties de gauche
Lien vers le Manifeste Agile (2001)
Les individus et interactions plus que les processus et les outils
Des logiciels qui marchent plus que une documentation exhaustive
La collaboration avec les
clients
plus que la négociation contractuelle
L’adaptation au changement plus que plus que le suivi d’un plan

Le Manifeste Agile
Principes à destination des clients
๏ Notre plus grande priorité est de satisfaire le client en livrant au plus tôt et de manière
continue un logiciel de valeur.
๏ Tout changement des exigences est bienvenu, même tardivement dans le
développement. Les méthodes Agiles transforment le changement en avantage
compétitif pour le client.
๏ Livrer régulièrement un logiciel fonctionnel, toutes les deux semaines à deux mois, en
préférant la plus haute fréquence.
๏ Les personnes du métier et les développeurs doivent collaborer quotidiennement tout
au long du projet.

Le Manifeste Agile
Principes à destination des managers
๏ Bâtir des projets autour de personnes motivées. Leur donner l'environnement et le soutien
dont elles ont besoin et leur faire confiance pour accomplir le travail.
๏ La plus efficace des méthodes pour transmettre l'information à destination et au sein
d'une équipe de développement est le face-à-face.
๏ Un logiciel qui fonctionne est la première mesure de progrès.
๏ Les méthodes Agiles favorisent un rythme de développement soutenable.
Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir ce rythme
indéfiniment.

Le Manifeste Agile
Principes à destination des équipes
๏ Une attention constante à l'excellence technique et à la qualité de la conception
améliore l'agilité.
๏ La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.
๏ Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui
s’organisent elles-mêmes.
๏ À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis
modifie et ajuste son comportement dans ce sens.

SYNTHÈSE : MÉTHODES AGILES ? KESAKO ?
Il existe une galaxie de méthodes agiles. Parmi elles, Scrum est le framework le plus utilisé.
Le Manifeste Agile, c’est 4 valeurs, déclinées en 12 principes, qui mettent au coeur l’humain et
la collaboration
Le Manifeste Agile
1. Les individus et les échanges plus que les processus et les outils.
2. Un produit fonctionnel plus qu’une documentation pléthorique.
3. La collaboration avec le client plus que la négociation du contrat.
4. La réactivité au changement plus que le suivi d'un plan.
Donc, bien qu’il y ait de la valeur sur les parties de droite, nous accordons plus de valeur aux
parties de gauche
Lien vers le Manifeste Agile (2001)

Cadrage 360°
03
19

Cadrage 360°
pour obtenir une équipe alignée, prête à démarrer PRODUIT TECH ORGATECHORGA
Partager les
fondamentaux
Agiles et initialiser
la dynamique
d’équipe
AGILE
BOOTSTRAP
Quel est le rôle de
chacun ?
Quelles sont les
interactions ?
RÔLES ET
RESPONSABILITÉS
Quelles sont les macro-fonctionnalités ?
+
+
+
-
EPIC
(activités)
FONCTIONS
(macros)
Quels risques ?
Quelles contre-
mesures ?
RISQUESSTORYMAP
Quelle trajectoire de réalisation ?
ROADMAP
Janvier Février Mars
Point
d’attent°
Feature
Victoire
4 à 6 semaines
Qui sont les
utilisateurs ?
Quels sont leurs
problèmes / besoins ?
Quels enjeux pour
l’entreprise ?
Quelle proposition de
valeur ?
Personnaliser
les utilisateurs
pour mieux les
comprendre
PERSONAS
Quels critères de succès ?
VISION TECHNIQUE
PROCESSUS DE
RÉALISATION
ARCHITECTURE
APPLICATIVE
FLUX PRATIQUES
DE DÉV.
ARCHITECTURE
TECHNIQUE
Quels
logiciels/technologies/fr
ameworks ?
Quelle solution
d’industrialisation du code
Quels échanges de
données ? Quels
formats ?
Quel matériel ?
Quels standards de
qualité pour le code ?
Quels tests ?
Quelles métriques ?
Quels process ?
Quels rituels ?
? ? ?

Principes directeurs d’un cadrage 360°
1
2
3
4
Une équipe prête à commencer
L’équipe est constituée, les premières fonctionnalités identifiées et spécifiées
Le chemin parcouru est aussi important que le livrable
Créer une dynamique et souder l’équipe produit (équipe pluridisciplinaire)
Une construction incrémentale des livrables par une
démarche collaborative et itérative
Donner de la visibilité régulièrement, réajuster ensemble, identifier et qualifier les besoins réels
Un exercice court et timeboxé
Converger rapidement vers des compromis, ne pas rigidifier le produit trop tôt afin de favoriser le
changement

Livrables d’un cadrage 360°
PRODUIT
TECH
ORGATECH
ORGA
❏ Vision MVP (Minimum Viable Product)
❏ Personae
❏ Experience Map
❏ Storymap
❏ Product Backlog
❏ 1er sprint backlog
❏ Liste de beta testeurs
❏ Prototypes de design
❏ Définition qualité de code
❏ Architecture
❏ Définition du fini (DoD - Definition of Done)
❏ CI/CD
❏ Sprint 0 goal
❏ Rôles et responsabilités
❏ Matrice de compétences
❏ Risques
❏ Cartographie des parties prenantes
❏ Board visuel et dématérialisé
Réunir les critères de succès :
❏ l’équipe est constituée et dynamique
❏ l’équipe est alignée sur la vision du
produit
❏ les 1ères fonctionnalités identifiées
et spécifiées
❏ les équipes ont déjà commencé à
monter en compétence (SCRUM et
agilité en général)

L’ADN d’un développement produit réussi
50%
30%
Presque
jamais
ou jamais
utiliséesParfois
ou peu
souvent
utilisées
Fréquemment
utilisées
50%
des fonctionnalités
sont rarement
ou jamais utilisées (*)
20%
des fonctionnalités
sont utiles (*)
9produits
sur 10ne trouvent pas leur client… (**)
20%
(*) The Standish Group CHAOS Manifesto 2013. (**) Startup Failure Rate, source Forbes & Fortune.

La qualité est non négociable
Un coût
financier
⦿ Des évolutions
de plus en plus
chères à
produire
⦿ Des clients
insatisfaits qui
ne payent plus
Un coût
humain
⦿ Des
développeurs
démotivés et
désengagés
⦿ Les meilleurs
démissionnent
Un coût
stratégique
⦿ Des difficultés à
répondre au
« time to
market »
⦿ Une perte de
confiance dans
la marque
Coût de la non-qualité

Le Framework SCRUM : aperçu
04
25

๏ 3 Rôles
< Product Owner
< Scrum Master
< Development Team
๏ 3 Artefacts
< Product Backlog
< Sprint Backlog
< Increment
๏ 5 Événements
< Sprint
< Sprint Planning
< Daily Scrum
< Sprint Review
< Sprint Retrospective
Définitions clés de SCRUM
26
SCRUM est un framework, basé sur 3 rôles, 3 artefacts et 5 événements

Les rôles de SCRUM
27
Scrum Team
Product Owner
Les utilisateurs
finaux
Les sponsors
L’équipe de réalisation
Scrum Master
Coach Agile
Experts
techniques
(OPS, UX, UI…)
Selon la charge de travail, les experts
techniques font partie de l’équipe de
réalisation (temps plein), ou intervenants
extérieurs
Rôle tournant dans
l’équipe ou 1 Scrum
Master pour plusieurs
équipes
Priorise les besoins
des utilisateurs finaux
et ceux des sponsors
Ecrit le backlog
produit et le
priorise pour
l’équipe de dév
Réalise le produit
correctement (qualité
technique).
Le tech lead veille à la
bonne résilience de
l’équipe (gestion du
loto factor) et fait
grandir son équipe
S’assure de la montée
en compétence de
l’organisation en
termes d’agilité
(sponsors ou équipes)
S’alignent sur une
vision produit claire et
donne du feedback de
manière régulière à la
Scrum Team

Synthèse: SCRUM team
28
Product Owner
L’équipe de réalisation
Scrum Master
Faire le bon
produit (valeur
client)
Faire les
choses bien
(qualité
technique)
Garant de la
méthodologie,
enlève les
points
bloquants
pour la Scrum
Team
(organisation
-nels ou autre)
Un produit de
qualité

๏ Le “Product Backlog” (ou Backlog Produit)
< Liste de fonctionnalités (US) à réaliser, ordonnée par ordre de priorité.
< Cette liste est définie, maintenue et priorisée strictement par le Product Owner.
๏ Le “Sprint Backlog” (ou Backlog de Sprint)
< C’est un sous-ensemble du Product Backlog à réaliser dans un Sprint
< A partir des fonctionnalités priorisées et souhaitées par le Product Owner
< Son contenu est organisé et maintenu par la Team en cours de Sprint.
๏ L’incrément
< L'incrément est la somme de toutes les fonctionnalités terminées pendant le sprint additionnée
des items terminés dans les précédents sprints
< L’incrément est le résultat d’un travail terminé qui peut être inspecté et qui supporte
l’expérimentation dès la fin d’un sprint
Les artéfacts de SCRUM
29

Les événements SCRUM
Aperçu d’une itération
PLANIFICATION
D'ITÉRATION
2h
15
min.
(1) Toutes les durées sont des durées indicatives maximales
(2) Il ne s’agit plus d’un rituel SCRUM officiel mais d’une
bonne pratique
(1)
(1)
(1)
SPRINT REVIEW
2h (1)
(2)
(1)

D’autres questions ?
Quê-Minh VO
Coach Agile
Tribu Scale
@OCTO Technology part of Accenture Digital
Coach Agile, c'est quoi ? (vidéo 1’50)
Source : Welcome to the Jungle
nvo@octo.com
@anna_qm
@

Sensibilisation à l'Agile

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Sensibilisation à l'Agile

Ähnlich wie Sensibilisation à l'Agile (20)

Mehr von OCTO Technology

Mehr von OCTO Technology (20)

Sensibilisation à l'Agile