Scrum: Como trabalhar em uma história de cada vez

Fui indicado como scrum master em uma nova equipe de scrum formada. Já fizemos alguns sprints. No começo, tentei fazer minha equipe trabalhar em uma história de cada vez. Mas não deu certo. Minha equipe teve dificuldades para distribuir as tarefas de forma que elas possam trabalhar simultaneamente em uma história. Talvez estejamos fazendo algo errado?

Por exemplo: temos uma história para criar uma nova caixa de diálogo. Criamos as seguintes tarefas:

• Criar classes de modelo
• Ler dados do modelo do banco de dados
• Conectar classes de modelo com vista
• Implementar manipulação de diálogo
• Salvar dados ao fechar
• Documentação de teste
• Descrição da solução

Essas tarefas podem ser executadas por mais de uma pessoa por vez? As tarefas - mais ou menos - se baseiam. Ou projetamos as tarefas de maneira errada?

Por que toda a equipe deve trabalhar em uma única história?

Por que não fazer histórias pequenas o suficiente (e independentes o suficiente) para que uma pessoa (ou melhor, um par fazendo programação em pares) possa trabalhar em uma única história. Esse processo também ajuda a definir melhor os requisitos e a pensar mais sobre o problema e a implementação. As estimativas também podem se tornar mais precisas, mas não há garantias aqui.

Embora isso dependa muito do tamanho da história do usuário, em muitos casos, apenas um desenvolvedor deve ser atribuído a uma história para evitar que seus desenvolvedores pisem nos dedos dos outros. Embora histórias maiores ou muito complexas possam exigir mais desenvolvedores, mas também pode ser possível dividi-las em muitas histórias menores que podem ser atribuídas individualmente.

O que geralmente fazemos é dividir as histórias em subtarefas dev / infra / analyst.

1. Geralmente, qualquer coisa com mais de um dia de trabalho é uma história.

2. Depois que as tarefas são divididas, um ou no máximo dois desenvolvedores trabalham em uma história, dependendo do número de tarefas em mãos. Geralmente é esse.

3. Registramos o tempo gasto e atualizamos a estimativa restante no final do dia antes de partirmos ou antes de levantarmos diariamente.

4. As subtarefas são criadas para quaisquer novos problemas que surgem durante o trabalho.

5. Uma história com mais de duas semanas de trabalho é considerada uma Epopéia.

6. Uma epopeia pode ser composta de muitas histórias

O que você deseja que sua equipe faça é chamado de enxame , mas nem todos os itens da lista de pendências podem ser espalhados por toda a equipe. O pensamento comum é que o enxame requer algumas pré-condições:

• uma equipe multifuncional e colocada
• uma história não trivial
• uma definição de "feito" que implica o envolvimento de toda a equipe

Ao dividir uma história em tarefas, a equipe já deve estar no modo de enxame, para que as tarefas geradas sejam compatíveis com o enxame e possam envolver toda a equipe.

Mas tenha cuidado ao usar o enxame com muita frequência ou com muitas pessoas ao mesmo tempo, pois você pode encontrar um problema excessivo, quando alguns conflitos podem aparecer entre os membros da equipe, pois muitos deles estão trabalhando no mesmo item.

Você pode ler o livro de Mike Cohn, " Deve uma equipe passar por um item de backlog" de cada vez? ou este artigo que escrevi (ontem) que trata mais especificamente de bugs: Enxame ou não enxame

Uma grande parte do SCRUM é que a equipe deve tomar esse tipo de decisão. A lista de pendências deve ter as histórias do usuário com informações esperançosamente suficientes para que as tarefas sejam geradas.

Embora seja possível coagir uma história do usuário a um item no qual toda a equipe possa trabalhar simultaneamente, o mais importante é que a equipe escolha os itens para trabalhar, define as tarefas para finalizar a história do usuário e usa o suporte diário para ver se você está no caminho certo com o trabalho prometido.

A dor que você sente ao tentar trabalhar em apenas uma história de cada vez precisa ser reconhecida pela equipe e em possíveis soluções retrospectivas em sprint, é preciso trazer à tona. Descubra o que você está fazendo certo e o que precisa ser melhorado.

Usando seu exemplo da dificuldade na distribuição de tarefas que podem ser trabalhadas simultaneamente, uma solução possível é assumir várias histórias e entregar 3 ou 4 itens em um sprint. Como as tarefas dessa história de usuário são construídas umas sobre as outras, será difícil distribuir o trabalho. Então, ao invés de lutar contra isso.

Suas tarefas, conforme indicado, parecem 'pequenas' o suficiente para serem distribuídas, mas há algum acoplamento entre tarefas como a de modelar os dados e recuperá-los do banco de dados.

O que seria possível é dividi-lo em três coisas principais nas quais as pessoas podem trabalhar simultaneamente, com algum trabalho / configuração extra:

• Back-end (banco de dados, modelo etc.)
• Front-end (usando dados simulados)
• Testes (configurando expectativas, cenário etc.)

Tarefas que não podem ser divididas podem ser feitas por pares. E, é claro, não há nada inerentemente errado com mais de uma história em andamento a qualquer momento; desde que todos os membros da equipe saibam o que os outros estão fazendo e possam ajudar sempre que necessário (como em 'propriedade do código compartilhado').

Você deve manter sua equipe focada, sim, mas ao mesmo tempo precisa manter todos ocupados e todos envolvidos.

Além disso, qual é o tamanho da sua equipe? Este também é um fator; é muito difícil ter dez pessoas trabalhando em uma história e, se você puder, sua história é muito, muito grande e deve ser dividida (assim como sua equipe).