Le besoin lié aux User Stories

Lorsque l’on démarre un projet de développement, exprimer les besoins, les contraintes et exigences sont généralement la première étape. De plus, c’est probablement l’une des étapes les plus importantes du projet, étant donné qu’une mauvaise gestion de cette étape peut avoir un impact négatif sur la manière de s’organiser, mais aussi sur l’architecture du code.

Cependant, il est généralement accepté qu’écrire un gros pavé, de plusieurs centaines de pages de spécification de doc techniques, devient très rapidement obsolète et inexploitable. Comme la technologie de nos jours, les projets de développement sont amenés à changer et évoluer, à une vitesse très soutenue.

C’est pourquoi dans les méthodes Agiles, les gens ne veulent pas passer du temps sur l’écriture et la conception de spécifications qui pourraient être potentiellement utilisée dans 6 mois (et qui seraient bien entendu devenues obsolètes d’ici là), mais préfèrent décrire de manière sommaire leurs besoins, très souvent sous forme d’User Stories.

Vous pouvez créer une nouvelle User Story depuis de nombreux endroits sur Azure Boards. L’un des plus rapides se situe sur la page du Backlog, depuis laquelle vous pouvez créer une User Story juste en précisant son nom.

Vous pouvez ensuite organiser votre projet en priorisant les User Stories, ainsi qu’en traçant les roadmaps de vos Sprints, durant lesquels vous implémenterez vos User Stories, avec un peu de chance 😊.

Les spécifications dans la méthode Agile

En tant que développeur, on peut comprendre que personne n’a envie de perdre du temps à écrire un pavé de spécifications, qui seront obsolètes en un rien de temps, parfois avant même le début du projet. Pourtant, lorsque l’on s’attaque à une tâche de développement, s'il est appréciable de bénéficier d'une certaine liberté sur les sujets techniques pour laisser s'exprimer son expérience et sa créativité, avoir trop de liberté peut amener à faire des hypothèses bien souvent fausses, ou à minima différentes de ce que l’utilisateur souhaitait.

Je vous laisse donc deviner : Oui, il y a probablement un curseur à régler entre pondre un pavé de spécifications à n’en plus finir, et avoir 2 lignes écrites sur un post-it pour exprimer un besoin.

Du coup, il semble évident qu’à un moment, nous allons avoir besoin de spécifications détaillés avant de pouvoir démarrer une tâche de développement avec une vision claire de ce qui doit être fait, et également aligné avec ce que le client souhaite. La question qui subsiste, dans un contexte de méthodes Agiles : qui doit prendre en charge ce sujet, et quand ?

Le product owner, gardien du savoir

Bon, le titre gâche la surprise, mais dans une méthode Agile, c’est bien le Product Owner qui a la charge de produire des spécifications détaillées d’un point de vue fonctionnel.

Cependant, c’est une tâche extrêmement chronophage, et le plus grand défi est de réussir à les produire suffisamment en avance pour que l’équipe ait le temps de les revoir et de s’organiser en fonction d’elles, mais pas trop en avance pour ne pas perdre du temps et de l’énergie sur des détails de spécifications qui vont être dépriorisées, modifiées ou pire, abandonnées.

En général, on essaie toujours de garder l’équivalent d’un ou deux sprints d’User Stories d'avance (i.e. sans compter le sprint courant). Ces User Stories doivent être suffisamment détaillées pour permettre d’optimiser l’organisation d’un Sprint en permutant une ou plusieurs User Stories en cas d’urgence fonctionnelle ou technique inattendue.

Pour détailler une User Story, on peut écrire dans les champs Description, Critère d’acceptation, ajouter un lien vers un fichier ou encore l’ajouter en tant que pièce jointe d’une User Story

Cependant, suivant le niveau de compréhension technique du product owner, avoir une « revue technique » sur chaque User Story est généralement une bonne pratique.

Revue technique et estimation

Faire en sorte que les User Stories soient relues par les développeurs est très important, étant donné qu’il est crucial de comprendre parfaitement le besoin derrière chacune pour pouvoir fournir la meilleure solution technique. C’est également très souvent le moment où de nombreuses questions non anticipées par le product owner surgissent. Et c’est souvent également un bon moment pour saisir un ordre de grandeur de la complexité à implémenter la User Story sous forme de Story Point ou d’Effort, ce qui permet au product owner de prioriser son backlog avec cette information complémentaire.

Glisser-déposer des User Stories sur la page du Backlog pour les prioriser en fonction des Story Points et Efforts

Suivant le niveau de maturité de l’équipe, cette revue peut être effectuée en amont d’un Sprint, ou bien pendant le Sprint Planning. La première solution a pour avantage de permettre de se focaliser sur les détails techniques durant le Sprint Planning, tandis que la seconde solution permet d’optimiser le temps passé sur les spécifications.

Conclusion

Finalement, faire un « gros cahier épais de spécifications » n’est plus vraiment la meilleure solution dans un monde changeant aussi rapidement de nos jours. De l’autre côté, le manque de détails fonctionnels disponibles quelques semaines avant le début du Sprint peut également avoir un impact négatif sur l’organisation de l’équipe.

En bref, trop d’anticipation n’est pas bon, mais aucune anticipation n’est pas envisageable non plus

Que le code soit avec vous !