Drupal et Scrum depuis les tranchées - Définir le périmètre du projet

De la raison d'être aux fonctionnalités

L'itération 0 est une itération particulière qui ne ressemble pas aux autres, c'est celle par laquelle tout débute et qui va servir à préparer la matière dont l'équipe a besoin pour démarrer les développements. Elle ne fait pas partie de la méthodologie Scrum "officiellement" car elle ne donne pas lieu à la livraison de fonctionnalités directes mais un cadrage est requis avant de pouvoir lancer les développements.
Au cours de l'itération 0 nous allons commencer par formaliser la raison d'être du projet. Verbalisation pour quoi et pour qui ce projet prend vie et va nous servir de cap lorsqu'il faudra arbitrer entre deux décisions (faut-il encore affiner l'algorithme de remontée des résultats de recherche VS basculer sur un autre thème fonctionnel ?).

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 fonctionnalités 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 complètes, elles ne sont que leur titre. Nous vous recommandons au cours de l'itération 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 compléter la rédaction. C'est le moment où nous allons préciser les critères d'acceptation et rédiger la description des fonctionnalités reprenant le modèle "En tant que [rôle utilisateur] je peux [action] afin de [but]" .

Les critères d'acceptation sont la liste des tests que le développeur et la cliente 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 fonctionnalité. Si par exemple des validations de format, des messages d'erreur / de confirmation doivent apparaître il faut le préciser à ce moment là.

N'oubliez pas qu'au cours de votre itération 0 nous ne devons pas écrire la liste exhaustive des fonctionnalités détaillées de tout le projet (titre, description et critères d'acceptation), ce serait un travail titanesque et surtout aberrant car la liste des priorités lors de l'itération 0 ne sera probablement pas la même que lors de l'itération 4 (autant éviter de travailler pour rien).
Il faut se contenter de préparer un nombre suffisant de fonctionnalités pour que l'équipe ait du travail au cours de l'itération 1 et nous assurer que la cliente s'est familiarisée avec le concept de fonctionnalité en mettant l'accent sur les critères d'acceptation qui seront la garantie 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 de l'itération 0 des fonctionnalités techniques doivent être intégrées, votre cliente 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 fonctionnalités telles que la gestion de l'arborescence du projet, le modèle des URLs à réécrire, les permissions, l'identification de modes d'affichage...
Rappelons-nous que notre cliente ne connaît 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 fonctionnalités (et du temps (une demie journée) si nous faisons cela au cours de l'itération 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 cliente que nous allons travailler ensemble (et qu'elle va devoir travailler elle aussi) et que nous n'allons pas être un prestataire qu'elle se contente de piloter. Ah et bien entendu nous pouvons dès maintenant lui annoncer qu'elle sera en retard pour livrer ses contenus !

TL;DR

• Votre interlocuteur(ice) doit connaître 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 structurer le périmètre initial du projet
• Rien ne sert de se précipiter, il suffit d'avoir un périmètre bien préparé pour l'itération 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 fonctionnalités seront testées vous en aurez la même lecture
• Ne pas oublier que Drupal impose ses propres fonctionnalités. (Création de fonctionnalités techniques et limitation des fonctionnalités utilisateurs)
• Aider la cliente autant que possible en lui proposant des exemples lorsque vous attendez des livrables de sa part.