La taille compte, même lorsque vous êtes Agile

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : Sven aka MrSnow76
Source : Size Does Matter - even when you're Agile
Date : 12/10/2014


Traducteur : Fabrice Aimetti
Date : 11/11/2018


Traduction :

Salut la compagnie,

Au cours des dernières années, lorsque j'ai travaillé avec des équipes ou des organisations, j'ai souvent remarqué qu'il était difficile de définir la taille des exigences.

Avant de commencer à parler du monde du logiciel, prenons un exemple assez simple.

Obtenir de la nourriture. Et pour rester simple, nous n'utilisons que des fruits à partir de maintenant.

L'exercice des fruits

Si vous avez besoin de nourriture pour une personne, les choses doivent être claires.
Vous avez besoin d'une pomme, d'une banane, de cerises ou de raisins et vous êtes prêt.

Fruits-1.jpg

Achèteriez-vous 3 pastèques pour une personne ? En fait non.

Pour nourrir une famille, vous aurez besoin d'un peu plus. Alors vous allez chercher un gros melon, un sac de bananes, un sac de pommes, quelques oranges et le tour est joué.

Et si maintenant, vous organisez une grande fête pour toutes les générations de votre famille, du grand-père aux petits-enfants ?
Vous ne penseriez plus aux simples pommes, mais vous compteriez en cageots.

Pensons plus grand. Vous organisez une grande fête dans votre club sportif et vous supposez que 500 à 700 personnes viendront, ce sera dans 2 ou 3 mois. Que voudriez-vous acheter ? Avez-vous des données empiriques pour savoir ce dont vous auriez besoin ? Difficile, non ?

Fruits-2.jpg

Vous avez assez de fruits. Nous y reviendrons plus tard.

Même dans le développement logiciel Agile, vous planifiez.
Et il existe différents niveaux de planification.

5 niveaux de Planification Agile

Vision (1-3 ans)

La vision est la raison pour laquelle nous développons la prochaine version de notre/nos produit(s) actuel(s). Elle fournit une orientation à tous les participants du portefeuille pour un alignement à long terme.

Roadmap / Feuille de route - Portefeuille (1/2 à 1 année)

En fonction de la taille de votre entreprise, vous pouvez avoir un portefeuille complet de produits différents. Certains pourraient avoir des dépendances entre eux. La planification du portefeuille dépend de la cadence des versions, mais elle est généralement effectuée moins souvent que la planification des versions.

Version (plusieurs par an)

L'objectif à long terme s'accompagne de certains éléments clés qui doivent être créés pour atteindre l'objectif. Ces éléments sont analysés et décomposés pour être implémentés dans les versions. Je vais expliquer dans un instant ce que sont ces éléments et comment nous les appelons en Agile.

Sprint (1 à 4 semaines)

Un sprint définit la quantité de travail qu'une équipe multi-fonctionnelle peut effectuer dans la cadence du sprint. Les équipes Scrum utilisent généralement 2 semaines, mais la plage va de 1 à 4 semaines.

Jour

Même par jour, nous planifions en Agile. Vous avez peut-être entendu parler d'une activité appelée la Mêlée Quotidienne. Dans d’autres courants Agile, la planification peut même être effectué plusieurs fois par jour, par exemple en Kanban, lorsque vous vous efforcez de limiter le travail en cours et de le livrer rapidement.

Tout est dans la façon de dimensionner les choses

Sizes in Agile-001 fr.png

Regardez le schéma pour comprendre les différents artefacts de la planification, leurs tailles et leurs noms.

Ce n'est pas une liste officielle et la plupart des noms autres que Story sont souvent confondus et utilisés là où il n'y a pas lieu d'être.

Mais quel est le lien avec les 5 niveaux de planification ?!
Quels noms utiliser dans quel contexte ?

Sizes in Agile-002 fr.png

Règle empirique pour dimensionner


Vous trouverez ci-dessous les règles que j'utilise pour travailler avec des équipes.
Si vous pouvez et devez les utiliser dans votre contexte de travail, cela dépend totalement de l’environnement dans lequel vous travaillez.
Si vous n'avez qu'une seule équipe et aucun objectif commercial à long terme, vous pourriez également avoir uniquement besoin de Features et de Stories. Certaines équipes ne décomposent pas les Stories en Tâches, car leur Product Owner découpe les découpe suffisamment de petite taille pour être mises en oeuvre dans un délai de 1 à 3 jours.

Lorsque vous travaillez dans une domaine où vous devez effectuer la Planification de Portefeuille, il est assez important de ne pas confondre les différentes tailles d'éléments de travail.
Dans la Vision et la Planification de la Feuille de route, souvent, seuls les termes Feature, Epic et Thème sont utilisés.
Ceci est fait pour cacher la grande complexité d'avoir des centaines de Stories et pour garder une vue globale de bonne qualité.

Lorsque vous effectuez la Planification des Versions, vous souhaitez savoir quand vous obtiendrez les Features A, B et C, mais vous n'êtes pas intéressé par les Tâches que l'équipe a définies dans les Stories.

Une Story pourrait être une Feature, mais pas une Epic

Les Features et les Epics sont les mêmes pour certaines personnes. J'aime les distinguer.
Le format permettant de décrire n'importe quel élément de travail en Agile peut être exactement le même : "EN TANT QUE ..., JE SOUHAITE ..., POUR QUE ...". Cela les rend très difficile à différencier. C'est pourquoi j'aime utiliser des post-it de couleurs différentes pour signaler ce qu'est une Story et ce qu'est une Feature ou une Epic.

En discutant d'une Story, vous découvrirez peut-être qu'elle est trop grosse pour tenir dans un Sprint et qu'elle est donc une Feature, vous la découpez alors en plusieurs Stories que vous pouvez ensuite implémenter Sprint par Sprint.

Un exemple pour un Epic serait : "Implémenter la caisse pour une Boutique en ligne".
Cela pourrait se décomposer en Features telles que "Choisir le moyen de paiement, Fournir l'adresse de livraison, Afficher la page de confirmation".
Les Stories pourraient être "Ajouter le mode de paiement Paypal, le paiement par carte de crédit, le paiement sur facture".

Rules of thumb sizes fr.png

Qu'est-ce que tout cela a à voir avec les fruits ?

Alors pourquoi diable ai-je commencé à parler de fruits ?
Eh bien, l’alimentation humaine est un concept beaucoup plus facile à comprendre que la taille des besoins en développement logiciel.
v Bien qu'il soit tout à fait facile de définir le nombre de fruits dont vous aurez besoin pour une personne, il est déjà un peu plus complexe de trouver la quantité de travail appropriée pour une journée ou de dimensionner correctement une Tâche.

Trouver la bonne quantité de Stories pour un Sprint est déjà bien plus difficile que de nourrir une famille complète avec des fruits.

Lorsque vous réfléchissez à organiser une grande fête pour 500 à 700 personnes, pensez-vous qu'il s'agisse de pommes individuelles ou de sacs ? Ou préférez-vous acheter directement des cageots ?
C'est la même chose pour la Planification de Versions. Vous ne parlez pas de Tâches ou de Stories. Vous voulez réaliser des Features / Epics.

Lorsque vous commencez avec une vision à long terme (2 à 3 ans), que faites-vous en premier ?
Aucune idée ? Eh bien, vous pouvez commencer par décomposer les éléments en tailles que vous pourrez gérer, par exemple des Thèmes et des Epics, les prioriser ensuite en fonction de leur criticité, de leur valeur métier, du coût du retard, puis les planifier dans le flux.

Et puis vous commencez à définir la première Version où vous décomposez les Epics en Features et les Features en Stories. À partir de là, vous faites cela de manière continue, Version après Version, en ajustant votre Feuille de route en fonction de la situation du Marché et des exigences en constante évolution.
J'espère que cela vous a permis de mieux comprendre la façon dont les éléments de travail sont dimensionnés lorsque vous utilisez Scrum.

La prochaine fois que vous parlerez d’éléments de travail, vous saurez quel terme utiliser au bon moment.
Et si vous parlez à quelqu'un qui ne comprend pas, indiquez-lui cet article pour qu'il puisse le lire.

Fruits-3.jpg
Ne mélangez pas des pommes avec des poires ;) ou des Stories avec des Tâches / Features.

Si l'un des concepts expliqués ici n'a pas de sens ou si vous utilisez un vocabulaire complètement différent, laissez-moi un commentaire ou un Tweet @MrSnow76

Merci pour la lecture de cet article,
Sven aka MrSnow76