No Scrum, tarefas como a configuração do ambiente de desenvolvimento e o desenvolvimento de recursos devem ser gerenciadas como subtarefas nas histórias reais do usuário?

Às vezes, nos projetos, precisamos dedicar tempo a tarefas como:

1. explorando estruturas e ferramentas alternativas
2. aprendendo a estrutura e as ferramentas selecionadas para o projeto
3. configurando os servidores e a infraestrutura do projeto (controle de versão, ambientes de construção, bancos de dados etc.)

Se estivermos usando histórias de usuário, para onde todo esse trabalho deve ir?

Uma opção é fazer com que todos façam parte da primeira história do usuário (por exemplo, crie a página inicial do aplicativo). Outra opção é fazer um pico para essas tarefas. Uma terceira opção é tornar a tarefa parte de um problema / impedimento (por exemplo, ambiente de desenvolvimento ainda não selecionado) em vez de uma história do usuário.

Nós pensamos bastante sobre esse problema no ano passado.

Embora eu concorde que exista uma estrutura básica antes do início do projeto, em uso prático, ela pode fazer parte do próprio projeto. Então você tem que gerenciar de alguma forma.

Embora misturar a configuração do projeto com as histórias de usuários às vezes faça sentido, decidimos por tarefas simples que podem ser adicionadas à lista de pendências do produto e recebemos a mesma atenção das histórias de usuários. Sabemos que essas tarefas técnicas são necessárias algumas vezes, mas devem ser justificadas em qualquer caso. Se a equipe achar que é absolutamente necessário para atingir um determinado objetivo, fará parte de um sprint.

É difícil dizer o que funciona melhor para você, então experimente ! Um pico pode ser suficiente por enquanto, mas acho que você acabará com o mesmo problema mais tarde, então planeje com antecedência. Execute tarefas que são um espaço reservado para essas atividades. Para separar as tarefas das duas histórias, eu as compararei rapidamente com base na minha experiência com elas.

Tarefa: uma tarefa é uma necessidade técnica. Pode ser algo para gerenciamento de configuração ou configuração geral do projeto, como configurar um repositório para confirmações ou adicionar a ferramenta mais avançada de revisão de código que você já viu no processo de desenvolvimento. As tarefas devem ser consideradas no planejamento, da mesma forma que uma história de usuário. Se a equipe puder convencer o proprietário do produto de que ter a melhor e mais recente ferramenta de revisão de código aumenta o desempenho e aprimora a comunicação da equipe, eliminando sessões de programação em pares de longa duração ou revisões de código presenciais, chamará a atenção do proprietário do produto.

Histórias : focadas apenas na perspectiva dos negócios, as histórias sempre produzem valor visível para o cliente. Qualidade interna é algo que acompanha a produção de valor comercial.

Nós até atribuímos pontos de história a tarefas e, às vezes, trabalhamos com eles da mesma forma que faríamos com histórias.

No final, eu usaria essa solução no seu caso (que também poderia ser aplicada em geral):

1. Separe "configuração" e material técnico em tarefas (material que não produz diretamente valor comercial para o proprietário do produto).
2. Talvez faça um pico antes da configuração do projeto para colocar as ferramentas mais importantes no lugar (SCM, ferramentas de desenvolvimento, definição de processos, padrões de codificação etc.)
3. Aceite que essas tarefas ocorram durante o projeto e planeje isso tendo um "tipo" de atividades separado de histórias.

Faça o que fizer mais sentido na sua empresa. Nunca permita que outras pessoas façam um obstáculo ao bom senso.

Mas direi que todas essas tarefas parecem algo que deve acontecer muito antes de você começar o desenvolvimento. Então, questiono se o Scrum é relevante para essas tarefas. Há alguma manutenção em andamento, como controle de origem e bancos de dados, mas eles não devem ser agendados, devem ser apenas coisas que acontecem e afetam sua velocidade.

Haverá momentos em que você precisará selecionar uma estrutura ou o que for durante um projeto, mas quando digo isso, quero dizer uma estrutura como nHibernate, não uma estrutura como .NET. Nesses casos, a pesquisa deve ser aumentada e com timebox, para não mencionar bastante curta. Tente gerenciá-lo como se você tivesse um desenvolvedor doente por alguns dias.

A transferência de conhecimento é outro processo contínuo que deve ser gerenciado fora da velocidade geral de desenvolvimento.

Existe um nome para a tomada de decisões de design possível antes do início "oficial" do seu projeto. Chama-se cachoeira. Não há nada de errado com as histórias de usuários como "Como desenvolvedor, preciso selecionar uma estrutura, para termos um ponto de partida para o site". Se for grande demais para caber em uma iteração, tente detalhá-la como "Como desenvolvedor, preciso implementar uma página inicial básica no Drupal, para que possamos saber se ela se encaixa em nossas necessidades".

Uma opção é fazer com que todos façam parte da primeira história do usuário, por exemplo, crie a página inicial do aplicativo.

Quebra a "história do usuário" como um conceito. Qual usuário está envolvido nisso? Nenhum. Este é um trabalho que você já deveria ter feito.

Outra opção é fazer um pico para isso.

Não é ruim.

A terceira opção é tornar a tarefa parte de um problema (por exemplo, ambiente de desenvolvimento ainda não selecionado) em vez de uma história do usuário.

Quase o mesmo que um pico, no que diz respeito ao planejamento e às despesas gerais.

A instalação não é uma história de usuário.

É o que você deveria ter implementado antes mesmo de iniciar este projeto.

Você não pode realmente iniciar o projeto a menos que tenha a estrutura / ferramenta e os servidores configurados e prontos para o uso.

Estou ciente de que muitas organizações realmente não existem até depois da assinatura do contrato. Também estou ciente de que muitas organizações não escolhem uma tecnologia até depois da assinatura do contrato. Essas são coisas ineficientes que estão fora das histórias de usuários.

No trabalho, usamos uma tarefa para preparar o ambiente. Pode ser confuso para algumas pessoas, mas a tarefa que usamos é praticamente a mesma que a de uma história de usuário. A tarefa não pertence a uma história do usuário, mas é estimada em horas e deve ser acordada pelo proprietário do produto para ser concluída em um sprint específico.

Também usamos a tarefa para trabalhos de arquitetura que não possuem um valor comercial "aparente", mas que agregam qualidade ao produto, particularmente para um produto existente com uma grande base de códigos.

Isso pode não se aplicar ao seu ambiente de trabalho, mas funcionou bem para nós.

Eu acho que você está misturando duas coisas independentes. Uma história de usuário não deve incluir detalhes técnicos.

A escolha da estrutura, a configuração de repositórios e servidores e outras tarefas deve entrar na iteração inicial.

Eu participei de um curso Scrum recentemente e o instrutor sugeriu que um sprint especial chamado Sprint 0 deveria ser usado para resolver exatamente esse tipo de problema. Havia pessoas no curso com diferentes graus de experiência no Scrum e praticamente todas as pessoas experientes concordaram, dizendo que fizeram a mesma coisa. Em alguns casos, as empresas usaram o Sprint 0 para avaliar o projeto e decidiram se era viável ou não.

Para alguém novo na metodologia Scrum como eu, parece uma solução fantástica, pois mantém você livre de histórias de usuários e de todos os outros aspectos de um sprint normal, como feedback do usuário.

Como o Sprint 0 tem o mesmo período de tempo que seus outros sprints, ele atua como uma maneira de garantir que você não gaste muito tempo configurando as coisas, porque elas sempre podem ser ajustadas posteriormente. O ponto principal é entrar em um estado em que você pode realmente começar a desenvolver o produto.

em explorar 2-3 estrutura / ferramenta alternativa

Às vezes, isso pode acontecer se você tiver um requisito especial, precisará fazer um POC para escolher a melhor ferramenta para resolver o requisito. É para isso que serve o pico, porque sem saber qual estrutura você usará, provavelmente não poderá estimar a história e armazenar sem estimativa não pode ser planejado e dividido em tarefas.

depois, aprendendo a estrutura que selecionamos para o projeto

Bem. Isso é bastante perigoso. Quando o cliente paga um SW, ele espera que você seja profissional e que já saiba como usar suas ferramentas. O cliente não paga por aprendizado ou abordagem de desenvolvimento de tentativa / falha. É responsabilidade do desenvolvedor aprender novas ferramentas em seu tempo livre ou em um tempo alocado especial pago pelo funcionário e não pelo cliente. Gastar dinheiro do cliente para aprender sem informar o cliente não é profissional.

Se você realmente precisar usar algo especial (por exemplo, a API ou a ferramenta de um cliente selecionado por um cliente) que você nunca usou antes, deverá informar ao cliente que o preço será aumentado pelo tempo necessário para aprender a usar a API. Talvez o cliente mude de idéia se o aumento de preço for muito grande.

Claro, não estou falando de uma situação em que você deve procurar algum novo problema específico na estrutura que você usou várias vezes. Quero dizer a situação em que você começa a usar a nova API ou estrutura sem gastar um tempo significativo (fora do projeto) para aprender.

Se você violar isso, estará visível na sua velocidade de qualquer maneira, porque você fornecerá uma quantidade muito pequena de valor comercial por iteração. Se o cliente não estiver ciente do motivo, ele provavelmente cancelará o projeto.

Isso ainda é válido no caso de projetos internos - você deve informar seu gerente / empresa sobre o tempo necessário para aprender nova API ou ferramenta. Geralmente, tem consequências muito ruins se o gerente contar com sua produtividade normal e sua produtividade for apenas uma fração devido à nova API que você está tentando aprender durante suas tarefas. Isso é obviamente ainda pior se algumas pessoas de vendas calcularem com produtividade normal quando assinarem contrato com o cliente.

na configuração dos servidores (SVN, bancos de dados, etc.)

Essa é sua infraestrutura e custos internos. Quando você inicia o projeto, espera-se que você tenha sua infraestrutura preparada. A configuração do seu ambiente de desenvolvimento não tem valor para o cliente e não deve fazer parte de nenhum indicador relacionado ao projeto - por exemplo, velocidade no Scrum. Vi isso implementado como uma iteração pré-projeto especial usada apenas para configurar o ambiente, criar infraestrutura básica etc.