Qui écrit les «user stories» techniques dans Scrum
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 le développeur commence à 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 aussi 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
L'équipe de développement é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 - seulement. La ventilation 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 pourrait écrire Tâches techniques pour les 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 pas de valeur commerciale.
Pour plus d'informations sur la répartition du travail, recherchez [~ # ~] xp [~ # ~] (Extreme Programming), Code propre , Programmation pragmatique , Génie logiciel , Cartes CRC , OOP/OOA/OOD , Design Patterns , Refactoring , Travailler efficacement avec le code hérité , [~ # ~] tdd [~ # ~] ( Développement piloté par les tests), [~ # ~] bdd [~ # ~] (Développement piloté par le comportement), [~ # ~] atdd [~ # ~] (Développement piloté par les tests d'acceptation).
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, User Story est destiné aux utilisateurs , générant Valeur commerciale aka Valeur secondaire dans le What-World . Scrum est principalement What-World uniquement. Il ne dit pas grand-chose sur le How-World , essentiellement rien de plus que "How-World est la responsabilité de la Dev-Team".
User Story vs Task
Habituellement, Les éléments du backlog qui sont pour le How-World ne sont pas appelés User Story mais Tâche technique ou Sous-tâche . 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 :
- [Réunion de planification de sprint] L'équipe découvre un malentendu de l'histoire si différents coéquipiers arrivent avec des estimations différentes Story Point pendant les Planification du poker -> Discussion.
- [Définition de Ready] L'équipe n'accepte pas les User Stories trop grandes (Story Points trop élevés). Une règle d'or que l'on retrouve dans de nombreuses définitions de prêt est que les Story Points doivent être inférieurs à la moitié de la vitesse de l'équipe.
- [Définition de prêt] L'équipe n'accepte pas les histoires d'utilisateurs sans une description suffisante des critères d'acceptation. Les critères d'acceptation sont suffisants si l'équipe a suffisamment confiance dans 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 de raffinement du backlog ou au moins la deuxième partie des Sprint Planning Meeting (pour certaines équipes Sprint Planning 2 Meeting).
Avec des équipes inexpérimentées, j'ai trouvé utile de s'efforcer de Atomic User Stories pendant le Backlog Refinement et Sprint Planning. 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 atomiques, 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 incorrecte/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 ainsi tomber 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 la Dev Team . Les rôles tels que Architect ou Ingénieur principal 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 une liste de plus de choses à décomposer, 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 à le mettre en œuvre. (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 de construire, l'équipe doit décider comment de 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 compléter 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'organiser elle-même et doit savoir ses forces et ses faiblesses.
veuillez vous souvenir du 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.