Manipulando trabalho "relacionado" em um único item de trabalho ágil

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.

1. 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.

2. 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?

O planejamento ágil e as histórias de usuários concentram-se em fornecer valor e transparência às partes interessadas no projeto e aos usuários do software. Isso é uma coisa boa, mas não substitui, nem deve substituir, nem rebaixar a importância de boas diretrizes de arquitetura, gerenciamento de projetos, boas práticas de desenvolvimento e manutenção de dívidas técnicas.

O Agile não faz bem o último porque não foi concebido como uma resposta para esses problemas e questões principalmente técnicos.

Sabendo que discordo totalmente de que tarefas de refatoração, tratamento técnico de dívidas e trabalho de design devem ser responsáveis ​​por histórias de usuários separadas em um determinado sprint. Essas são apenas tarefas que um desenvolvedor pode realizar para ajudar a conhecer a história do usuário para esse sprint.

Lembre-se de que uma tarefa é qualquer unidade de trabalho atribuível que ajuda a concluir uma determinada história do usuário dentro das diretrizes de arquitetura e a manter as boas práticas de design e desenvolvimento do software como um todo.

É por isso que a estimativa de horas deve ser feita em tarefas e não em histórias de usuários. É também por isso que algumas tarefas são críticas para a conclusão de várias histórias de usuários.

Vermelho, Verde, Refatorador. Esse é o escopo de um único item de trabalho. Escreva um conjunto de testes com falha que cubra o escopo da alteração, codifique a quantidade mínima necessária para passar no teste e refatore para atender aos padrões de codificação enquanto ainda passa nos testes. Todas as três etapas são necessárias; você não pode codificar a solução até ter definido o problema; se você refatorar ao escrever a linha de código, invariavelmente violará o YAGNI, mas se você não se atrasar e refatorar após passar nos testes, por definição você terá uma dívida técnica. que você eventualmente terá que pagar.

Dada essa definição e que ela foi seguida, um ponteiro de 5 que acaba sendo um ponteiro de 13 foi uma estimativa incorreta. O que você consideraria um trabalho de refatoração provavelmente era mais como reestruturação; você precisava reorganizar uma área bastante significativa da base de código para que a nova funcionalidade fosse incluída de maneira compreensível e sustentável. Isso geralmente indica uma falha da equipe em entender o caminho geral geral do desenvolvimento, levando a que algo seja implementado com muita simplicidade em uma iteração anterior, quando eventualmente seria necessário que ele fosse muito SÓLIDO. Uma melhor comunicação entre os BAs e o PM, que sabem o que está mais abaixo na lista de pendências, e a equipe de desenvolvimento que geralmente se concentra no sprint atual, podem atenuar isso. Como alternativa, essa história expôs uma grande quantidade de dívida técnica incorrida em desenvolvimento passado, e simplesmente alcançou a equipe. Melhores processos de revisão de código, além de um melhor conhecimento conceitual dos padrões de design e do caminho futuro geral do projeto, podem ajudar a reduzir essas ocorrências.

Uma coisa a ter em mente é que a refatoração é um trabalho "não ideal". No Agile SCRUM, as tarefas são estimadas em "horas ideais"; isto é, o número de horas passadas de cabeça para baixo escrevendo código novo em folha que nunca existiu e promove a base de recursos do projeto. Um dia do desenvolvedor de 8 horas pode, realisticamente, ter apenas 5 horas ideais; às vezes, você pode contar com 6, especialmente no "alongamento" de um projeto em que a equipe está realmente animada. Refatorar ou voltar e fazer alterações que não afetam a funcionalidade do projeto, mas que melhoram a base de código de outras maneiras, é um trabalho não ideal, assim como planejamento, design, comunicação, revisão, quebras ou tempo de inatividade técnico. Além do tempo de inatividade técnico, o trabalho não ideal é importante, mas não progride aos olhos do proprietário do produto.

Portanto, desde que a refatoração não duplique as horas reais gastas, uma certa quantidade de trabalho de refatoração é esperada quando você estimar as horas ideais. Digamos, porque eu não sei exatamente como a escala de pontos da sua equipe é calibrada, que um ponteiro de 5 é equivalente a uma semana ideal para desenvolvedores, ou cerca de 25 horas ideais. Aquele 5, que se transformou em 13 (mais de duas semanas de desenvolvedor na mesma escala), é motivo de alguma retrospecção sobre o que causou um aumento na complexidade. Talvez a base de código não precisasse de tanta refatoração quanto a que foi realmente feita, talvez uma grande quantidade de dívida técnica tenha se acumulado sem o conhecimento da equipe que precisou ser resolvida para fazer os novos recursos funcionarem,

Em um universo alternativo, vamos imaginar que um 5 estimado em horas ideais se tornasse 7 (~ 35 horas) com base nas horas reais, porque você precisava de 10 horas de refatoração adicional para colocar o novo código e alguns bits anteriores em um padrão adequado. arquitetura de design. Nesse caso, o extra está dentro da "lacuna" entre horas ideais e totais durante o número de dias do desenvolvedor que a história deveria levar. Então, como gerente de projeto, eu chamaria um 5 que se tornou um 7 de uma estimativa razoável e seguiria em frente.

Os pontos da história são uma estimativa da complexidade relativa de uma determinada história do usuário. Parece que você está usando pontos da história para dizer que isso levará X homem dias / horas. Em vez disso, lute por dois objetivos

1. Divida as histórias até que elas estejam em um intervalo consistente (3, 5 ou 8 pontos)
2. Suponha que a história inclua qualquer refatoração necessária

Com o tempo, isso fornecerá uma linha de base para a velocidade. Cada história de 5 pontos não leva a mesma quantidade de tempo que as outras, mas a velocidade média por sprint (quantos pontos de história a equipe pode completar) será consistente.

Preocupar-se com quanto tempo uma história específica levará é contraproducente. As estimativas apenas medem a média de histórias de tamanho consistente em volume (o ponteiro do IE one 5 pode demorar um pouco mais devido à refatoração, mas você obtém o benefício desse esforço em um relacionado).

Deve haver um corte relativo de quanto está dentro do item de trabalho original e quanto há outra coisa. Histórias de usuários são pontos de partida para discussões e, portanto, pode haver todos os tipos de elementos de escopo a serem definidos durante um sprint durante o trabalho em uma história.

Pode haver momentos em que, em um sprint de planejamento, uma história possa adicionar critérios adicionais a ela, em um esforço para evitar a "fluência do escopo", o que pode acontecer quando um usuário deseja um novo formulário e, em seguida, 101 alterações no formulário que não são realistas para às vezes, é feito em um sprint de 2 semanas.

Um outro lado a ter em mente é quanto valor está sendo ganho com esse trabalho extra. Pode haver toneladas de possíveis refatorações que poderiam ser feitas, mas qual é o benefício de alguém por todo esse trabalho? É aqui que deve haver algumas diretrizes para ajudar a manter a equipe trabalhando bem, mas não se perder na tentativa de aperfeiçoar o código.