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.