SlideShare uma empresa Scribd logo
1 de 76
Baixar para ler offline
Real Options: quand et comment
(ne pas) prendre des décisions
Pascal Van Cauwenberghe
Donne des conseils
Gère des projets
Programme

Agile Open
http://agileopen.net

http:/www.atbru.be

@pascalvc
http://blog.nayima.be

Crée des Jeux
Raconte des histoires
Organise des Conférences
http:/www.xpday.net
http://www.cafepress.com/+true-story+mugs
Il était une fois...
Le projet (1)
Site Social
Jeu Video

http://www.flickr.com/photos/rohdesign/3307874546

http://www.flickr.com/photos/seandreilinger/2187892869
Le site

http://www.flickr.com/photos/rohdesign/3307874546
LE NIOUZE
CELEBRITY NEWS AND GOSSIP

WORLD EXCLUSIVES

NOUVEAU DESIGN !!
L'analyse par les Options Réelles est
une technique qui permet de prendre
des décisions sur les décisions. C'est
cool, c'est meta.

Redesign
de tous les
sites!
Le “vieux” design jaune
sera remplacé par un
design bleu cool, fresh et
clair

Mais quel est l'intéret pour l'équipe au
quotidien ?

Vous prenez plein de décisions
chaque jour comme développeur ou
architecte. Des décisions qui peuvent
couter cher.

Les Options Réelles ne sont pas très
compliquées, cela s'explique en
quelques minutes. Mais en appliquant
les Options Réelles sur les projets
informatiques et sur l'architecture des
logiciels j'ai découvert que plein de
choses que je croyais vraies ou qui
me semblaient intuitivement
correctes étaient fausses.

J'illustre chaque technique avec des
exemples qui viennent de projets
auxquels j'ai participé les dernières
années, ou bien de la vie de tous les
jours.

Découvrez une autre façon de voir les
décisions, des techniques simples
pour gérer des projets ou définir une
architecture de logiciel. Vous
découvrirez peut-être que vous aussi
croyez des choses qui sont fausses.

Au minimum vous entendrez
quelques histoires belges... :-)

Template:
www.presentationmagazine.com
Le Redesign

http://www.flickr.com/photos/rohdesign/3307874546
La réaction
Chiffre de vente (estimé)
#

http://en.wikipedia.org/wiki/File:Sinterklaas_2007.jpg

http://commons.wikimedia.org/wiki/File:Jonathan_G_Meath_portrays_Santa_Claus.jpg

t
1. Cost of Delay

€

t
Les redesigns précédents
Creative Process
Générer des
options
Problème

MOA
Maitrise d’ouvrage

Tester et choisir
des options
Implémenter

MOE
Maitrise d’oeuvre
Creative Process
Creative Process chez nous
N’essayez pas de décider
trop vite!
2. The Creative Process
http://www.flickr.com/photos/miagant/5203621384
Real Options Team to the
Rescue!

Olav

Chris

Chris

“Donnez nous un jour et on vous dira quand et comment décider”
Quel est le problème?
Cost of Delay: un retard (même d’un jour)
peut nous coûter 50% des ventes
Real Options
Les Real Options
Ont une valeur
Ont un coût (= le prix de l’option)
Ont un prix (“strike price”) quand on exerce l’option
Ont une date/condition d’expiration
~ “Call Option”

Une option n’est pas une obligation
Ceci est une métaphore
Quelles sont nos options?
1. Aller en production avec le nouveau design bleu
•
•

Oui mais, on risque d’être en retard s’il faut attendre que
le design bleu soit stabilisé
Oui mais, entre temps il y aura plein de changements
dans le design

2. Aller en production avec le design jaune existant,
puis retravailler avec le design bleu
•
•

Oui mais, ce ne sera pas consistent
Oui mais, le retravail va augmenter le budget
Comparons les options
Option

Valeur

Bleu
Jaune +
Bleu

Coût

Prix

Expiration

Design
???
consistent

/

???

Risque
réduit de
délai

Redesign ???
en bleu

???
Quand est-ce qu’il faut
décider?
On est ici!

Option jaune + bleu ???

Production
DVD
Stockage
Magasin
Serveurs

Option bleu ???

Mars

????

Oct

Nov

Dec
Questions aux développeurs
• Est-ce qu’il faut appliquer le design immédiatement?
• “On l’a toujours fait dès le début, mais on pourrait le faire
plus tard”

• Combien de temps est-ce qu’il faut pour appliquer le
design jaune?
• “A peu près un mois”

• Combien de temps pour un design vraiment
compliqué?
• “Moins de 2 mois”

• Imaginez le pire design que les créatifs peuvent
inventer
• Rire. “Deux mois. On a de l’expérience avec ce type de
design” 
Quand est-ce qu’il faut
décider?
On est ici!

Option jaune + bleu ???

Production
DVD
Design et
test
(2M)
Serveurs

Option bleu ???

Mars

Stockage
Magasin

Août

Oct

Nov

Dec
Comment est-ce qu’on va
décider?
• SI le nouveau design bleu est complètement stable
• ET si l’estimation de la charge de travail du design
bleu est moins que deux mois
• ALORS on applique le design bleu
• SINON on applique l’ancien design jaune et on
planifiera le redesign bleu quand il sera stable
• Rendez vous: 1er Août
Et entre temps...
• On développe le site en “noir et blanc”

• Un membre de l’équipe participe aux réunions de suivi
du redesign (2h toutes les 2 semaines) et tient l’équipe
au courant de la situation.
La journée n’est pas encore
finie
• On a encore quelques questions:
• Développeurs, qu’est-ce qu’il faut changer quand
le design change?
• Développeurs montrent l’architecture et le code

• Et s’il y avait moins à changer?
• Petit spike architectural: séparation, déduplication...

• Ca coûte combien pour améliorer l’architecture?
• “On peut faire cela en quelques jours”
• “Après, un redesign ne coûtera jamais plus qu’un
mois”
Quand est-ce qu’il faut
décider?
On est ici!

Option jaune + bleu ???

Production
DVD
Design et
test
(2M)
Serveurs

Option bleu ???

Mars

Stockage
Magasin

Août

Oct

Nov

Dec
Quand est-ce qu’il faut
décider?
On est ici!

Option jaune + bleu ???

Production
DVD
Design
et test
(1M)
Serveurs

Option bleu ???

Mars

Stockage
Magasin

Sept

Oct

Nov

Dec
L’avantage de réduire le
temps de cycle
• On peut décider encore un mois plus tard
• On a un mois de plus pour implémenter la
fonctionnalité
• Un redesign jaune -> bleu ne coûte plus qu’un mois au
lieu de deux

• Rendez-vous pour la décision: 1er septembre
Comparons les options
Option

Valeur

Coût

Prix

Bleu

Design
1 semaine de /
consistent refactoring
+ 2h de suivi /
2 semaines

Jaune +
Bleu

Risque
réduit de
délai

Expiration
01/09/20XX

1 semaine de Redesign en 01/09/20XX
refactoring
bleu (1 mois)
+ 2h de suivi /
2 semaines
3. Real Options
Optimal Decision Process
Décisions

Option

Option

Option

http://commitment-thebook.com/

Implement
er

Deadline
Retro
• 1 septembre: le design bleu n’est pas stable (ce n’était
pas une surprise). On utilise le design jaune
• Projet livré à temps
• “Ce projet était beaucoup moins stressant que les
précédents”
• Fonctionnalité:
• Design:
Et ils vécurent heureux à tout jamais
Encore une petite histoire?
Le projet (2)
Internet Banking

http://www.flickr.com/photos/seeminglee/8276505285
p.s. La banque n’est pas HSBC

Internet Banking servers

http://en.wikipedia.org/wiki/File:Rack001.jpg
Votre mission, si vous
l’acceptez...
• On lance notre service online banking le
DD/MM/YYYY
• Société X va développer l’application web
• Vous devez livrer l’application serveur à temps

• Petits détails...
• On est en train de décider sur quelle plateforme
• On est en train de la documenter la DB que vous
devez utiliser
• On est en train de rédiger le cahier des charges
• “Mais commencez déjà à développer, car on n’a pas
beaucoup de temps!”
• Accepteriez vous cette mission?
Notre problème
On est ici!

Decision

Plateforme A
Pas assez de
Implementer
temps

Plateforme B
Notre solution
• Si on n’a pas assez de temps pour implémenter
plateforme A OU plateforme B
• On va implémenter plateforme A ET B
• C’est logique... En Belgique 
Notre solution
On est ici!

Decision

Implémenter
Plateforme A
Implémenter
Plateforme B

Finir
implementation
de la plateforme
choisie
Set-based development
APP

3 implementations en parallèle :
•Plateforme A
•Plateforme B
•Environnement de développement et test

API

A
Server

B
Server

Test
Server
Retro
• Décision: plateforme A
• Implémentation A est allée en production à temps
• Implémentation dev/test continue à être utilisée
pendant le développement
• Implémentation B na servi à rien

• A suivre...
Et ils vécurent...
LE NIOUZE
CELEBRITY NEWS AND GOSSIP

WORLD EXCLUSIVES

EDITEUR B BOUFFE EDITEUR A
L'analyse par les Options Réelles est
une technique qui permet de prendre
des décisions sur les décisions. C'est
cool, c'est meta.

Redesign
de tous les
sites!
Le “vieux” design jaune
sera remplacé par un
design bleu cool, fresh et
clair

Mais quel est l'intérêt pour l'équipe au
quotidien ?

Vous prenez plein de décisions
chaque jour comme développeur ou
architecte. Des décisions qui peuvent
couter cher.

Les Options Réelles ne sont pas très
compliquées, cela s'explique en
quelques minutes. Mais en appliquant
les Options Réelles sur les projets
informatiques et sur l'architecture des
logiciels j'ai découvert que plein de
choses que je croyais vraies ou qui
me semblaient intuitivement
correctes étaient fausses.

J'illustre chaque technique avec des
exemples qui viennent de projets
auxquels j'ai participé les dernières
années, ou bien de la vie de tous les
jours.

Découvrez une autre façon de voir les
décisions, des techniques simples
pour gérer des projets ou définir une
architecture de logiciel. Vous
découvrirez peut-être que vous aussi
croyez des choses qui sont fausses.

Au minimum vous entendrez
quelques histoires belges... :-)

Template:
www.presentationmagazine.com
Un peu plus tard
• Editeur de plateforme B envoit une lettre à la banque:
“Bonne nouvelle! Nous venons d’acquérir la plateforme A.
Tout développement sur cette plateforme est arrêté. Le
support sera arrêté bientôt.
Veuillez migrer vers la plateforme B.”
• Facile!
C
A

B
B
Et ils vécurent heureux
4. Set-based development

Option
A

Option
B

Option
C
Mais c’est logique, capitaine!
Ce n’est que du bon sens!
Irrationnel, mais prévisible
Predictably Irrational
• Sunk Cost Fallacy
• “Il ne faut pas mettre du bon argent sur du mauvais”

• On ne sait pas estimer des valeurs absolues
• Mais l’estimation relative, ça va

• Nous sur-estimons la valeur de ce qu’on a
• Et nous sur-estimons le coût du changement

• Notre modèle d’escompte est buggé
• Aujourd’hui versus demain

• Trop de choix nous rend angoissé
• On n’aime pas l’incertitude
• “Je préfère une mauvaise décision à pas de décision!”
Comment est-ce vous avez
survécu aussi longtemps?
5. On n’est pas rationnels,
mais on peut faire
semblant
Oui mais…
Les Options sont trop
chères
Un autre projet
• Une loi européenne sur la TVA change le 01/01/YYYY
• Le système actuel n’est pas compatible avec la loi

• On construit un système de remplacement
• Qu’est-ce qui se passe si on livre en retard?
• Cost of Delay?

• La fin de l’année n’est plus loin..
Le problème
On est ici

Nouveau Système

01/01/XXXX
Est-ce qu’on peut acheter
une option “Plan B”?
• Est-ce qu’il y a un “Plan B” ?

• Option: on demande à l’éditeur un prix et une date
d’expiration pour mettre à jour l’ancienne application
• Mon estimation: cette option coûte < 1000€
L’option “Plan B”
On est ici

Décision

Nouveau Système

Mise à jour ancien
système ???

Implémenter

01/01/XXXX
NON !
“L’échec n’est pas une option”
Et puis...?
• Le nouveau système n’est pas prêt en décembre
• On ne peut plus facturer nos clients
• Chaque mois de délai: perte de X00.000€
• Mais on a économisé quelques milliers d’euros sur les
options...
Qu’est-ce qu’on a appris ?
•
•
•
•

Il faut gérer le processus créatif
Voir les décisions difficiles comme des options
Ne décidez pas. Decidez quand et comment décider.
Parfois, faire tout est la bonne option
• Pour avoir plus d’information

• Considérez d’abord valeur, puis le coût
• Ce outils m’aident à rester calme dans des situations
stressantes
• Keep it simple:
• Mon outil de gestion d’options: Google Calendar
Décisions
architecturales
Tout ce que vous avez appris
sur l’architecture est faux!
“L’Architecture c’est toutes les décisions
qu’il faut prendre tôt parce qu’elles sont
difficiles à défaire”

Le problème: tôt dans chaque projet on
n’a pas assez d’information pour prendre
les décisions correctes. Et puis, le
monde change.
Principe du bon moment
Décision facile à changer: décidez tôt

Décision difficile à changer:
• Rendez la plus facile à changer
• Décidez le plus tard possible
Principe de l’effort minimal
Ne faites pas le travail de demain
aujourd’hui (YAGNI)
ET

Ne faites rien aujourd’hui qui entrave le
travail de demain
“Le principe du fainéant”
Une bonne architecture...
Une bonne architecture crée des options
pour votre équipe, votre organisation et
vos clients
Créer et maintenir les options ce fait tous
les jours, à petits pas
Sinon, vous créez des systèmes legacy
qui ont de moins en moins options
“Dans chaque mauvaise
décision, il se cache une
bonne décision.
Mais il faut chercher pour
la trouver.”
Mr Nobody

A boy faced with the consequences of choices...
A boy faced with the consequences of choices...

Chooses not to choose

“Mr. Nobody” a movie by Jaco Van Dormael
MERCI !
• Si vous voulez en savoir plus...

pascal@nayima.be
http://blog.nayima.be
Real Options Lean Kanban France 2013
Real Options Lean Kanban France 2013

Mais conteúdo relacionado

Semelhante a Real Options Lean Kanban France 2013

Lean & Agile UX - afterwork Axance
Lean & Agile UX - afterwork AxanceLean & Agile UX - afterwork Axance
Lean & Agile UX - afterwork AxanceAlexandre Jubien
 
cipe jeu gestion de projet.pdf
cipe jeu gestion de projet.pdfcipe jeu gestion de projet.pdf
cipe jeu gestion de projet.pdfCIPE
 
Le Rapid Prototyping, ça marche !
Le Rapid Prototyping, ça marche !Le Rapid Prototyping, ça marche !
Le Rapid Prototyping, ça marche !Catherine Verfaillie
 
Afterworkshop #4 : Appréhender son premier design sprint
Afterworkshop #4 : Appréhender son premier design sprintAfterworkshop #4 : Appréhender son premier design sprint
Afterworkshop #4 : Appréhender son premier design sprintNewflux UX/UI News
 
Agile Wake Up #3 : Lean UX
Agile Wake Up #3 : Lean UXAgile Wake Up #3 : Lean UX
Agile Wake Up #3 : Lean UXZenika
 
Conférence Paris Web 2015 - Vers une bonne pratique du Pair Design
Conférence Paris Web 2015 - Vers une bonne pratique du Pair DesignConférence Paris Web 2015 - Vers une bonne pratique du Pair Design
Conférence Paris Web 2015 - Vers une bonne pratique du Pair DesignCatherine Verfaillie
 
UX Days 2019 by Flupa - Conférence : Pauline Thomas
UX Days 2019 by Flupa - Conférence : Pauline ThomasUX Days 2019 by Flupa - Conférence : Pauline Thomas
UX Days 2019 by Flupa - Conférence : Pauline ThomasFlupa
 
Appréhender et s'adapter aux mutations de l'économie numérique.
Appréhender et s'adapter aux mutations de l'économie numérique. Appréhender et s'adapter aux mutations de l'économie numérique.
Appréhender et s'adapter aux mutations de l'économie numérique. Thibaut Brousse
 
Développer en mode kick-ass à Devoxx France
Développer en mode kick-ass à Devoxx FranceDévelopper en mode kick-ass à Devoxx France
Développer en mode kick-ass à Devoxx FranceSamuel Le Berrigaud
 
Agile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileAgile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileLaurent Deséchalliers
 
AT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileAT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileNormandy JUG
 
10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptx10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptxGuillaume Saint Etienne
 
Le développement logiciel expliqué à votre patron en 24 slides
Le développement logiciel expliqué à votre patron en 24 slidesLe développement logiciel expliqué à votre patron en 24 slides
Le développement logiciel expliqué à votre patron en 24 slidesYassine CHAOUCHE
 
Développer en mode kick-ass à Scrum Day
Développer en mode kick-ass à Scrum DayDévelopper en mode kick-ass à Scrum Day
Développer en mode kick-ass à Scrum DaySamuel Le Berrigaud
 

Semelhante a Real Options Lean Kanban France 2013 (20)

Lean & Agile UX - afterwork Axance
Lean & Agile UX - afterwork AxanceLean & Agile UX - afterwork Axance
Lean & Agile UX - afterwork Axance
 
cipe jeu gestion de projet.pdf
cipe jeu gestion de projet.pdfcipe jeu gestion de projet.pdf
cipe jeu gestion de projet.pdf
 
Le Rapid Prototyping, ça marche !
Le Rapid Prototyping, ça marche !Le Rapid Prototyping, ça marche !
Le Rapid Prototyping, ça marche !
 
Formation créativité
Formation créativitéFormation créativité
Formation créativité
 
Afterworkshop #4 : Appréhender son premier design sprint
Afterworkshop #4 : Appréhender son premier design sprintAfterworkshop #4 : Appréhender son premier design sprint
Afterworkshop #4 : Appréhender son premier design sprint
 
Agile Wake Up #3 : Lean UX
Agile Wake Up #3 : Lean UXAgile Wake Up #3 : Lean UX
Agile Wake Up #3 : Lean UX
 
Conférence Paris Web 2015 - Vers une bonne pratique du Pair Design
Conférence Paris Web 2015 - Vers une bonne pratique du Pair DesignConférence Paris Web 2015 - Vers une bonne pratique du Pair Design
Conférence Paris Web 2015 - Vers une bonne pratique du Pair Design
 
Une expérience agile
Une expérience agileUne expérience agile
Une expérience agile
 
HETIC Projet d'une nuit 3D UX
HETIC Projet d'une nuit 3D UXHETIC Projet d'une nuit 3D UX
HETIC Projet d'une nuit 3D UX
 
Nuit Charette HETIC 3D UX
Nuit Charette HETIC 3D UXNuit Charette HETIC 3D UX
Nuit Charette HETIC 3D UX
 
UX Days 2019 by Flupa - Conférence : Pauline Thomas
UX Days 2019 by Flupa - Conférence : Pauline ThomasUX Days 2019 by Flupa - Conférence : Pauline Thomas
UX Days 2019 by Flupa - Conférence : Pauline Thomas
 
Logbook Opus Design
Logbook Opus DesignLogbook Opus Design
Logbook Opus Design
 
Appréhender et s'adapter aux mutations de l'économie numérique.
Appréhender et s'adapter aux mutations de l'économie numérique. Appréhender et s'adapter aux mutations de l'économie numérique.
Appréhender et s'adapter aux mutations de l'économie numérique.
 
Développer en mode kick-ass à Devoxx France
Développer en mode kick-ass à Devoxx FranceDévelopper en mode kick-ass à Devoxx France
Développer en mode kick-ass à Devoxx France
 
Agile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileAgile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agile
 
AT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileAT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet Agile
 
10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptx10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptx
 
Etude materiel
Etude materielEtude materiel
Etude materiel
 
Le développement logiciel expliqué à votre patron en 24 slides
Le développement logiciel expliqué à votre patron en 24 slidesLe développement logiciel expliqué à votre patron en 24 slides
Le développement logiciel expliqué à votre patron en 24 slides
 
Développer en mode kick-ass à Scrum Day
Développer en mode kick-ass à Scrum DayDévelopper en mode kick-ass à Scrum Day
Développer en mode kick-ass à Scrum Day
 

Mais de AgileCoach.net

Vous pouvez ignorerr les controleurs de gestion
Vous pouvez ignorerr les controleurs de gestionVous pouvez ignorerr les controleurs de gestion
Vous pouvez ignorerr les controleurs de gestionAgileCoach.net
 
Keynote agile grenoble 2013
Keynote agile grenoble 2013Keynote agile grenoble 2013
Keynote agile grenoble 2013AgileCoach.net
 
Real Options: How and When (not) to take Decisions
Real Options: How and When (not) to take DecisionsReal Options: How and When (not) to take Decisions
Real Options: How and When (not) to take DecisionsAgileCoach.net
 
Chouette! Encore un bug! Agile Tour 2012
Chouette! Encore un bug! Agile Tour 2012Chouette! Encore un bug! Agile Tour 2012
Chouette! Encore un bug! Agile Tour 2012AgileCoach.net
 
Chouette! Encore un bug!
Chouette! Encore un bug!Chouette! Encore un bug!
Chouette! Encore un bug!AgileCoach.net
 
Conflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - FrenchConflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - FrenchAgileCoach.net
 
Lean out your backlog - Lean and Kanban Belgium 2010
Lean out your backlog - Lean and Kanban Belgium 2010Lean out your backlog - Lean and Kanban Belgium 2010
Lean out your backlog - Lean and Kanban Belgium 2010AgileCoach.net
 
Conflict resolution diagram tutorial
Conflict resolution diagram tutorialConflict resolution diagram tutorial
Conflict resolution diagram tutorialAgileCoach.net
 
Agile 2010 Estimation Games
Agile 2010 Estimation  GamesAgile 2010 Estimation  Games
Agile 2010 Estimation GamesAgileCoach.net
 
Business value by systems thinking
Business value by systems thinkingBusiness value by systems thinking
Business value by systems thinkingAgileCoach.net
 

Mais de AgileCoach.net (11)

Vous pouvez ignorerr les controleurs de gestion
Vous pouvez ignorerr les controleurs de gestionVous pouvez ignorerr les controleurs de gestion
Vous pouvez ignorerr les controleurs de gestion
 
Keynote agile grenoble 2013
Keynote agile grenoble 2013Keynote agile grenoble 2013
Keynote agile grenoble 2013
 
Real Options: How and When (not) to take Decisions
Real Options: How and When (not) to take DecisionsReal Options: How and When (not) to take Decisions
Real Options: How and When (not) to take Decisions
 
Chouette! Encore un bug! Agile Tour 2012
Chouette! Encore un bug! Agile Tour 2012Chouette! Encore un bug! Agile Tour 2012
Chouette! Encore un bug! Agile Tour 2012
 
Great! another bug
Great! another bugGreat! another bug
Great! another bug
 
Chouette! Encore un bug!
Chouette! Encore un bug!Chouette! Encore un bug!
Chouette! Encore un bug!
 
Conflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - FrenchConflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - French
 
Lean out your backlog - Lean and Kanban Belgium 2010
Lean out your backlog - Lean and Kanban Belgium 2010Lean out your backlog - Lean and Kanban Belgium 2010
Lean out your backlog - Lean and Kanban Belgium 2010
 
Conflict resolution diagram tutorial
Conflict resolution diagram tutorialConflict resolution diagram tutorial
Conflict resolution diagram tutorial
 
Agile 2010 Estimation Games
Agile 2010 Estimation  GamesAgile 2010 Estimation  Games
Agile 2010 Estimation Games
 
Business value by systems thinking
Business value by systems thinkingBusiness value by systems thinking
Business value by systems thinking
 

Real Options Lean Kanban France 2013

  • 1. Real Options: quand et comment (ne pas) prendre des décisions Pascal Van Cauwenberghe
  • 2. Donne des conseils Gère des projets Programme Agile Open http://agileopen.net http:/www.atbru.be @pascalvc http://blog.nayima.be Crée des Jeux Raconte des histoires Organise des Conférences http:/www.xpday.net
  • 4. Il était une fois...
  • 5. Le projet (1) Site Social Jeu Video http://www.flickr.com/photos/rohdesign/3307874546 http://www.flickr.com/photos/seandreilinger/2187892869
  • 7. LE NIOUZE CELEBRITY NEWS AND GOSSIP WORLD EXCLUSIVES NOUVEAU DESIGN !! L'analyse par les Options Réelles est une technique qui permet de prendre des décisions sur les décisions. C'est cool, c'est meta. Redesign de tous les sites! Le “vieux” design jaune sera remplacé par un design bleu cool, fresh et clair Mais quel est l'intéret pour l'équipe au quotidien ? Vous prenez plein de décisions chaque jour comme développeur ou architecte. Des décisions qui peuvent couter cher. Les Options Réelles ne sont pas très compliquées, cela s'explique en quelques minutes. Mais en appliquant les Options Réelles sur les projets informatiques et sur l'architecture des logiciels j'ai découvert que plein de choses que je croyais vraies ou qui me semblaient intuitivement correctes étaient fausses. J'illustre chaque technique avec des exemples qui viennent de projets auxquels j'ai participé les dernières années, ou bien de la vie de tous les jours. Découvrez une autre façon de voir les décisions, des techniques simples pour gérer des projets ou définir une architecture de logiciel. Vous découvrirez peut-être que vous aussi croyez des choses qui sont fausses. Au minimum vous entendrez quelques histoires belges... :-) Template: www.presentationmagazine.com
  • 10. Chiffre de vente (estimé) # http://en.wikipedia.org/wiki/File:Sinterklaas_2007.jpg http://commons.wikimedia.org/wiki/File:Jonathan_G_Meath_portrays_Santa_Claus.jpg t
  • 11. 1. Cost of Delay € t
  • 13. Creative Process Générer des options Problème MOA Maitrise d’ouvrage Tester et choisir des options Implémenter MOE Maitrise d’oeuvre
  • 16. N’essayez pas de décider trop vite!
  • 17. 2. The Creative Process
  • 18.
  • 20. Real Options Team to the Rescue! Olav Chris Chris “Donnez nous un jour et on vous dira quand et comment décider”
  • 21. Quel est le problème? Cost of Delay: un retard (même d’un jour) peut nous coûter 50% des ventes
  • 22. Real Options Les Real Options Ont une valeur Ont un coût (= le prix de l’option) Ont un prix (“strike price”) quand on exerce l’option Ont une date/condition d’expiration ~ “Call Option” Une option n’est pas une obligation Ceci est une métaphore
  • 23. Quelles sont nos options? 1. Aller en production avec le nouveau design bleu • • Oui mais, on risque d’être en retard s’il faut attendre que le design bleu soit stabilisé Oui mais, entre temps il y aura plein de changements dans le design 2. Aller en production avec le design jaune existant, puis retravailler avec le design bleu • • Oui mais, ce ne sera pas consistent Oui mais, le retravail va augmenter le budget
  • 24. Comparons les options Option Valeur Bleu Jaune + Bleu Coût Prix Expiration Design ??? consistent / ??? Risque réduit de délai Redesign ??? en bleu ???
  • 25. Quand est-ce qu’il faut décider? On est ici! Option jaune + bleu ??? Production DVD Stockage Magasin Serveurs Option bleu ??? Mars ???? Oct Nov Dec
  • 26. Questions aux développeurs • Est-ce qu’il faut appliquer le design immédiatement? • “On l’a toujours fait dès le début, mais on pourrait le faire plus tard” • Combien de temps est-ce qu’il faut pour appliquer le design jaune? • “A peu près un mois” • Combien de temps pour un design vraiment compliqué? • “Moins de 2 mois” • Imaginez le pire design que les créatifs peuvent inventer • Rire. “Deux mois. On a de l’expérience avec ce type de design” 
  • 27. Quand est-ce qu’il faut décider? On est ici! Option jaune + bleu ??? Production DVD Design et test (2M) Serveurs Option bleu ??? Mars Stockage Magasin Août Oct Nov Dec
  • 28. Comment est-ce qu’on va décider? • SI le nouveau design bleu est complètement stable • ET si l’estimation de la charge de travail du design bleu est moins que deux mois • ALORS on applique le design bleu • SINON on applique l’ancien design jaune et on planifiera le redesign bleu quand il sera stable • Rendez vous: 1er Août
  • 29. Et entre temps... • On développe le site en “noir et blanc” • Un membre de l’équipe participe aux réunions de suivi du redesign (2h toutes les 2 semaines) et tient l’équipe au courant de la situation.
  • 30. La journée n’est pas encore finie • On a encore quelques questions: • Développeurs, qu’est-ce qu’il faut changer quand le design change? • Développeurs montrent l’architecture et le code • Et s’il y avait moins à changer? • Petit spike architectural: séparation, déduplication... • Ca coûte combien pour améliorer l’architecture? • “On peut faire cela en quelques jours” • “Après, un redesign ne coûtera jamais plus qu’un mois”
  • 31. Quand est-ce qu’il faut décider? On est ici! Option jaune + bleu ??? Production DVD Design et test (2M) Serveurs Option bleu ??? Mars Stockage Magasin Août Oct Nov Dec
  • 32. Quand est-ce qu’il faut décider? On est ici! Option jaune + bleu ??? Production DVD Design et test (1M) Serveurs Option bleu ??? Mars Stockage Magasin Sept Oct Nov Dec
  • 33. L’avantage de réduire le temps de cycle • On peut décider encore un mois plus tard • On a un mois de plus pour implémenter la fonctionnalité • Un redesign jaune -> bleu ne coûte plus qu’un mois au lieu de deux • Rendez-vous pour la décision: 1er septembre
  • 34. Comparons les options Option Valeur Coût Prix Bleu Design 1 semaine de / consistent refactoring + 2h de suivi / 2 semaines Jaune + Bleu Risque réduit de délai Expiration 01/09/20XX 1 semaine de Redesign en 01/09/20XX refactoring bleu (1 mois) + 2h de suivi / 2 semaines
  • 35. 3. Real Options Optimal Decision Process Décisions Option Option Option http://commitment-thebook.com/ Implement er Deadline
  • 36. Retro • 1 septembre: le design bleu n’est pas stable (ce n’était pas une surprise). On utilise le design jaune • Projet livré à temps • “Ce projet était beaucoup moins stressant que les précédents” • Fonctionnalité: • Design:
  • 37. Et ils vécurent heureux à tout jamais
  • 38. Encore une petite histoire?
  • 39. Le projet (2) Internet Banking http://www.flickr.com/photos/seeminglee/8276505285 p.s. La banque n’est pas HSBC Internet Banking servers http://en.wikipedia.org/wiki/File:Rack001.jpg
  • 40. Votre mission, si vous l’acceptez... • On lance notre service online banking le DD/MM/YYYY • Société X va développer l’application web • Vous devez livrer l’application serveur à temps • Petits détails... • On est en train de décider sur quelle plateforme • On est en train de la documenter la DB que vous devez utiliser • On est en train de rédiger le cahier des charges • “Mais commencez déjà à développer, car on n’a pas beaucoup de temps!” • Accepteriez vous cette mission?
  • 41. Notre problème On est ici! Decision Plateforme A Pas assez de Implementer temps Plateforme B
  • 42. Notre solution • Si on n’a pas assez de temps pour implémenter plateforme A OU plateforme B • On va implémenter plateforme A ET B • C’est logique... En Belgique 
  • 43. Notre solution On est ici! Decision Implémenter Plateforme A Implémenter Plateforme B Finir implementation de la plateforme choisie
  • 44. Set-based development APP 3 implementations en parallèle : •Plateforme A •Plateforme B •Environnement de développement et test API A Server B Server Test Server
  • 45. Retro • Décision: plateforme A • Implémentation A est allée en production à temps • Implémentation dev/test continue à être utilisée pendant le développement • Implémentation B na servi à rien • A suivre...
  • 47. LE NIOUZE CELEBRITY NEWS AND GOSSIP WORLD EXCLUSIVES EDITEUR B BOUFFE EDITEUR A L'analyse par les Options Réelles est une technique qui permet de prendre des décisions sur les décisions. C'est cool, c'est meta. Redesign de tous les sites! Le “vieux” design jaune sera remplacé par un design bleu cool, fresh et clair Mais quel est l'intérêt pour l'équipe au quotidien ? Vous prenez plein de décisions chaque jour comme développeur ou architecte. Des décisions qui peuvent couter cher. Les Options Réelles ne sont pas très compliquées, cela s'explique en quelques minutes. Mais en appliquant les Options Réelles sur les projets informatiques et sur l'architecture des logiciels j'ai découvert que plein de choses que je croyais vraies ou qui me semblaient intuitivement correctes étaient fausses. J'illustre chaque technique avec des exemples qui viennent de projets auxquels j'ai participé les dernières années, ou bien de la vie de tous les jours. Découvrez une autre façon de voir les décisions, des techniques simples pour gérer des projets ou définir une architecture de logiciel. Vous découvrirez peut-être que vous aussi croyez des choses qui sont fausses. Au minimum vous entendrez quelques histoires belges... :-) Template: www.presentationmagazine.com
  • 48. Un peu plus tard • Editeur de plateforme B envoit une lettre à la banque: “Bonne nouvelle! Nous venons d’acquérir la plateforme A. Tout développement sur cette plateforme est arrêté. Le support sera arrêté bientôt. Veuillez migrer vers la plateforme B.” • Facile! C A B B
  • 49. Et ils vécurent heureux
  • 51. Mais c’est logique, capitaine!
  • 52. Ce n’est que du bon sens!
  • 53.
  • 55. Predictably Irrational • Sunk Cost Fallacy • “Il ne faut pas mettre du bon argent sur du mauvais” • On ne sait pas estimer des valeurs absolues • Mais l’estimation relative, ça va • Nous sur-estimons la valeur de ce qu’on a • Et nous sur-estimons le coût du changement • Notre modèle d’escompte est buggé • Aujourd’hui versus demain • Trop de choix nous rend angoissé • On n’aime pas l’incertitude • “Je préfère une mauvaise décision à pas de décision!”
  • 56. Comment est-ce vous avez survécu aussi longtemps?
  • 57. 5. On n’est pas rationnels, mais on peut faire semblant
  • 58. Oui mais… Les Options sont trop chères
  • 59. Un autre projet • Une loi européenne sur la TVA change le 01/01/YYYY • Le système actuel n’est pas compatible avec la loi • On construit un système de remplacement • Qu’est-ce qui se passe si on livre en retard? • Cost of Delay? • La fin de l’année n’est plus loin..
  • 60. Le problème On est ici Nouveau Système 01/01/XXXX
  • 61. Est-ce qu’on peut acheter une option “Plan B”? • Est-ce qu’il y a un “Plan B” ? • Option: on demande à l’éditeur un prix et une date d’expiration pour mettre à jour l’ancienne application • Mon estimation: cette option coûte < 1000€
  • 62. L’option “Plan B” On est ici Décision Nouveau Système Mise à jour ancien système ??? Implémenter 01/01/XXXX
  • 63. NON ! “L’échec n’est pas une option”
  • 64. Et puis...? • Le nouveau système n’est pas prêt en décembre • On ne peut plus facturer nos clients • Chaque mois de délai: perte de X00.000€ • Mais on a économisé quelques milliers d’euros sur les options...
  • 65. Qu’est-ce qu’on a appris ? • • • • Il faut gérer le processus créatif Voir les décisions difficiles comme des options Ne décidez pas. Decidez quand et comment décider. Parfois, faire tout est la bonne option • Pour avoir plus d’information • Considérez d’abord valeur, puis le coût • Ce outils m’aident à rester calme dans des situations stressantes • Keep it simple: • Mon outil de gestion d’options: Google Calendar
  • 67. Tout ce que vous avez appris sur l’architecture est faux! “L’Architecture c’est toutes les décisions qu’il faut prendre tôt parce qu’elles sont difficiles à défaire” Le problème: tôt dans chaque projet on n’a pas assez d’information pour prendre les décisions correctes. Et puis, le monde change.
  • 68. Principe du bon moment Décision facile à changer: décidez tôt Décision difficile à changer: • Rendez la plus facile à changer • Décidez le plus tard possible
  • 69. Principe de l’effort minimal Ne faites pas le travail de demain aujourd’hui (YAGNI) ET Ne faites rien aujourd’hui qui entrave le travail de demain “Le principe du fainéant”
  • 70. Une bonne architecture... Une bonne architecture crée des options pour votre équipe, votre organisation et vos clients Créer et maintenir les options ce fait tous les jours, à petits pas Sinon, vous créez des systèmes legacy qui ont de moins en moins options
  • 71. “Dans chaque mauvaise décision, il se cache une bonne décision. Mais il faut chercher pour la trouver.”
  • 72. Mr Nobody A boy faced with the consequences of choices...
  • 73. A boy faced with the consequences of choices... Chooses not to choose “Mr. Nobody” a movie by Jaco Van Dormael
  • 74. MERCI ! • Si vous voulez en savoir plus... pascal@nayima.be http://blog.nayima.be