Accor Agile 201904 v1.0

FORMATION AGILE
- ACCOR -
2019-0651F – version 1.0 – 12,18,19 mars
OCTO Part of Accenture Digital © 2019 - Al l rights reserved

Agenda de la formation
01 // p03 02 // p35
Jour 1 Jour 2 et 3
Les bases de l’agile Le métier de Product Owner en
détail
OCTO Part of Accenture Digital © 2019 - Al l rights reserved 2

JOUR 1
Les bases de l’agile
THERE IS A BETTER WAY

3
Agenda
Jour 1
VENDREDI 12 AVRIL
9H30 Tour de table & attentes
10H00 Pourquoi vouloir être agile ?
10H30 Les grands principes
12H30 Déjeuner
14H00 Mise en situation : Lego for Scrum
16H30 Pause
17H00 Conclusion & questions/réponses
17H30 Fin du jour 1

01
Tour de table et attentes

5
Le blason
 Dessinez votre blason et présentez-le au groupe
MON NOM MA FONCTION
MON NIVEAU DE
CONNAISSANCE DE MA DEVISE
L’AGILE DU JOUR
(NOTE SUR 5)
MES ATTENTES POUR

CETTE FORMATION

02
Pourquoi être agile ?

7
Le contexte historique du manifeste agile
2001
LE MANIFESTE AGILE
1950 1960 1970 1980 1990 2000
MICRO MICRO ORDINATEURS

TRANSISTORS INTERNET WEB 2.0
PROCESSEURS ORDINATEURS PERSONNELS
L’informatique est L’informatique L’informatique

L’ informatique est L’informatique sort L’informatique est
réservé aux entre dans les s’installe dans les
confidentielle de la DSI partout
chercheurs·euses entreprises entreprises
EXPÉRIMENTALE MANUELLE PROFESSIONNELLE INDUSTRIELLE GÉNÉRALISÉE OMNIPRÉSENTE

Le contrôle des coûts

La spécialisation
??

Les biais des projets en méthode classique

Conclusion
Un problème de gestion des risques
La boucle de feedback entre le besoin des utilisateurs finaux, son expression par le
RISQUE
RISQUE BUSINESS
BUSINESS métier et sa réalisation par les équipes techniques est trop longue
→ La vie est trop courte pour créer des produits qui ne seront pas utilisés
En sur-spécialisant les acteurs des projets informatiques, la communication entre les

RISQUE HUMAIN parties prenantes pose problème et dessert la qualité du produit final
→ Ensemble, on ne va pas plus vite mais on va plus loin
A force de considérer l’informatique comme un centre de coût, on en vient à prendre

RISQUE TECHNIQUE des choix techniques qui compromettent la viabilité du produit à long terme
→ If you pay peanuts, you get monkeys

03
Les grands principes

13
Les quatre piliers

Les douze principes - principes dédiés aux clients
Notre plus grande priorité est de satisfaire le client en livrant au plus tôt et de manière
LA VALEUR
continue un logiciel de valeur
Tout changement des exigences est bienvenu, même tardivement dans le

LE CHANGEMENT développement
Les méthodes agiles transforment le changement en avantage compétitif pour le client
Livrez régulièrement un logiciel fonctionnel, toutes les deux semaines à deux mois, en
LA FRÉQUENCE
préférant la plus haute fréquence
Les personnes du métier et les développeurs doivent collaborer quotidiennement tout au

LA COLLABORATION
long du projet

Les douze principes - principes dédiés aux managers
Bâtissez des projets autour de personnes motivées

LA CONFIANCE Donnez-leur l’environnement et le soutien dont ells ont besoin et faites leur confiance
pour accomplir le travail
La plus efficace des méthodes pour transmettre l’information à destination et au sein

LA CO-LOCALISATION
d’une équipe de développement est la conversation en face-à-face
Les méthodes agiles favorisent un rythme de développement soutenable

LE RYTHME Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir ce rythme
indéfiniment
LA MESURE D’AVANCEMENT Un logiciel qui fonctionne est la première mesure de progrès

Les douze principes - principes dédiés aux équipes
Une attention constante à l’excellence technique et à la qualité de la conception

LA QUALITÉ
améliore l’agilité
LA SIMPLICITÉ 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

L’AUTO-ORGANISATION
s’organisent ells-mêmes
A intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace puis modifie
L’AMÉLIORATION
et ajuste donc comportement dans ce sens

La proposition de valeur de l’agilité
VISIBILITÉ ADAPTABILITÉ
VALEUR MÉTIER RISQUE
MÉTHODES AGILES MÉTHODES TRADITIONNELLES

Les trois piliers
VALEURS PRATIQUES CONCEPTS

VALEURS – management par la confiance

PRATIQUES – encourager l’échec & l’apprentissage rapide

PRATIQUES – rituels d’équipe

CONCEPTS – réalisation itérative & incrémentale

CONCEPTS – négocier le périmètre et non la qualité
PÉRIMÈTRE PÉRIMÈTRE
QUALITÉ QUALITÉ
COÛTS DÉLAIS COÛTS DÉLAIS

VALEURS – adapter les outils à l’état d’esprit

VALEURS – attention aux faux-semblants

VALEURS – l’exemple de Scrum
COURAGE
FOCUS TRANSPARENCY
COMMITMENT INSPECTION
RESPECT ADAPTATION
OPENNESS

Un état d’esprit avant d’être une méthode

04
Lego for Scrum

30
Les apprentissages
VALEURS PRATIQUES CONCEPTS
AUTO- AMÉLIORATION
ENGAGEMENT COURAGE RÔLES TIMEBOX
ORGANISATION CONTINUE
PRIORISATION PAR DÉPLOIEMENT VALIDATION JUSTE CE QU’IL

ÉCHEC JUSTE À TEMPS
LA VALEUR CONTINU CONTINUE FAUT
CRITÈRES DÉCOUPAGE DES PLURI- PAS DE SURPRISE À

TRANSPARENCE PARTENARIAT
D’ACCEPTATION TÂCHES DISCIPLINARITÉ LA FIN
PARTAGE DE
CONFIANCE AMBITION DÉMONSTRATION RÉTROSPECTIVE VISION GLOBALE
CONNAISSANCE
ITÉRATIF &
CRÉATIVITÉ PLAISIR DAILY STAND-UP ESTIMATION « SLACK »
INCRÉMENTAL

05
Conclusion & questions/réponses

32
Agenda
Jour 2
JEUDI 18 AVRIL
9H30 Retour sur votre semaine
10H00 Vision produit & connaissance des utilisateurs
11H15 Pause
11H30 Cartographier le produit
12H30 Déjeuner
14H00 Roadmap & lancement de projet
16H00 Pause
16H15 Product Ownership in a nutshell
17H30 Fin du jour 2

Agenda
Jour 3
VENDREDI 19 AVRIL
9H00 Stand up meeting
9H45 Les user stories
11H00 Rituels & dynamique d’équipe
12H00 Déjeuner
13H30 Lean & Kanban
15H30 Stratégie produit, stratégie technique
16H30 Conclusion & questions / réponses
17H00 Fin du jour 3

JOUR 2
Le métier de Product Owner en pratique

35
Agenda
Jour 2
JEUDI 18 AVRIL
9H30 Retour sur votre semaine
10H00 Vision produit & connaissance des utilisateurs
11H15 Pause
11H30 Cartographier le produit
12H30 Déjeuner
14H00 Roadmap & lancement de projet
16H00 Pause
16H15 Product Ownership in a nutshell
17H30 Fin du jour 2

01
Présentation du fil rouge des deux jours

37
Cas fil rouge pour illustrer le métier de PO
Site e-commerce spécialisé dans les jeux et jouets
Vous faites partie d’un groupe spécialisé dans les jeux et jouets
Bousculé par la concurrence des grands acteurs du e-commerce, vous décidez de lancer un
nouveau projet pour disrupter le marché du jouet d’occasion !
Votre ambition : concurrencer les leaders du marché
Votre existant :
- Un réseau de magasins physiques
- Un site internet de vente de jeux et jouets neufs

02
Vision produit & connaissance des utilisateurs

39
Le danger majeur

Les prérequis pour construire ou enrichir un produit
AVOIR UNE VISION CLAIRE CONNAÎTRE SES UTILISATEURS

Atelier vision
Définir la vision du produit
QUI SONT LES UTILISATEURS ?
QUELS SONT LEURS PROBLÈMES ET BESOINS ?
QUELS SONT LES ENJEUX POUR L’ENTREPRISE ?
QUELLE EST NOTRE PROPOSITION DE VALEUR ?
QUELS SONT NOS CRITÈRES DE SUCCÈS ? MANIFESTE PRODUIT

Un outil – la vision par le cadran

Les personas
Une persona représente un groupe Une persona est définie par ses
d’utilisateurs avec des besoins et ses objectifs en utilisant
caractéristiques et des objectifs le produit
communs
Personnage imaginaire, une persona est inspirée

par le recueil d’informations sur les utilisateurs et
vise à créer de l’empathie

Un outil – les personas
Sylvain SON UTILISATION DU PRODUIT

Consulte le montant de son encours
Commercial chez •
• Consulte le plafond disponible par type d’opération
OCTO Technology • Consulte la liste des opérations effectuées (retrait et
36 ans paiement)
• Consulte la liste des DABs partenaires les plus proches
SON HISTOIRE
DES FREINS, FRUSTRATIONS POTENTIELLES
•Sylvain travaille chez OCTO Technology depuis 4 ans à Paris.
• Pas de wi-fi ou 3G, absence de connexion
•Il travaille au sein du pôle Banque et Assurances après avoir travaillé en tant
• Désynchronisation des données
que commercial chez un acteur mondial de logiciels bancaires. • Problème de lisibilité des informations
•Sylvain adore son métier, le contact privilégié avec ses clients et les
déplacements qu’il est amené à faire fréquemment auprès des filiales du CE QUI PEUT L’INFLUENCER
groupe, en suisse, en Belgique et au Brésil. • Rapidité d’utilisation et accès rapide aux informations
•Il est complètement accro à son iPhone dont il se sert tous les jours pour • N’est plus obligé de faire appel au SAV sur des
problématiques simples et anxiogènes (niveau
consulter sa messagerie, son agenda, organiser ses rendez vous et appeler ses
d’encours par rapport au plafond)
clients et prospects.
SES BUTS L’HEUREUSE SURPRISE

•Accéder aux informations d’utilisation de sa carte corporate à tout moment • Pouvoir transmettre en direct ses notes de frais
• Pouvoir régler en direct le déblocage du plafond
•Etre guidé sur les montants disponibles par type d’opération
avec le SAV
•Pouvoir s’orienter et rechercher le DAB/GAB partenaire le + proche

03
Cartographier le produit

46
Un changement de perspective
Liste de tâches Description d’un parcours

Pas de discussion Format collaboratif
Pas de boucle de feedback Boucle de feedback positive

Atelier storymap
Cartographier l’histoire que raconte le produit
Identifier et prioriser collectivement
les macro-fonctionnalités du parcours
des utilisateurs dans le produit
en alignant toute l’équipe

Un outil – la storymap
INDISPENSABLE
UTILE
CONFORT

Atelier experience map
Cartographier l’expérience des utilisateurs au sein du produit
Décrire l’état émotionnel d’un utilisateur
lors de ses interactions avec le produit
en détaillant ses buts
et les actions qu’il entreprend pour y parvenir

Un outil – l’experience map
SOUS- SOUS- SOUS- SOUS- SOUS- SOUS- SOUS- SOUS- SOUS- SOUS- SOUS- SOUS- SOUS- SOUS- SOUS- SOUS-
SOUS-ÉTAPE SOUS-ÉTAPE
ÉTAPE ÉTAPE ÉTAPE ÉTAPE ÉTAPE ÉTAPE ÉTAPE ÉTAPE ÉTAPE ÉTAPE ÉTAPE ÉTAPE ÉTAPE ÉTAPE ÉTAPE ÉTAPE
ÉTAPE 1 ÉTAPE 2 ÉTAPE 3 ÉTAPE 4 ÉTAPE 5
Point de Point de Point de Point de Point de Point de Point de Point de Point de Point de Point de Point de Point de Point de Point de Point de
Point de contact
contact contact contact contact contact contact contact contact contact contact contact contact contact contact contact contact
- Action 1
- Action 2
- Action 1 - Action 1 - Action 1 - Action 1 - Action 1 - Action 3 - Action 1
- Action 1
- Action 2 - Action 2 - Action 2 - Action 2 - Action 2 - Action 4 - Action 2 - Action 1
- Action 2
- Action 3 - Action 3 - Action 3 - Action 3 - Action 3 - Action 5 - Action 3
- Action 6
Description précise de
l’émotion
Description précise de l’émotion Description précise de l’émotion
Description précise de l’émotion Description précise

de l’émotion
Description précise Description précise
Description précise de l’émotion de l’émotion de l’émotion
Description précise
de l’émotion
Description précise de Description précise de l’émotion Description
l’émotion Description précise Description précise de
Description précise de l’émotion
de l’émotion précise de l’émotion
l’émotion
Description précise de l’émotion Description précise de l’émotion Description précise
de l’émotion Description précise de l’émotion
Description précise de l’émotion Description Description

précise de précise de
Description précise de l’émotion l’émotion l’émotion

04
Roadmap et lancement de projet

52
Un changement de perspective… encore !

Un changement de perspective… encore !
TOUTES LES ESTIMATIONS SONT FAUSSES ON APPREND PLUS APRÈS AVOIR LIVRÉ

Le chiffrage en agile
Une estimation relative

Un outil – extreme quotation
S M L XL ?
FONCTIONNALITÉ 1 FONCTIONNALITÉ 3 FONCTIONNALITÉ 7 FONCTIONNALITÉ 2 FONCTIONNALITÉ 4
FONCTIONNALITÉ 5 FONCTIONNALITÉ 6 FONCTIONNALITÉ 13 FONCTIONNALITÉ 8 FONCTIONNALITÉ 12
FONCTIONNALITÉ 11 FONCTIONNALITÉ 9 FONCTIONNALITÉ 14
FONCTIONNALITÉ 10
FONCTIONNALITÉ 15
1. L’équipe définit collectivement un étalon d’estimation avec une fonctionnalité

2. Chaque personne à son tour peut :
- soit ajouter une nouvelle fonctionnalité dans une colonne
- soit déplacer une fonctionnalité déjà estimée dans une autre colonne
3. Le résultat final doit faire l’objet d’un consensus
Les principes d’une roadmap agile
Incarner la stratégie produit dans un flux progressif

Roadmap – la gestion des délais
Moduler les catégories d’échéances

pour éviter le paradoxe de l’urgence :
si tout est urgent, rien n’est urgent

Roadmap – le niveau de précision
Adopter le bon niveau de granularité

Le détail n’est utile que pour les éléments proches,
on peut rester vague pour les éléments lointains

Roadmap – exprimer la stratégie
Rattacher la roadmap à la stratégie
- Détailler les KPI que chaque fonctionnalité cherche à

faire évoluer
- Inscrire dans la roadmap une période d’apprentissage
en fonction des résultats mesurés en production

Comment lancer un projet ?
Trouver l’équilibre entre valeur de l’apprentissage et valeur business

Les trois artefacts dans Scrum
PRODUCT BACKLOG SPRINT BACKLOG PRODUCT INCREMENT
Liste des fonctionnalités Sous-ensemble du Somme de toutes les

ordonnée par ordre de Product Backlog couvrant fonctionnalités terminées
priorité le périmètre d’un sprint pendant le sprint,
Cette liste est définie, Cette liste est organisée additionnée à tous les
maintenue et priorisée par la Dev Team à partir items des précédents
par le Product Owner des souhaits du Product sprints, livrable en
Owner production à tout moment

05
Product Ownership in a nutshell

63
JOUR 3
Le métier de Product Owner en pratique

65
Agenda
Jour 3
VENDREDI 19 AVRIL
9H00 Stand up meeting
9H45 Les user stories
11H00 Pause
11H00 Rituels & dynamique d’équipe
12H00 Déjeuner
13H30 Lean & Kanban
15H30 Stratégie produit, stratégie technique
16H30 Conclusion & questions / réponses
17H00 Fin du jour 3

01
Stand up meeting

67
Atelier – daily stand up

Quelques astuces pour vos stand up
Le stand up est conçu pour partager de l’information au sein de l’équipe

→ C’est un moment d’écoute avant d’être un moment de parole
C’est sa récurrence qui fait sa valeur et son efficacité

→ Soyez assidus, réguliers et patients si les résultats ne sont pas là dès le début
Le partage quotidien d’information est la première pierre de la confiance

→ Si la parole n’est pas libre au stand up, pourquoi le serait-elle en rétrospective ?
Le stand up n’est pas un moment de débat et de résolution des problèmes

→ Instaurez l’utilisation d’un bâton de parole si des interruptions de parole ont lieu
Le stand up doit être court pour garder de la concentration et de l’efficacité

→ Mettez en place une alarme si l’équipe ressent le besoin de mesurer le temps passé

02
Rituels & dynamique d’équipe

70
Vue d’ensemble du cycle Scrum
3 RÔLES 3 ARTEFACTS 4 RITUELS
o Product Owner o Product Backlog o Sprint Planning

o Scrum Master o Sprint backlog o Daily Scrum
o Dev Team Member o Product increment o Sprint review
o Sprint retrospective
Pourquoi fonctionner par itérations courtes ?
Pour créer un cadre identique et répété de façon systématique

→ Ce cadre permet une démarche de comparaison expérimentale d’une itération à l’autre
Pour imposer une contrainte forte au système

→ Cette contrainte permet de faire apparaître plus rapidement les dysfonctionnements
Pour mitiger plus vite les problèmes et éviter les bombes à retardement
→ On peut repérer les problèmes avant qu’ils ne grossissent et les contrer plus facilement
Pour donner une cadence et un rythme à l’équipe

→ Les itérations créent du mouvement et évitent l’essoufflement grâce à leur format cyclique

Pourquoi faire des rituels ?
Pour ne pas se poser de question logistique (agenda, salle, disponibilité des participants, etc.)
→ Les réunions sont ritualisées et font partie du quotidien
Pour créer une culture d’équipe, inscrire dans son ADN des pratiques qui visent l’amélioration
→ Les rituels rythment la vie de l’équipe et participent à sa cohésion
Pour donner un cadre standard aux réunions et maximiser leur impact

→ Chacun connaît la forme des rituels et peut se focaliser sur le fond des sujets

Les trois rôles dans Scrum
PRODUCT OWNER SCRUM MASTER DEV TEAM MEMBER
Le Product Owner est le Le Scrum Master est Equipe pluridisciplinaire,

leader du produit et le garant du respect des avec les compétences
représentant des processus Scrum nécessaires pour réaliser
utilisateurs Il a un rôle de coach au des incréments de produit
Il est responsable du sein de l’équipe et de (ex : devs front et back,
Product Backlog, interagit facilitateur auprès du UX / UI designers, Ops,
avec les parties prenantes reste de l’organisation etc.)
& l’équipe de dev

Les quatre rituels dans Scrum
SPRINT PLANNING DAILY SCRUM SPRINT REVIEW SPRINT RETROSPECTIVE
Réunion de travail où le Réunion de 15 minutes Réunion avec les parties Réunion d’amélioration
Product Owner et la Dev maximum où l’équipe se prenantes où l’équipe de toute l’équipe Scrum
Team sélectionnent les coordonne et partage de démontre ce qui a été On analyse les faits du
éléments du Product l’information réalisé et récolte du sprint pour déclencher
Backlog à réaliser Il s’agit de lever les feedback pour améliorer des actions
pendant le sprint problèmes, pas de les le produit d’amélioration à réaliser
traiter pendant le prochain
sprint

03
Les user stories

76
Atelier – les peintres

Comment manger un éléphant ?

Combien de user stories pour cet écran ?

Réponse ?
IL N’Y A PAS DE BONNE RÉPONSE, TOUT EST FONCTION DE L’ÉQUIPE

Quel est le MVP de cette page ?

User stories splitting patterns

Quelques astuces pour les user stories
LES 3 C PRINCIPES CRITÈRES DE TEST
C ARTE
I
NDEPENDANT
G IVEN
… N EGOTIABLE …
C ONVERSATION
V ALUABLE
W HEN
… ESTIMABLE …
C ONFIRMATION
SHORT
T HEN
… TESTABLE …

04
Lean & Kanban

84
Atelier – le jeu des balles

Les piliers du Lean
VALEUR
Apporter de la valeur au client final

> grâce aux collaborateurs
> pour qu’ils comprennent finement les
STANDARDS
AMÉLIO- besoins des différents clients
& JUSTE À
QUALITÉ RATION > qu’ils produisent juste à temps pour
MANAGE- TEMPS
CONTINUE servir chaque client
MENT VISUEL
> en incluant la qualité dès le départ
> et en améliorant en continu le process
RESPECT DES PERSONNES

Discussion – quels sont vos standards ?
Avez-vous des standards

d’équipe ?
Sont-ils connus par tous les

membres de l’équipe ?
Mesurez-vous leur respect

à chaque itération ?
Sont-ils connus par vos

parties prenantes ?

La visualisation du travail
QUELLES DOULEURS ? QUELLES RÉPONSES ?
> Toute activité comporte une part non-mesurée > Modéliser son flux de travail : tout ce qui
de travail réalisé de façon invisible compose sa chaîne de production de valeur
> Toute activité rencontre des blocages qui ont > Définir les definition of done qui permettent de
des effets de bords démultipliés lorsqu’ils ne passer d’une étape à l’autre
sont pas connus
> Toute activité nécessite un pilotage qui est > Matérialiser les blocages, interruptions et
rendu long et complexe si le travail n’est pas autres avaries par rapport au flux classique de
visible facilement valeur
> Toute tentative d’amélioration devient difficile > Intégrer les éléments connexes au flux
lorsque les indicateurs sont difficiles à (méthodes, pratiques, etc.)
rassembler

Fluidifier le travail : la théorie des files d’attente
CAPACITÉ CAPACITÉ
D’UTILISATION D’UTILISATION
FAIBLE > 85%
LOI DE LITTLE
Lead Time = WIP / débit
Lead Time : temps de traversée (commande → livraison)

WIP : Work In Progress, travail en cours
Débit : nombre d’éléments traités par unité de temps
Corollaire : la capacité d’utilisation est un risque

Comment réduire efficacement les délais ? → au-delà de 85% d’utilisation, la moindre variation a
→ en réduisant le WIP car augmenter le débit est plus un effet désastreux sur le débit
coûteux et plus difficile → pour favoriser le flux, il faut réduire la capacité
d’utilisation

Exemple de management visuel

Discussion – quels sont vos pratiques de management visuel ?
Votre flux de travail entier

est-il représenté ?
Toutes les tâches faites

sont-elles représentées ?
Avez-vous des Definition Of

Done affichées ?
Affichez-vous d’autres
éléments ?

Le tableau de base
À FAIRE EN COURS TERMINÉ
USER STORY 4 USER STORY 3 USER STORY 1
USER STORY 5 USER STORY 2
USER STORY 6

Les Definition of Done
Définition 1
Définition 1
Définition 2
Définition 2
Définition 3
USER STORY 6

Limiter l’encours 1/2
Définition 1
Définition 1
Définition 2
Définition 2
Définition 3
USER STORY 5
USER STORY 6

Limiter l’encours 2/2
Définition 1
Définition 1
Définition 2
Définition 2
Définition 3
WIP LIMIT
USER STORY 6

Représenter la chaîne de valeur
SPEC DEV RECETTE

À FAIRE TERMINÉ
EN COURS EN COURS EN COURS
USER STORY 8 USER STORY 6 USER STORY 4 USER STORY 3 USER STORY 1
USER STORY 9 USER STORY 7 USER STORY 5 WIP LIMIT

USER STORY 2
WIP LIMIT
USER STORY 10
WIP LIMIT
USER STORY 11
USER STORY 12

Représenter la chaîne de valeur dans sa totalité
BESOIN SPEC CHIFFRAGE GO / NOGO DEV RECETTE RECETTE GO LIVRÉ

TERMINÉ
EXPRIMÉ EN COURS EN COURS MÉTIER EN COURS EN COURS MÉTIER PROD EN PROD
USER USER USER USER USER USER USER USER

BESOIN 1
STORY 14 STORY 12 STORY 11 STORY 9 STORY 8 STORY 5 STORY 3 STORY 1
USER USER USER WIP LIMIT USER USER USER

BESOIN 2
STORY 15 STORY 13 STORY 10 STORY 6 STORY 4 STORY 2
WIP LIMIT WIP LIMIT USER

STORY 7
WIP LIMIT
CADRAGE DÉVELOPPEMENT RECETTE DÉPLOIEMENT

Visualiser facilement les typologies de sujets…
BESOIN SPEC CHIFFRAGE GO DEV RECETTE RECETTE GO LIVRÉ

TERMINÉ
USER USER USER USER USER USER

BESOIN 1 BUG 2 BUG 1

BESOIN 2

STORY 7
WIP LIMIT

… ou de projets

TERMINÉ

BESOIN 1

BESOIN 2

STORY 3
WIP LIMIT

Traiter les urgences

TERMINÉ
USER
STORY 8
E X P E D I T E

BESOIN 1

BESOIN 2

STORY 3
WIP LIMIT

Visualiser l’activité de l’équipe & les blocages

TERMINÉ
USER JOHN
STORY 8
E X P E D I T E
USER LÉA USER USER USER TIM USER USER USER LÉO USER
BESOIN 1 WAIT
USER USER WILL USER WIP LIMIT USER USERCARL USER

BESOIN 2 JACK BUG

STORY 3
WIP LIMIT

Un exemple de board physique

05
Stratégie produit, stratégie technique

103
Une recherche de la pérennité

Stratégie produit – prendre des décisions grâce à des faits mesurables
PROBLÈME Les décisions sont toujours prises par les HIPPOs

(HIPPO : HIghest Paid Person in the Office)
SOLUTIONS Faire de la livraison le premier pas et non le dernier

pas
Rendre systématique la mesure de l’impact des
fonctionnalités produites
Viser des métriques simples, contextualisées au
produit et à la typologie d’utilisateurs
BÉNÉFICE Montrer au métier que l’IT n’est pas qu’un exécutant

sans valeur ajoutée

Stratégie produit – faire parler les utilisateurs grâce à du feedback qualitatif
PROBLÈME Qu’est-ce que la valeur ?

Qu’est-ce qu’un MVP ?
SOLUTIONS Rencontrer les utilisateurs (en chair et en

os, par téléphone, …)
Se débarrasser de biais si ancrés qu’ils sont
impossibles à identifier
BÉNÉFICE Utiliser les utilisateurs comme juges de paix

dans les contextes politiquement
complexes
Définir ce qu’est la valeur !

Stratégie produit – garantir une cohérence d’ensemble
PROBLÈME J’ai l’impression de subir et de n’être

jamais proactif
SOLUTIONS Remettre en question en permanence

l’équilibre court terme / long terme
Repérer les problèmes récurrents dans
lesquels il faut investir du temps
aujourd’hui pour en gagner dans le futur
Donner un sens macro aux demandes
micro pour pouvoir définir une stratégie et
une direction afin d’éviter l’effet feature
factory
BÉNÉFICE Garantir la cohérence du produit et de

ses responsabilités dans l’écosystème de
l’entreprise

Stratégie technique – rendre possible la qualité logicielle
PROBLÈME Il y a trop de bugs, l’équipe n’arrive plus à

livrer de nouvelles fonctionnalités
CAUSES Il y a peu voire pas de tests automatisés

POSSIBLES Le métier est mal compris par l’équipe
(problèmes de nommage, etc.)
On pousse l’équipe à en faire toujours plus,
on « challenge » les estimations
SOLUTIONS Partager un langage commun entre le métier

et la technique
Se porter garant du temps nécessaire pour
garantir la qualité produite
Réserver du temps pour améliorer en continu
le code existant

Stratégie technique – le code est un asset vivant de l’entreprise
PROBLÈME Les évolutions sont trop chères !
CAUSES On a pas pris le temps de bien faire : le

POSSIBLES code ressemble à un plat de spaghettis
Les connaissances ne sont pas partagées,
il n’y a pas de standards
SOLUTIONS Quand le métier évolue, le code doit

évoluer aussi : ce n’est pas parce que ça
marche que ça marche bien !
Toute décision sur le produit ou sur
l’équipe a un impact sur le code : il faut le
reconnaître et l’anticiper

06
Conclusion & questions/réponses

110
En quelques mots…
PORTER LA MAXIMISER
CRÉER DU MENER UNE
VISION DU L’IMPACT DE
CONSENSUS STRATÉGIE
PRODUIT L’ÉQUIPE


Accor Agile 201904 v1.0

Transféré par

Droits d'auteur :

Formats disponibles

Accor Agile 201904 v1.0

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Accor Agile 201904 v1.0

Transféré par

Droits d'auteur :

Formats disponibles

FORMATION AGILE

OCTO Part of Accenture Digital © 2019 - Al l rights reserved

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 2

THERE IS A BETTER WAY

9H30 Tour de table & attentes

10H00 Pourquoi vouloir être agile ?

10H30 Les grands principes

14H00 Mise en situation : Lego for Scrum

17H00 Conclusion & questions/réponses

17H30 Fin du jour 1

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 4

THERE IS A BETTER WAY

 Dessinez votre blason et présentez-le au groupe

MON NOM MA FONCTION

MES ATTENTES POUR

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 6

THERE IS A BETTER WAY

1950 1960 1970 1980 1990 2000

MICRO MICRO ORDINATEURS

L’informatique est L’informatique L’informatique

EXPÉRIMENTALE MANUELLE PROFESSIONNELLE INDUSTRIELLE GÉNÉRALISÉE OMNIPRÉSENTE

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 8

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 9

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 10

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 11

En sur-spécialisant les acteurs des projets informatiques, la communication entre les

A force de considérer l’informatique comme un centre de coût, on en vient à prendre

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 12

THERE IS A BETTER WAY

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 14

Tout changement des exigences est bienvenu, même tardivement dans le

Les personnes du métier et les développeurs doivent collaborer quotidiennement tout au

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 15

Bâtissez des projets autour de personnes motivées

La plus efficace des méthodes pour transmettre l’information à destination et au sein

Les méthodes agiles favorisent un rythme de développement soutenable

LA MESURE D’AVANCEMENT Un logiciel qui fonctionne est la première mesure de progrès

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 16

Une attention constante à l’excellence technique et à la qualité de la conception

Les meilleures architectures, spécifications et conceptions sont issues d’équipes qui

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 17

VALEUR MÉTIER RISQUE

MÉTHODES AGILES MÉTHODES TRADITIONNELLES

VALEURS PRATIQUES CONCEPTS

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 20

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 21

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 22

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 23

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 24

COÛTS DÉLAIS COÛTS DÉLAIS

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 25

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 26

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 27

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 28

OCTO Part of Accenture Digital © 2019 - Al l rights reserved 29

THERE IS A BETTER WAY

VALEURS PRATIQUES CONCEPTS

PRIORISATION PAR DÉPLOIEMENT VALIDATION JUSTE CE QU’IL

CRITÈRES DÉCOUPAGE DES PLURI- PAS DE SURPRISE À