Quando parar de escrever histórias de usuários e começar a codificar?

Ao descobrir histórias para o primeiro sprint, como você sabe quando parar de escrever e seguir em frente?

Eu perguntei a algumas pessoas que eu conheço e, basicamente, a resposta que recebi é: depende do contexto em que o projeto existe e de como o cronograma geral do projeto também é.

Existe alguma maneira padrão de saber quando parar de escrever histórias de usuários? Em caso afirmativo, qual é a base para isso e como isso se aplica a sprints futuros?

Você precisa estimar cada história depois de realizá-la - isso pressupõe que você esteja colocando suas histórias em ordem de prioridade e que elas sejam elaboradas o suficiente para o desenvolvimento.

Quando você tiver estimado o suficiente para uma iteração, comece a codificar.

Quando você tem uma lista de pendências completa do produto e boas histórias completas de usuários de todos os casos. Em seguida, divida-os em iterações e inicie a programação.

As duas atividades não são antagônicas.

Escrever histórias é sobre definir as necessidades desejadas sob a restrição de fornecer valor comercial.

O início do código acontece no meio de um sprint. Para iniciar um sprint, o único pré-requisito é um backlog de sprint definido - priorizado pelo OP (o escritor da história) e selecionado pela equipe.

Você deve parar de escrever matérias (= interromper o projeto), quando o benefício marginal de implementar a matéria versus o custo de implementação e o custo operacional atualizado da função definida for negativo.

Você deve começar a codificar no contexto de um sprint, quando a história for entendida (análise) e os testes e implementação forem definidos (design) - a abordagem clássica de desenvolvimento de software.

quando as histórias se tornam granulares o suficiente para se transformarem em lógica programável. e quando os programadores podem atribuir uma certa quantidade de pontos da história que se encaixam na linha do tempo dos sprints.

uma história que é estimada em 50 horas / pontos de história seria difícil (IMO) para durar mais de uma semana de sprint. dividir a história ainda mais permitiria que outras pessoas assumissem várias partes da tarefa, mas se o código não puder ser desenvolvido em paralelo, provavelmente é o mais curto possível.

Existe alguma maneira padrão de saber quando parar de escrever histórias de usuários? Em caso afirmativo, qual é a base para isso e como isso se aplica a sprints futuros?

Eu pessoalmente não conheço um método padrão por si só. Na verdade, tudo se resume a uma combinação de sua metodologia e das expectativas de seus clientes.

Descobri que é melhor começar a codificar assim que você tiver histórias "suficientes" do seu cliente para começar. Como outros já disseram, isso pode ser para uma única iteração, mas pode ser para mais. Sua medida do suficiente deve ser guiada pela frequência com que você pretende liberar o código de trabalho para seu cliente e, em vez de pedir que ele lhe forneça uma lista interminável de histórias (muitas das quais provavelmente nunca serão concluídas, ou poderão mudar, ou não) prazo de lançamento principal), é melhor solicitar ao seu cliente os primeiros 3 a 5 recursos mais importantes e de maior prioridade. Quando essas são finalizadas e liberadas para o seu cliente, você coleta os próximos três a três recursos mais importantes e assim por diante. Peça mais ou menos, dependendo de quanto tempo suas iterações provavelmente serão.

Talvez seu cliente ou contrato ou prazo limite possa orientá-lo sobre quando realmente parar de pedir histórias, mas, enquanto isso, você está pedindo histórias e parando com a frequência das iterações. Quando, por acordo, você e o cliente sentirem que o produto está completo o suficiente, poderá decidir o que fazer com as sobras de histórias que o cliente ainda não tenha lhe dado.

A principal vantagem dessa abordagem é que você acaba entregando o maior valor ao cliente antecipadamente e, à medida que o projeto cresce e o tempo passa, a quantidade de valor que você está entregando ao cliente diminui até o ponto em que o cliente pode gerar um valor. decisão sobre os "últimos 20% dos recursos" que eles poderiam desejar e que talvez nunca fossem realmente usados. Também reduz o tempo desperdiçado em itens triviais e de baixa prioridade, colocando a responsabilidade (e o estresse) de priorizar e agendar iterações novamente no cliente, e tudo baseado apenas nas necessidades do cliente. Isso não significa, no entanto, que você não deve fornecer orientação ao cliente para evitar gargalos de programação difíceis que podem se tornar aparentes à medida que você conversa com os requisitos do cliente.

Leia o Desenvolvimento de software enxuto da Poppendeicks, se desejar uma descrição mais detalhada dessa abordagem em um contexto mais amplo.

você nunca para de escrever histórias. É só que, quando você tiver histórias suficientes para o sprint 1, fará o planejamento do sprint e sua equipe começará a trabalhar de acordo com o backlog do sprint.

O proprietário do produto continuará cuidando do backlog do produto, ou seja, escrevendo mais histórias de usuários, dividindo grandes histórias, como épicas, em outras menores, elaborando mais sobre os critérios de aceitação de histórias, priorizando ...