Le backlog est vivant, il bouge avec des feedbacks (épisode 3 - 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 :)
C’est un peu fou cette situation, elle se rend compte qu’elle est soit PO, soit développeur.
Elle discute avec ses utilisateurs, elle est PO.
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 spécification. 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 kanas, en tant que Charlotte, je veux m’entraîner à les reconnaître en romaji. »
C’est un peu court.
A 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 kanas 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 ?
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 — c’est plutôt qu’il y a beaucoup à apprendre et Charlotte a besoin d'une méthode progressive : pas tout d'un coup ç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
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.
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.
DEV — L’utilisateur voit un kana et il clique sur le romaji associé, il sait alors si il a juste ou faux
PO — c’est ça
DEV — il devine le romaji, 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 romaji ».
DEV — une séquence d'entraînement (quizz) 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, il voit son résultat
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. 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 parmis ceux de la leçon sélectionnée
- Charlotte clique 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 process est très clair maintenant dans sa tête.
Charlotte-PO parle avec ses utilisateurs pour comprendre leurs besoins.
Charlotte-PO formalise ses idées pour y répondre.
Charlotte-développeur discute avec Charlotte-PO pour faire émerger les détails importants.
Charlotte-développeur formalise les spécifications à suivre pour développer.
Charlotte-développeur développe.
Charlotte-PO montre le logiciel à ses utilisateurs et discute pour avoir des feedbacks.
Et elle recommence.
épisodes :
2 - pour découvrir le produit, il faut le construire
3 - le développeur en piste
4 - les utilisateurs seront ravis
7 - la PO n'est pas certaine, elle pourrait aller plus vite