Comme connu chez les agilistes, et dans le monde de développement des produits et applications en agile, on n'utilise pas un cahier de charge comme le cas dans l'approche traditionnelle, mais plutôt un "Product Backlog" qui est l'outil de collecte et de partage de l'ensemble du travail à faire par l'équipe de développement.
Lors des formations agiles et plus précisément "Scrum" J'entend souvent la phrase suivante : "Dans le Product Backlog on ne doit mettre que les demandes fonctionnelles autrement dit les User Stories", alors que c'est pas vrai, car il y a des situations où l'équipe de réalisation peut passer du temps sur des demandes techniques, de recherche, et d'analyse, du coup quel type de travail doit-on mettre exactement dans le Backlog ?
En fait, Il existe plusieurs types de demandes et tâches à insérer dans le Product Backlog,en occurrence :
Les "User Stories" contenant du code (Demandes fonctionnelles qui ajoutent de la valeur métier).
Les "User Stories" sans code à créer (Demandes fonctionnelles qui ajoutent de la valeur sans ajouter du code : Paramétrage d'une application, assistance téléphonique d'un utilisateur final, ...Etc.).
Les demandes de la "Dette technique" (Organisation du code existant, et remaniement à faire).
Les "Technical Stories" (Demandes techniques : Paramétrage serveur, installation, développement des composants techniques, ...Etc.).
Les "Bugs" (Anomalies à corriger pour rétablir de la valeur métier perdue).
Les "Spikes" (Demandes d'analyse et de recherche).
Les "Explorer" (Demande de découverte d'un outil par exemple ou une nouvelle version d'un logiciel).
Le contenu d'un Sprint peut contenir les différents types de demandes citées ci-dessus selon l'ordre de priorité du Backlog.
Le Pattern "Storyotype" permet aux équipes Scrum de savoir quoi mettre exactement dans le Backlog comme type de demandes, ainsi que de consiste à regrouper un ensemble de Stories partageant la même liste de la "D.o.D" (Definition Of Done).
Comme déjà indiqué de ma part dans l'article associé à la "D.o.D" et "D.o.R", la "Definion Of Done" est spécifiques à chaque équipe selon le contexte et l'environnement de travail associé, du coup si on utilise le Pattern Storyotype, cette définition doit être personnalisé pour chaque type de demande existant dans le Product Backlog, ainsi que pour chaque niveau à part si c'est souhaité par l'équipe (User Story, Feature, Sprint, Release, ...Etc.).
Conclusion :
Même si la gestion du "Product Backlog" est allouée au Product Owner, mais l'équipe de développement, ainsi que les parties prenantes doivent collaborativement aider et participer à la mise à jour et l’organisation de cet artefact Scrum.
L'utilisation du Pattern "Storyotype" va faciliter le travail de l'équipe Scrum afin d'avoir un "Product Backlog" propre, organisé, bien ordonné, réduit, vivant, public, émergent, et contenant l'ensemble du travail nécessaire pour le produit ou l'application concernée.
Comments