Como uma equipe do Scrum explica as tarefas de infraestrutura na reunião de planejamento?

Como uma equipe Scrum considera as tarefas de desenvolvimento / infraestrutura na reunião de planejamento?

À primeira vista, eles não parecem histórias de usuários, pois não agregam valor ao usuário final.

No entanto, anexá-los como tarefas a uma história de usuário específica às vezes também não faz sentido. Por exemplo, diga que a tarefa é: "Setup Bamboo". Essa tarefa não é necessária para concluir nenhuma história do usuário, pois a equipe pode criar e implantar manualmente. Portanto, anexá-lo a uma história do usuário não faz sentido, pois essa tarefa não é necessária para concluir a história do usuário.

Portanto, isso sugere que essas tarefas se tornam histórias de usuários. Mas então, se a história da equipe apontá-los, isso muda a velocidade que é ímpar, já que o Dono do produto quer saber a velocidade contra seu backlog, não contra o backlog com várias histórias técnicas de usuários anexadas a ele.

Na verdade, não são histórias de usuários. São histórias de partes interessadas. A menos que o software seja realmente pago diretamente pelos usuários, é raro que uma história seja criada inteiramente para seu benefício.

Eu dou alguns exemplos:

• artigos com palavras-chave, que permitem que os anunciantes tenham anúncios mais eficazes
• CAPTCHAs, que existem para impedir que os moderadores tenham que lidar com spam manualmente.

A maioria das histórias técnicas realmente oferece um benefício comercial, mas raramente é para os usuários. Expressá-los de uma maneira diferente pode ajudar. Normalmente, uso o modelo de injeção de recursos de Chris Matts:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

Isso reconhece explicitamente todos os tipos de partes interessadas, incluindo a equipe de desenvolvimento. Agora você também pode descrever suas histórias técnicas, destacando o benefício comercial:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

Eu escrevi algumas postagens de blog sobre isso: elas não são histórias de usuários , injeção de recursos e manipulação de histórias técnicas . Espero que eles ajudem.

Velocidade é uma medida da capacidade da equipe de realizar um trabalho útil (em oposição ao Drag). As tarefas de infraestrutura ainda agregam valor ao usuário final, embora indiretamente, tornando a equipe mais eficiente a longo prazo. Não tenho problemas para rastrear essas coisas como histórias de usuários (o usuário é a equipe de desenvolvedores neste caso) e priorizá-las adequadamente. Um Dono do produto em boa comunicação com o (s) cliente (s) deve ser capaz de descobrir onde essas tarefas podem se encaixar sem interromper as entregas.

Faça-os gradualmente.

Se nenhuma parte interessada quiser, não faça história. Apenas cuide disso, um pouco de cada vez. Por exemplo, a primeira vez que você implanta manualmente. Na segunda vez, você automatiza um pouco disso. Na terceira vez, você automatiza um pouco mais. Eventualmente, sua compilação não é o maior problema, então você se concentra em outra coisa.

Você terá mais dessas tarefas focadas no desenvolvedor no início, e tudo bem; sua velocidade (medida pelas histórias) será apenas menor. Essa é uma representação correta da situação. Mas você sempre terá alguns, por isso é importante que a equipe tenha o hábito de fazer o que é necessário para melhorar o processo.

IMHO, a abordagem ideal é colocar o esforço de infraestrutura como tarefas na história do usuário, onde ele primeiro valoriza; como você mencionou.

Tomando o seu exemplo; criar e implantar manualmente implica que é um esforço contínuo e não tem forma de conclusão. Existe indefinidamente.

O mesmo poderia ser dito para o código que automatiza qualquer parte do esforço em um aplicativo típico que foi feito anteriormente manualmente. Definir esse esforço como uma tarefa em uma história de usuário define completo; que, por sua própria natureza, tem valor para o usuário final.

Você certamente pode criar e implantar o aplicativo em todos os sprints, mas isso se torna parte das tarefas do dia a dia que não são formalmente rastreadas por meio da lista de pendências e tudo isso se torna discutível.

Histórias de usuários definem um valor de negócio da perspectiva do usuário. Por esse motivo, as tarefas de infraestrutura são geralmente consideradas como um "desperdício". Isso não significa que eles não são necessários. Isso significa que realizar mais tarefas de infraestrutura fornecerá menos valor comercial. Por esse motivo, as tarefas de infraestrutura não devem ser consideradas como um histórico de usuários e não devem ser anexadas a nenhuma história de usuário.

Em uma reunião de planejamento, a equipe deve considerar quais tarefas de infra-estrutura serão absolutamente necessárias durante o próximo sprint. O compromisso será feito com essas tarefas de infraestrutura em mente. Isso afetará a velocidade da equipe, que é o resultado correto, porque a velocidade mede quanto valor comercial a equipe pode oferecer.

Eu nunca igualei as histórias de usuários a fornecer valor ao usuário final. Pode ser comum, mas não é assim que lidamos com histórias de usuários. Às vezes, esses tipos de tarefas são considerados picos, mas também tivemos histórias de usuários regulares, pontos estimados como qualquer outra história de usuário.

Pelo que vi, grande parte da infraestrutura é considerada um dado. Isso inclui coisas como:

• Sistema de controle de revisão;
• Sistema de construção automatizado;
• IDE e outras ferramentas de desenvolvedor;
• Servidores de desenvolvimento;
• Processo de implantação; e
• Processo e padrões do projeto.

A maioria das metodologias com as quais trabalhei não dá muita atenção a elas. Eles formam o que eu chamo de Liberação 0. Essas coisas devem estar em vigor antes de você começar o desenvolvimento. Depois que você começar a trabalhar nas histórias, quaisquer mudanças nessas coisas poderão ser rastreadas como melhorias no processo.

Embora a equipe de desenvolvimento possa ter informações, a maioria desses itens deve ser tratada por uma equipe de suporte ao projeto. A padronização desses itens em vários projetos deve ter um retorno significativo para a organização.

Considere o seguinte:

• Equipe Scrum adicionando recursos principais a um conjunto de produtos existente.

• É necessário atualizar a tecnologia / ferramentas / utilitários de desenvolvimento para manter-se atualizado com base nas melhores práticas de engenharia.

• Faz sentido carregar antecipadamente uma versão com este trabalho para que, ao longo da versão, os problemas do Sprints possam ser resolvidos.

• Como a empresa obtém valor indireto desses itens, sugiro que, no interesse da transparência, esses sejam PBIs ( Product Backlog Items ).

• A equipe dimensiona esses itens e os trata como tratariam qualquer PBI.

Esse problema para mim se resume ao fato de que não quero perder tempo tentando descobrir como ocultar esse trabalho como tarefas sob outros PBIs mais centrados nos negócios.

Não quero que o tamanho do PBI seja distorcido por esse tipo de trabalho de infraestrutura. Quero ver o que está sendo feito e entender o que estou pagando.

Também acho que vale a pena que a equipe entenda o compromisso que a empresa está assumindo investindo na infraestrutura necessária para fornecer soluções de qualidade.

O XP recomenda sugerir um "zero de iteração" em que todas as ferramentas e infraestrutura estão configuradas. Escrever histórias para eles é opcional, mas provavelmente é uma boa ideia. Ser capaz de testar sua infraestrutura (criação incremental, teste e implantação automatizados, notificações etc.) é benéfico

Em nossa equipe, fazemos o seguinte:

1. Suponha um fator de foco menor .
2. Tente incluir essas tarefas nas histórias de usuários que realmente precisam implementá-las.
3. Se algumas tarefas são totalmente necessárias, mas não fornecem valor comercial direto (como a migração de testes de unidade de uma estrutura para outra), no início do sprint, criamos uma lista de "tarefas contínuas" . Essas são tarefas relacionadas ao desenvolvimento que não são histórias, mas a equipe de desenvolvimento deseja que elas sejam concluídas. Listamos essas tarefas no quadro-negro, mantendo-as separadas das histórias. Durante o sprint, em cada reunião diária, analisamos o que foi feito para alcançá-los.

O passo 2 é o mais importante. Como em uma prática ágil, no Scrum, você tenta fazer o mínimo possível para realizar suas tarefas. Tome isso como uma maneira de não desperdiçar sua vida fazendo trabalhos desnecessários: minha experiência mostra que até 50% das coisas "que seriam legais" acabam sendo abandonadas e mantidas a longo prazo.