1. Pascal peux-tu te présenter ?
Pascal Van Cauwenberghe, pendant la journée je donne des conseils, je gère des projets, je suis architecte, je programme. La nuit, je crée des jeux, et j'organise des congrès.
Les Real Options sont un outil pour prendre des décisions, où on va d'abord regarder la valeur plutôt que le coût, où on va essayer d'avoir plusieurs options et de retarder les décisions, ce qui va nous permettre d'avoir plus d'informations et prendre de meilleures décisions.
3. Tu parlais (lors de Lean Kanban France) de trois grands axes dans les Real Options.
D'abord, protéger la valeure, ensuite les options ouvertes, c'est à dire ne pas prendre de décisions aujourd'hui mais les prendre au bon moment, et dernière partie sur la création d'options. Les options ne se recueillent pas, elles se créent. Donc il faut investir à créer et surtout trouver des options.
4. Cela fait un moment qu'on entend parler des Real Options, depuis quand les as-tu croisées ?
La première fois que j'ai entendu le terme, c'était à la conférence XP en Europe et aux Etats-Unis en 2001. Je faisais du XP depuis 1999, et ça marchait mais on ne savait pas pourquoi. Donc là, les Real Options, ça expliquait une partie du puzzle. Mais en retrospective, ceci marche parce que cela, mais est-ce qu'on peut l'utiliser pour la suite, non pas encore.
5. Donc une grosse partie théorique pour expliquer, mais d'où vient cette pratique du coup ?
Quelques années plus tard, aux XP Days à Londres, j'ai vu une présentation de Chris Matts, et là la théorie devenait un peu plus pratique. J'avais déjà un algorithme pour décider quand il faut décider. Et ça déjà, c'était un outil qu'on pouvait appliquer.
Il a continué pendant des années à faire des présentations sur les Real Options. Certaines personnes ont dit "Ah oui, on a compris !", mais la plupart des gens ont dit "Ouais, cool mais ... ouais". Maintenant, Matt a sorti avec Olaf Masson et Chris Guery une bande dessinée sur les Real Options qui s'appelle Commitment. Et là, il a changé sa façon de présenter, il ne présente plus la théorie, il nous raconte une histoire. Comment on a appliqué la théorie, quels ont été les effets, et après vient la théorie. Et là ça touche les gens du côté émotionnel plutôt que du côté intellectuel. Et là ça parle beaucoup plus.
7. C'est ça qui t'as poussé à parler de Real options aussi ?
J'ai essayé de faire la même technique, de raconter ce qu'est la théorie et j'avais la même réaction. Et depuis peu, sachant que je sais appliquer les Real Options, au lieu d'expliquer, je raconte des histoires. Qu'est-ce qu'on a fait, quel était le problème, comment l'a-t-on résolu, quels étaient les résultats ? Et là ça parle beaucoup plus, les gens sont beaucoup plus enthousiastes.
8. Et donc ton histoire des real options que tu présentes ?
Je raconte plusiseurs histoires, une histoire est celle d'une équipe qui doit développer des sites web où il y a régulièrement des changements de design, et à chaque fois qu'il y a un petit changement, ça pertube tout le développement. Mais on a une deadline, et ça peut coûter très cher si on la rate. Et donc à l'aide de real options, d'abord, on peut calmer la situation, parce qu'il y a une panique totale avec le dernier redesign, il faut prendre une décision aujourd'hui. Et bien non. On a vu qu'on pouvait prendre la décision plusieurs mois plus tard. Entre temps, on pouvait avoir beaucoup plus d'informations, et on n'était pas perturbés par tous les changements. Et donc là, on a livré le projet à temps, et en plus c'était le projet où il y avait le moins de stress de tous les projets dans cette entreprise. Et donc là ils ont vu que c'était une bonne façon de faire, donc ils ont changé leur méthode pour développer des sites web.
C'est un outil, un outil pour réfléchir, c'est un élément. Et le deuxième élément, c'est un outil pour calmer la situation. J'ai pris beaucoup de mauvaises décisions, pourquoi ?, souvent dû au stress, une décision difficile, on est stressé, on veut prendre la décision maintenant, mais maintenant quand on est stressé, c'est le pire moment pour la prendre. Donc les real options ça nous donne un algorithme, un outil, et il y a des étapes, donc c'est bien structuré, on fait toutes les étapes, et en le faisant, tout le monde se calme un peu, et le stress part.
Il y a plein de ressources en ligne, sur les real options, mais la plupart est axée sur la partie financière, et donc on peut appliquer les real options dans la technologie et dans la vie de tous les jours, et là c'est beaucoup plus simple. Le plus simple est de regarder des ressources en ligne et de voir des présentations de gens qui ont appliqué les real options.
11. Dans quel domaine tu as vu ou pratiqué les real options ?
Dans le monde du travail, décision d'architecture, réduction de risques, project management, là ça marche très bien. Mais c'est un outil qu'on utilise tous les jours. Dans la vie de tous les jours, il faut prendre des décisions, parfois des décisions difficiles, et là aussi ça aide d'avoir plusieurs options si on sait exactement comment on va décider.
12. Un petit exemple, par rapport à la préparation de conférences par exemple ?
Une conférence, il y a beaucoup à faire, et il y a une deadline qui est "dure". Aujourd'hui 8h30, il y a 250 personnes qui sont ici (à Codeurs en Seine), donc il faut livrer à temps, et donc on a envie de prendre des décisions très tôt, comme ça c'est fait, on est tranquilles. Non, on peut décider quand est-ce qu'il faut décider, et repousser la décision jusque là. Un exemple de la conférence Lean Kanban, c'était un public mixte Français-Anglais, est-ce que je vais faire la présentation en Français ou en Anglais ? On m'a invité plusieurs mois avant la conférence, donc est-ce que je prends la décision là ? non ! J'investis dans des options : faire la présentation en Français et en Anglais. Cela m'a permis d'offrir la décision de faire la présentation en Français ou en Anglais 5 minutes avant le congrès.
Il y a deux problèmes psychologiques. Le premier c'est qu'on veut d'abord optimiser le coût. Non, il faut d'abord regarder la valeur. Et s'il y a cette valeur, le coût généralement n'est pas très grand. Deuxième chose, c'est qu'on a investi dans des options, et abandonner quelque chose où on a investi, c'est difficile. Mais de nouveau, l'algorithme real options facilite les choses parce qu'on sait qu'on va abandonner ces options, on a déjà pris la décision d'abandonner ces options. Le moment venu, la décision est beaucoup plus facile.
Est-ce que les développeurs prennent des décisions difficiles ? Oui, de temps en temps il faut prendre des décisions difficiles, où on a pas beaucoup d'informations, et une technique consiste à prédire le futur. On va prédire le futur pour les 5 ans qui viennent et on va coder tout ce qu'il faut pour les 5 ans qui viennent. Ca fait quelques années qu'on essaie ça, et ça ne marche pas très bien. Un des principes des méthodes agiles et lean est de pouvoir prendre des décisions plus tard, et d'être très agile. Mais pour être très agile, il nous faut du code et des systèmes très agiles. C'est très facile d'être très agile avec des Post-it, être agile avec du code c'est un métier.
Le principe était déjà dans le livre de Ken Beck (eXtreme Programming) en 1999, YAGNI : You ain't gonna need it. On ne met pas quelque chose dans l'application ou dans l'architecture pour "au cas où quelqu'un en aurait besoin". On ne met pas quelque chose pour le futur. En fait c'est assez facile, mais il manque un deuxième principe. Le premier est "On ne fait rien et on suit le principe de ne pas faire le travail de demain aujourd'hui", et le second "On ne fait rien aujourd'hui qui entrave le travail de demain". C'est la deuxième partie qu'on oublie souvent et qui nous mène à du code legacy.
16. Explique-nous ta vision sur le code legacy ?
Le code legacy dans sa définition dans le livre "Working Effectively with Legacy Code", c'est "du code sans tests". Ma définition c'est "du code qui ne contient plus d'options". C'est du code où si quelqu'un vient avec une question "je veux ça", la réponse est "c'est impossible !". Mais impossible n'est pas Français. Donc s'il n'y a pas d'options, tout est impossible. Si le code est agile, s'il y a beaucoup d'options dedans, on peut aller dans différentes directions, et là on est agile avec un petit "a".
Oui, mais en fait c'est "back to the future", on revient à la situation où on était en 1999-2000, on redécouvre les principes eXtreme Programming (XP).
Il y a une partie planning, à court-terme, tout le monde connaît les User Stories et Velocity, mais à l'intérieur il y a toutes les pratiques de développement. On travaille en binôme, pour améliorer la qualité, et disperser les connaissances, on fait du Test Driven Development, des tests unitaires, d'intégration. On travaille ensemble avec les clients pour d'abord définir les tests, comme ça c'est clair, c'est concret et on a une suite de tests. Il y a le refactoring continu, il n'y a pas "maintenant on arrête pendant 6 mois et on fait du refactoring". Non, on le fait tout le temps, tous les jours le code est un peu meilleur que le jour précédent. L'intégration continue, tests continus, commits réguliers, travail en petites étapes, on est toujours en contrôle du code.
D'abord, il y a une séparation des différents éléments, comme ça si un élément doit changer, le changement est très local, il y a l'utilisation des plugins, des interfaces. En fait, c'est le principe SOLID : Open-Closed principle, le système reste ouvert à l'extension, on peut ajouter des choses même si on ne sait pas encore quoi. Mais on sait que c'est possible.
C'est simple, on regarde l'atmosphère dans l'équipe, et on voit la venue du product owner ou du product manager avec de la peur. Une des métriques que j'utilise souvent, c'est le "fear factor", si je vous demande de modifier un module, est-ce que vous avez peur ou non ?
21. Cela peut aussi se mesurer au nombre d'idées que donne l'équipe de développement ?
Oui, dans de bonnes équipes, quand on montre la nouvelle version, la réaction des clients c'est "Wouhaou ! Je ne savais pas que ça c'était possible". Ceci ne vient pas du client ou du product manager, ça vient de l'équipe, qui voit des possibilites que les autres ne voient pas.
22. Donc ceux qui sont dans le moteur, dans la fabrication, peuvent contribuer au produit.
"Doivent" contribuer au produit.
23. Tu me parlais d'une revanche ou d'une révélation, peux-tu nous en dire un peu plus ?
Dans les années qui sont passées, on a un peu oublié les développeurs, les architectes, les designers. Tout était autour des Scrum Masters, Product Owners qui déplaçaient des post-it. On a découvert qu'il faut aussi de très très bons programmeurs, sinon on a une équipe agile, mais avec du code qui n'est plus agile. Donc on va re-valoriser le métier de développeur, parce que ce n'est pas tout le monde qui peut développer du code agile.
24. Donc c'est la revanche des Nerds comme tu disais ?
Soyons positifs, et disons "revalorisation". Mais revanche c'est plus facile à dire !