Le développement logiciel expliqué à votre patron en 24 slides
Real Options - Agile France 2013
1. Real Options: quand et comment
(ne pas) prendre des décisions
Pascal Van Cauwenberghe
11:40h – 12:40h Salle Belvédère
#AgileFrance
2. Donne des conseils
Gère des projets
Programme
Crée des Jeux
Organise des Conférences
@pascalvc
http://blog.nayima.be
http:/www.xpday.net
http:/www.atbru.be
7. 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
10. 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
20. Real Options Team to the
Rescue!
“Donnez nous un jour et on vous dira quand et comment décider”
Olav Chris Chris
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 un coût (= le prix de l’option)
Ont une valeur
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 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, 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 Coût Prix Valeur Expiration
Bleu ??? / Design
consistent
???
Jaune +
Bleu
??? Redesign
en bleu
Cost of
Delay == 0
???
25. Quand est-ce qu’il faut
décider?
Option jaune + bleu ???
Option bleu ???
DecNov
Stockage
Magasin
Oct
Production
DVD
Serveurs
????Mars
On est ici!
26. 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”
27. Quand est-ce qu’il faut
décider?
Option jaune + bleu ???
Option bleu ???
DecNov
Stockage
Magasin
Oct
Production
DVD
Serveurs
AoûtMars
On est ici!
Design et
test
(2M)
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?
Option jaune + bleu ???
Option bleu ???
DecNov
Stockage
Magasin
Oct
Production
DVD
Serveurs
AoûtMars
On est ici!
Design et
test
(2M)
32. Quand est-ce qu’il faut
décider?
Option jaune + bleu ???
Option bleu ???
DecNov
Stockage
Magasin
Oct
Production
DVD
Serveurs
SeptMars
On est ici!
Design
et test
(1M)
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 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
35. 3. Real Options
Optimal Decision Process
Option Implement
er
Option
Option
Décisions Deadline
http://commitment-thebook.com/
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:
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?
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
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. 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.
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
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!
A B
B
C
55. 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”
56. 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
57. 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 »
59. 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
65. 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
66. 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
68. La situation (après) -
Technique
EDI
Vendeurs
IMPL
Fabricants
IMPL
IMPL
IMPL
IMPL
IMPL
IMPL
IMPL
IMPL
69. 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
70. 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
71. 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”
72. Hola Hop, Barbatruc
EDIVendeurs Fabricants
“Et si on changait de plateforme et langage?
Sans arreter le système, bien sur!”
“Impossible!”
Gestion
73. 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
75. 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
77. Quelle est la valeur
ajoutée pour le client
de votre architecture et
votre processus?
78. 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
79. 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
81. 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
82. 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”
83. 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