Resposta curta
A equipe de desenvolvimento escreve as coisas técnicas. O Scrum ajuda um pouco, mas não muito, com a falha técnica resp. começando em uma história de usuário. O Scrum é quase o que é o mundo . A falha técnica é o How-World .
A composição fornecida pelo Scrum é:
- História do usuário -> Critérios de aceitação
A divisão que as pessoas costumam usar além disso é:
- Épico -> Histórias de usuários
- História do usuário -> Subtarefas
- Critérios de aceitação -> Testes de aceitação
Além disso, a equipe pode escrever tarefas técnicas para o que sabe que precisa ser feito (por exemplo, instale o IntelliJ IDEA para todos no início do projeto), mas que não têm valor comercial.
Para obter mais orientações sobre como trabalhar com detalhamento, procure XP (Extreme Programming), Código Limpo , Programação Pragmática , Engenharia de Software , Cartões CRC , OOP / OOA / OOD , Padrões de Design , Refatoração , Trabalhando Efetivamente com o Legacy Code , TDD ( Desenvolvimento Orientado a Testes), BDD (Desenvolvimento Orientado a Comportamentos), ATDD (Desenvolvimento Orientado a Testes de Aceitação).
Resposta longa
Como o Scrum pensa
What-World e How-World
Existe um mundo do quê e um mundo do como . Como você se sentiu corretamente, a História do Usuário é para Usuários , gerando Valor Comercial, também conhecido como Valor Secundário, no What-World . Scrum é principalmente o What-World. Diz pouco ou nada sobre o How-World , basicamente não mais do que "O How-World é de responsabilidade do Dev-Team".
História do Usuário x Tarefa
Geralmente, os itens de lista não processada que são do How-World não são chamados de História do usuário, mas Tarefa técnica ou Subtarefa . Muitas ferramentas permitem dividir a história do usuário do What-World em subtarefas no How-World .
Como o Scrum ajuda e onde essa ajuda termina
A ajuda do Scrum for the How-World termina em alguns momentos da Sprint Planning Meeting :
- [Sprint Planing Meeting] A equipe descobre um mal-entendido da história se diferentes colegas de equipe apresentarem estimativas diferentes de Story Point durante o Planning Poker -> Discussion.
- [Definição de Pronto] A equipe não aceita Histórias de Usuários muito grandes (Story Points muito altas). Uma regra prática encontrada em muitos Definition of Ready é que os Story Points devem ter menos da metade da velocidade da equipe.
- [Definição de Pronto] A equipe não aceita Histórias de Usuário sem descrição suficiente dos Critérios de Aceitação. Os critérios de aceitação são suficientes se a equipe tiver confiança suficiente em como começar a escrever os testes de aceitação.
Algumas dicas sobre o nível de Scrum
Achei útil fazer uma divisão das Histórias de Usuário em Subtarefas durante as reuniões de Refinamento de Backlog ou pelo menos a segunda parte da Reunião de Planejamento da Sprint (para algumas equipes Reunião de Planejamento 2 da Sprint ).
Com equipes inexperientes, achei útil procurar histórias de usuários atômicas durante o refinamento de backlog e o planejamento de sprint. Uma história de usuário atômica é uma história de usuário que não pode ser dividida em histórias de usuário menores sem perder totalmente o seu valor comercial. Em geral, as Histórias de Usuário não precisam ser Atômicas, acabei de descobrir que isso me ajuda com equipes inexperientes.
E não faça "(Arquitetura | Design | Implementação | Teste) do Recurso X" como Histórias de Usuários. Eu recomendo que você tente evitar isso como uma subtarefa.
Se eu tenho o Atomic User Stories e eles parecem precisar de mais detalhes além dos Critérios de Aceitação a serem implementados, significa para mim que algo não está funcionando no nível ideal. A arquitetura está errada / muito complicada, ou seja, técnica em vez de orientada para os negócios. Ou a equipe é inexperiente. Ou ambos. De qualquer forma, seriam necessárias ações para melhorar a situação, treinando e disseminando conhecimento.
Além do Scrum
O Scrum Master além do Scrum
Hoje, o Scrum Master é entendido principalmente como um papel gerencial , e isso é besteira. Originalmente, o Scrum Master era, e eu defendo isso, um papel técnico , não um papel gerencial, assim como o treinador no XP .
É muito fácil confiar no Scrum e no Scrum Master e, assim, cair em uma enorme lacuna, porque o Scrum não diz quase nada sobre o How-World.
Rotativo Scrum Master
Idealmente, o Scrum Master alterna entre os desenvolvedores experientes que também possuem habilidades gerenciais e de comunicação suficientes até que todos na equipe vivam "Inspecione e adapte" tão profundamente de cor que o Scrum Master se torne redundante; ninguém e todo mundo seria Scrum Master ao mesmo tempo.
Mas cuidado, o Scrum Mastery é mais como cozinhar, não como limpar a mesa e lavar a louça. Você pode alternar quem limpa a mesa e lava a louça, como todo mundo poderia fazer. Mas você não gostaria de girar o cozimento para todos, porque há pessoas que não sabem cozinhar ou não gostam de cozinhar, e você quer comer boa comida.
A coisa boa sobre a rotação do Scrum Master entre desenvolvedores especialistas é que é mais provável que a equipe aprenda sobre mais métodos.
A equipe auto-organizada
Da perspectiva do Scrum, a equipe deve descobrir a si mesma, idealmente com a ajuda do Scrum Master .
O Scrum também fala apenas da equipe de desenvolvimento . Funções como arquiteto ou engenheiro líder não existem no Scrum. Isso não significa que eles são proibidos, apenas significa que Scrum não diz nada sobre eles. O Scrum proclama uma equipe auto-organizada , o que significa que, se a equipe declarar um arquiteto, a equipe terá um arquiteto. Isso não é definido pelo Scrum, mas é compatível com o Scrum. Não estou proclamando arquitetos dedicados (trabalhei como arquiteto designado por anos e, embora gostei, sou fundamentalmente contra a ideia de um arquiteto designado), apenas dando um exemplo.
Testes de aptidão
Histórias de usuários têm critérios de aceitação . Esses critérios de aceitação são transformados em testes de aceitação
Outras coisas
Para obter uma lista de mais informações sobre detalhamento, consulte Como dividir um projeto de programação em tarefas para outros desenvolvedores?
Espero que isto ajude.