Je sais qu'un propriétaire de produit devrait écrire une histoire d'utilisateur dans Scrum.

Une user story décrit une fonctionnalité pour l'utilisateur final.

Mais qui décrit ce qui doit être développé techniquement et comment cela doit être mis en œuvre

et où sont stockées ces informations concernant la mêlée?

Cela m'intéresserait vraiment!

Je constate un grand manque de connaissances dans notre entreprise lorsque les développeurs commencent à implémenter l'histoire mais ils ne savent pas COMMENT l'implémenter!

Par exemple, ils doivent gérer une API COM héritée et ne savent pas comment la gérer, ou ils ne sont pas très compétents sur le plan technique avec WPF / WEB ou autre.

Comment Scrum aide-t-il les gens à commencer avec la user story?

Non-agile-hater ici. Développer les détails de la mise en œuvre et déterminer les tâches à effectuer se produit lors de la réunion de planification du sprint, qui transformera les user stories en tâches / exigences réelles pour le sprint. L'échec de nombreux processus agiles est que la réunion de planification du sprint est en fait censée être faite en grande partie par les développeurs ... si ce ne sont que les propriétaires de produits, ils décideront simplement d'obtenir la lune. C'est là que vous trouveriez une histoire d'utilisateur (plutôt nébuleuse) comme:

As a non-technical user, I need to have a simpler interface with the API

Alors que le propriétaire du produit définit les user stories qui ont la priorité la plus élevée, les programmeurs prennent ces priorités et les transforment en une liste de tâches (appelée le backlog de sprint). C'est là que vous avez une idée de la façon dont vous allez mettre en œuvre les choses ... le backlog de sprint peut être aussi technique que vous le souhaitez. C'est également là que vous découvrirez "pour réaliser une API plus simple, nous devrons refactoriser cette API COM folle. Tout le monde sait comment l'utiliser?". Lorsque la réponse est "Hell No", vous commencerez à voir que la portée de cette user story pourrait être plus grande qu'il n'y paraît. Compte tenu de cela, vous devriez pouvoir diviser la user story en tâches:

• Documenter et comprendre l'API actuelle
• Concevoir une nouvelle API
• Implémenter une nouvelle API
• Peu importe...

Compte tenu de cela, il est OK de négocier les user stories pour les diviser en petits changements. La méthodologie agile signifie que vous souhaitez aborder ce que la personne veut par étapes incrémentielles. Vous pouvez donc dire "Hé, regardez. Nous ne pouvons pas réviser l'API en une seule itération. Permet de la diviser en" En tant que client non technique, j'ai besoin d'une API bien documentée "ect".

Réponse courte

La Dev Team écrit les choses techniques. Scrum vous aide un peu mais pas beaucoup avec la panne technique resp. commencer une User Story. Scrum est presque What-World -only. La panne technique est How-World .

La ventilation fournie par Scrum est la suivante:

• User Story -> Critères d'acceptation

La ventilation que les gens utilisent souvent en plus est la suivante:

• Epic -> User Stories
• User Story -> Sous-tâches
• Critères d'acceptation -> Tests d'acceptation

De plus, l'équipe peut écrire des tâches techniques pour des choses dont elles savent qu'elles doivent être effectuées (c'est-à-dire installer IntelliJ IDEA pour tout le monde au début du projet) mais qui n'ont aucune valeur commerciale.

Pour plus d'informations sur la répartition du travail, recherchez XP (Extreme Programming), Clean Code , Pragmatic Programming , Software Engineering , CRC-Cards , OOP / OOA / OOD , Design Patterns , Refactoring , Working Effectively with Legacy Code , TDD ( Test-Driven Development), BDD (Behavior-Driven Development), ATDD (Acceptance-Test Driven Development).

Longue réponse

Comment Scrum pense

What-World et How-World

Il y a un What-World et un How-World . Comme vous l'avez ressenti correctement, la User Story est destinée aux utilisateurs , générant une valeur commerciale aka une valeur secondaire dans What-World . Scrum est principalement What-World uniquement. Cela ne dit pas grand-chose du How-World , rien de plus que "How-World est la responsabilité de la Dev-Team".

User Story vs Task

Habituellement, les éléments de backlog qui sont pour le How-World ne sont pas appelés User Story mais Technical Task ou Subtask . De nombreux outils permettent de décomposer la User Story du What-World en sous- tâches dans le How-World .

Comment Scrum aide et où finit cette aide

L'aide de Scrum pour le How-World se termine à quelques moments de la réunion de planification du sprint :

• [Sprint Planing Meeting] L'équipe découvre une incompréhension de l'histoire si différents coéquipiers proposent des estimations de Story Point différentes pendant le Planning Poker -> Discussion.
• [Définition de Ready] L'équipe n'accepte pas les User Stories trop grandes (Story Points trop élevés). Une règle de base trouvée dans de nombreuses définitions de prêt est que les points d'histoire doivent être inférieurs à la moitié de la vitesse de l'équipe.
• [Définition de prêt] L'équipe n'accepte pas les récits d'utilisateurs sans une description suffisante des critères d'acceptation. Les critères d'acceptation sont suffisants si l'équipe a suffisamment confiance en la façon de commencer à rédiger les tests d'acceptation.

Quelques conseils sur le niveau de Scrum

J'ai trouvé utile de décomposer les User Stories en sous-tâches lors des réunions Backfin Refinement ou au moins la deuxième partie de la réunion de planification Sprint (pour certaines équipes Sprint Planning 2 Meeting).

Avec des équipes inexpérimentées, j'ai trouvé utile de chercher des histoires d'utilisateurs atomiques pendant le raffinement du backlog et la planification du sprint. Une User Story atomique est une User Story qui ne peut pas être décomposée plus loin en Small User Stories sans perdre complètement sa valeur commerciale. En général, les User Stories n'ont pas besoin d'être Atomic, je viens de découvrir que cela m'aide avec des équipes inexpérimentées.

Et ne faites pas "(Architecture | Conception | Implémentation | Test) de la fonctionnalité X" comme User Stories. Je vous recommande même d'essayer d'éviter cela en tant que sous-tâche.

Si j'ai des histoires d'utilisateurs atomiques et qu'elles semblent avoir besoin d'une ventilation supplémentaire en dehors des critères d'acceptation à mettre en œuvre, cela signifie pour moi que quelque chose ne fonctionne pas au niveau optimal. Soit l'architecture est erronée / trop compliquée, c'est-à-dire technique au lieu d'être orientée métier. Ou l'équipe est inexpérimentée. Ou les deux. En tout état de cause, des actions seraient nécessaires pour améliorer la situation par la formation et la diffusion des connaissances.

Au-delà de Scrum

Le Scrum Master au-delà de Scrum

Aujourd'hui, le Scrum Master est principalement compris comme un rôle de gestion , et c'est des conneries. À l'origine, le Scrum Master était, et je le préconise, un rôle technique , pas un rôle de gestion, tout comme le coach dans XP .

Il est trop facile de compter sur Scrum et le Scrum Master et de tomber ainsi dans un énorme fossé parce que Scrum ne dit presque rien sur le How-World.

Scrum Master rotatif

Idéalement, le Scrum Master tourne parmi les développeurs expérimentés qui ont également des compétences de gestion et de communication suffisantes jusqu'à ce que tous les membres de l'équipe vivent "Inspecter et adapter" si profondément par cœur que le Scrum Master devient redondant; personne et tout le monde ne seraient Scrum Master en même temps.

Mais attention, Scrum Mastery est plus comme la cuisine, pas comme le nettoyage de la table et la vaisselle. Vous voudrez peut-être faire pivoter qui nettoie la table et lave la vaisselle, comme tout le monde pourrait le faire. Mais vous ne voudriez pas faire tourner la cuisine sur tout le monde, car il y a des gens qui ne peuvent pas cuisiner ou qui n'aiment pas cuisiner, et vous voulez manger de la bonne nourriture.

La bonne chose à propos de la rotation du Scrum Master entre développeurs experts est que l'équipe est plus susceptible d'en savoir plus sur les méthodes.

L'équipe auto-organisatrice

Du point de vue de Scrum, l'équipe doit se découvrir, idéalement avec l'aide du Scrum Master .

Scrum ne parle que de l' équipe de développement . Les rôles comme Architect ou Lead Engineer n'existent pas dans Scrum. Cela ne signifie pas qu'ils sont interdits, cela signifie seulement que Scrum ne dit rien à leur sujet. Scrum proclame une équipe auto-organisée , ce qui signifie que si l'équipe déclare un architecte, l'équipe a un architecte. Ce n'est pas défini par Scrum, mais il est conforme à Scrum. Je ne proclame pas des architectes dévoués (j'ai travaillé comme architecte désigné pendant des années, et bien que cela me plaise, je suis fondamentalement contre l'idée d'un architecte désigné), je donne juste un exemple.

Tests d'acceptation

Les user stories ont des critères d'acceptation . Ces critères d'acceptation sont transformés en tests d'acceptation

D'autres choses

Pour obtenir une liste d'autres éléments à analyser, voir Comment diviser un projet de programmation en tâches pour d'autres développeurs?

J'espère que cela t'aides.

Celui qui est le mieux qualifié dans l'équipe doit décomposer les exigences des propriétaires de produits en histoires d'utilisateurs exploitables. D'après mon expérience, nous avons utilisé l'approche suivante:

• Il a toujours été un développeur qui écrit les histoires sur la base de discussions avec les propriétaires de produits.
• Ces histoires sont ensuite estimées (en fonction des points ou du temps) par les développeurs
• Les propriétaires de produits décident ensuite de la priorité des choses.

Si les développeurs ne savent pas comment implémenter une histoire, alors l'un de ces cas pourrait être vrai:

• La tâche n'est peut-être pas assez claire (ajoutez plus de détails / captures d'écran / maquettes)
• Il doit être ventilé davantage afin que les tâches spécifiques soient plus claires
• Il a besoin de plus de temps pour que le développeur puisse rechercher et apprendre à l'implémenter. (Lors de l'estimation de cette tâche, ajoutez plus de temps pour en tenir compte)
• Le développeur n'est pas suffisamment qualifié pour l'implémenter et il peut être nécessaire de l'attribuer à quelqu'un d'autre, ou le développeur doit être aidé par quelqu'un d'autre.

Vous pouvez suivre ce cours sur SCRUM à Udemy gratuitement et en apprendre davantage sur les aspects individuels du processus SCRUM - https://www.udemy.com/scrum-methodology/

La réponse courte est la suivante: le propriétaire du produit est responsable de la création des histoires que l'équipe doit livrer. C'est l'équipe qui décide comment livrer les histoires. Si une partie de la livraison implique des histoires techniques, c'est l'équipe qui écrit ces histoires. L'équipe travaille ensuite avec le propriétaire du produit pour décider de la priorité.

Encore une fois, l'OP décide quoi construire, l'équipe doit décider comment mettre en œuvre ces histoires.

Ce n'est pas un problème Agile. Le problème est que l'équipe n'a pas suffisamment de connaissances techniques pour terminer une user story (agile) ou une exigence (traditionnelle). Agile peut-il aider dans cette situation? Non, si l'équipe n'a pas été sélectionnée avec soin et que personne dans l'équipe n'a suffisamment d'expérience technique pour effectuer ses tâches. Oui, si certains des membres de l'équipe ont de bonnes connaissances techniques qui peuvent aider d'autres membres de l'équipe à effectuer leurs tâches. Pour cette équipe, elle doit s'auto-organiser et doit savoir ses forces et ses faiblesses.

n'oubliez pas le principe Agile suivant.

"Les meilleures architectures, exigences et conceptions émergent d'équipes auto-organisées"

Cela se produit car dans un environnement agile, la confiance des équipes est élevée et ils délèguent le travail entre eux.