De la fonctionnalité à la tâche
Avant de démarrer un sprint, l’équipe se réunit pour analyser les fonctionnalités en attente et déterminer le scope du prochain sprint. Mais pourquoi ne pas se dire “un sprint = une fonctionnalité” ?
Tout simplement car une fonctionnalité peut être très large et longue à mettre en oeuvre. Cela peut être, par exemple, “Compte utilisateur”. Or l’intérêt des méthodes agiles est justement de découper le projet en petites tâches plus faciles à planifier et à tester. Ces tâches sont appelées des “Stories” car elles sont écrites de manière à raconter une histoire.
Les Stories
Rappelez-vous de la première valeur du Manifeste : “Les individus et leurs interactions sont plus importants que les processus et les outils”. L’utilisateur est au coeur des méthodes agiles. Notre objectif, en tant qu’équipe de développement, est donc de créer un programme qu’il utilise vraiment. Avoir en tête l’utilisation de l’outil, plus que le nom d’une fonctionnalité, nous aide à garder en tête ce qui doit effectivement être produit.
Une Story est une action réalisée par l’utilisateur dans un certain but. Par exemple : “Linda veut cliquer sur “se connecter” pour accéder à son compte”.
Le première tâche est donc de découper une fonctionnalité en Stories. Dans notre cas, ça pourrait être :
“Linda veut cliquer sur “se connecter” pour accéder à son compte.”
“Linda veut cliquer sur “mon compte” pour voir ses informations personnelles.”
“Linda veut cliquer sur “modifier mes informations” pour changer son mot de passe.”
etc.
Écrire une User Story
Vous avez peut-être remarqué que j’ai construit mes phrases selon le même modèle.
“<En tant que>, je veux <faire une action> pour <résultat de l’action>”.
Écrire ses User Stories en suivant ce modèle vous permet d’être pragmatique et de visualiser très rapidement qui effectue l’action, l’action en elle-même et le résultat attendu.
Une User Story raconte une histoire et peut être réalisée en un sprint. La notion nous vient de l’Extreme Programming. Un des cofondateurs de la méthode, Ron Jeffries, propose d’ailleurs les trois caractéristiques suivantes :
La carte : toute User Story est représentée par une carte.
La conversation : le titre de la carte raconte une histoire.
La confirmation : le contenu de la carte détaille le résultat attendu et donc le moment où nous pouvons indiquer que la story est terminée.
Je savais bien que le pouvoir des trois me libèrerait un jour ! Ok je sors…
Vous pouvez ajouter d’autres détails importants dans la carte, comme des sous-tâches techniques par exemple.
Définir un planning
Chaque Story inclut également une estimation de sa complexité en nombre de points. Elle est calculée en équipe pendant un “planning poker”.
Chouette, on va jouer au poker ? Tu aurais dû nous le dire plus tôt !
Concrètement, le Scrum Master distribue un paquet de cartes à chaque développeur. Ce paquet n’a ni as ni roi mais la suite de Fibonacci (1, 2, 3, 5, 8, …). L’équipe pose des questions sur le contenu de la story puis chaque membre montre, en même temps, son estimation. L’équipe en discute et mise sur un chiffre.
Puis elle propose un planning. Évidemment, plus une story est complexe et plus il sera compliqué de prévoir la date de livraison. C’est pourquoi nous utilisons la suite de Fibonacci et non une suite linéaire.
Un membre se propose alors de réaliser la story et en devient responsable.
Découper en tâches
Le responsable de la story la découpe en tâches. Chaque tâche est un jour de travail. Si nous résumons, un sprint a une ou plusieurs stories qui ont elles-mêmes plusieurs tâches.
Quand tout ceci est prêt, nous pouvons commencer le sprint ! Houra !
Développer une story
Les étapes
Chaque story suit les mêmes étapes qu’un projet séquentiel mais à son échelle ! C’est-à-dire :
écriture des spécifications fonctionnelles,
écriture des spécifications techniques,
tests et code
Les spécifications fonctionnelles forment le manuel utilisateur. Commencer par détailler comment l’utilisateur se servira du programme aide le développeur à éclaircir toutes les étapes du développement. Ces spécifications sont souvent moins détaillées que dans le cadre d’un projet séquentiel.
Les spécifications techniques forment la documentation technique et sera très utile à toute l’équipe.
Coder et tester. Une bonne pratique de développement dans un projet agile est de commencer par écrire les tests puis d’écrire le code qui les valide. Il s’agit du Test Driven Development (TDD pour les intimes). C’est un mode de pensée très différent mais extrêmement puissant.
Les tests en agile sont très similaires à ceux utilisés dans les méthodologies séquentielles (tests unitaires et d’intégration). Laissez-moi vous présenter un petit nouveau : le test de confirmation.
Les tests de confirmation
Vous souvenez-vous des trois caractéristiques d’une story ? Carte, conversation et confirmation. Nous n’avons pas encore parlé de la dernière composante : la confirmation. En effet, comment le développeur peut-il être sûr que la story est terminée ? C’est le rôle du Product Owner de donner les conditions qui font que le développeur pourra passer à la story suivante.
Souvent, la confirmation coule de source car elle correspond à la User Story. Quand “Linda veut cliquer sur “se connecter” pour accéder à son compte.”, nous savons que la story est terminée quand elle peut effectivement le faire !
Mais quand la story est technique ou correspond à un bug, il peut être intéressant d’indiquer les conditions requises. Par exemple : “Recevoir les données de l’API Google Maps”.
Souvent, nous y faisons référence en les appelant “Tests de confirmation” car les développeurs font rarement la vérification à la main. Tout comme en séquentiel, ils vont configurer un robot qui va, comme un grand, tester que le programme remplit bien les conditions demandées.
La story est morte, vive la story !
Quand la story passe les tests de confirmation, elle est déclarée finie et son responsable la déplace dans la colonne “Done”.
Puis il passe à une nouvelle story qui fait partie du sprint en cours ! Quand les stories prévues pour la release sont finies, on met toutes les stories en ligne et on passe à un nouveau sprint.
En résumé, une story passe par les phases suivantes :
Proposition : un jour, une personne suggère une nouvelle fonctionnalité.
Acceptée : le Product Owner accepte la proposition et l’ajoute dans le backlog.
Estimée : l’équipe estime la taille de la story.
Prête : la story est écrite et estimée. Elle est en attente de développement.
En cours : l’équipe est en train de la développer.
Fini : elle est en ligne !
Les étapes peuvent être différentes selon les pratiques de chaque équipe. Le backlog de Brian Cervino ne montre pas les stories proposées mais ajoute les étapes intermédiaires suivantes : “Code Review” et “Test”.
Bravo, vous en savez maintenant plus sur la gestions de projet ! En vérité, il vous reste tout un monde à découvrir. Laissez-moi vous donner quelques pistes dans le chapitre suivant.
