Upload
agilecoachnet
View
1.115
Download
2
Embed Size (px)
DESCRIPTION
How to use Real Options and related thinking tools to take architectural decisions and bring a happy ending to your project
Citation preview
Real Options: quand et comment (ne pas) prendre
des décisionsPascal Van Cauwenberghe
11:40h – 12:40h Salle Belvédère
#AgileFrance
Donne des conseilsGère des projetsProgramme
Crée des JeuxOrganise des Conférences@pascalvc
http://blog.nayima.be
http:/www.xpday.net
http:/www.atbru.be
http://www.cafepress.com/+true-story+mugs
Il était une fois...
http://www.flickr.com/photos/seandreilinger/2187892869
http://www.flickr.com/photos/rohdesign/3307874546
Jeu Video
Site Social
Le projet (1)
http://www.flickr.com/photos/rohdesign/3307874546
Le site
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.
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... :-)
CELEBRITY NEWS AND GOSSIP WORLD EXCLUSIVES
LE NIOUZE
Redesign de tous les sites!
Le “vieux” design jaune sera remplacé par un design bleu cool, fresh et clair
Template: www.presentationmagazine.com
Le Redesign
http://www.flickr.com/photos/rohdesign/3307874546
La réaction
Chiffre de vente (estimé)
t
#
http://en.wikipedia.org/wiki/File:Sinterklaas_2007.jpg
http://commons.wikimedia.org/wiki/File:Jonathan_G_Meath_portrays_Santa_Claus.jpg
1. Cost of Delay
t
€
Les redesigns précédents
Creative Process
Problème
Générer desoptions
Tester et choisirdes options
Implémenter
MOAMaitrise d’ouvrage
MOEMaitrise 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!
“Donnez nous un jour et on vous dira quand et comment décider”
Olav Chris
Chris
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 OptionsOnt un coût (= le prix de l’option)Ont une valeurOnt un prix (“strike price”) quand on exerce
l’optionOnt 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 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 design2. Aller en production avec le design jaune, 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 Coût Prix Valeur Expiration
Bleu ??? / Design consistent
???
Jaune + Bleu
??? Redesign en bleu
Cost of Delay == 0
???
Quand est-ce qu’il faut décider?
Option jaune + bleu ???
Option bleu ???
DecNov
StockageMagasin
Oct
Production DVD
Serveurs
????Mars
On est ici!
Quelques 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?
Option jaune + bleu ???
Option bleu ???
DecNov
StockageMagasin
Oct
Production DVD
Serveurs
AoûtMars
On est ici!
Design et test(2M)
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?
Option jaune + bleu ???
Option bleu ???
DecNov
StockageMagasin
Oct
Production DVD
Serveurs
AoûtMars
On est ici!
Design et test(2M)
Quand est-ce qu’il faut décider?
Option jaune + bleu ???
Option bleu ???
DecNov
StockageMagasin
Oct
Production DVD
Serveurs
SeptMars
On est ici!
Design et test(1M)
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 Coût Prix Valeur Expiration
Jaune + Bleu
1 semaine de refactoring+ 2h de suivi / 2 semaines
Redesign en bleu (1 mois)
Cost of Delay == 0
01/09/20XX
Bleu 1 semaine de refactoring+ 2h de suivi / 2 semaines
/ Design consistent
01/09/20XX
3. Real Options Optimal Decision
Process
Option Implementer
Option
Option
Décisions Deadline
http://commitment-thebook.com/
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)
http://www.flickr.com/photos/seeminglee/8276505285p.s. La banque n’est pas HSBC
http://en.wikipedia.org/wiki/File:Rack001.jpg
Internet Banking Internet Banking servers
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
Plateforme A
Implementer
Plateforme B
Decision
On est ici!
Pas assez de temps
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
Implémenter Plateforme A
Finir implementation de la plateforme choisie
Implémenter Plateforme B
Decision
On est ici!
Set-based development
APP
API
A Serve
r
B Serve
r
Test Serve
r
3 implementations en parallèle :• Plateforme A• Plateforme B• Environnement de développement et test
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...Ce n’est pas encore fini
EDITEUR B BOUFFE EDITEUR AL'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.
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... :-)
CELEBRITY NEWS AND GOSSIP WORLD EXCLUSIVES
LE NIOUZE
Redesign de tous les sites!
Le “vieux” design jaune sera remplacé par un design bleu cool, fresh et clair
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!
A BBC
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!
Irratio
nnel
Irrationnel, mais prévisible
Sunk Cost(*) fallacy
(*) coûts irrécupérables, coûts échoués
• Tout ce qui est déjà investi est perdu• On ne devrait pas en tenir compte pour décider
si on continue• Mais on accorde beaucoup de valeur à l’argent
(et le temps) déjà investi• Solution: regarder les “deltas” de valeur et coût
• “Marginal Economics” (Reinertsen, Flow)
• Aussi: “Emotional Sunk Cost”
On ne sait pas estimer
• On a du mal avec des chiffres absolus• On utilise des estimations relatives pour prendre des décisions
• On surestime les coûts vs. bénéfice• Une fois qu’on a décidé on a peur de perdre ce qu’on a
• On surestime la valeur de ce qu’on a• Pour confirmer qu’on a fait un bon choix
• On surestime la valeur dans le présent vs le futur• => Décisions qui favorisent le court terme
L’embarras du choix
• Quand il y a beaucoup de choix on bloque• Plus de choix, plus de chance de se tromper
• Quand on a beaucoup d’options on perd de vue le but• On passe tout son temps à la “chasse aux options”
• Ne créez pas des solutions « génériques »
Et surtout...
On n’aime pas l’incertitude
• Surtout en moments de stress• Ces outils m’aident à rester calme
• Au lieu de décider on établit un plan pour décider:• Quand on prend quelles décisions• Comment on va prendre les décisions• Sur base de quelles données• Qui est impliqué• => On prend ces décisions rapidement et surement
• Mon outil préféré pour gérer mes Real Options: mon calendrier
Comment est-ce vous avez survécu aussi longtemps?
6. On n’est pas rationnels,
mais on peut faire semblant
Encore une histoire
Le projet (3)
http://www.flickr.com/photos/caseorganic/3216853440 http://www.flickr.com/photos/danielfoster/4725849931
EDI
Vendeurs Fabricants
La situation (avant)
EDI
Vendeurs
IMPL
Fabricants
IMPL
Les problèmes de nos clients
• Ceux qui veulent utiliser la plateforme doivent connecter leurs systèmes et implémenter 1 API• Et puis nous configurons/customisons la plateforme
• Pour les vendeurs et fabricants de cette industrie c’est un “grand projet”
• Les vendeurs et fabricants ne tiennent pas leur planning• Donc notre planning de customisation ne sert à rien
• Une intégration dure longtemps, donc retour sur investissement tardif
Et si c’était notre problème?
• Si chaque flux est indépendant, chaque intégration est un petit projet
• Si on peut customiser rapidement un flux pour un client, on n’a plus besoin du planning du client
• Si on peut mettre les customisations rapidement en production, le client a un retour sur investissement rapide et incrémental
La situation (avant)
EDI
Vendeurs
IMPL
Fabricants
IMPL
La situation (après) - Technique
EDI
Vendeurs
IMPL
Fabricants
IMPL
IMPL
IMPL
IMPL
IMPL
IMPL
IMPL
IMPL
La situation (après)
• Chaque flux est un composant indépendant. Mais si le client en a implémenté plus qu’un ils coopèrent.• Par exemple: il y a un flux pour les données
catalogue et un flux pour les commandes qui sont indépendants. Si on a les deux, le composant “catalogue” peut faire des validations et augmentations pendant la commande
• On est passé d’une architecture “pipe et filter” vers “blackboard”
• On avait déjà un système continuous delivery
La situation (après) - clients
• Le client a l’option de faire une intégration incrémentale• Dans l’ordre qu’il veut
• Le client ne doit plus nous donner de planning, ils annoncent quand un flux est prêt• On customise, test et met en production
immédiatement• Le client reçoit de la valeur avec chaque flux
• => La plateforme devient plus facile à vendre
C’est quoi l’architecture?
“L’architecture c’est les décisions qui sont difficiles à changer et qu’il faut prendre au début du projet”
Pour des décisions difficiles à changer• Ou bien on rend la décision facile à changer• Ou bien on retarde le point de décision
Je suis prêt à payer pour des options qui ont de la valeur
• “Oui mais... Il y a des choses qu’on ne peut pas changer”
Hola Hop, Barbatruc
EDIVendeurs Fabricants
“Et si on changait de plateforme et langage? Sans arreter le système, bien sur!”
“Impossible!”
Gestion
Changer de plateforme et de langage
• D’abord des prototypes pour apprendre• Puis on aborde la partie avec le moins de risque
client• On garde et maintient l’ancien composant
pendant la transition• On peut toujours revenir un (petit) pas en
arrière• Déploiement continu et développement
incrémental réduisent la complexité et le risque
Oui mais... L’option coûte trop cher
Le projet (4)
• Projet avec deadline dur: loi change le 01/01/YYYY• Le système actuel n’est pas compatible
• On développe un nouveau système compatible• Qu’est-ce qui se passe si on livre en retard?
• On n’a pas voulu dépenser < 1000€ pour créer une option “backup”• “Combien ça coûte pour adapter le système
actuel?”• “Failure is not an option”• Le système est livré en retard• Chaque mois d’indisponibilité: X00,000€ par
mois
Faites attention aux fausses économies
Quelle est la valeur ajoutée pour le client de votre architecture et
votre processus?
Techniques utiles (1)
• Cost of Delay:• Quel est l’effet d’une livraison retardée ou
avancée?• Creative Process:
• Générer des options, puis sélectionner les options• Options:
• Cout, valeur, prix, date/condition d’expiration• Optimal Decision Process:
• Moment de décision = deadline – temps d’implémentation
Techniques utiles (2)
• Variation Separation:• Séparez les éléments qui varient à des vitesses
différentes• Set-based design:
• Faire la même chose de 3 façons peut être moins cher qu’une
• Sunk Cost Fallacy:• Oubliez combien vous avez déjà investi
• Créez des options pour vos clients
Décisions architecturales
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”
Donald Reinertsen
Questions
#AgileFrance