Eu sei que o proprietário de um produto deve escrever uma história de usuário no scrum.

Uma história de usuário está descrevendo um recurso para o usuário final.

Mas quem descreve o que precisa ser tecnicamente desenvolvido e como precisa ser implementado

e onde estão as informações armazenadas sobre o scrum?

Isso realmente me interessaria!

Vejo uma grande falta de conhecimento em nossa empresa quando o desenvolvedor começa a implementar a história, mas eles não sabem como implementá-la!

Por exemplo, eles precisam lidar com uma API COM herdada e não têm idéia de como lidar com isso ou eles não são tão tecnicamente qualificados com WPF / WEB ou o que quer.

Como o scrum ajuda essas pessoas a começar com a história do usuário?

Aqui não é um ódio ágil. A divulgação dos detalhes da implementação e a determinação das tarefas que precisam ser realizadas acontecem durante a reunião de planejamento do sprint, que transformará as histórias do usuário em tarefas / requisitos reais para o sprint. O fracasso de muitos processos ágeis é que a reunião de planejamento do sprint deve ser realizada em grande parte pelos desenvolvedores ... se forem apenas os proprietários do produto, eles decidirão pegar a lua. É aqui que você cria uma história de usuário (bastante nebulosa) como:

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

Embora o proprietário do produto defina quais histórias de usuários são a maior prioridade, os programadores pegam essas prioridades e as transformam em uma lista de tarefas (chamada de lista de pendências do sprint). É aqui que você tem a idéia de como implementará as coisas ... o backlog do sprint pode ser tão técnico quanto você desejar. É também aqui que você descobrirá "para obter uma API mais simples, teremos que refatorar essa louca API COM. Alguém sabe como usá-la?". Quando a resposta for "Inferno Não", você começará a ver que o escopo dessa história de usuário pode ser maior do que parece. Dado isso, você deve dividir a história do usuário nas tarefas:

• Documentar e entender a API atual
• Projetar nova API
• Implementar nova API
• Tanto faz...

Diante disso, não há problema em negociar as histórias de usuários para transformá-las em mudanças menores. A metodologia ágil significa que você deseja abordar o que a pessoa deseja em etapas incrementais. Então você pode dizer "Ei, olha. Não podemos revisar a API em apenas uma iteração. Vamos dividi-la em 'Como cliente não técnico, preciso de um ect bem documentado da API".

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.

Quem está mais qualificado na equipe precisa dividir os requisitos dos proprietários do produto em histórias de usuários acionáveis. Na minha experiência, usamos a seguinte abordagem:

• Sempre foi um desenvolvedor que escreve as histórias com base em discussões com os proprietários do produto.
• Essas histórias são então estimadas (com base em pontos ou tempo) pelos desenvolvedores
• Os proprietários do produto decidem como as coisas são priorizadas.

Se os desenvolvedores não souberem implementar uma história, um desses casos poderá ser verdadeiro:

• A tarefa pode não estar clara o suficiente (adicione mais detalhes / capturas de tela / modelos)
• Ele precisa ser dividido ainda mais, para que as tarefas específicas sejam mais claras
• Ele precisa de mais tempo para que o desenvolvedor possa pesquisar e aprender como implementá-lo. (Ao estimar esta tarefa, adicione mais tempo para explicar isso)
• O desenvolvedor não está qualificado o suficiente para implementá-lo e pode precisar ser atribuído a outra pessoa ou o desenvolvedor precisa ser ajudado por outra pessoa.

Você pode fazer este curso gratuitamente no SCRUM na Udemy e aprender sobre aspectos individuais do processo do SCRUM - https://www.udemy.com/scrum-methodology/

A resposta curta é a seguinte: o proprietário do produto é responsável por criar as histórias que a equipe deve entregar. É a equipe que decide como entregar as histórias. Se parte da entrega envolve algumas histórias técnicas, é a equipe que as escreve. A equipe trabalha com o proprietário do produto para decidir a prioridade.

Novamente, o OP decide o que construir, a equipe decide como implementar essas histórias.

Este não é um problema ágil. O problema é que a equipe não possui conhecimento técnico suficiente para concluir uma história do usuário (ágil) ou um requisito (tradicional). O Agile pode ajudar nessa situação? Não, se a equipe não foi selecionada com cuidado e ninguém na equipe possui experiência técnica suficiente para executar suas tarefas. Sim, se alguns dos membros da equipe tiverem bons conhecimentos técnicos, poderão ajudar outros membros da equipe a desempenhar suas tarefas. Para que a equipe precise ser auto-organizada, deve saber suas forças e fraquezas.

lembre-se do seguinte princípio ágil.

"As melhores arquiteturas, requisitos e projetos emergem das equipes auto-organizadas"

Isso acontece porque no ambiente ágil, a confiança da equipe é alta e eles delegam trabalho entre si.