CT
P
RE
SENT
S
L’art de développer en agile
Sylvie PONTHUS-VIOLLAND
octo.com I blog.octo.com
THERE IS A BETTER WAY
AFIN
D’APPRENDRE
LE JAPONAIS
Derrière OCTO, il y a des centaines d’Octos, et autant de
talents cachés…
Sylvie
Ponthus- Violland
À travers cet ouvrage illustré, la collection OCTO Presents
tourne ses projecteurs sur la talentueuse Octo Sylvie PonthusViolland.
Développeuse, chef de projet, coach agile, Sylvie se passionne pour le
développement de logiciels utiles, fiables et agréables à utiliser.
Afin de transmettre encore mieux ses convictions comme ses apprentissages,
elle décide d'écrire un livre qui raconterait de l'intérieur un projet agile.
Les illustrations sont de Aryana Pezé. Aryana a publié avec OCTO “À la
découverte du DevOps !”.
octo.com I blog.octo.com
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Préface
De Christophe Thibaut
Technical Advisor et Coach Technique
En 2015, Dave Thomas, développeur, co-auteur du précieux guide "The Pragmatic Programmer",
co-signataire du Manifeste Agile déclarait : "L'Agile est mort".
3
Cette opinion, dans la communauté de celles et ceux qui depuis plus de 10 ans défendaient,
illustraient et implémentaient XP, Scrum, ou leurs variantes, ne déclencha pas ou peu de
controverse. Pourtant une idée qui meurt, c'est une idée dont on ne parle plus. Or aujourd'hui,
tout le monde "parle" l'Agile. Vous ne rencontrerez pas une seule personne impliquée dans le
développement d'applications qui ne connaisse pas le terme "user story" par exemple. L'agilité
semble s'être diffusée partout, et pourtant sa mise en œuvre semble fort rare. On dira que les
idées agiles ont subi la loi de l'étalement de la confiture : plus la tartine est grande, plus la couche
est fine. On dira que l'agilité, comme le bon sens, est la chose du monde la mieux partagée. Et
franchement, c'était inévitable : quelle entreprise revendiquerait, en 2001, en 2015 comme en
2022, de ne pas être agile ?
L'agilité, dans un grand nombre d'entreprises, n'est pas morte, au contraire : elle est tout juste
embryonnaire. La démarche décrite en substance par le Manifeste Agile est encore très peu
répandue. Certes tout le monde "parle" l'Agile, mais seulement parce que le vocabulaire des
méthodes agiles s'est répandu comme se répandent les idées, les mèmes, les modes. Une
communauté grandissante, riche et vivante, combinée aux forces de l'industrie du conseil, et
naviguant à la vitesse de la lumière sur un réseau de partage d'information universel et gratuit :
comment aurait-il pu en être autrement ?
Le livre de Sylvie est le récit d'une naissance : c'est l'histoire d'une personne, puis d'une équipe,
qui découvre et met en place une approche agile non pas en lisant des livres ou en recevant la
formation Scrum, mais en essayant par elle-même de nouvelles idées. Ce livre est l'histoire de cette
lutte : essayer de nouvelles idées, d'abord chez soi, dans l'apparent confort du "temps libre", puis
en équipe, à contre-courant des "forces de rappel" de la culture prégnante, puis dans l'entreprise
elle-même. Le Manifeste Agile, avec ses quatres préférences et ses douze principes, est un des
documents qui a le plus véhiculé les idées agiles dans les entreprises. On l'a cité, expliqué, traduit,
réduit maintes fois, et reformulé parfois. Il m'a toujours semblé que la phrase la plus importante de
ce manifeste est la toute première :
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres
à le faire.
L'histoire de Charlotte, l'héroïne que nous suivrons ici, c'est la saga d'une personne qui s'est mise
en tête de mieux développer des logiciels par la pratique et en aidant les autres à le faire. C'est
l'histoire des petits et des grands succès, des crises, des doutes et des régressions. C'est la distance
parcourue entre le statu quo et sa trompeuse "résistance au changement" et la joie simple de
l'amélioration continue. C'est une course d'endurance à travers les collines et les vallées. C'est
une réponse à la question dubitative, judicieusement incrédule, qui doit venir naturellement après
chaque présentation, chaque formation, chaque "sensibilisation" à l'Agile : Mais concrètement ?
4
S mmaire
O1 Le backlog est vivant, il bouge avec des feedbacks
Glossaire
Apprenez vos kana !
Pour découvrir le produit, il faut le construire
Le développeur en piste
Les utilisateurs seront ravis
Le backlog bouge
Le backlog bouge encore
La PO n’est pas certaine, elle pourrait aller plus vite
C’est un succès
O2 Le refactoring c’est tout le temps, et c’est normal
Glossaire
Le plaisir de coder
Il y en a partout
Appel à un ami
Montre-moi
Un nouvel espoir
Pas facile
Le développement est sinueux, pas linéaire
Le travail du développeur
6-41
7
8
10
16
21
24
27
32
38
42-76
44
45
47
55
60
63
67
70
73
Le backl g
est vivant,
il b uge avec
des feedbacks.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Glossaire
Backlog : c’est le carnet de produit, l’endroit où sont écrites les idées à réaliser.
Feedbacks : retours.
Hiragana : cet alphabet est principalement utilisé pour les mots japonais.
Kana : syllabe de l’alphabet japonais.
Katakana : cet alphabet est principalement utilisé pour transcrire les mots étrangers.
PO (Product Owner) : c’est le propriétaire du produit, ainsi que le représentant des utilisateurs.
YouTubeur Julien Fontanier : artiste vidéaste qui publie sur la plateforme YouTube.
7
Il est le créateur de la chaîne Cours de japonais ! 1.
1. https://youtu.be/Hs8oR3xDokA
Julien Fontanier a financé son projet sur la plateforme Ulule(ulule.com/japonais-saison3).
Retrouvez-le aussi sur Facebook, Twitter (@JulienFontanier) et Instagram (@coursdejaponais).
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Apprenez vos kana !
Charlotte a deux enfants, Théo 18 ans et Léa 14 ans. Tous les trois sont de grands admirateurs de la
culture japonaise : ses mangas et ses spécialités culinaires. Ils sont déjà allés au Japon tous ensemble
et veulent y retourner. C’est tout naturellement que Théo et Léa commencent l’apprentissage du
japonais. Leur apprentissage est autodidacte, c’est Léa qui s’en sort le mieux, elle est très assidue.
Son apprentissage a l’air facile, elle suit les vidéos du YouTubeur Julien Fontanier qui a beaucoup
de succès. Charlotte est curieuse, elle regarde donc une de ces vidéos. C’est effectivement très
bien expliqué. Charlotte décide à son tour d’étudier le japonais, et s’abonne à la chaîne YouTube.
8
Les cours sont agréables et Charlotte enchaîne les leçons. À partir de la dixième leçon, le YouTubeur
est très insistant sur l’auto-apprentissage en dehors des cours, il répète : « apprenez vos kana ! ». Il
explique que la maîtrise des kana est un prérequis indispensable et qu’il a plusieurs fois observé que
les élèves qui décrochent sont ceux qui ne les maîtrisent pas. Effectivement, Charlotte a de plus en
plus de mal à suivre les leçons et doit finalement suspendre le visionnage des vidéos YouTube pour
travailler ses kana.
Elle a regardé les applications du marché et les a trouvées trop denses, voire trop compliquées.
Elle veut juste des devinettes. Elle souhaite respecter l’intention du senseï (le professeur YouTubeur)
qui conseille sa méthode pour maîtriser les kana : « apprenez les cinq premiers kana, quand vous
les maîtrisez, passez aux cinq suivants et révisez les dix en même temps ».
Comme elle est informaticienne, elle a l’idée de réaliser une application pour apprendre facilement
les kana. Son application doit permettre exactement ceci.
Le besoin est simple : construire un quiz de kana, regroupés par leçons, faire deviner soit un kana
(l’écriture japonaise) soit un rōmaji (l’écriture latine).
ka
un kana
son rōmaji
Elle imagine tout de suite une utilisation mobile, pour pouvoir s’entraîner en toutes circonstances.
Elle se lance donc dans la réalisation de son application qu’elle nomme Apprendre les kana.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Par curiosité, elle demande à sa fille comment elle a fait pour dépasser ce stade, puisque Léa
maîtrise ses kana. La réponse de Léa l’amuse : « c’est simple, j’ai écrit sur une feuille blanche les kana
de la ligne 1 dans leurs versions rōmaji et kana. Puis j’ai tout découpé et je les ai mis dans une boîte.
Je mélange, et je devine. Quand j’ai fini la ligne 1, j’ajoute les kana de la ligne 2 et je recommence. »
Charlotte a souri, parfois il n’y a peut-être pas besoin de logiciel ! Elle se rassure en se disant que sa
solution logicielle est portable, et la boîte non.
Bon, du coup, c’est simple. Un quiz, des devinettes, des leçons qui s’accumulent. Elle sait bien qu’il ne
faut pas faire compliqué, des années d’expérience dans le développement de logiciels lui ont forgé
une conviction : un produit qui ravira ses utilisateurs est un produit simple et efficace.
Elle formalise l’intention de son produit, écrit les premières idées et les priorise. L’intention du
produit est la suivante :
9
IL ÉTAIT UNE FOIS un monde où les étudiants
veulent apprendre tout seuls le japonais
CHAQUE JOUR ils regardent des vidéos YouTube
MAIS UN JOUR ils sont largués, car ils n’ont pas une
maîtrise parfaite des kana
À CAUSE DE ÇA, les cours YouTube deviennent
difficiles
À CAUSE DE ÇA AUSSI, ils se découragent, certains
abandonnent même
JUSQU’À CE QUE FINALEMENT l’application
« Apprendre les kana » soit créée, un quiz qui leur
permet d’apprendre facilement les kana, de les
maîtriser et finalement de continuer les leçons de
japonais
Charlotte rédige ses idées à développer.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Pour découvrir le produit,
il faut le construire
Les idées fusent. Charlotte prend plaisir à formaliser ses idées, et les rédige comme des petites
histoires utilisateurs qui prendront vie quand le logiciel fonctionnera. Elle raconte comment ce sera
bien d’utiliser le logiciel. C’est un moment agréable et facile. Il permet de jouer aux devinettes
de kana et de rōmaji, il possède un mode aléatoire, il permet aux élèves de connaître leur
progression…
C’est salvateur de formaliser toutes ces histoires : elle avait ces idées en tête, mais les écrire lui
permet de se projeter sur la suite. Elle a l’impression de bien travailler, de prendre les choses dans
l’ordre et de travailler proprement. C’est vraiment un bon moment !
10
Le résultat est le suivant :
En tant qu’étudiant, je veux
voir un kana afin de deviner
son rōmaji
En tant qu’étudiant, je veux
que l’affichage des kana soit
aléatoire afin de savoir si je
les connais vraiment
Apprendre
le Japonais
En tant qu’étudiant, je veux
deviner les kana de la leçon 1
afin d’apprendre progressivement
et de choisir quoi apprendre
Deviner
En tant qu’étudiant, je veux
voir des rōmaji afin de deviner
les kana
En tant qu’étudiant, je veux
pouvoir choisir un des deux
alphabets afin d’apprendre
à ma guise
Clic sur la réponse (kana ou rōmaji)
pour afficher la solution et donc
pas sur le bouton solution
S’ameliorer
En tant qu’étudiant, je ne veux
me souvenir de mes scores
afin de savoir si je progresse
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
C’est angoissant. Elle sent bien qu’elle peut se tromper et elle commence à saisir la gravité de ses
décisions de priorisation. Elle réfléchit :
Suis-je bon stratège ? Est-ce que je prends les choses dans le bon ordre ? Si je suis cette liste
d’idées, serai-je fidèle à mon intention du début ? Ne suis-je pas en train de perdre mon temps
avec du travail superflu ?
11
Elle ne peut pas faire patienter ses enfants 3 mois ou 6 mois. Elle aurait l’air ridicule, pas
compétente. Ou alors pire, ils n’auraient plus envie. Elle voudrait leur demander souvent :
« ça vous plaît ? ». Elle s’entend bien avec ses ados, elle compte bien en profiter pour récupérer des
feedbacks et améliorer son produit à chaque fois !
C’est rigolo, elle sait qu’elle a rarement des rapports aussi francs et transparents avec ses utilisateurs.
Elle aimerait bien pourtant. Elle décide de leur poser souvent la question. Leur promettre quelque
chose et le leur montrer. Puis le refaire souvent.
Des petites promesses, faciles à tenir.
Elle retravaille ses idées en les regroupant. Elle les montrera en même temps, au même
moment. Ce premier moment (l’itération 1), c’est la promesse qu’elle fait à ses utilisateurs du
futur fonctionnement. Cette promesse est une phrase, mûrement réfléchie, qui rend logique le
regroupement de ces idées-là pour la première itération.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
« Maman elle fera quoi ton appli ?
— Tu vas pouvoir t'entraîner à reconnaître les kana.
— Ok. »
L’enthousiasme des ados n’est pas délirant non plus, les utilisateurs sont à convaincre finalement.
Le logiciel a intérêt à tenir ses promesses et même plus, il doit ravir ses utilisateurs, les exciter pour
qu’ils demandent la suite.
Charlotte a promis : « tu vas pouvoir t’entraîner à reconnaître les kana ». Elle cherche quelles
idées sont en lien avec ça. Elle se rend compte que sa promesse modifie un peu ses idées. Elle
réfléchit : la promesse est plus importante que les idées déjà écrites. Du coup elle découpe des
idées, change des priorités. Elle découvre un nouveau chemin d’idées pour tenir sa promesse :
pour progresser, il faut s’entraîner à deviner. Elle décide donc que l’entraînement se fera d’abord
sur la reconnaissance des kana en mode rōmaji, et ce dans les deux alphabets des kana (hiragana
et katakana).
12
Pour autant, elle ne s’arrête pas de réfléchir et elle a d’autres idées. Ces nouvelles idées ne sont pas
en lien avec sa première promesse, elles sont donc moins importantes. Elle les écrit, en y apportant
peu de détails, car il s’agit juste de ne pas les oublier, et y reviendra plus tard.
Sa nouvelle liste d’idées ressemble à ça : (schéma ci-contre).
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Sa nouvelle liste d’idées ressemble à ça :
Mes idées
Afin d’apprendre sûrement
les kana, en tant que Charlotte,
je veux m’entraîner à les
reconnaître en rōmaji
Afin d’apprendre les deux
alphabets, en tant que Charlotte,
je veux pouvoir en sélectionner
un ou les deux
Afin d’ancrer mes apprentissages,
en tant que Charlotte, je veux voir
mes leçons en cours
Afin de savoir si je suis assidue,
en tant que Charlotte, je veux
savoir quand je me suis entrainée
Deviner
S’améliorer
13
Apprendre
le Japonais
Deviner - plus tard
S’améliorer - plus tard
Parler - plus tard
Partager - plus tard
Afin de savoir dessiner des kana,
en tant que Charlotte, je veux voir
des rōmaji
Afin de rendre plus facile
l’utilisation de l’application, en
tant que Charlotte, je veux faire
moins de clics
Examens
Voir un extrait dans un manga ou
un livre.
Afin de savoir mon niveau,
en tant que Charlotte, je veux
connaître mon score
Afin de savoir si je progresse,
en tant que Charlotte, je veux
me souvenir de mes scores
Afin de savoir si je maîtrise des
kana,en tant que Charlotte,
je veux connaître ma progression
dans mon apprentissage
Afin de progresser doucement,
en tant que Charlotte, je veux
choisirmes leçons
Entendre un kana
Créer des amis
Activité de mes amis
Score de mes amis
Défis
Plus tard
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Elle est un peu rassurée. Les idées présentées sous cet ordre sont moins risquées. Cette constructionlà du backlog plaira mieux, elle en est sûre. Elle voit l’itération 1 comme un premier pas qui, elle
l’espère, la rassurera encore. Enfin, elle verra ce que les enfants en diront.
Bon finalement c’est fatigant d’écrire ces idées, elle avait l’impression de savoir quoi faire et
pourtant elle se rend compte qu’elle découvre son produit. C’est un comble, c’est elle qui le construit !
Elle n’est pas encore convaincue, et elle est inquiète maintenant, car elle a l’impression de tâtonner.
Ou alors c’est une démonstration ; elle doit chercher, prouver.
La promesse 1 + la promesse 2 + la promesse 3 = l’intention de son produit.
Construire le backlog, c’est comme essayer de faire une bonne démonstration.
Vu comme ça, c’est sympa ces promesses. Très facile en fait.
14
Elle imagine un dialogue avec sa fille pour tester si l’argumentaire est convaincant. Comme je
vous l’ai annoncé plus tôt, très chère utilisatrice, nous travaillerons d’abord sur l’entraînement
à reconnaître les kana. Puis vous pourrez apprendre ce que vous voudrez. Puis vous connaîtrez
votre score.
Elle vérifie et vérifie encore. La promesse 1 plus la promesse 2 plus la promesse 3, ça marche. C’est
cohérent avec l’intention du produit. Très très très facile. Chouette.
Vous allez vous entraîner à reconnaître des kana. Cette promesse regroupe finalement deux
idées seulement, c’est suffisant.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Apprendre
le Japonais
Deviner
Afin d’apprendre sûrement
des kana, en tant que
Charlotte, je veux m’entraîner
à les reconnaître en rōmaji
Vous allez vous entraîner
à reconnaître des kana
S’améliorer
15
Afin d’apprendre les kana
avant de les deviner,
en tant que Charlotte, je veux
voir l’alphabet entier
Quelle fierté d’avoir économisé du temps. Ce sera du travail de développer tout ça, et c’est un
soulagement de découvrir que la promesse sera atteinte avec deux idées seulement au lieu de
trois. Du temps économisé pour faire autre chose.
Non, pas juste du temps économisé. Charlotte se rend compte que si elle développait une idée « en
trop », les utilisateurs auraient une fonction en trop. Ce serait dommage de réaliser une application
dense, il y en a assez comme ça, elle n’aime pas ça.
C’est comme dans la langue française. Bien, c’est bien. Beaucoup, c’est un peu trop. Trop, c’est un
aveu d’échec.
Finalement, bien réaliser c’est réaliser moins et mieux.
Elle pensait savoir ce qu’elle voulait depuis
le début. Elle se rend bien compte qu’elle
passe du temps à écrire ses idées … et à les
modifier, et à les déplacer.
C’est déconcertant mais elle l’avoue, elle
comprend de mieux en mieux son produit.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Le développeur en piste
C’est le moment tant attendu de la réalisation du produit.
Aujourd’hui, Charlotte est la super développeuse de ce super produit. Elle est motivée, prête à
travailler dans les règles de l’art du développement logiciel. Je vais me focaliser sur le besoin et
trouver les meilleures solutions pour y répondre, se dit-elle. Elle se sent capable de soulever des
montagnes. En plus dans son cas c’est facile, elle connaît bien la PO…
16
C’est un peu fou cette situation, elle se rend compte qu’elle est soit PO, soit développeur. Si elle
discute avec ses utilisateurs, elle est PO. Si elle développe le logiciel, elle est développeur. Pour
ajouter à la schizophrénie, elle se rend compte qu’il lui manque un interlocuteur qui lui parlerait de
comment faire. Elle réfléchit : doit-elle jouer un personnage de plus ?
Elle veut développer à partir de l’idée « afin d'apprendre sûrement des kana, en tant que Charlotte,
je veux m’entraîner à les reconnaître en rōmaji ».
C’est un peu court.
À bien y réfléchir, c’est très flou. En tant que développeuse, elle a envie de poser plein de questions.
Il y a des mots qui la gênent dans l’expression du besoin
tel qu’il est affiché. Apprendre sûrement, ce mot sûrement
n’est sûrement pas là par hasard et rien ne l'explique. La
PO parle de kana et ne dit pas quoi apprendre… Tout ? Rien
n’est précis. Elle comprend le besoin mais rien n’explique
comment faire. La PO doit bien avoir sa petite idée ?
La spécification manquante porte sur un « petit » besoin,
autant poser les questions directement. Bref, il va falloir
avoir une discussion entre la PO et la développeuse.
DEV — Pourquoi “sûrement” ?
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
PO — Parce que quand Charlotte fait ses entraînements d'écriture de kana, elle les dessine en faisant
des lignes, elle sait les dessiner mais elle se rend compte qu’elle n'a pas retenu le son associé.
DEV — Donc faire des lignes ne suffit pas à apprendre ?
PO — Oui. Non seulement il y a beaucoup à apprendre, mais surtout, à chaque kana, il faut retenir
deux choses : l’écriture et le son. Ça fait beaucoup : Charlotte a besoin d'une méthode progressive, pas
tout d'un coup sinon ça lui fait trop.
DEV — Ok, donc apprendre petit à petit.
PO — Oui, apprendre avec des leçons.
DEV — Le nombre de leçons est connu ?
PO — Oui, et toutes les leçons sont affichées.
17
La PO se note pour plus tard une idée à écrire : « Apprentissage : Charlotte choisira exactement
quels kana à apprendre, elle construira sa leçon ».
DEV
— C'est quoi ces leçons ?
PO — Des leçons de syllabes. L’alphabet japonais est syllabique. C’est une matrice de voyelles et de
consonnes. 5 voyelles (a, i, u, e, o,) et 11 consonnes (-, k, s, t, n, h, m, y, r, w, -n) produisent ces
syllabes.
DEV — Deux fois la consonne “n” ?
PO — Oui, la deuxième fois “-n” est une syllabe particulière, elle ne se décline pas avec les voyelles.
DEV — Ok donc ça fait 11 consonnes * 2 alphabets = 22 leçons avec 5 choix chacun.
PO — Presque, certaines consonnes n'ont pas toutes les voyelles, et il y a des leçons supplémentaires
pour des sons différents de consonnes.
DEV — Ok, vous nous fournirez le détail.
PO — Oui. Une exception, les leçons “wa wo” et “-n” sont à regrouper en une seule leçon.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
DEV — Ok.
PO — Attention, l’ordre de la leçon est important, c’est l’association consonne - voyelle qui donne
l’ordre alphabétique.
DEV — Alors leçon 1 puis la leçon 2 ça fait … a i u e o ka ki ku ke ko.
PO — Vous avez tout compris !
DEV — Qui décide de la leçon à lancer ?
PO — L’utilisateur. Quand il clique sur une leçon, cela affiche aléatoirement un kana à deviner.
DEV — Un kana à deviner qui fait partie de la leçon lancée.
PO — Oui. Il a choisi une leçon déjà définie.
18
DEV — L’utilisateur voit un kana et il clique sur le rōmaji associé, il sait alors s’il a juste ou faux.
PO — C’est ça.
DEV — Il devine le rōmaji, pas le kana, nous sommes d'accord ?
PO — Ici oui, il y aura une idée pour deviner le kana.
Note pour plus tard : créer l’idée « deviner le kana », et aussi une idée « donner la possibilité de
choisir ce que l’on devine, le kana ou le rōmaji ».
DEV — Une séquence d'entraînement (quiz) dure combien de temps ? Ou plutôt un entraînement est
joué combien de fois ?
PO — 10 fois. Pour la suite, on mettra une limite de temps.
Note pour plus tard : créer une idée « durée du quiz » (1 minute par défaut, modifiable par
l’utilisateur).
PO — Au bout de 10 jeux, la leçon est finie et il voit son résultat.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
DEV — Le résultat c’est le nombre de réponses bonnes / nombre total de questions ?
PO — Exactement. Puis, l’utilisateur peut relancer la leçon autant de fois qu’il veut.
DEV — Le calcul est propre à chaque leçon ? Pas d’historique ?
PO — Pas pour l’instant.
Note pour plus tard, créer une idée « historique des résultats ».
C’était parfait. L’échange a été fructueux et a permis de détailler tout ça. Charlotte sourit, elle a
maintenant de quoi développer correctement : une spécification.
19
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Elle regarde ses notes.
Spécification :
• lister toutes les leçons par ordre alphabétique pour chaque alphabet
sélectionner une leçon
• afficher un kana aléatoire parmi ceux de la leçon sélectionnée
• clic sur la réponse, le résultat s’affiche : juste ou faux
• au bout de 10 jeux, le jeu affiche “fini” avec le score obtenu
Le processus est très clair maintenant dans sa tête.
1. Charlotte-PO parle avec ses utilisateurs pour
comprendre leurs besoins.
2. Charlotte-PO formalise ses idées pour y répondre.
20
3. Charlotte-dev discute avec Charlotte-PO
pour faire émerger les détails importants.
4. Charlotte-dev formalise les spécifications à
suivre pour développer.
5. Charlotte-dev développe.
6. Charlotte-PO montre le logiciel à ses utilisateurs et discute pour avoir des feedbacks.
Et elle recommence.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Les utilisateurs seront
ravis
La semaine a été longue. Voici à quoi ressemble l'application à la fin de l’itération 1 :
Fin de l'itération 1
21
C’est avec beaucoup d’empressement qu’elle montre son produit à ses utilisateurs. Théo et Léa
sont silencieux, ils jouent avec l’application fraîchement déployée sur leur téléphone. Tests en
conditions réelles.
Elle profite de ce moment pour se répéter : ne pas trop se vanter, ce ne serait pas un bon exemple.
Oui, le produit est conforme à la première promesse. Oui, le produit répond aux attentes. Oui,
le produit est génial. Elle attend encore les applaudissements quand les premières remarques
tombent. Heureusement, elle est assise.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
« On est bloqué ? »
« C’est un memory, maman ! Un choix sur cinq, c’est appris en quelques secondes et pas vraiment
appris en fait. Si tu me montres ce kana au milieu de beaucoup d’autres je ne pense pas le
reconnaître. »
« C’est un jeu de déduction, on n’apprend rien. »
Charlotte, une fois le choc passé, tente le déni :
« N'était ce pas ce que nous avions convenu ?
Reconnaître des kana ?
— Oui ok mais pas jouable en fait. »
Colère :
« Hein ? »
22
Négociation :
« En fait, ce que j’ai développé, c’est plutôt vous
apprendrez vos leçons.
— Ben oui. »
Tristesse :
« C’est pourtant ce dont nous avions convenu.
— Oui oui, mais maman tu vois bien toi aussi en jouant que c’est un memory. »
Acceptation :
« Et il manque quoi pour passer de “vous apprendrez vos leçons” à “vous connaîtrez vos kana ?” ».
Grosse grosse réflexion.
« Jouer avec plus de kana.
— Jouer avec plus de kana ou plutôt - dans une même leçon - avoir plus de rōmaji proposés que
ceux de la leçon ?
— Je ne sais pas maman, je suis occupée. »
Pas de standing ovation finalement.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Charlotte conclut ainsi : le produit fonctionne. Les utilisateurs ont joué avec un bon moment. Le
produit n’ira pas tout de suite en production. Les utilisateurs ont des remarques. Ils veulent voir la
suite.
Ça va modifier les priorités, sûrement.
23
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Le backlog bouge
Début de l’itération 2. Charlotte boude dans son fauteuil. Elle
joue avec l’application. C’est dur tout de même d'encaisser
toutes ces remarques. Mais en même temps, ils ont raison.
Elle voit bien qu’elle apprend une leçon rapidement, et qu’en
rejouant une heure après la leçon n’est pas vraiment acquise.
Elle joue longtemps, comme pour retarder le moment où elle
casse tout pour continuer. Oui, car prendre en compte les
remarques va impliquer des modifications sur ce qui a déjà été
fait.
24
Il va falloir refaire quelque chose qui fonctionne déjà. Refaire.
Je déteste refaire, se dit Charlotte. C’est pour la bonne cause,
se rassure-t-elle. Refaire pour faire mieux. Tout en jouant, elle
compte les feedbacks.
Et il y en a beaucoup, des feedbacks.
Vus lors de la discussion entre le PO et les utilisateurs :
• Créer une idée « jouer avec plus de kana ».
Vus lors de la conversation entre le développeur et le PO :
• Créer une idée « apprentissage ».
• Créer une idée « deviner le kana ».
• Créer une idée « choisir de deviner le kana ou le rōmaji ».
• Créer une idée « historique des résultats ».
Autre chose : elle a bien noté que l’ergonomie n’était pas festive. Comme les remarques étaient
douloureuses, ils n’en n’ont pas rajouté avec l’interface, ils ont été gentils. Elle a bien senti que ce
n'était pas satisfaisant.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Vu par le PO :
• Créer une idée « améliorer l’ergonomie mobile ».
Voilà voilà voilà.
Le plus rigolo c’est que Charlotte avait déjà prévu des choses à faire pour la prochaine itération.
Elle avait prévu de continuer l’apprentissage en dessinant les kana, en écoutant les sons des kana…
et elle va devoir s’arrêter sur l’apprentissage.
Ok donc le backlog c’est une chose vivante, ça bouge.
Elle a bien compris la gravité de la situation : une application d’apprentissage doit permettre de
faire des apprentissages. Elle privilégie le retour « jouer avec plus de kana ». Elle cherche à le
reformuler correctement. Quelle nouvelle promesse doit-elle écrire pour ça ? C’est clair.
L’itération 2 sera : « Vous allez apprendre progressivement. »
25
Logiquement, les promesses suivantes seront :
L’itération 3 : « Vous apprendrez ce que vous voulez. »
L’itération 4 : « Vous allez connaître votre progression. »
Maintenant elle identifie les impacts dans le backlog. Une seule idée survivra, les autres attendront.
Trois nouvelles idées sont créées.
Elle s’attarde un peu sur le choix des mots, elle comprend combien il était important de bien
exprimer l’intention. Elle se réfère à l’intention initiale pour vérifier. Pour ne pas se tromper.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
« Vous allez apprendre progressivement », c’est un plan en 4 étapes :
• Afin de savoir reconnaître des kana, en tant que Charlotte, je veux voir des rōmaji.
• Afin de me concentrer sur ma leçon, en tant que Charlotte, je veux voir uniquement la leçon.
• Afin de progresser doucement, en tant que Charlotte, je veux suivre un plan d’apprentissage.
• Afin de maîtriser les kana, en tant que Charlotte, je veux deviner un kana parmi tous les kana que
j’ai déjà appris.
Elle discute avec son développeur préféré, la conversation est toujours riche et lui permet de
peaufiner ces idées. À la fin de l'après-midi, les conversations ont fait émerger les spécifications
nécessaires pour développer.
Maintenant elle s'apprête à « casser » le code avec plaisir. Elle sait où elle va, et le résultat sera
meilleur que le précédent.
26
Une nouvelle question arrive, comme ça : aurait-elle pu imaginer ces idées au début ? Elle y cogite
à peine, finalement elle avait mal réfléchi à son produit au départ. C’est bizarre, elle ne voit pas où
était son erreur de raisonnement.
Elle laisse cette réflexion culpabilisante pour plus tard.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Le backlog bouge encore
Ça s’arrête quand de bouger ? Charlotte ne sait plus si c’est une bonne ou une mauvaise nouvelle
tous ces changements.
L’application à la fin de l’itération 2 :
Fin de l'itération 2
27
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
L’application à la fin de l’itération 3 :
Fin de l'itération 3
28
Maintenant c’est la fin de l’itération 3. Théo et Léa ont l’air de plus en plus contents. Pourtant,
Charlotte est dépitée…
L’application grossit en se modifiant à chaque fois. Et en s'améliorant à chaque fois.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Maintenant il y a un vrai parcours d’apprentissage. Chaque leçon validée permet d’apprendre de
plus en plus, sûrement.
Le dernier ajout en date : la fonction « Continuer la leçon » tout en haut de la page d’accueil. Les
utilisateurs ont pris l’habitude d’utiliser ce bouton pour continuer à apprendre. L’application sait où
ils en sont. L’application sait ce qu’ils ont à faire. L’application les aide à progresser.
Et puis, l’avenir est radieux.
Les autres fonctions à venir ont l’air géniales. Charlotte-PO parle avec ses utilisateurs de nouvelles
idées très pertinentes.
Par exemple, elle ne savait pas avant qu’elle voudrait écrire cette idée : « deviner un rōmaji sans
choix proposés ». En effet, vu avec ses utilisateurs, c’est toujours un peu un jeu de déduction. Ils
ont donc décidé que l’étape d’après, ce sera de demander à l’utilisateur d’écrire le rōmaji avec le
clavier. Il devinera sans aucune proposition de rōmaji. La devinette ne sera plus un jeu de déduction.
29
Là ce sera parfait. Fini la déduction, le memory, le peu de réflexion. Le kana est affiché, la zone de
saisie invitera l’utilisateur à deviner vraiment le rōmaji.
Comme si elle n’avait pas vraiment réfléchi à son produit au début. Pourquoi a-t-il vraiment fallu
ces trois itérations pour avoir ce produit là ?
C’est ça qui la dépite. Tout le monde est content, et pourtant tout a été cassé, reconstruit. La moitié
disons, sans dramatiser. La moitié de ses idées initiales ont été modifiées ou supprimées. Et les
utilisateurs sont plus contents que lors de la première itération.
Finalement, les feedbacks sanglants de l’itération 1 n’étaient pas un accident. Ils ont permis de
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
pivoter, de choisir un meilleur chemin pour l’application. De pivoter tôt.
Probablement parce que les feedbacks sont vrais.
Théo et Léa ont exprimé leurs feedbacks en ayant l’application en main. Les feedbacks ne peuvent
pas arriver autrement que par la vraie utilisation du système. L’application se construit avec
l'expérience des utilisateurs, et cette expérience est réelle. C’est la vraie vie. Les points remontés
sont concrets, les ajustements qui ont lieu sont bénéfiques. Douloureux et bénéfiques. Il a fallu
modifier des parties déjà fonctionnelles, et elle se rend à l’évidence, le résultat est meilleur.
Les adaptations successives de l’application contribuent à son adoption progressive. Une réussite.
Elle rumine encore : si elle avait persisté dans son backlog initial, aujourd’hui elle n’aurait pas du
tout ce résultat-là. Si ça se trouve, les utilisateurs n’y joueraient pas. Les enfants seraient déçus.
Alors que là, elle a toute leur admiration.
Du coup elle repense à ses projets précédents, sans tous ces feedbacks. Comment faisait-elle ? Un
planning. Un planning avec la liste de tout ce qu’il y a à faire.
30
Rapide jeu des sept différences entre ces deux situations.
Elle en trouve deux :
• Ici, le produit marche à chaque fois qu’elle le montre.
• Ici, les feedbacks permettent d’augmenter la satisfaction utilisateur.
Elle réfléchit, il y a une autre différence, plus importante : elle a le droit de refaire. Elle est autorisée
à se tromper. Les feedbacks ici ne sont pas une erreur, elle les voit comme une chance d’améliorer
le produit. Pourquoi ici, maintenant, et pourquoi pas dans sa vie professionnelle ?
Qu’est-ce que le contexte familial a modifié dans ce cas précis ? Peut-être parce que le projet lui
tient davantage à cœur, peut-être parce que devant ses enfants il faut absolument réussir. Peutêtre aussi parce qu’elle ne peut pas se permettre de perdre son temps : c’est du temps personnel tout
ça et elle pourrait tout aussi bien le passer avec eux plutôt qu’à développer un logiciel informatique
pour après passer du temps avec eux !
Donc c’est normal que le backlog bouge, et il bougera toujours.
Elle conclut ainsi :
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Le planning, c’est de l’imagination : « ça devrait se passer comme ça ».
Les itérations, c’est la vraie vie : « ça vous plait ? »
Solution 1 : la voyance existe.
Solution 2 : la voyance, bof.
Le produit est construit avec de vraies informations, pas des suppositions. Sans cesse remis en
question, sans cesse amélioré. Le backlog bouge et bougera encore. C’en est déconcertant. Ça a
l’air évident, et pourtant pour elle, c’est une découverte.
31
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
La PO n’est pas certaine,
elle pourrait aller plus vite
C’est embêtant le doute.
Une petite voix dans sa tête qui ne s’arrête pas.
Une idée comme ça, que si ça se trouve tout est faux.
Charlotte soupçonne qu’elle pourrait aller plus vite.
32
Ce serait dommage de perdre du temps, elle a beaucoup d’idées en tête, elle pourrait prendre
un moment et tout écrire. Elle voit bien que ça prend du temps de faire juste une itération, puis de
recevoir des feedbacks, puis d’en faire une deuxième, puis de recevoir des feedbacks, puis de faire
une troisième, puis de recevoir des feedbacks, etc. Elle ne sait même pas combien il y en aura, des
itérations. Probablement beaucoup. C’est peut-être un luxe cette agilité, c’est long.
Elle se dit qu’elle sait ce qu’elle veut après tout, elle n’a pas de choses fondamentales à apprendre.
Elle se dit aussi qu’elle irait plus vite si elle écrivait la solution complète maintenant. Les feedbacks
permettent un apprentissage certain, mais ils ont un certain coût.
Allez, c’est parti, elle met de côté ces itérations et
elle réfléchit à tout ce qu’il y a à faire. Elle prend
une jolie feuille blanche et elle décrit l’application
finale.
C’est un bon moment, car elle se projette vraiment,
la réflexion va plus loin.
Elle réfléchit enfin à la fonction de partages entre
amis, elle y avait pensé dès le début et sous prétexte
que ce n’était pas le plus important, elle n’avait pas
pu l’approfondir. Elle imagine des défis entre amis,
c’est stimulant. Elle prend plaisir à y travailler,
car le fait d’avoir laissé de côté cette idée la
frustrait un peu.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
C’est enthousiasmant, le fait de tout écrire. Elle voudrait tout maintenant. Bien sûr, un vieux
bonhomme barbu en costume rouge ne va pas lui offrir son application demain avec tout ça,
mais elle y croit un peu. C’est comme si elle avait 6 ans : toute son énergie est mobilisée dans la
description de son cadeau de Noël.
Elle décrit toutes les fonctions qui devront être réalisées.
En tant que développeur, elle est ravie. En effet, elle voit tout ce qu’il y a à faire. La conception
logicielle sera meilleure, car elle voit l’ensemble. Quand elle travaillait avec des itérations, elle
recevait les informations par petits bouts. Elle manquait d’informations pour bien faire les choses,
elle avait du mal à savoir si sa conception était bonne ou pas. De plus, la conception pouvait être
remise en cause à chaque itération, c’était fatigant.
Elle a rédigé un joli document : architecture, spécifications et conception. Joli et complet. Il lui tarde
de développer tout ça, c’est très clair. Elle réfléchit : il est gros ce document, je vais passer du
temps à développer tout ça. Si ça se trouve cela prendra deux mois de travail, et si à la fin ça ne
leur plait pas ce sera la catastrophe. C’est tout ou rien, trop risqué, je devrais le leur montrer.
33
Elle va fièrement voir Théo et Léa :
« Regardez, j’ai écrit un document qui regroupe toutes les informations de tout ce qu’il y a à faire
sur l’application ! J’ai besoin de votre lecture et surtout de votre accord pour développer tout ça. »
Théo note tout de suite le nombre de pages du document : « 62 pages, c’est une blague ? Tu veux
qu’on lise tout ça ? »
Léa s’arrête à la page 6 : « Maman je n’y comprend rien, ça veut dire quoi exigences, mapping de
sources, composants graphiques, et pourquoi toutes ces flèches sur les schémas ? »
Charlotte pèse ses mots pour répondre, elle sent qu’elle n’a pas plusieurs chances pour expliquer :
« et bien les exigences sont le résumé du travail à faire, elles sont unitaires, testables, elles décrivent
les règles de gestion à développer. Les schémas quant à eux mettent en évidence les flux et les
couches à mettre en place avant d’attaquer le cœur fonctionnel… ».
Le fichier était refermé. Ce n’était plus la peine.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Théo est fâché : « ah non maman stop. Ça c’est ton travail, je n’y comprends rien et je n’ai pas envie
de comprendre ça ne m’intéresse pas. Est ce que je te fais relire mes cours de mathématiques
moi ? »
Charlotte est interloquée : « et comment je fais, moi, pour être sûre que ça ira ? »
Léa : « Comme tu veux. »
34
Quelle violence. Les bras lui en tombent. C’est comme au travail finalement. Personne ne veut
valider ses documents. Ce n’est pas juste, elle en a besoin pour travailler.
Elle dessine.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
35
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Les idées s’ajoutent, se modifient, elle redessine plusieurs fois cette feuille. Elle itère avec ellemême, finalement. Il y a beaucoup d’idées maintenant, il est difficile de toutes les positionner.
Elle se demande ce qui se passerait si elle faisait jouer Théo et Léa avec ce logiciel-là. Celui qui est
dessiné avec toutes les fonctions. Elle aimerait bien savoir ce qu’ils en diraient.
Ils ne veulent pas valider ses documents, ils accepteraient peut-être de les tester.
Elle compare les deux logiciels (le logiciel actuel et le logiciel du dessin), et elle constate qu’il y a un
gros écart. Un très gros écart, même.
Elle imagine Théo et Léa cliquer là et là. Ils ont déjà fait tellement de remarques, elle aimerait bien
les faire cliquer sur son dessin.
Au fur et à mesure qu’elle noircit la feuille, elle est partagée. Elle voudrait être contente et elle n’y
arrive pas. C’est un leurre, le dessin devrait la rassurer sur tout ce qu’il y a à faire, et en fait ça
l’inquiète de savoir si ça va leur plaire.
36
Du coup elle dessine un dessin intermédiaire. Elle imagine qu’ils cliquent sur ce dessin intermédiaire.
Ça devrait leur plaire.
Elle fait des suppositions. Elle continue son dessin en supposant que ça leur plaît.
Et si ça ne leur plaît pas… il faudrait qu’elle comprenne pourquoi.
Elle se rend compte qu’en réalisant ce gros dessin complet, elle s’interdit de demander à Théo et
Léa ce qu’ils en pensent. C’est comme si elle n’avait pas l’autorisation de leur parler.
Cela lui rappelle qu’il se passe la même chose au travail, Charlotte parle rarement à ses utilisateurs.
Même si elle insistait, elle n’aurait pas le temps, car les projets sont souvent tendus, en retard, avec
beaucoup de discussions vers la fin, c’est épuisant. Et en plus ce n’est pas si grave car souvent,
la version 2 rattrape le tir. Ou la version 3. Parfois la mise en production tarde longtemps. Les
feedbacks des utilisateurs arrivent entre chaque version.
C’est à se demander comment les projets peuvent réussir dès leur première version.
Bon, ici, elle a le droit de demander aux utilisateurs ce qu’ils en pensent. Ce qu’ils pensent du dessin
complet, ce qu’ils pensent du dessin intermédiaire. Ce qu’ils pensent du logiciel. Ce qu’ils pensent
du logiciel de l’itération 1, ce qu’ils pensent du logiciel de l’itération 2.
Ce sera moins risqué si elle les fait tester souvent, si elle leur demande souvent ce qu’ils en pensent.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
À contrecœur, elle admet qu’elle a besoin d’eux. Oui c’est elle qui a eu l’idée du produit, mais sans
eux elle n’y arrivera pas. S'ils ne l’utilisent pas, ce sera un fiasco. Ce n’est pas un produit pour elle
toute seule.
Charlotte se remet à coder l'itération suivante.
Elle peut jeter son dessin tout noirci. Théo et Léa sont plus importants que ses idées initiales.
37
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
C’est un succès
La foule est en liesse. Et c’est peu dire.
Théo et Léa utilisent l’application autant que
leurs autres applications. Les GAFA n’ont qu’à
bien se tenir.
Et pourtant, il y en a encore eu de belles.
Le plus gros changement est arrivé tard, c’était
énervant de devoir le reconnaître. Les lots de
feedbacks amènent leurs lots de changements,
Charlotte en avait accepté l’idée. Et pourtant
c’était encore surprenant.
38
Théo avait dit dès l’itération 2 : « La règle des 100%, tu peux l’enlever ? »
Léa était plus exigeante : « Maman, je veux faire ce que je veux, pas suivre ton plan machin-là. Je
veux apprendre cette leçon-là ou celle-là, et je dois tout faire avant ? C’est sérieux ? »
Charlotte avait mis ça sur le compte de la jeunesse, et aussi sur l'inébranlable certitude que ses
enfants sont les plus beaux, les meilleurs, qu’ils apprenaient déjà bien sans l’application. Donc pas
assez représentatifs. Cela justifiait amplement que Charlotte prenne quelques libertés. Comme de
refuser de prendre en compte ces feedbacks.
Elle a résisté pendant une itération.
Après, il a fallu céder.
À la fin de l’itération 3, Théo n’est pas venu. Elle l’a appelé une fois, deux fois, il a dit de voir avec
sa sœur. Pourtant l’application de l’itération 3 était mieux que celle de l’itération 2. Il y avait un
minuteur, et les statistiques de succès.
C’est dur pour Charlotte. Elle se rassemble et réfléchit. Elle se souvient maintenant.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
L’intention du départ était de progresser. Le senseï avait expliqué ça. Charlotte-PO avait interprété
ce besoin avec :
• un plan de leçons qui se débloquent au fur et à mesure d’un apprentissage complet (les fameux
100%),
• une fonction « tous les hiragana appris » et « tous les katakana appris » qui permet de jouer avec
beaucoup de kana, cumulés selon l’apprentissage acquis.
C’était une belle démonstration de l’intention initiale. Et pourtant, il y avait un raté. Un gros.
L’application était trop guidée.
Les utilisateurs ne voulaient pas de cette progression-là. Ils voulaient eux-mêmes décider de leur
progression. Les utilisateurs voulaient de la liberté. Les applications ne sont pas assez ouvertes, se
dit Charlotte, elles sont trop fermées.
39
Charlotte est habituée à « guider » les utilisateurs en les contraignant à suivre le chemin qu’elle
a imaginé pour eux. C’était sa façon de réaliser des logiciels. Les utilisateurs doivent suivre un
processus que Charlotte a conçu.
Charlotte reconnaît en y réfléchissant qu’elle avait peur. Peur que ses utilisateurs n’y arrivent pas.
Elle avait oublié que l’utilisateur sait se débrouiller. Il cherche. Si l’utilisateur choisit une leçon difficile,
la prochaine fois il ajustera. En fonction de son niveau, de son expérience à lui.
Charlotte constate qu’il y a une multitude de chemins, en fait.
L’intention du départ était de progresser. Le senseï avait expliqué ça.
Charlotte-PO pourrait interpréter ce besoin avec :
• Toutes les leçons peuvent être jouées.
• Un niveau facile propose la leçon seule.
• Un niveau difficile propose la leçon ainsi que les précédentes leçons du plan d’apprentissage.
C’était une autre belle démonstration de l’intention initiale.
La même intention, deux démonstrations différentes. L’une meilleure que l’autre apparemment.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
L’application à la fin de l’itération 4 :
Fin de l'itération 4
40
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Comment Charlotte a-t-elle finalement accepté de pivoter ? En reconnaissant qu’elle perdait ses
utilisateurs. Ils ne venaient pas voir le résultat ! Et en jouant seule, longtemps. Finalement elle était
d’accord avec eux. Elle a lâché ses décisions dictatoriales. Elle a enlevé le blocage des leçons et le
blocage des 100%.
Ses convictions fortes sur son produit étaient sa force, elles auraient pu être sa faiblesse. Maintenant
Charlotte accepte les feedbacks comme une loi de construction. Si les feedbacks sont des détours,
c’est ainsi, il fallait les prendre. Il fallait apprendre.
En plus c’est amusant, l’itération 4 est d’une simplicité déconcertante.
Elle ne doute plus. Elle n’aurait pas pu prendre de chemin plus court. Y avait-il une ligne droite ?
Imaginaire peut-être, en vrai elle ne fait que casser le système.
Pour faire simple, pour faire parfait, il a fallu prendre plein de détours. Ce n’est pas fini. Elle pourra
faire plus simple, elle aura besoin de plus d’itérations. Blaise Pascal disait : « Je vous écris une
longue lettre parce que je n'ai pas le temps d'en écrire une courte. »
41
Le backlog est vivant, il est même jetable.
L’application à la fin de l’itération 4 n’est pas la somme des idées des itérations 1, 2, 3 et 4. Si
Charlotte avait réalisé un manuel d’utilisation à chaque itération, il aurait fallu itérer sur l’écriture
de ce manuel autant de fois qu’elle a itéré sur le développement de l’application.
Le manuel d’utilisation montré à l’itération 8 sera plus intéressant que le backlog de l’itération 8,
que le backlog tout entier même. Le backlog aura servi à construire et c’est déjà énorme.
Le backlog permet de dessiner des chemins, et d’apprendre pendant la route. C’est une illusion de
croire que l’on peut revenir dans le temps et corriger tous ces détours pour trouver la ligne droite.
Charlotte accepte maintenant que la conception initiale exhaustive est un raccourci de la pensée,
que cette conception ne représente en aucun cas la réalité.
C’est tentant de produire beaucoup. De
montrer combien le développeur est
performant, magicien même. C’est décidé,
dorénavant elle passera son temps à
réaliser des logiciels de qualité, même si
cela signifie développer moins de choses.
Le backlog est vivant, il bouge avec des
feedbacks.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
42
Le refactoring
c’est tout le
temps, et
c’est n rmal.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
43
Charlotte a appris que le backlog bouge. C’est une évidence maintenant, les feedbacks
le font bouger, et c’est une bonne chose.
Et le code, est-ce qu'il bouge aussi ? Charlotte-dev a de solides convictions sur le
développement, elle ne doute pas. Après tout c’est son métier, le métier de PO elle l’a
expérimenté à la maison, mais ce n’est pas son vrai métier.
Les questions arrivent dès l’itération 2.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Glossaire
Dakuten et handakuten : petits accents qui modifient la lecture du kana. Plus précisément : la
consonne du kana change de son.
• Dakuten : petit accent ressemblant à un guillemet `` qui a plusieurs dénominations, dakuten ou
ten-ten. Ce signe est utilisé avec les kana pour indiquer les consonnes voisées.
• Handakuten : petit accent ressemblant à un petit rond ° qui a plusieurs dénominations, handakuten
ou maru (qui signifie rond).
Soit, par exemple, les changements suivants (valables avec toutes les voyelles, et ce pour les
hiragana et les katakana) :
44
ka
ga
sa
za
ta
da
ha
ba
ha
pa
Refactoring : réusinage de code. Opération consistant à retravailler le code source d'un
programme informatique – sans toutefois y ajouter des fonctionnalités ni en corriger les bogues –
de façon à en améliorer la lisibilité et, par voie de conséquence, la maintenance, ou à le rendre plus
générique ; on parle aussi de « remaniement ». Cette technique utilise quelques méthodes propres
à l'optimisation de code, avec des objectifs différents. Source : Wikipédia.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Le plaisir de coder
Coder c’est génial.
C’est comme réaliser un cadeau pour la fête des pères. En construisant le logiciel, Charlotte
s’imagine le moment magique où elle va l’offrir. Le cadeau caché derrière son dos, empaqueté.
Se dirigeant vers le bureau paternel et montrant le cadeau, au creux de ses mains, en affirmant :
« C’est moi qui l’ai fait ! ». Quelle fierté. Bon, d’accord, elle n’a plus 6 ans. La presbytie est bien
présente maintenant, et Charlotte a déjà dépassé la phase où elle-même a reçu des cadeaux de
fête des mères. Pourtant elle a toujours besoin de ce sentiment.
Ce sentiment de grande fierté d’avoir réalisé par elle-même quelque chose d’extraordinaire.
45
Elle recommence à coder.
Elle écrit des lignes de code et elle voit le logiciel se former.
Elle avance de plus en plus vite. Une fonction de plus, qui marche. Elle voit arriver le moment où elle
va pouvoir montrer son logiciel à ses utilisateurs. Son cadeau de la fête des pères. C’est exaltant.
Elle identifie des petits moments où elle aurait besoin d’aller moins vite, comme par exemple pour
mieux nommer une fonction, ou pour diminuer le nombre de paramètres d’une fonction. Ça la
ralentirait, elle se demande si cela en vaut la peine. Elle note ses idées d’amélioration, comme pour
déculpabiliser de ne pas les traiter. Elle se remet à coder : elle décide vite, et ça marche.
Elle se trouve très compétente. Elle est fière d’elle.
J’ai toujours su développer vite, se dit Charlotte avec satisfaction, j’en suis capable.
Elle sait qu’elle devra ensuite passer du temps à corriger des détails. Ce n’est pas grave.
L’effet aura été obtenu. Elle aura montré sa compétence. Au travail, c’est pareil. En plus fun, car
il y a les collègues. Un peu d’amitié et un peu de concurrence. Une blague récurrente lui plait
beaucoup : « demande à Charlotte, elle a sûrement déjà fini ». C‘est comme si elle était au collège
et qu’elle passait la ligne d’arrivée en vainqueur.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Finalement, elle se rend compte que ses réflexions sont très infantilisantes. Elle n’assume pas le
côté puéril de la chose. Développer, c’est puéril ? Non, bien sûr que non. Développer c’est un travail
sérieux.
Développer c’est un travail sérieux comme… jouer à un jeu vidéo. Elle code et elle avance dans
l’aventure. Elle code et elle débloque un bonus. Elle code et elle passe un niveau. Le boss de fin,
c’est la mise en production. Elle s’amuse toute seule.
Bon, toujours puéril finalement.
Développer c’est un travail sérieux comme… réaliser une création artistique.
Développer, c’est inventer. Si ce n’était pas inventer, ce serait reproduire. Le développement, c’est
tout sauf de la reproduction. Ce n’est jamais le même problème, ce n’est jamais la même solution.
Développer, c’est inventer une solution pour résoudre un problème. Puis le problème change. Il
faut inventer autre chose. Le travail n’est pas répétitif. L'œuvre est unique. Pour développer, il faut
faire preuve d’imagination. Au départ la solution semble fictive, puis c’est tout un art de lui donner
forme.
46
C’est ça. Charlotte se sent comme une artiste. Elle s’autorise beaucoup de choses que ne s'autorise
pas un esprit cartésien et analytique. Pendant qu’elle développe, elle rêve, elle prend du recul, elle
observe, elle médite sur la solution.
C’est prolifique.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Il y en a partout
C’est un tel plaisir que ça en semblerait facile. Pourtant, ce n’est plus le cas. Cela devient compliqué
même. Normal, avec tout ce qu’elle a déjà réalisé.
Elle a pourtant fait bien attention au fur et à mesure, elle n’a pas développé des fonctions trop
grosses, et le plus souvent, elle a réutilisé des fonctions existantes. Elle a travaillé proprement.
47
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Trois objets, c’était évident. D’ailleurs elle y a pensé dès le début.
À la réflexion elle est gênée car dans l’objet Devinette rien ne s’appelle lancerLaDevinette
ou devinerQuelqueChose.
Devinette, c’est l’objet le plus gros.
Ils sont tous gros en fait les objets.
Normal, elle a beaucoup travaillé.
Elle tâtonne un peu, elle ne sait plus si la fonction qui lance le jeu doit s’appeler
lancerLaDevinette, lancerLeJeu ou lancerUnEntrainement, et pourquoi il n’y a pas de
fonction lancerUneLeçon. Donc elle l’avoue, elle ne sait plus si la fonction qui doit lancer le jeu
doit se trouver dans l’objet Devinette ou dans l’objet Leçon.
48
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
C’est gênant, elle n’est pas sûre de sa construction. Elle se rassure en jouant avec le logiciel.
Le logiciel marche.
Le logiciel marche bien.
Je ne dois pas me laisser perturber.
Tout est très bien développé.
La preuve : le logiciel marche.
Charlotte se remet à coder.
La nouvelle histoire à développer est la suivante : « Afin de progresser dans mon apprentissage, en
tant que Charlotte, je veux jouer une leçon difficile ».
Spécification :
49
• Créer deux modes dans l’affichage des leçons : facile et difficile.
• Le mode facile correspond au mode par défaut.
• Le mode difficile consiste à faire deviner un kana ou un rōmaji parmi les kana de
plusieurs leçons.
• Les leçons à deviner sont la leçon sélectionnée ainsi que les leçons précédentes.
Les leçons précédentes sont calculées en fonction de leur position dans l’alphabet syllabique.
C’est une fonction très attendue, les feedbacks étaient nombreux. Les utilisateurs étaient très
insistants sur le côté « memory » du logiciel, ils ont
l’impression de deviner la solution et de ne pas
vraiment apprendre : l’apprentissage devrait être
meilleur avec cette histoire. Charlotte se retrousse
les manches.
Développer cette histoire repose la question du
lancement du jeu. Est ce que le jeu « niveau difficile »
est une fonction de l’objet Devinette ou de l’objet
Leçon ? Pas de l’objet Kana, ça c’est sûr.
La fonction à développer pourrait se nommer
lancerUnEntrainement2. Ce serait vite fait et
sans impact sur le reste du code. Non, ce n’est pas
raisonnable, elle réfléchit à un autre nom. Tous les
noms sont déjà pris, ou alors il faudrait revoir tous
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
les noms déjà pris. Elle ne s’y résigne pas.
Comment ai-je réussi à construire un bazar pareil ?
Elle se souvient.
Au début, la leçon « facile » consistait à afficher les rōmaji dans l’ordre alphabétique et la leçon
« difficile » consistait à afficher les rōmaji dans un ordre aléatoire. C’est différent de dire qu’une
leçon difficile est une somme de leçons. La conception initiale n’était pas fausse, elle était bonne au
moment de la conception initiale.
Charlotte repense au travail. Ses chefs lui disent souvent qu’ils veulent des applications
maintenables, ils sont d’accord avec ce concept. Ou plutôt : ils veulent dès le début une solution
maintenable. Comme si ce problème pouvait être traité une fois pour toute au début du projet, tout
simplement en l’exigeant.
50
Charlotte aussi voulait une solution maintenable dès le début du projet. Or là, elle se rend compte
qu’elle a échoué, il faudrait tout renommer pour que ce soit plus clair. Les noms avaient peut-être
leur logique au début, mais la logique a changé. L’application a changé et a grossi.
Charlotte ne s’en doute pas : les hésitations sur le nommage sont les signaux faibles de la
catastrophe à venir.
Aujourd’hui c’est l’itération 4. Charlotte hésite à renommer, elle se demande si c’est vraiment
nécessaire. Elle a peur de tout casser.
Cela lui rappelle les tours de Kapla des enfants : c’est génial à monter et à la fin ça se casse. Dès le
début, la construction monte tellement vite qu’elle dépasse la taille de l’enfant. C’est rigolo, l'enfant
monte sur une chaise pour construire encore plus haut. Il s’applique car il prend de plus en plus
de risques de faire tomber la tour. Normal, elle est très haute. Puis c’est encore plus drôle quand
l’enfant, debout sur sa chaise, est plus petit que la tour. Papa vient à son secours et le prend sur ses
épaules. C’est génial, encore plus de construction possible. À la fin, papa et l’enfant sur la pointe
des pieds ne respirent plus. L’enfant pose encore des briques de Kapla en haut de la tour. Avec une
délicatesse extrême. Puis tout tombe dans un bruit retentissant. L'événement était attendu, et tout
le monde rit.
Je n’ai pas construit tout ça pour le faire tomber, moi.
En plus, derrière le problème de renommage se cache un autre problème. Avec un peu de mauvaise
foi, elle faisait comme si elle ne l’avait pas vu. Là, il devient plus flagrant.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Elle a un problème avec le terme « kana ». Elle en parle difficilement : « La fonction affichera le
kana en mode kana ou en mode rōmaji ». Ça fait deux fois le mot « kana » dans la même phrase
pour deux utilisations différentes. Le terme « kana » pose problème, Charlotte-PO a sûrement mal
expliqué. Elle décide de regarder à nouveau les vidéos du YouTubeur. Trois heures après et une
dizaine de vidéos visionnées, c’est plus clair.
51
Un kana est une lettre japonaise. Une syllabe est un groupe de consonnes et de voyelles se
prononçant d’une seule émission de voix. Une syllabe est un son qui peut s’afficher en mode « kana »
(la lettre japonaise) ou en mode « rōmaji » (nos lettres latines).
Conclusion : l’objet Kana n’est en fait pas un objet Kana mais un objet Syllabe qui a deux sousobjets : Kana et Rōmaji. La leçon est une leçon de syllabes, et c’est la devinette qui affichera à
deviner soit le kana, soit le rōmaji.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Encore plus de renommage. Et pas que du renommage. Là c’est sérieux, il faut changer des
concepts, casser du code. Beaucoup.
Charlotte est en pleine réflexion. Moi aussi, au début, je voulais écrire du code évolutif. Du code
qui peut évoluer facilement, tout le temps. Pourquoi n’ai-je pas réussi ? J’aurai dû, dès le début,
écrire du code évolutif dans toutes les directions… Comment aurais-je pu connaître toutes les
directions possibles ?
Charlotte se rend compte que la tâche aurait été trop grande, trop vaste.
Non, au début, je ne pouvais pas savoir. C’était même le pire moment, au début, pour savoir
comment le produit allait évoluer.
Je pensais que les utilisateurs allaient beaucoup me faire travailler sur les fonctions de partage
des réseaux sociaux, je ne pensais pas que j’allais travailler autant sur les leçons. Le début, c’est
le moment où j’en savais le moins. Comment aurais-je pu, à ce moment-là, concevoir le plus ? Je
ne peux pas tout prévoir, il y a trop de directions possibles.
Charlotte se sent moins fautive, elle comprend ce qui s’est passé.
52
Elle était concentrée sur le résultat à obtenir, une application qui fonctionne, elle n’était pas
concentrée sur le chemin pour obtenir ce résultat. Le code actuel fonctionne, mais il n’est plus
évolutif. C’est une petite falaise maintenant ce code.
Elle ne se résout pas à casser tout ça. Contrairement à la tour de Kapla, là ce n’est pas drôle.
Quand ses enfants montaient la tour ils prenaient du plaisir : le pouvoir de création. Ils ont eu
plaisir à fabriquer la tour … jusqu’à ce que la tour se casse. À chaque Kapla posé, ils mesuraient
la solidité du système. Ou plutôt la fragilité du système. La fragilité était visible. Chaque Kapla
supplémentaire faisait tanguer la tour.
Charlotte aurait monté une tour de fonctions. Dont elle ne voyait pas la fragilité. Et maintenant
que sa tour casse, elle est surprise, elle n’avait pas anticipé ça. Elle aurait bien aimé voir avant que
c’était fragile et que ça allait casser, pas quand ça casse.
Elle voit ça comme une fatalité.
Ce n’est pas ma faute. J’ai bien travaillé et la fin logique serait que tout est à refaire. Ce n’est
pas juste. Au travail, c’est pareil, il faut souvent refaire des gros morceaux, des objets entiers, des
modules, parfois même des applications entières. Il y a eu beaucoup de construction, des années
de développement avec des grosses équipes, et à la fin il faut tout refaire.
C’est un cycle presque accepté : « l’application est trop vieille, il faut refaire », « l’application a trop
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
grossi, il faut refaire », « impossible d’ajouter facilement ces fonctions, il faut refaire ».
Charlotte est dépitée. Ce n’est pas possible que le cycle du développement logiciel soit de
refaire des applications quand elles deviennent grosses, comme si le développement logiciel
était une construction de tours de Kapla. Et puis ça coûte cher de redévelopper des applications
juste parce qu’elles sont devenues grosses. Grosses et fragiles.
Ne peut-on pas être plus sérieux que ça ? Ne peut-on pas être plus industriel que ça ? Construire
gros et solide, ce n’est pas possible ?
53
C’est comme si le développement avait une limite. C’est comme si le développeur avait pour limite
sa capacité à construire sans casser.
Quand je développe, j’ai tout en tête. Je vide ma tête, je prends un nouveau problème, et je
recommence, je passe à la fonction suivante. Finalement, j’ai obtenu un tas de petites fonctions,
mais je suis perdue. Je n’y arrive pas pour deux raisons :
1. Ce n’est pas possible de tout voir au début.
2. C’est trop gros pour tout voir en même temps.
Conclusion, je suis limitée : c’est difficile de gérer toutes les informations en même temps et en
plus d’en ajouter d’autres.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
La limite de l’artiste.
Je dois faire comment pour ne pas tout casser tout le temps ? Pour ne pas avoir un bazar pareil ?
Ranger. Au fur et à mesure. Ranger et maintenir rangé.
Elle repense au rangement de son garage : un seul rangement en cinq ans. Résultat, c’était devenu
un vrai foutoir. Le rangement de l’été a été profitable : beaucoup de choses jetées et de l’espace
retrouvé, des choses nouvellement accessibles. Charlotte avait déclenché une dispute avec son
mari en prétextant que c’est lui qui ne rangeait pas et qui provoquait le désordre. Elle lui a demandé
de ranger souvent.
Son code est devenu comme le garage. Comme la tour de Kapla.
Le code a besoin de rangement, sinon on ne pourra plus s’en servir : il faudra tout refaire.
54
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Appel à un ami
Trop de doutes, Charlotte a besoin de conseils. Marc est indépendant, il est très fort techniquement
et très gentil, ça va bien se passer c’est sûr. Elle a toute confiance.
« Marc mon ami, tu pourrais me faire une revue de code ? J’ai beaucoup avancé et j’ai besoin de
tes feedbacks pour continuer. Je me pose quelques questions sur des endroits bien précis, mais le
mieux je pense c’est que je te laisse regarder.
— D’accord, pas de soucis, je regarde ça.
— Merci ! »
55
Charlotte n’a pas osé être franche : elle l’attend comme le sauveur. Il a toujours de bonnes idées,
avec ses commentaires je vais repartir de plus belle.
La tour de Kapla défiera les lois de la gravité.
Marc met un peu de temps à s’y mettre. Charlotte trouve le temps long. Elle a pour sa part
arrêté toute activité de développement. En fait, elle est bloquée. Si elle continue comme ça sans
rien changer, elle voit bien que ce n’est pas une tour mais plutôt une décharge de Kapla qu’elle
construira. Elle attend les commentaires tous les jours et rien. Elle vérifie, il ne s’est pas encore
connecté. Elle n’est pas sûre que Marc soit intéressé finalement. Elle bascule sur d’autres activités
qu’elle avait laissées de côté dans sa passion créatrice.
Elle écrit des tests.
Le test doit proposer des devinettes de la leçon ainsi que de ses précédentes leçons. La leçon
précédente n’existe pas vraiment. C’est une astuce aujourd’hui qui rend ça possible.
Je dois ajouter un ordre de leçons. Dans quel objet ? Pas facile non plus, certaines questions sont
les mêmes.
Elle observe son code longtemps, et la conclusion est toujours la même : il faut casser du code. Ou
alors un petit bout. Elle essaie d’identifier une petite partie cassable. Pas facile, tout est lié.
« Charlotte, il faut qu’on se parle. »
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
C’était direct. Pas forcément brutal se convainc-t-elle. « C’est du niveau de toutes les sociétés
d’informatique : sale et efficace. »
Charlotte ne sait pas quoi répondre, elle tente une explication : « j’ai développé tout ça en 4
semaines, j’ai eu plein d’idées et j’ai dû faire plein d’allers-retours. Les utilisateurs sont ravis, ils
utilisent vraiment l’application. »
Marc n’écoute pas les excuses.
56
« Raconte-moi ton code. Ça commence où ?
— Là : le fichier index. Puis les appels de tous les objets, l’objet qui lance l’application est
Devinette, il contient la fonction LancerUnEntrainement qui va créer la Leçon. La devinette
sera un kana de la leçon. Le jeu consiste à trouver quel est le bon rōmaji qui correspond au kana
affiché. L'entraînement est lancé quand la fonction a associé le kana et les propositions à deviner.
— C’est un jeu, une devinette ou un entraînement ?
—…
— Comment tu peux t’y retrouver dans ton code si tu ne sais pas de quoi tu parles ?
— Oui, c’est un peu difficile à expliquer. C’est un entraînement.
— Une devinette c’est plusieurs entraînements ou un entraînement c’est plusieurs devinettes ? Et un
jeu c’est quoi ?
— … Je ne sais pas, mais les utilisateurs sont ravis.
— Ouais ben pas le développeur, lui, il pleure. »
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Charlotte soupire et marmonne. Tous les feedbacks sont méchants en fait. Ils ne se rendent pas
compte que les gens travaillent dur pour ça, pas obligé de se fâcher.
Elle tente une réponse argumentée :
« Au début je me suis inspirée de Google traduction, donc oui c’était une devinette, et puis avec
l’alphabet japonais il faut s’entraîner, et puis quand les utilisateurs ont joué il est devenu pertinent
de …
— Bon arrête, il faut renommer. »
Charlotte est déçue, les remarques de Marc ne lui apprennent pas grand chose.
57
« Il n’y a pas un autre moyen ? Il y a beaucoup de lignes de code quand même.
— Ecoute, là, je suis plutôt inquiet sur ta production au travail. Si tu veux, je t’aide. Je te propose
qu’on refactore tout, petit à petit.
— C'est-à-dire ?
— On refactore, on débranche, on rebranche. D’habitude tu ne fais jamais de refactoring ?
— J’ai lu des articles, je n'en n’ai jamais fait. »
C’est un aveu, elle comprend qu’elle n’a plus le choix, si elle veut son aide, si elle veut progresser, il
faut avouer.
« J’ai déjà vu du code refactoré. C’est pas mal, j’essaie de m’en inspirer.
— Pas mal … Tu ne peux pas t’en inspirer, en fait ! Tu n’y arriveras JAMAIS en une fois. Si tu ne
refactores pas ton code, il est pourri, il mourra bientôt. »
Charlotte est déçue : cette discussion est trop compliquée, on ne parle même pas technique. En
plus remettre en cause sa compétence à développer, c’est vexant. Marc est en train de dire qu’elle
travaille mal.
« Pourquoi je n’y arriverai jamais en une fois ?
— Écoute. Quand tu écris un mail important, tu fais comment ?
— Et bien je fais attention.
— Moi j’ai déjà envoyé des mails que je n’aurais pas dû. Mal écrits, mal reçus.
— Oui, moi aussi ! Depuis je fais attention justement, je m’impose un processus qui marche bien :
1. D’abord, je ne remplis pas la zone “destinataire”, je le fais à la fin quand je suis contente du
mail.
2. J’écris toutes mes idées, brutes.
3. Je relis en vérifiant que tout y est. Ma vérification est facile, je contrôle que tous les points
que je veux aborder sont présents.
4. J’écris la conclusion.
5. Je réécris deux ou trois fois la conclusion en testant qu’elle est bien cohérente avec les
données brutes présentées.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
6. Je déplace la conclusion tout en haut du mail. Comme ça mon expéditeur saura tout de suite
ce que je lui demande.
7. Je reprends mes données brutes, je les positionne tout en bas du mail avec la mention “Plus
précisément”.
8. Je relis mes données brutes, je les réécris pour qu’elles soient compréhensibles.
9. À la fin je fais une dernière relecture, voire une deuxième.
10. J’ajoute le ou les destinataires et j’envoie.
— Tu es trop forte.
— Comment ça ?
— Tu sais refactorer un mail mais tu ne sais pas refactorer du code. »
Là c’est dur. Elle ne sait plus où elle en est.
58
« Tu écris ton mail, ça marche. Puis tu retravailles ton mail, ça marche encore. Tu l’améliores, ça
marche toujours. Tu es tellement satisfaite que tu décides de l’envoyer. Le code c’est pareil. Tu sais
développer, ça marche. Et finalement, est-ce que tu es contente de ton code ?
— C’est vrai que je ne suis pas perfectionniste moi, je suis plutôt rapide.
— Attention aux mots. Un perfectionniste, il n’y arrive pas : il est toujours à vouloir refaire les choses
car il ne les trouve jamais assez parfaites. Un mail important, tu le traites rapidement ?
— Non, j’utilise mon process.
— Traite ton code comme quelque chose d’important. »
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
À ce moment-là, Charlotte reçoit trop d’informations en même temps, qui génèrent trop de
réflexions en même temps.
« D’accord, je vais tout nettoyer, répond-elle, résignée.
— Surtout pas. »
Décidément la discussion est difficile.
59
Marc reprend calmement :
« Si tu nettoies tout, ça va prendre du temps. Tes utilisateurs peuvent attendre ?
— Je ne sais pas, avoue-t-elle.
— De plus, qu’est-ce qui nous garantit que tu ne vas pas recommencer ? Que tu ne vas pas me
rappeler dans deux mois car ton code est de nouveau illisible ?
— Je ne sais pas, avoue-t-elle à nouveau.
— Qu’est-ce qui est le plus cool à faire selon toi ?
— Développer une nouvelle fonction.
— Et bien je vais te montrer comment développer une nouvelle fonction en faisant du refactoring.
— Mais attends, je n’ai pas le droit d’en faire, moi, d’habitude. Au travail, je dois respecter le budget
qui m’est attribué et puis le tech lead doit faire une présentation sur le refactoring, mais là on n’a
pas le temps.
— Tu as sûrement raison, et ce sont d’autres problèmes. Concentrons-nous sur maintenant si tu
veux bien, ici personne ne t’en empêchera. »
Marc propose de ranger souvent. Marc l’autorise à ranger souvent. Elle procrastinait, le chantier
était trop gros.
Elle a hâte maintenant.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Montre-moi
Marc prend le clavier. Il parcourt le code en le lisant à voix haute. Ça va vite. Charlotte a du mal à
anticiper les déplacements du curseur sur l’écran, elle cherche un repère en regardant les mains
de Marc sur le clavier. Il utilise des raccourcis, elle ne sait pas ce qu’il fait. Elle ne comprend rien.
Elle se sent nulle.
« Ça, ça n’a pas besoin d’être gros : ces fonctions sont longues et celles-là ont plus de trois
paramètres, c’est trop. C’est quoi cet amas de données dans cette fonction, tu es sûre que la
fonction fait une seule chose ? Le nom que tu lui as donné est forcément faux. Là, tu ne décides
pas : il y a beaucoup de cas différents, c’est difficile de comprendre, le métier a autant de chemins
alternatifs ? Je vois aussi beaucoup de champs temporaires, c’est suspect tous ces changements.»
60
« Là, tu décides et je ne sais pas pourquoi : je vois un nombre magique.
— Pourquoi magique ?
— Magique pour moi, je ne sais pas pourquoi il est là, rien ne me l’explique. Si c’était une constante
tu l’aurais nommée et je comprendrais à quoi elle sert. »
« Ces commentaires ne disent pas la même chose que la fonction. Qui a raison ? »
« Ici, on dirait que tu fais exprès de fabriquer des choses difficiles : beaucoup d’objets sont ouverts,
et pourquoi ces deux objets sont systématiquement passés en paramètres de ces sept fonctions ?
« L’objet syllabe est compliqué pour rien, ces fonctions ne sont pas utilisées : pourquoi as-tu créé
des syllabes dakuten et handakuten ?
— C’est pour le moment où je voudrais faire des leçons de dakuten et handakuten… En répondant
à la question Charlotte comprend le problème.
— Charlotte, n’écris pas du code pour le cas où. Nous ne sommes pas omniscients nous autres les
êtres humains, en général nous sommes de mauvais spéculateurs. Ce code que tu as écrit pour une
fonction qui pourrait arriver dans le futur, cette fonction dont personne ne veut maintenant, qui va
l’utiliser et te donner du feedback ? Ah et puis là c’est du code dupliqué.
— Non, ça c’est pour le cas où… »
Regards croisés en silence.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
61
« Marc, j’avais bien compris que ce que j’avais fait n’allait pas, tu devais me montrer.
— Oui, oui c’est vrai. Bon écoute, les problèmes d’écriture de code sont connus et résolus. Tu n’as
pas à inventer des solutions pour ça, tu dois juste les connaître et les appliquer.
— Je sais. Tes remarques sont pertinentes mais je risque de tout casser si je les prends toutes en
compte.
— Prends-les une par une.
— Une par une… Je répète, je vais tout casser si je remanie en permanence.
— Pas si tu as des tests.
— Je ne vois pas le rapport.
— Ton premier “jet” de code qui marche est bien car il marche, mais il n'est pas du tout satisfaisant
car il n’est pas remanié. Cela revient à construire sur des bases fragiles, ça va forcément casser. »
Charlotte sourit, elle pense que Marc a dû construire beaucoup de tours de Kapla, lui aussi.
Marc reprend :
« Aucun développeur au monde ne peut écrire du code satisfaisant du premier coup, heureusement
il y a le refactoring pour ça. Les remaniements successifs rendent le code acceptable.
— Comme mon process d’écriture de mail.
— Exactement. Tous les points que j’ai soulevés doivent être vus lors du refactoring. »
Charlotte est en pleine réflexion.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
« Tu peux me montrer concrètement ?
— Oui. Quelle est la prochaine fonction à développer ?
— “Afin d’éviter les déductions, en tant que Charlotte, je veux apprendre à un niveau difficile”.
— Tu as la spécification ?
— Oui, voici :
Spécification :
62
• Une leçon peut être lancée en 3 modes : facile - normal - difficile.
• Le mode facile propose les kana de la leçon uniquement.
• Le mode normal propose les kana de la leçon lancée ainsi que les kana des leçons
précédentes.
• Le mode difficile propose les mêmes kana que le mode normal.
• Le mode difficile affiche au maximum 5 propositions pour chaque devinette.
• Aléatoirement, le mode difficile peut afficher des propositions à deviner avec ou
sans la bonne réponse.
— D’accord, c’est parti. »
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Un nouvel espoir
Charlotte est très attentive.
« Charlotte, comment vas-tu tester ? »
Déconcentration totale : Charlotte ne comprend pas pourquoi Marc pose cette question.
« Je ne sais pas encore.
— Tu dois le savoir maintenant. »
Charlotte a du mal à rester concentrée.
63
« Marc, d’abord nous codons. Après, nous testons.
— Non, coder, ce n’est pas un travail à la chaîne. Coder nécessite beaucoup d’allers-retours
pendant le développement. Ton mail, tu l’as écrit en une fois ?
— Non, Marc, mon mail, je ne l’ai pas écrit en une fois.
— C’est ça. À chaque fois que tu le modifiais, tu le testais. Tester permet de construire. »
Charlotte est au bord de la rupture, elle envisage une reconversion. Marc lâche le clavier, il voit
qu’il la perd.
« Charlotte, je t’ai dit que je te montrerai, je te montre. Tu vas comprendre, c’est toi qui fais. Je
répète : comment vas-tu tester cette nouvelle fonction qui va permettre à ton utilisateur d’éviter
les déductions ? »
Charlotte accepte la question, elle veut comprendre.
« Je vais tester … trois choses :
1. Que les propositions de la leçon soient les kana de la leçon.
2. Que la bonne réponse soit présente dans les propositions de la leçon.
3. Que la bonne réponse ne soit pas présente dans les propositions de la leçon.
— Commençons par le premier test. Écris le libellé du test.
— D’accord : les propositions de la leçon devraient être les kana de la
leçon. Ah ! Mais une fonction que j’ai codée le fait déjà, pas la peine d’écrire le test !
— Quelle fonction ?
— Eh bien la fonction de niveau normal propose déjà les kana de la leçon lancée plus ceux des
leçons précédentes.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
— Premièrement, sois plus précise, modifie le titre s’il te plait : les propositions de la
leçon difficile devraient être les kana de la leçon normale. Deuxièmement,
tu me dis que le test existe déjà ?
— Non, mais le code oui.
— Charlotte, tu me dis que ce n’est pas la peine d’écrire un test qui n’existe pas d’une fonction qui
existe. Autrement dit, rassurez-vous messieurs-mesdames les utilisateurs, je n’ai pas testé mais ça
marche.
— …J’ai testé en jouant avec l’application, ça compte, non ?
— C’est déjà ça. Tu as joué combien de tests ? Comment pouvons-nous savoir si les tests que tu as
joués sont suffisants ? Ils faisaient quoi exactement ces tests ? Tu peux les refaire là, maintenant ?
— … Je ne sais plus exactement.
— Alors écrivons le test, comme ça nous serons sûrs de ce que nous testons. »
Charlotte réfléchit, elle a l’intuition que Marc est peut-être en train de proposer de coller les Kapla.
Il veut coller les Kapla pendant qu’il construit la tour.
64
« Charlotte, écrivons le test : les propositions de la leçon difficile devraient
être les kana de la leçon normale. Qu’est-ce que ce test reçoit en entrée ?
— Le test reçoit la leçon ka-ki-ku-ke-ko et les propositions a-i-u-e-o-ka-ki-ku-ke-ko.
— Que doit-il afficher en sortie ?
— Vrai. C’est la bonne liste de propositions de kana à deviner pour cette leçon difficile.
— D’accord. Écris la fonction de test. Maintenant autre chose, comment doit s’appeler la fonction
qui va être testée ?
— Alors, nous allons dire : kanaAAfficherPourLeçonDifficile, mais je ne l’ai pas encore
développée !
— Normal, crée la fonction mais ne la développe pas. Et comme elle n’est pas vraiment créée, faislui renvoyer Faux. Maintenant le test est complet, lance-le. Que dit-il ?
— Ben, il dit Faux. C’est normal hein car nous n’avons pas codé la fonction
kanaAAfficherPourLeçonDifficile.
— Effectivement, nous l’avons appelée dans le test et nous ne l’avons pas codée. Codons maintenant
cette fonction de la manière la plus simple possible.
— Même si c’est mal écrit ?
— Même si c’est mal écrit.
— D’accord… Voilà.
— Relance le test. Maintenant que dit-il ?
— Vrai.
— Nous avons maintenant la fonction et son test. Et le code marche. Regarde à nouveau la
fonction. Tu la trouves comment ?
— Pas très jolie, je peux réutiliser une fonction existante et enlever un paramètre.
— Une action seulement, commence par la première. Relance le test pour vérifier que le code
marche toujours. Qu’en dis-tu maintenant ?
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
— Je peux enlever un paramètre.
— Vas y, le test est toujours vert ? Ok. Et maintenant ?
— C’est mieux. Je peux encore renommer des variables.
— Ok, n’oublie pas de relancer le test. Et maintenant ?
— Ça va. »
65
C’était mal écrit, mais ça marchait. Charlotte a émis des feedbacks et elle a itéré. C’est mieux.
Tiens, ça lui rappelle quelque chose.
Marc est tout souriant. « Charlotte, nous avons codé un test que nous avons pu lancer trois fois
instantanément, et grâce à ce test, nous avons refactoré notre code trois fois sans nous inquiéter
de tout casser. »
Charlotte est épatée par un point : ce n’était pas dur. L'exercice intellectuel d'écriture et de
réécriture du code était plus facile que lorsqu’elle écrit du code sans test : le code a été écrit comme
une réponse à l’écriture du test. Elle compare son code précédent et celui-ci et, indéniablement, le
résultat est meilleur. Elle en est contente.
« Ce n’est pas de la sur-qualité ?
— Tester tu veux dire ?
— Pas que tester, tout le process que tu m’as montré :
1. Ecrire des tests avant de coder,
2. coder,
3. refactorer,
4. recommencer.
— Tu le trouves comment ton code comme ça ? »
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Charlotte repense à toutes les remarques de Marc quand il a lu son code la première fois.
« Mieux. Et tu fais tout le temps ça ?
— Oui.
— Et ça marche tout le temps ?
— Oui. Tu n’auras plus besoin de regarder méticuleusement ton code pour savoir ce qui ne marche
pas. Imagine que tu fais ça tout le temps. Le débuggage consistera à regarder quel test ne passe
pas. Imagine le nombre de tests que tu auras si tu en as environ trois par fonction, que tu peux
lancer immédiatement. Tu n’auras plus peur de rien. Si tu as de meilleures idées, tu pourras modifier
ton code à ta guise, et le remanier. Ton code deviendra de plus en plus robuste. »
Charlotte est admirative.
Marc colle les Kapla. Marc construit des tours solides.
66
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Pas facile
Deux heures que Charlotte écrit ce test. Pourtant
avec Marc c’était rapide. C’est le premier qu’elle
écrit toute seule et c’est douloureux. Elle râle.
Avec Marc on n’avait fait que le début en fait.
En fait, c'était un cas facile.
C’était facile car nous n’avons pas fait grand-chose.
67
Charlotte n’arrive pas à écrire un test. Deux heures
que ça dure et ce n’est pas fini. Ça ne marche pas
son truc.
De plus, elle a l’impression d’écrire des évidences.
Le test doit tester qu’il y a un maximum de cinq propositions.
Je crée un test qui prend cinq propositions en entrée, je lui dis de renvoyer vrai.
Ce test ne sert à rien !
Charlotte est chagrinée. Elle n’a pas le choix, elle doit rappeler Marc. Si elle abandonne maintenant
tout ça n’aura servi à rien, et elle ne sera pas plus avancée.
« Marc, j’écris un test et je n’y arrive pas. Sans te fâcher, tu as cinq minutes pour regarder le code
avec moi ?
— Oui. Partage ton écran. Tu fais quoi avec ce test ?
— Je teste que mes propositions ne dépassent jamais cinq. J’ai des impacts partout ! Normal hein
ça remet en cause ce que j’ai déjà développé avant. J’ai plein de choses à tester maintenant avec
ta technique. Je nettoie une fonction, qui en appelle une autre et caetera. J’en ai partout.
— Je vois. »
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Marc pose un long silence, Charlotte sent qu’elle perd patience.
« Tu as beaucoup de choses à faire. Je vais te dire un secret : je n’ai pas de mémoire. Je suis un peu
limité de ce côté-là. Mon atout à moi, c’est d’être précis. J’aime bien nommer clairement, je prends
plaisir à définir les choses.
— C’est de la fausse modestie, ça, tu es très fort, tout le monde le sait. Ça marche tout le temps ce
que tu fais.
— C’est bien que tu le croies, c’est bien que tout le monde le croie, en vrai pas tant que ça. Je
déteste me rappeler des choses, je veux me décharger de ce type de savoir. Je me fais des listes
de ce que je dois faire et je les coche. Comme aux courses, pareil.
— C’est pas compréhensible ce que tu dis. »
Charlotte en a marre de ne rien comprendre.
Elle rumine : ok je ne sais pas coder, ok je ne teste pas, ok mon code n’est pas maintenable et lui
il y arrive car il est bête. Elle devient irritable, elle le voit bien, et Marc remarque son énervement. Il
est amusé, il n’est pas étonné. Il ne s’attendait pas à ce qu’elle y arrive du premier coup.
68
« Pardon pardon, je vais être un peu plus clair. Ce que tu as à faire pour ce test-là, c’est beaucoup
de choses.
— Ah !
— Oui, je ne sous-estime pas ton travail, bien au contraire. Peu de développeurs vivent une
expérience pareille. Il te faudra la raconter. »
Charlotte est toute ouïe.
« Tu as beaucoup de choses à faire, fais une liste. Une chose à la fois s’il te plait. Ce n’est pas un
travail difficile ma technique, pas besoin d’être un savant. Je ne suis pas en train de te proposer une
révolution dans ton code, les gros changements ne marchent pas, on ne sait jamais quoi faire. Tu
réussiras si tu fais des petits changements, plein de petits changements tout le temps. »
Charlotte réalise qu’elle voulait encore aller vite. Elle voit bien que rien que de penser à écrire la
liste, ça l'énerve, elle a envie d‘aller plus vite que cela.
« Grâce à ta liste, à chaque fois que tu modifies ton code, il doit être meilleur. Tu codes et tu vois
d’autres modifications à faire : note-les, s’il te plait. Fais-toi un fichier TODO et liste tous tes points. »
Devant l’ampleur du travail à faire, elle n’avait pas fait de liste. La liste aurait été trop grosse,
démoralisante.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
« Tu sais voir quand les standards de code ne sont pas respectés, quand les nombres magiques
sont utilisés, quand le formatage est incorrect, quand les classes sont trop grosses, que les noms
sont mauvais, enfin tout ça tu sais très bien le faire. »
Charlotte reçoit des félicitations, c’est une expérience nouvelle.
« Prends ton temps ! Les tests vont te protéger, ils ne vont pas te tuer. Deviens une experte des
petits pas. Quand on n’a pas de mémoire comme moi c’est facile, je suis obligé de noter tous les
points à modifier, et j’écris autant de tests qu’il faut pour les traiter. Comme ça je libère mon esprit
de tous ces problèmes que je vois et je consacre mon attention toute entière à la correction de
chaque point. »
C’est plus clair pour Charlotte maintenant : elle doit accepter de ne pas en faire trop.
« Je sais que ça prend du temps de faire confiance. Tu as confiance en moi ? Eh bien fais confiance
au process. Si c’est une discipline, c’est facile. »
69
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Le développement
est sinueux, pas linéaire
Cela fait maintenant deux semaines que Charlotte suit les conseils de Marc. Les nouvelles fonctions
sont faciles à reconnaître, ce sont celles qui ont des tests. Une cinquantaine de tests pour une
dizaine de nouvelles fonctions. Facile à lancer, facile à débugger.
Avant, elle ne touchait plus à son code quand il marchait. Aujourd'hui, si elle ne peut pas y toucher,
elle suspecte que le code ne marche pas.
70
Avant, coder vite la grisait. Aujourd’hui, coder lentement la rassure. Le lièvre et la tortue, ça
l'énerve.
C’est un exercice nouveau d’améliorer le code en permanence, un luxe qu’elle ne s’autorisait pas
avant. Avant, elle l’améliorait un peu bien sûr. Un peu.
Elle a encore plein de questions. Le refactoring est possible grâce aux tests écrits avant de
coder. Ceux qui veulent aller vite ne font pas de refactoring et ne font pas autant de tests. Ses
fondamentaux conception-développement-tests sont modifiés, c’est toute sa connaissance du
génie logiciel qui est remise en cause.
« Marc, la conception bouge beaucoup pendant le refactoring.
— Oui, et alors ?
— Alors, cela veut dire qu’au début la conception est fausse ?
— Non, ça veut dire que tu améliores au fur et à mesure que tu construis. Je te l’ai déjà dit, personne
ne peut construire du code parfait du premier coup. Le refactoring te permet de ne pas être
coincée avec ta conception initiale. Quand tu es face à un problème, tu te sens capable de trouver
la bonne solution en une fois ?
— Pas toujours, non.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
— Le refactoring te permet de trouver la bonne réponse, car en plusieurs fois tu as plus de chances
d’y arriver.
— Je vois, donc je dois retravailler plusieurs fois mon code ?
— Je répète, tu te sens capable de trouver la bonne solution en une fois ?
— Non…
— Ne pas refactorer, c’est croire que développer est une formule linéaire. C’est tout le contraire. Ce
n’est pas parce que le code se lit de haut en bas qu’il a été écrit de haut en bas. L’écriture du code
suit un chemin itératif, non linéaire.
— C’est dommage de devoir refaire.
— Pas refaire, améliorer. Si tu ne refactores pas, ton code pourrira. L'entropie est un phénomène
naturel, le refactoring est un process pour lutter contre. »
Marc sourit tout le temps, il est moins brutal.
« Refactorer, c’est la meilleure méthode connue pour écrire du code améliorable. Le process
fonctionne, tu peux lui faire confiance : tester-coder-refactorer, c’est LE process de construction
d’un code maintenable. »
71
Charlotte réfléchit, elle ne voit pas comment expliquer ça à son chef lundi.
« Tu es d’accord que ce process coûte plus cher que juste coder ?
— Oui, la qualité du code coûte cher si c’est ce que tu veux dire. Tout le monde serait d’accord pour
faire du code maintenable si ce n’était pas cher. Je te pose la question, ce code est-il maintenable ?
— Oui oui. »
Charlotte connaît maintenant le prix du code maintenable. Elle y repense, peut-être que ce code
maintenable coûte moins cher que de devoir tout refaire de temps en temps, se convainc-t-elle. Il
faudrait essayer ça au travail. Malik est curieux, avec lui ça devrait aller.
Charlotte reconsidère sa notion de collage des Kapla. Ce n’est pas de la colle entre les kaplas que
Marc a posé : ce sont des bouts de scotch. À chaque nouveau test, il enlève des bouts de scotch
et il replace des bouts de scotch. Il modifie le nombre de Kapla ainsi que leur positionnement
sans faire tanguer la tour. Il modifie des tests et il modifie du code sans rien casser.
Il a trouvé un moyen de construire en solidifiant la construction. Et si ça se trouve, ce n’est pas plus
cher. Le code avant refactoring et le code après refactoring ne sont pas comparables. J’espère
bien que le code remanié aura moins de défauts.
Charlotte a fait deux grandes découvertes :
1. La pratique du refactoring s’appuie sur les tests.
2. Les tests permettent de refactorer sans casser le code.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Elle ne développait pas mal avant, elle développait dangereusement. Charlotte vivait dans
l’angoisse de ne pas être efficace, elle avait du mal à refaire car refaire c’était casser, refaire c’était
ralentir. Comme une artiste, elle était émotionnellement attachée à son travail, refaire était un
aveu d’échec.
Elle a appris que coder ce n’est pas faire du code refactoré, mais plutôt faire du code refactorable.
72
Le problème du garage était qu’il n’était plus rangeable, c’est pour ça qu’il a fallu tout ranger.
D’ailleurs au dernier rangement elle a mis en place des espaces plus pratiques. Le garage aura
besoin d’autres rangements, elle s’en doute bien. Elle espère seulement que les rangements
suivants seront moins douloureux. Elle a trouvé des moyens de maintenir le garage rangé. Par
exemple, le panier vide à l’entrée du garage qui permet de poser rapidement les petites affaires
de vélo (lunettes, gants) sans devoir les ranger, et de les retrouver facilement à chaque sortie, c’est
une amélioration qui marche bien, elle en est très fière.
Charlotte comprend qu’elle doit réaliser un code aménageable, facile à maintenir. Le refactoring
permet de maintenir le code rangé.
Dans son code, il y aura des allers-retours ; le refactoring est le process non linéaire d’écriture
du code.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Le travail du développeur
Deux mois ont passé depuis l’échange avec Marc. Charlotte et Malik vénèrent le refactoring. Ils se
sont isolés des autres, ça tombe bien ils ne sont que deux développeurs sur leur projet. Ils ont bien
tenté de présenter leur démarche aux autres développeurs de la société, ils ont animé un atelier à
la communauté des développeurs. Les réactions ont été décourageantes :
« Impossible chez nous, c’est trop gros.
— Chez nous c’est très compliqué, il y a beaucoup de règles légales à respecter.
— Moi je n’ai pas d’activité refactoring prévue dans mon rapport d’activités, si j’en fais je vais devoir
dépasser sur une de mes autres activités prévues. »
73
Tant pis pour le projet de sauver le monde, Charlotte et Malik sauveront leur projet. Sylvain, leur
PO, leur fait confiance, il parle tout le temps feedback utilisateurs et n’intervient pas dans leurs
affaires. D'ailleurs, il n’a pas le temps, Charlotte et Malik ont toujours une version de logiciel à lui
montrer.
Nous sommes en août, Charlotte est à la plage. Malik est en arrêt, et ce n'était pas prévu, cas de
force majeure. Sylvain n’a plus son équipe de choc mais il est serein, le logiciel a fait ses preuves
pendant la recette avec le métier.
Yoann sait tout ce qui se passe en production, c’est son travail.
« Allo Sylvain ? Ton site est cassé, enfin une partie. »
Sylvain arrête toutes ses activités.
« Ça veut dire quoi ? Qui a fait quoi ? »
— Je ne sais pas qui a fait quoi, je vois juste qu’un service ne fonctionne pas. Ça m’inquiète. Qui est
là ? Ton équipe ne répond pas.
— Personne. Personne n’est là.
— C’est embêtant ça, Sylvain.
— C’est pas mon problème, moi je ne m’occupe pas de technique. Demande aux autres
développeurs.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
— Tu crois que les développeurs aiment bien les bugs peut-être ? Ils ne se sentent pas très concernés
quand c’est leur code et que ça marche sur leur poste, alors quand ce n’est pas leur code je te laisse
imaginer l’engouement. Bon j’appelle qui ?
— Je ne sais pas ! Et toi tu peux non ?
— Non, moi je ne suis pas compétent pour ça. »
Sylvain est démuni. Yoann reprend :
« Écoute, nous allons y arriver. Envoie-moi un développeur disponible ce matin, je lui explique les
contraintes opérationnelles et il corrige ça. »
Sylvain est énervé, ils sont embêtants ces informaticiens, ça ne peut pas être simple. Yoann a
raison, aucun développeur ne se rend disponible.
« Je ne sais pas ce qu’ils ont fait, je préfère ne pas y toucher. »
« Je ne connais pas cette technologie, je ne suis pas la bonne personne. »
« Ça sera trop long, je n’ai pas le temps. »
74
Sylvain se demande qui n’aura pas le courage de refuser : Alexandre. Un jeune stagiaire
sympathique. Sympathique et stagiaire. Sylvain n’a pas vraiment le choix, et il ne veut plus que ce
soit son problème. Il se prépare mentalement à expliquer en haut lieu les causes et les conséquences
de l’incident.
Yoann ne s’offusque pas du choix du développeur, ils commencent à travailler.
« Allo Sylvain ? Tu peux faire des tests et me confirmer que c’est bon pour toi ? »
Sylvain ne comprend pas ce que Yoann lui demande, il est dans ses slides en pleine analyse des
impacts financiers.
« Tester quoi ? Tu m’as dit que tu étais inquiet et que ça risquait de recommencer.
— Maintenant ça marche, j’ai besoin de toi pour les derniers tests. »
Sylvain se dit que c’est Noël, pourtant pas si tôt d’habitude.
« Effectivement, ça marche, je ne vois pas de différences avec ce qu’ont fait Charlotte et Malik.
— Bon, parfait, nous déployons la version.
— Vous n’avez rien changé ? Il n’y a plus de problème ?
— Alexandre a corrigé le problème. Il est chouette, tu devrais le garder. »
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Sylvain juge ceci incompréhensible. Tous les autres développeurs-experts-soit-disant-très-fortssur-des-sujets-sensibles ne s’y sont pas risqués et Alexandre a tout plié, tout seul. Un génie, ce
stagiaire. Sylvain le garde sur le projet et chante ses louanges au monde entier.
Charlotte et Malik sont de retour, un peu penauds. Ils ont bien compris qu’ils ont raté un moment
important et tentent de recoller les morceaux. Ils sont ravis d’avoir un nouveau collègue aussi
compétent dans leur équipe, Alexandre n’est pourtant pas très expérimenté.
« Ah c’est vous l’équipe de Sylvain. Merci à vous deux, vous êtes géniaux.
— Alexandre, c’est plutôt toi le génie qui a sauvé le projet, bravo à toi.
— Ah non non, moi j’ai juste lu et lancé vos tests. »
Charlotte et Malik sont intrigués.
75
« J'ai regardé les logs et j'ai vu les données que recevait le service. J’ai cliqué sur testrun, puis j'ai
modifié les données en entrée d’un test pour voir. J'ai vu ce qui ne passait pas. J’ai lu votre code,
il est super bien écrit ! Trois corrections. J'ai relancé les tests, et c'est passé. Yoann a déployé et
c'était fini. Je ne suis pas fort hein, je veux apprendre. Je suis très content de vous rencontrer, vous
pouvez me montrer comment vous avez fait tout ça ? C’est super pratique. »
Charlotte est impressionnée, même si elle se dit qu’il faut vite aider Alexandre à écrire de nouveaux
tests plutôt que de remplacer les tests existants. Elle est fière que le code soit maintenable, même
par un junior.
Charlotte a progressé : elle connaît maintenant sa responsabilité de développeur. Elle ne rendra
plus négociable les activités de refactoring.
Ce doit être fait.
Ce n’est pas clairement dit, mais tout le monde compte sur le développeur pour que les activités de
refactoring soient réalisées.
Le refactoring c’est tout le temps, et c’est normal.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
76
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
Le mot de la fin :
Remerciements :
Merci à Yohan et Marion, Christophe, Aryana, Marc, Alexandre, Ivan,
Sonny, tous les relecteurs OCTO et OCTO Toulouse.
O C T O P R E S E N T S > P R O J E C T E U R S S U R S Y LV I E P O N T H U S -V I O L L A N D
OCTO Technology
CABINET DE CONSEIL ET DE RÉALISATION IT
“ Dans un monde complexe aux ressources finies,
nous recherchons ensemble de meilleures façons
d’agir. Nous œuvrons à concevoir et à réaliser les
produits numériques essentiels au progrès de nos
clients et à l'émergence d’écosystèmes vertueux. ”
– Manifeste OCTO Technology –
78
2
PRODUITS
PLUS DE
1OOO
COLLABORATEURS
3
IMPLANTATIONS
Paris
Toulouse
Hauts-de-France
OCTO EN TÊTE
DU PALMARÈS
6x
3 CONFÉRENCES
La conférence tech par OCTO
FORMATION
Dépôt légal : Novembre 2022
Conçu, réalisé et édité par OCTO Technology.
© OCTO Technology 2022
Les informations contenues dans ce document présentent le point de vue actuel
d'OCTO Technology sur les sujets évoqués, à la date de publication.
Tout extrait ou diffusion partielle est interdit sans l'autorisation préalable d'OCTO
Technology.
Les noms de produits ou de sociétés cités dans ce document peuvent être les
marques déposées par leurs propriétaires respectifs.