Story-Splitting-b-agile

C’est donc plus ou moins une question de goût si vous préférez un diagramme de cas d’utilisation graphique ou une liste d’histoires d’utilisateurs (textuelles).

Permettez-moi de résumer la discussion sur la structuration des exigences dans le grand: Indépendamment de la notation, une décomposition d’un gros problème en processus déclenché de l’extérieur est le moyen le plus neutre de parvenir à cette décomposition. Il n’est basé sur aucune structure interne des systèmes (pas ses fonctions, pas ses sous-systèmes, pas ses objets,.,,) mais uniquement sur les besoins de l’environnement.

Cela ne veut pas dire que les autres stratégies de décomposition mentionnées ci-dessus ne fonctionnent pas, mais seulement une suggestion pour ne pas rester coincé dans les discussions structurelles internes.

Diviser dans le petit

Comme vous pouvez le voir dans l’exemple simple du système de navigation ci-dessus ce processus (indépendamment de la notation que vous préférez) semble encore trop complexe pour être implémenté en une seule itération. Vous devez absolument le décomposer en plus petits morceaux. Lawrence (https://agileforall.com/resources/how-to-split-a-user-story/) a suggéré plusieurs façons de s’attaquer à de plus gros morceaux et de les diviser en histoires suffisamment petites pour une itération.

Alors que les méthodes classiques suggéraient principalement de mieux comprendre un processus complexe en regardant sa séquence d’étapes, nous sommes maintenant confrontés à un problème supplémentaire dans le monde agile: nous voulons créer de la valeur à chaque itération, c’est-à-dire proposer des incréments de produits potentiellement expédiables. Il ne suffit pas de décomposer un grand processus (un cas d’utilisation ou une grande histoire) pour mieux le comprendre. Après la décomposition, chacune des pièces doit encore fournir une certaine valeur à l’utilisateur indépendamment des autres pièces.

Cela empêche les divisions techniques telles que la division en couches techniques telles que l’interface utilisateur, la fonctionnalité du domaine et la couche de persistance, car l’implémentation de la couche de persistance en premier (c’est-à-dire la création de tables de base de données) ne fournit aucune valeur métier tant que vous ne pouvez pas les remplir et les afficher. La même chose est souvent vraie pour la décomposition pure des processus métier en ses étapes : la mise en œuvre de la seule étape 7 d’un processus complexe peut ne pas apporter de valeur tant que les étapes précédentes et ultérieures ne sont pas là.

(Juste une remarque historique intéressante sur les guerres terminologiques entre méthodologistes: Mike Cohn s’est plaint que les histoires d’utilisateurs ne sont pas des cas d’utilisation simplement en utilisant l’argument: Elles peuvent être trop grandes pour les implémenter en une seule itération. Ivar Jacobson a accepté cet argument sur la taille, mais revenez en arrière en affirmant que les “tranches de cas d’utilisation” sont une bien meilleure façon de penser que de travailler avec des histoires d’utilisateurs suffisamment petites, car les tranches de cas d’utilisation fournissent une valeur de bout en bout.)