Drupal et Scrum depuis les tranchées - Constitution du backlog produit

Une fois après avoir sauté de joie en apprenant que c'est avec nous que notre client tant convoité veut travailler, il faut se remettre au travail pour constituer la matière que les développeurs vont exploiter au moment de produire. Il va dès lors falloir que nous convertissions le cahier des charges de notre client en stories. Bonne nouvelle c'est à cela que sert le sprint 0.

Une fois après avoir sauté de joie en apprenant que c'est avec nous que notre client tant convoité veut travailler, il faut se remettre au travail pour constituer la matière que les développeurs vont exploiter au moment de produire. Il va dès lors falloir que nous convertissions le cahier des charges de notre client en stories. Bonne nouvelle c'est à cela que sert le sprint 0.

Pour les gens pressés : TL;DR.

De la vision aux stories

Le sprint 0 est un sprint particulier qui ne ressemble pas aux autres, c'est celui par lequel tout débute et qui va servir à préparer la matière dont l'équipe a besoin pour démarrer le premier sprint. Au cours du sprint 0 nous allons commencer par formaliser la vision du projet. La vision est la verbalisation de pour quoi et pour qui ce projet prend vie et va nous servir de cap lorsqu'il faudra arbitrer entre deux décisions (laquelle des deux options nous permet de servir au mieux la vision ?).

Il est ensuite possible de dresser le portrait de quelques personas, cette étape n'est pas obligatoire. Les personas sont l'incarnation des profils type d'utilisateurs de notre système, on dresse leur portrait-robot et leur donne un petit nom, ce qui rend plus simple dans nos stories de désigner Mélissa ou Philippe lorsque l'on évoque un administrateur ou un contributeur à notre site Drupal.

Nous voilà fin prêts à passer en revue le périmètre fonctionnel du projet. On va commencer par lister les grands sujets du projet identifiés dans le chiffrage ou le cahier des charges puis, pour chacun de ces domaines, détailler la liste des fonctionnalités. Toutes ces fonctionnalités ne sont pas encore des stories complètes, elles ne sont que leur titre. Nous vous recommandons au cours du sprint 0 d'essayer de dresser une liste assez exhaustive des fonctionnalités pour se rendre compte de l'ampleur du travail. Une fois cette liste établie il faut la prioriser par ordre de valeur ajoutée pour l'utilisateur final de la plus importante à la moins importante. Lorsque cette partie du travail est terminée, il suffit de repasser en revue les fonctionnalités les plus importantes pour en faire de vraies stories. C'est le moment où nous allons préciser les critères d'acceptation et rédiger la description des stories reprenant le modèle "En tant que [nom du persona ou de l'utilisateur] je peux [action] afin de [but]" .

Les critères d'acceptation sont la liste des tests que le développeur et le client vont dérouler lorsqu'ils vont valider qu'une fonctionnalité remplie ses besoins. Les critères d'acceptation listent ce que doit et ne doit pas faire une story. Si par exemple des validations de format, des messages d'erreur / de confirmation doivent apparaitre il faut le préciser à ce moment là.

N'oubliez pas qu'au cours de votre sprint 0 nous ne devons pas écrire la liste exhaustive des stories détaillées de votre projet (titre, description et critères d'acceptation), ce serait un travail titanesque et surtout abérant car la liste des priorités lors du sprint 0 ne sera probablement pas la même que lors du sprint 4 (autant éviter de travailler pour rien).
Il faut se contenter de préparer un nombre suffisant de stories pour que l'équipe ait du travail au cours du sprint 1 et nous assurer que le client s'est familiarisé avec le concept de story en mettant l'accent sur les critères d'acceptation qui seront la guarantie que nous nous entendons sur le fait qu'une fonctionnalité est terminée.

Drupal impose ses propres besoins

Il ne faut pas non plus omettre qu'au cours du sprint 0 des stories techniques doivent être intégrées, votre client doit comprendre que prévoir du temps pour concevoir une API, un composant technique important de son application, etc sont des étapes nécessaires toutes aussi indispensables que des choses directement utilisées par les utilisateurs finaux.

En plus de cela, Drupal va introduire ses propres stories telles que la gestion de l'arborescence du projet, le modèle des URLs à réécrire, les permissions, l'identification de view modes...
Rappelons-nous que notre client ne connait pas Drupal, si nous attendons de lui qu'il nous livre une liste de champs pour des types de contenu nous pourrions lui fournir un livrable d'exemple pour qu'il sache comment nous aider à avancer en économisant plusieurs aller retours.

Pensons à prévoir des stories (et du temps (une demie journée) si nous faisons cela pendant le sprint 0) pour la mise en place du dépôt, des éventuels scripts de déploiement ou de la configuration spécifique que pourrait nécessiter le processus d'industrialisation.

Cette première étape est l'occasion de rappeler à notre client que nous allons travailler ensemble (et qu'il va devoir travailler lui aussi) et que nous n'allons pas être un prestataire qu'il se contente de piloter. Ah et bien entendu nous pouvons dès maintenant lui annoncer qu'il sera en retard pour livrer ses contenus !

TL;DR

  • Votre interlocuteur doit connaitre son projet et être décisionnaire pour avancer
  • Le Cahier des Charges est important car c'est la matière première à partir de laquelle on va structure le backlog produit initial
  • Rien ne sert de se précipiter, il suffit d'avoir un backlog bien préparé pour le sprint 1, il restera du temps pour l'élargir et le compléter
  • Ne pas négliger les critères d'acceptation qui sont la garantie que vous savez comment faire les choses et que lorsque les stories seront testées vous en aurez la même lecture
  • Ne pas oublier que Drupal impose ses propres stories. (Création de stories de technique et limitation des users stories à l'aspect fonctionnel)
  • Aider le client autant que possible en lui proposant des exemples lorsque vous attendez des livrables de sa part.

Votre commentaire

Le contenu de ce champ sera maintenu privé et ne sera pas affiché publiquement.
Votre adresse servira à afficher un Gravatar et à vous notifier des réponses. Votre commentaire sera anonymisé si ce billet est dépublié pendant plus de 3 mois.

À propos de Julien

Co-fondateur - Scrum master & Expert technique

Utilisateur de Drupal depuis 2008, j’ai fait mes armes comme développeur chez Commerce Guys puis me suis mis à encadrer les nouveaux arrivants avant de donner des formations, participer aux avant ventes et accompagner les équipes au passage à Scrum.

Je suis impliqué dans la communauté française de Drupal depuis 2009, j’ai été tour à tour président puis vice-président de l’association Drupal France et francophonie entre 2011 et 2013.