Se uma funcionalidade volta repetidamente para correção, verificar mais cedo as premissas da solução pode evitar outra passagem pela implementação. Para reduzir o tempo de desenvolvimento nessa situação, traga feedback útil para o trabalho enquanto ainda há pouco código dependendo de uma decisão.

Uma equipe hipotética está adicionando uma exportação CSV a um relatório existente. Todos concordam que os dados exportados precisam respeitar as permissões do relatório, mas os exemplos de aceitação descrevem apenas o formato do arquivo. O desenvolvedor termina a exportação e, durante os testes de aceitação, a equipe descobre que um usuário com acesso limitado consegue baixar registros que não pode ver no relatório. A implementação precisa ser corrigida e o comportamento verificado novamente antes da entrega.

O retrabalho prolonga o ciclo

As correções prolongam o tempo de ciclo de desenvolvimento da exportação porque a funcionalidade ainda precisa de trabalho antes da entrega. Aqui, esse tempo vai do início do trabalho ativo na funcionalidade ao deploy em produção, depois da aprovação dos testes de aceitação.

O tempo dedicado a investigar e validar a funcionalidade faz parte desse intervalo. Se a equipe começa a verificar premissas mais cedo, mas conta o tempo apenas a partir do primeiro commit, parte do trabalho desaparece da comparação. A preparação continua consumindo tempo, e qualquer redução precisa se manter quando esse tempo entra na conta.

A orientação do DORA sobre testes descreve como o feedback recebido depois de a equipe dar o desenvolvimento por concluído pode exigir correções extensas, incluindo mudanças no design da solução. A recomendação é testar ao longo do desenvolvimento para descobrir problemas enquanto o trabalho ainda está tomando forma.

O requisito de permissão já estava acordado, mas os exemplos de aceitação não mostravam quais registros cada usuário deveria receber. Essa lacuna explica o retorno à implementação no exemplo. Uma equipe cujas mudanças passam a maior parte do tempo esperando revisão ou entrega tem outro problema para investigar, abordado no guia para identificar o gargalo de entrega.

Defina primeiro o comportamento

O desenvolvedor e os responsáveis por produto e testes precisam concordar sobre os registros que cada usuário deve receber. Comparar o relatório com a exportação esperada dá a eles uma forma concreta de verificar esse entendimento antes de concluir a geração do arquivo.

O administrador pode ver todos os registros do relatório do exemplo, por isso a exportação deve conter esses registros. Um usuário com acesso limitado vê um conjunto menor, e a exportação dele deve conter apenas esse conjunto. Esses exemplos dão ao desenvolvedor algo para verificar antes de concluir a geração do arquivo.

A documentação de Example Mapping do Cucumber descreve uma forma de registrar regras, exemplos concretos e dúvidas pendentes durante a discussão de uma história. Ela também separa as novas histórias descobertas na conversa do trabalho que já faz parte do escopo.

Se ninguém souber se a exportação deve incluir registros arquivados, a equipe precisa de uma resposta de quem é responsável por essa regra. Registrar a dúvida e o trabalho que depende dela permite decidir entre resolvê-la naquele momento ou adiar o trabalho afetado. A conversa pode se concentrar nas decisões que mudam o que o desenvolvedor deve construir, deixando as outras perguntas para quando afetarem o trabalho.

Um pedido de outro formato de exportação mudaria o trabalho acordado e precisa de uma decisão de escopo. Corrigir as permissões continua fazendo parte da funcionalidade original, porque a equipe já havia acordado que o arquivo precisa respeitar as restrições de acesso.

Revise cedo a decisão arriscada

A escolha de como obter os registros merece revisão antes que o restante da exportação passe a depender dela. Se essa abordagem não preservar as permissões do relatório, o desenvolvedor precisa saber enquanto ainda há pouco código para mudar.

O revisor pode avaliar essa escolha com a primeira parte coerente da exportação, seus exemplos de aceitação e os testes relevantes. O desenvolvedor deve explicar qual comportamento segue o relatório existente e o que continua sem resposta, para que o revisor examine a abordagem antes que mais partes da funcionalidade sejam construídas sobre ela.

A orientação do Google sobre mudanças pequenas aponta o trabalho desperdiçado quando uma mudança grande chega à revisão e o revisor identifica que sua direção está errada. Ela recomenda mudanças autocontidas que incluam o contexto necessário para compreendê-las.

O revisor precisa ver como a exportação seleciona os registros, com código suficiente ao redor para acompanhar a decisão. As práticas de revisão de código da equipe continuam valendo. Dividir a mudança em fragmentos que escondem esse comportamento dificultaria a revisão da decisão.

Teste além do formato do arquivo

A exportação pode ter colunas e delimitadores corretos e ainda retornar os registros errados. Seus testes precisam verificar o comportamento de permissão do relatório durante o desenvolvimento, para que a equipe confira o requisito que provocou a correção original.

Um teste unitário poderia verificar uma regra de permissão isoladamente, enquanto um teste pela aplicação verifica os registros que chegam ao arquivo exportado. Se os resultados divergirem, a equipe precisa rastrear a diferença antes de ampliar a funcionalidade. Desativar a verificação que falhou ou reexecutá-la até que passe deixaria a divergência sem explicação.

A orientação do DORA sobre integração contínua relaciona integração frequente e feedback à identificação e correção de problemas em mudanças menores. Ela também reconhece que concluir uma funcionalidade grande em uma branch pode levar menos tempo do que integrá-la de forma incremental, mas distingue essa conclusão local da entrega de software revisado e testado.

A equipe pode verificar cada incremento coerente da exportação com o relatório existente durante o desenvolvimento. Isso dá ao desenvolvedor feedback sobre o comportamento de permissão enquanto ainda é possível mudar a abordagem, antes de terminar o trabalho que depende dela.

Meça o ciclo completo

Compare mudanças semelhantes usando os mesmos eventos de início e fim, incluindo o tempo dedicado a esclarecer exemplos e verificar a abordagem. Uma etapa de implementação menor, sozinha, não demonstraria que o ciclo completo de desenvolvimento ficou mais curto.

Registre por que o trabalho voltou à implementação para distinguir uma correção de comportamento mal compreendido de um novo requisito ou de uma descoberta útil. Comentários e rodadas de revisão precisam de contexto, já que uma revisão cuidadosa pode impedir que um defeito chegue aos usuários.

Na sequência hipotética de feedback tardio, a equipe constrói a exportação, descobre a divergência de permissão na aceitação, corrige a implementação e repete as verificações. Na sequência de feedback antecipado, a equipe explicita os registros esperados, verifica a abordagem enquanto ela é pequena e desenvolve o restante da exportação usando esse feedback. O exemplo mostra em que momento o feedback entraria no trabalho, mas não contém dados de tempo que permitam estimar uma economia.

Mantenha um registro curto ao experimentar essa abordagem em uma mudança da sua equipe.

  • Registre a decisão incerta, como quais registros a exportação pode incluir.
  • Identifique a evidência necessária, como a correspondência entre os registros permitidos no relatório e no arquivo.
  • Escolha quando obter essa evidência, antes de ampliar a abordagem de seleção dos dados.
  • Observe se o mesmo mal-entendido provocou um retorno posterior à implementação.

Acompanhe separadamente os problemas descobertos depois do deploy, porque eles ficam fora do ciclo da funcionalidade já concluída. O DORA recomenda interpretar o desempenho de entrega em contexto, combinando medidas de throughput e instabilidade. Um ciclo mais curto seguido de mais trabalho corretivo merece investigação.

Escolha uma mudança recente que voltou para correção e pergunte às pessoas envolvidas qual informação chegou tarde. Combinem como obter essa informação mais cedo na próxima mudança comparável e, depois, comparem o ciclo completo e o trabalho que surgiu após a entrega.