Les éléphants ne sont pas des girafes et les user stories ne sont pas des exigences. Ils ont des caractéristiques communes et un contexte commun, mais cela ne les assimile pas. Cependant, beaucoup de gens pensent que les user stories sont une sorte de nouvelle lecture de ce que l'on appelle traditionnellement les exigences logicielles - après tout, il doit y avoir des exigences sur un projet, n'est-ce pas? Alors, je vais répondre - non, et encore non . Premièrement, ce ne sont pas des exigences, et deuxièmement, les exigences ne sont pas ce dont nous avons vraiment besoin. Les user stories sont, tout d'abord, l'occasion de voir différentes options d'implémentation afin de pouvoir ensuite profiter des opportunités qui se sont ouvertes. Et les exigences ... c'est de tout résoudre à l'avance, pour que plus tard, vous vous enlisiez dedans.
Est-il utile d'écrire un tel article? Cela ne semble-t-il pas évident? Non, je crois que des déclarations fréquentes comme «les exigences dans l'arriéré» indiquent que le paradigme de la pensée reste le même, seuls les signes ont changé. Le document d'exigences a commencé à s'appeler le backlog, les exigences elles-mêmes - les user stories, et maintenant nous sommes «agiles» ...
Un autre signe de malentendu possible est la pratique répandue de stocker les user stories dans la base de données avec l'attribution d'un identifiant unique. Il est possible que cela soit fait uniquement pour des raisons de commodité, mais il est possible que cela soit le résultat d'une tendance persistante à penser en termes d'exigences.
Mais la pratique consistant à inclure des user stories dans un contrat est déjà un signe à 100% que les user stories sont considérées comme des exigences. Le problème ici est qu'une user story, par définition, ne peut pas être aussi claire qu'une exigence, et cela dévalorise le contrat. Bien sûr, les exigences peuvent parfois aussi être interprétées assez librement, mais la technique même de les rédiger implique dans un premier temps l'élimination de l'ambiguïté, ce qui ne peut être dit des user stories. De plus, les exigences résistent au changement puisqu'elles sont incluses dans les contrats de projet. Afin de modifier ou d'ajouter de nouvelles exigences, elles doivent être transmises via le CCB . En d'autres termes, les parties prenantes doivent d'abord s'entendre et approuver. Voir ci-dessous pour plus de détails sur les contrats.
Alors, que sont les user stories? Considérez-les comme un outil de planification. À l'aide des user stories, nous priorisons, évaluons et décidons dans quel sprint la fonctionnalité correspondante sera implémentée. Ce sont toutes des caractéristiques typiques d'un outil de planification, alors n'essayez pas de les transformer en autre chose.
Le pouvoir des user stories est de donner lieu au dialogue. Au lieu de simplement prendre et transmettre à des collègues une spécification, qui est interprétée d'abord par les développeurs, puis par les testeurs, nous commençons une discussion. Nous incluons des employés ayant différentes compétences en communication. Et donc - pour chaque nouvelle fonctionnalité.
Comme la user story, en tant que telle, n'a pas beaucoup de sens, nous pouvons simplement la rejeter après la mise en œuvre de la fonctionnalité correspondante. Si vous le souhaitez, vous pouvez soigneusement garder des statistiques sur le nombre d'histoires réalisées, mais cela peut être assez limité.
Il s'avère que nous n'avons pas besoin d'exigences? En fait, ce n'est pas vrai. Après tout, d'une manière ou d'une autre, il y a des restrictions. Par exemple, l'équipement médical doit être conforme aux réglementations FDA . Alors appelons-les contraintes!
Et pourtant, les exigences décrivent le système en détail, peut-être y a-t-il une valeur pour nous dans une telle description? Par exemple, comment déterminer si un comportement du système est un bogue ou non, si nous n'avons pas d'exigences formelles présentées sous une forme ou une autre? La technique "Spécification par l'exemple" nous aidera ici. Il a donc été décidé que certaines fonctionnalités devraient être implémentées. Vous rédigez des règles métier et une série d'exemples de telle manière qu'ils soient: a) faciles à lire; b) réalisable. À partir de cette description, il devrait être clair ce que le système doit faire. Et aussi, si quelque chose ne va pas à la suite de changements - la violation de quelle règle commerciale était la cause de ce dysfonctionnement.
Comme je l'ai écrit plus tôt, la description du bogue doit être simple et claire. Les bogues sont des choses qui détruisent des informations, et ils sont mauvais que nous ayons une description d'exigence qui couvre un cas donné ou non.
Contrat
(par Matthias Skarin)
Alors qu'allons -nous utiliser à la place de la spécification des exigences? Après tout, nous devons comprendre si nous avons mis en œuvre exactement ce qui était nécessaire? Nous utiliserons des contrats agiles. Agile - les contrats sont l'occasion de voir la forêt pour les arbres, ils vous permettent de vous concentrer sur l'essence du projet et la réalisation conjointe de l'objectif, dont la mise en œuvre satisfera les besoins des utilisateurs.
Gardez à l'esprit que lorsque vous pensez au contrat pendant le projet afin de vérifier si votre partenaire a violé quelque chose, cela signifie déjà que quelque chose ne va pas. Le contrat doit instaurer la confiance entre les parties pour qu'il soit possible d'aller au-delà des détails et de ne pas s'enliser dans ceux-ci.
Résumé
- Malgré le fait que l'éléphant et la girafe ont quatre pattes, ce sont des animaux différents.
- Les user stories ne sont pas des exigences, mais un outil de planification.
- La spécification par l'exemple est la chose la plus proche des exigences.