Separando o que do como - Design em um ambiente ágil [fechado]

Question

Em um ambiente ágil (scrum), como fazer com que o gerenciamento de produtos crie itens ou histórias de backlog pequenos o suficiente sem que eles façam todo o design, o que não é sua especialidade?Em outras palavras, como separar o quê (requisitos de negócios) do como (design) no desenvolvimento ágil?

Answer 1

Com o scrum, o gestão de produtos deve ser uma pessoa:o Proprietário do produto .

O que você quer fazer é feito durante o planejamento de sprint, onde toda a equipe (product Owner, scrummaster, desenvolvedores) deverá estar presente.

O o que deve ser definido como histórias de usuários pelo Proprietário do produto .As histórias de usuários devem ser de alto nível, limitando o proprietário do produto a expressar os requisitos de negócios em histórias de uma frase devem resolver.

por exemplo. Como usuário do StackOverflow, gostaria de ver minha reputação

Um dos objetivos do planejamento do sprint é decidir as histórias que devem ser feitas durante o sprint.Assim, quando as histórias são escolhidas pelo product owner, a equipe pode subdividi-las, falar brevemente sobre o design (o como) e estimá-los.

Em poucas palavras, o o que deve ser feito pelo proprietário do produto, o como pela equipe.Se esse processo for explicado claramente ao proprietário do produto, ele não tentará projetar tudo.Se ele tentar de qualquer maneira, o scrummaster irá impedi-lo.

Answer 2

A primeira coisa que você deve fazer, e que é a causa de um grande número de falhas em Projetos Scrum, é ensinar seu gerenciamento de produto a desempenhar o papel de Product Owner.Você tem que mostrar para ele que ele é o responsável pelo ROI do projeto, e para isso, ele é responsável por priorizar as histórias/itens/necessidades/recursos do negócio ou o que você estiver usando para compor o seu Product backlog de uma forma que o mais itens valiosos têm prioridades mais altas.

Sou a favor de usar histórias de usuários como itens do backlog do produto e depois, no planejamento do sprint, quebrar em tarefas menores as histórias selecionadas para compor o backlog do sprint.

O que você deve sempre ter em mente ao escrever, ou ajudar seu PO a escrever, suas histórias de usuários é que as histórias devem ser INVESTIDAS. EUindependente, Negociável, Vvalioso para os clientes, Eestimável, Sshopping e Testável.

Acho que no início usar o modelo abaixo pode ser útil para manter o PO focado nos objetivos de negócios:

"Como um - tipo de usuário -, quero -algum objetivo- para que -algum motivo-."

Um exemplo de história seria "Como usuário do stackoverflow, quero votar em uma resposta para que a resposta mais valiosa possa ser facilmente encontrada".

Não se esqueça de escrever o PO ou definir o Teste de aceitação para cada história do seu Sprint Backlog, pois ele pode ser usado como critério básico para determinar se uma história está totalmente implementada.

Para o exemplo acima, dois testes de aceitação possíveis são:

"Teste para votar em uma resposta"

"Teste para votar contra uma resposta"

Com esta história e dois testes de aceitação a equipe sabe que o usuário stackoverflow pode votar nas respostas e para que o status da história seja atualizado faça Concluído, é necessário que o sistema permita que o usuário vote a favor ou contra uma resposta sem lançar exceções.

Answer 3

Não se esqueça que os itens do backlog do produto devem ser classificados em ordem de importância, utilizando um sistema de ponderação (números primos, fibonacci,..), para que se você tiver itens no seu backlog de importância semelhante (ou seja,2 itens com peso 21), então deveriam em teoria ambos tentar e ser inseridos no sprint antes dos 13 e 8.

Answer 4

Durante a (re)estimativa do backlog (após a priorização), a equipe deve fazer a modelagem para compreender toda a extensão da história do usuário e ser capaz de estimar com precisão a complexidade.Esta não é toda a extensão da modelagem que pode ocorrer (as equipes podem fazer mais desenvolvimento), mas é um ótimo lugar para começar e será capaz de aproveitar a presença do Cliente/Produto por perto para responder perguntas. e então.

Como resultado disso, a discussão resultante o ajudará a trabalhar com o Product Owner para dividir seus requisitos em uma granularidade significativa e adequada.