Estou em uma equipe de projeto de 4 desenvolvedores, inclusive eu. Temos discutido muito sobre como lidar com o trabalho extra que surge no decorrer de um único item de trabalho.
Esse trabalho extra costuma ser algo ligeiramente relacionado à tarefa, mas nem sempre necessário para atingir a meta do item (que pode ser uma opinião). Os exemplos incluem, mas não estão limitados a:
- refatoração do código alterado pelo item de trabalho
- código de refatoração vizinho ao código alterado pelo item
- re-arquitetando a área maior do código em torno do ticket. Por exemplo, se um item altera uma única função, você percebe que toda a classe agora pode ser refeita para acomodar melhor essa alteração.
- melhorando a interface do usuário em um formulário que você acabou de modificar
Quando esse trabalho extra é pequeno, não nos importamos. O problema é quando esse trabalho extra causa uma extensão substancial do item além da estimativa do ponto de recurso original. Às vezes, um item de 5 pontos leva 13 pontos. Em um caso, tínhamos um item de 13 pontos que, em retrospecto, poderia ter sido 80 pontos ou mais.
Há duas opções disponíveis em nossa discussão sobre como lidar com isso.
Podemos aceitar o trabalho extra no mesmo item de trabalho e descartá-lo como uma estimativa incorreta. Os argumentos para isso incluem:
- Planejamos "preenchimento" no final do sprint para explicar esse tipo de coisa.
- Sempre deixe o código em melhor forma do que você o encontrou. Não faça check-in no trabalho pela metade.
- Se deixarmos a refatoração para mais tarde, é difícil agendar e talvez nunca seja feito.
- Você está no melhor "contexto" mental para lidar com esse trabalho agora, já que já está na cintura do código. Melhor sair do caminho agora e ser mais eficiente do que perder esse contexto quando voltar mais tarde.
Nós desenhamos uma linha para o item de trabalho atual e dizemos que o trabalho extra entra em um ticket separado. Os argumentos incluem:
- Ter um ticket separado permite uma nova estimativa; portanto, não estamos mentindo para nós mesmos sobre quantos pontos as coisas realmente são ou para admitir que todas as nossas estimativas são terríveis.
- O "preenchimento" do sprint destina-se a desafios técnicos inesperados que são barreiras diretas ao preenchimento dos requisitos de ingresso. Não se destina a itens secundários que são apenas "agradáveis".
- Se você deseja agendar a refatoração, basta colocá-lo no topo da lista de pendências.
- Não há como contabilizar adequadamente essas coisas em uma estimativa, uma vez que parece algo arbitrário quando surge. Um revisor de código pode dizer que "esses controles da interface do usuário (que você realmente não modificou neste item de trabalho) são um pouco confusos, você pode corrigir isso também?" que dura cerca de uma hora, mas eles podem dizer "Bem, se esse controle agora herdar da mesma classe base que as outras, por que você não move todo esse código (centenas de linhas de) para a base e religa todas essas coisas? , as mudanças em cascata etc.? " E isso leva uma semana.
- "Contamina a cena do crime", adicionando trabalho não relacionado ao ticket, tornando nossas estimativas de pontos de recurso originais sem sentido.
- Em alguns casos, o trabalho extra adia um check-in, causando o bloqueio entre os desenvolvedores.
Agora, alguns de nós estão dizendo que devemos decidir alguns cortes, como se o material adicional for menor que 2 FP, ele vai para o mesmo ticket, se for mais, transformá-lo em um novo ticket.
Como estamos apenas alguns meses usando o Agile, qual é a opinião de todos os veteranos do Agile mais experientes por aqui sobre como lidar com isso?