Histoire (Français)

les Histoires agir comme un « jargon », où les deux côtés (les utilisateurs et les développeurs) peut convenir assez de travailler ensemble efficacement.

—Bill Wake, co-inventeur de la programmation extrême

Les histoires sont de courtes descriptions d’un petit morceau de fonctionnalité souhaitée, écrit dans la langue de l’utilisateur. Les équipes agiles mettent en œuvre de petites tranches verticales de fonctionnalités système et sont dimensionnées afin qu’elles puissent être complétées en une seule itération.,

Les Stories sont l’artefact principal utilisé pour définir le comportement du système dans Agile. Ce sont des descriptions courtes et simples de fonctionnalités généralement racontées du point de vue de l’utilisateur et écrites dans leur langue. Chacun est destiné à permettre la mise en œuvre d’une petite tranche verticale de comportement du système qui prend en charge le développement incrémental.

Les histoires fournissent juste assez d’informations pour que les gens d’affaires et les techniciens comprennent l’intention. Les détails sont reportés jusqu’à ce que l’histoire soit prête à être implémentée., Grâce aux critères d’acceptation et aux tests d’acceptation, les histoires deviennent plus spécifiques, aidant à assurer la qualité du système.

Les user stories fournissent des fonctionnalités directement à l’utilisateur final. Les histoires d’Enabler apportent une visibilité aux éléments de travail nécessaires pour soutenir l’exploration, l’architecture, l’infrastructure et la conformité.

le modèle D’exigences de SAFe décrit une hiérarchie à quatre niveaux d’artefacts qui décrivent le comportement fonctionnel du système: Epic, Capability, Feature et story. Collectivement, ils décrivent tout le travail pour créer le comportement prévu de la solution., Mais le travail de mise en œuvre détaillé est décrit à travers des histoires, qui constituent le Backlog de l’équipe. La plupart des histoires proviennent de fonctions commerciales et facilitatrices dans le carnet de commandes du programme, mais d’autres proviennent du contexte local de l’équipe.

Chaque histoire est un petit comportement indépendant qui peut être implémenté de manière incrémentielle et fournit une certaine valeur à l’utilisateur ou à la Solution. C’est une tranche verticale de fonctionnalités pour s’assurer que chaque itération offre une nouvelle valeur. Les histoires sont petites et doivent être complétées en une seule itération (voir la section diviser les histoires).,

souvent, les histoires sont d’abord écrites sur une fiche ou une note collante. La nature physique de la carte Crée une relation tangible entre l’équipe, l’histoire et l’utilisateur: elle aide toute l’équipe à écrire l’histoire. Les notes autocollantes offrent également d’autres avantages: elles aident à visualiser le travail et peuvent être facilement placées sur un mur ou une table, réarrangées dans l’ordre et même transmises si nécessaire., Les histoires permettent une meilleure compréhension de la portée et des progrès:

• « Wow, regardez toutes ces histoires pour lesquelles nous sommes sur le point de vous inscrire” (scope)
• « Regardez toutes les histoires que nous avons accomplies dans cette itération” (progress)

bien que tout le monde puisse écrire des histoires, les approuver dans le backlog de l’équipe et les accepter dans la ligne de base du système sont la responsabilité du Product Owner. Bien sûr, les stickies ne s’adaptent pas bien à l’ensemble de l’entreprise, de sorte que les histoires passent souvent rapidement dans les outils de gestion du cycle de vie Agile (Alm).,

Il existe deux types d’histoires dans SAFe, user stories et enabler stories, comme décrit ci-dessous.

Sources d’histoires

Les histoires sont généralement motivées par la division des fonctions métier et habilitantes, comme l’illustre la Figure 1.

articles de l’Utilisateur

les User stories sont le principal moyen d’exprimer les fonctionnalités nécessaires. Ils remplacent en grande partie la spécification des exigences traditionnelles., (Dans certains cas, cependant, ils servent à expliquer et à développer le comportement du système qui est ensuite enregistré pour prendre en charge la conformité, la traçabilité ou d’autres besoins.)

parce qu’elles se concentrent sur l’utilisateur en tant que sujet d’intérêt, et non sur le système, les User stories sont centrées sur la valeur. Pour supporter cela, la forme d’expression recommandée est la forme user-voice, comme suit:

en tant que (rôle Utilisateur), je veux (activité), de sorte que (valeur métier)

en utilisant ce format, les équipes sont guidées pour comprendre qui utilise le système, ce qu’elles en font et pourquoi elles le font., L’application du format « user voice » tend régulièrement à augmenter la compétence de l’équipe dans le domaine; ils en viennent à mieux comprendre les besoins réels de leur utilisateur. La Figure 2 fournit un exemple.

Les « Personas » décrivent les caractéristiques spécifiques des utilisateurs représentatifs qui aident les équipes à mieux comprendre leur utilisateur final. Exemple de personas pour le cavalier dans la Figure 2 pourrait être un amateur de sensations fortes « Jane » et un cavalier timide « Bob »., Les descriptions des histoires font ensuite référence à ces personnages (comme Jane je veux…).

bien que la voix de l’histoire de l’utilisateur soit le cas commun, tous les systèmes n’interagissent pas avec un utilisateur final. Parfois, l ‘ »utilisateur » est un périphérique (par exemple, une imprimante) ou un système (par exemple, un serveur de transactions). Dans ces cas, l’histoire peut prendre la forme illustrée à la Figure 3.

Enabler Stories

Les équipes peuvent avoir besoin de développer l’architecture ou l’infrastructure pour implémenter certaines user stories ou prendre en charge des composants du système. Dans ce cas, l’histoire ne peut toucher directement aucun utilisateur final. Ce sont des histoires facilitatrices et elles soutiennent l’exploration, l’architecture ou l’infrastructure. Les histoires de facilitateur peuvent être exprimées dans un langage technique plutôt que centré sur l’utilisateur, comme l’illustre la Figure 4.

Il existe de nombreux autres types d’histoires Enabler, notamment:

• Refactoring et Spikes (comme défini traditionnellement dans XP)
• création ou amélioration d’une infrastructure de développement/déploiement
• exécution de tâches nécessitant une interaction humaine (par exemple, indexer 1 million de pages web)
• création objectifs différents
• vérification des qualités du système (p. ex.,, performance and vulnerability testing)

Les histoires D’Enabler sont démontrées tout comme les histoires d’utilisateurs, généralement en montrant les connaissances acquises, les artefacts produits ou l’interface utilisateur, le stub ou la maquette.

écrire de bonnes histoires

Les bonnes histoires nécessitent plusieurs perspectives. Dans agile, l’ensemble de l’équipe – Product Owner, developers, and testers – crée une compréhension partagée de ce qu’il faut construire pour réduire le retravail et augmenter le débit. Les équipes collaborent en utilisant le Behavior-Driven Development (BDD) pour définir des tests d’acceptation détaillés qui décrivent définitivement chaque histoire., Les bonnes histoires nécessitent de multiples perspectives:

• Les propriétaires de produits fournissent aux clients une réflexion sur la viabilité et la désirabilité
• Les développeurs fournissent une faisabilité technique
• Les testeurs fournissent une réflexion générale sur les exceptions, les cas périphériques et d’autres façons inattendues d’interagir avec le système

L’écriture collaborative d’histoires garantit que toutes les perspectives sont prises en compte et que tout le monde s’accorde sur le comportement de l’histoire avec les résultats représentés dans la description de l’histoire, les critères d’acceptation et les tests d’acceptation., Les tests d’acceptation sont écrits en utilisant le langage de domaine du système avec le développement piloté par le comportement (BDD). Les tests BDD sont ensuite automatisés et exécutés en continu pour maintenir la qualité intégrée. Les tests BDD sont écrits en fonction de la configuration système requise (stories) et peuvent donc être utilisés comme déclaration définitive pour le comportement du système, remplaçant les spécifications basées sur des documents.,

the 3Cs: Card, Conversation, Confirmation

Ron Jeffries, l’un des inventeurs de XP, est crédité de décrire les 3CS d’une histoire:

• Card – capture la déclaration d’intention de l’histoire utilisateur à l’aide d’une carte d’index, d’une note autocollante ou d’un outil. Les fiches fournissent une relation physique entre l’équipe et l’histoire. La taille de la carte limite physiquement la longueur de l’histoire et les suggestions prématurées pour la spécificité du comportement du système., Les cartes aident également l’équipe à « sentir » la portée à venir, car il y a quelque chose de matériellement différent à tenir dix cartes dans sa main par rapport à regarder dix lignes sur une feuille de calcul.
• Conversation-représente une « promesse de conversation » sur l’histoire entre l’équipe, le client (ou le mandataire du client), le bon de commande (qui peut représenter le client) et d’autres parties prenantes. La discussion est nécessaire pour déterminer le comportement plus détaillé requis pour mettre en œuvre l’intention., La conversation peut générer une spécificité supplémentaire sous la forme de critères d’acceptation (la confirmation ci-dessous) ou de pièces jointes à l’histoire de l’utilisateur. La conversation couvre toutes les étapes du cycle de vie de l’histoire:
  • amélioration du Backlog
  • planification
  • mise en œuvre
  • Démo

ces discussions juste à temps créent une compréhension partagée de la portée que la documentation formelle ne peut pas fournir. La spécification par exemple remplace la documentation détaillée. Les Conversations aident également à découvrir les lacunes dans les scénarios utilisateur et les NFR.,

• Confirmation – les critères d’acceptation fournissent les informations nécessaires pour s’assurer que l’histoire est implémentée correctement et couvre les nfrs fonctionnels et pertinents. La Figure 5 fournit un exemple. Certaines équipes utilisent souvent la section de confirmation de la carte d’histoire pour écrire ce qu’elles vont faire.

Les équipes agiles automatisent les tests d’acceptation dans la mesure du possible, souvent dans un langage lisible par l’entreprise et spécifique au domaine., Automatisation crée une spécification exécutable pour valider et vérifier la solution. L’automatisation offre également la possibilité de tester rapidement la régression du système, ce qui améliore L’Intégration Continue, la refactorisation et la maintenance.,>Investir dans de bonnes histoires

le modèle INVEST, développé par Bill Wake , décrit les caractéristiques des bonnes histoires d’utilisateurs:

• I – indépendant (entre autres histoires)
• N – négociable (une déclaration d’intention flexible, pas un contrat)
• V – précieux (fournissant une tranche verticale précieuse au client)
• E – Estimable (petit et négociable)
• S – Petit (s’inscrit dans une itération)
• T – testable (assez compris pour savoir comment le tester)

estimation des histoires

les équipes agiles utilisent les story points et « estimating poker » pour valoriser leur travail ., Une histoire d’un point singulier qui représente une combinaison de qualités:

• Volume – Combien est-il?
• complexité – à quel point est-ce difficile?
• Connaissance – Ce qui est connu?
• incertitude-qu’est-ce qui est inconnu?

Les points D’histoire sont relatifs, sans lien avec une unité de mesure spécifique. La taille (effort) de chaque histoire est estimée par rapport à la plus petite histoire, qui se voit attribuer une taille de ‘un.’Une suite de Fibonacci modifiée(1, 2, 3, 5, 8, 13, 20, 40, 100) est appliqué qui reflète l’incertitude inhérente à l’estimation, en particulier les grands nombres (E.,g., 20, 40, 100) .

Estimating Poker

Les équipes agiles utilisent souvent « estimating poker », qui combine l’opinion d’experts, l’analogie et la désagrégation pour créer des estimations rapides mais fiables. La désagrégation consiste à diviser une histoire ou des éléments en éléments plus petits et plus faciles à estimer.

(notez qu’un certain nombre d’autres méthodes sont également utilisées.) Les règles d’estimation du poker sont:

• Les Participants comprennent tous les membres de l’équipe.
• Chaque estimateur est donné un jeu de cartes 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, et,?
• Le PO participe mais n’estime pas.,
• Le Scrum Master participe mais n’estime pas, sauf s’il effectue un travail de développement réel.
• pour chaque élément de l’arriéré à estimer, le PO lit la description de l’histoire.
• Les Questions sont posées et on y répond.
• chaque estimateur sélectionne en privé une carte d’estimation représentant son estimation.
• toutes les cartes sont retournées en même temps pour éviter les biais et rendre visibles toutes les estimations.
• les estimateurs haut et bas expliquent leurs estimations.
• après une discussion, chaque estimateur ré-estime en sélectionnant une carte.,
• Les estimations convergeront probablement. Si pas, le processus est répété.

une certaine quantité de discussion de conception préliminaire est appropriée. Cependant, passer trop de temps sur les discussions de conception est souvent un effort gaspillé. La valeur réelle de l’estimation de poker est de parvenir à un accord sur la portée d’une histoire. Il est aussi amusant!

vélocité

la vélocité de l’équipe pour une itération est égale à la somme des points pour toutes les histoires terminées qui répondaient à leur définition de Done (DoD)., À mesure que l’équipe travaille ensemble au fil du temps, leur vitesse moyenne (points d’histoire terminés par itération) devient fiable et prévisible. La vitesse prévisible aide à la planification et aide à limiter le travail en cours (WIP), car les équipes ne prennent pas plus d’histoires que leur vitesse historique ne le permettrait. Cette mesure est également utilisée pour estimer le temps nécessaire pour fournir des épopées, des fonctionnalités, des capacités et des facilitateurs, qui sont également prévus à l’aide de story points.

Capacité

la Capacité est la partie de l’équipe de la vitesse qui est réellement disponible pour une itération donnée., Les vacances, la formation et d’autres événements peuvent rendre les membres de l’équipe indisponibles pour contribuer aux objectifs d’une itération pendant une partie de l’itération. Cela diminue la vitesse potentielle maximale pour cette équipe pour cette itération. Par exemple, une équipe ayant une moyenne de 40 points par itération ajusterait sa vitesse maximale à 36 si un membre de l’équipe est en vacances pendant une semaine. Sachant cela à l’avance, l’équipe ne s’engage qu’à un maximum de 36 points d’histoire lors de la planification de l’itération., Cela aide également lors de la planification PI à prévoir la capacité disponible réelle pour chaque itération dans le PI afin que l’équipe ne s’engage pas trop dans la construction de ses objectifs PI.

base de départ pour L’Estimation

dans Scrum standard, l’estimation du point d’histoire de chaque équipe—et la vitesse résultante—est une préoccupation locale et indépendante. À grande échelle, il devient difficile de prédire la taille du point d’histoire pour les grandes épopées et les fonctionnalités lorsque les vitesses de l’équipe peuvent varier considérablement., Pour surmonter cela, les équipes sûres calibrent initialement une ligne de base de point d’histoire de départ où un point d’histoire est défini à peu près de la même manière pour toutes les équipes. Il n’est pas nécessaire de recalibrer l’estimation ou la vitesse de l’équipe. L’étalonnage est effectué une seule fois lors du lancement de nouveaux trains de Versions agiles.

Les story points normalisés fournissent une méthode pour arriver à une base de départ convenue pour les stories et la vélocité comme suit:

• donnez à chaque développeur-testeur de l’équipe huit points pour une itération de deux semaines (un point pour chaque journée de travail idéale, en soustrayant 2 jours pour les frais généraux).,
• soustrayez un point pour chaque jour férié et jour férié des membres de l’équipe.
• trouvez une petite histoire qui prendrait environ une demi-journée à coder et une demi-journée à tester et valider. Appeler un ».‘
• estimez toutes les autres histoires par rapport à celle-là.’

exemple: en supposant une équipe de six personnes composée de trois développeurs, deux testeurs et un PO, sans vacances ou vacances, alors la vitesse initiale estimée = 5 × 8 points = 40 points/itération. (Remarque: ajuster un peu plus bas peut être nécessaire si l’un des développeurs et testeurs est également le Scrum Master.,)

de cette façon, les points d’histoire sont quelque peu comparables entre les équipes. La direction peut mieux comprendre le coût d’un story point et déterminer plus précisément le coût d’une fonctionnalité à venir ou d’un epic.

alors que les équipes auront tendance à augmenter leur vitesse au fil du temps—et c’est une bonne chose— en réalité, le nombre a tendance à rester stable. La vitesse d’une équipe est beaucoup plus affectée par l’évolution de la taille de l’équipe et du contexte technique que par les variations de productivité.,

fractionnement D’histoires

Les histoires plus petites permettent une mise en œuvre plus rapide et plus fiable, car les petits éléments traversent n’importe quel système plus rapidement, avec moins de variabilité et un risque réduit. Par conséquent, diviser de plus grandes histoires en plus petites est une compétence obligatoire pour chaque équipe Agile. C’est à la fois l’art et la science du développement progressif. Dix façons de diviser les histoires sont décrites dans les exigences logicielles agiles de Leffingwell ., Voici un résumé de ces techniques:

• étapes du flux de travail
• variations des règles métier
• effort majeur
• Variations simples/complexes
• dans les données
• méthodes de saisie des données
• qualités différées du système
• opérations (ex., Créer, Lire, mettre à jour, Supprimer )
• scénarios de cas D’utilisation
• pic de rupture

La Figure 6 illustre un exemple de fractionnement par scénarios de cas d’utilisation.

histoires dans le modèle SAFe Requirements

comme décrit dans L’article SAFe Requirements Model, le cadre applique un ensemble étendu d’artefacts et de relations pour gérer la définition et les tests de systèmes complexes de manière La Figure 7 illustre le rôle des histoires dans ce tableau plus vaste.

à l’échelle, les stories sont souvent (mais pas toujours) créées par de nouvelles fonctionnalités. Et chaque histoire a des tests d’acceptation et des tests unitaires probables. Les tests unitaires servent principalement à s’assurer que la mise en œuvre technique de l’histoire est correcte. En outre, il s’agit d’un point de départ essentiel pour l’automatisation des tests, car les tests unitaires sont facilement automatisés, comme décrit dans L’article Test-Driven Development (TDD).

en savoir plus

Leffingwell, doyen., Exigences logicielles agiles: pratiques D’exigences Lean pour les équipes, les programmes et l’entreprise. Addison-Wesley, 2011. Cohn, Mike. User Stories Appliqué: Pour Le Développement De Logiciels Agiles. Addison-Wesley, 2004.

Dernière mise à jour: 17 décembre 2019