Como fazer uma revisão eficiente do código durante a febre do lançamento?

O prazo para o lançamento é amanhã, seu colega finalmente terminou sua tarefa crucial para este lançamento, o gerente de projeto está de pé por cima do seu ombro e pressiona você para finalmente fazer uma compilação e você percebe uma falha no código do seu colega durante a revisão. Não é crítico, mas algo que você não deixaria de lado se não fosse pelo lançamento amanhã. E para piorar as coisas, você tem seu próprio trabalho e precisa terminar o mais rápido possível. Então, o que você faz? Você levanta sua objeção apesar da pressão ou apenas deixa escapar esta?

Uma maneira que encontrei é mesclar temporariamente esse commit em um ramo diferente e deixar a revisão para mais tarde. Funciona se o problema é apenas cosmético e se é o único que ainda aguarda a revisão do código. No entanto, existe uma maneira mais eficiente de lidar com isso? Por exemplo, você recomendaria comprometer uma pessoa a apenas revisão e testes de código?

A resposta aqui é se comunicar.

1. Informe o líder técnico / da equipe sobre o problema
2. Converse com o controle de qualidade sobre o impacto potencial
3. Informe ao gerenciamento do projeto (que está logo atrás de você) que pode haver um problema que causa o atraso da liberação e você voltará com ele o mais rápido possível (em questão de minutos ou horas)
4. Avalie se esse problema é um impedimento para o lançamento

Se o problema não for um impedimento de exibição, continue com o lançamento. Informe o controle de qualidade e seus usuários sobre o problema e comprometa-se com uma data de acompanhamento em que o problema será corrigido. Isso apenas se torna outro risco para a produção.

Se for um impedimento de exibição (o que significa que terá um impacto negativo na linha de fundo ou na saúde de alguém), comunique isso à cadeia que sua recomendação é adiar o lançamento e informe o motivo. Em seguida, volte com o desenvolvedor e calcule quanto tempo levará para corrigir o problema e informe ao gerenciamento que você precisa de um número X de minutos / horas / dias.

As chances são de que a gerência não ficará feliz com a interrupção do programa no final do jogo, mas não desejará que isso seja liberado para produção.

Comunique-se e deixe a gerência fazer a ligação.

Não basta comunicar o problema, documentá-lo

Minha grande preocupação com as outras respostas até agora: tudo o que você disser nesse sentido para o gerente de projetos típico que enfrenta um prazo iminente provavelmente será ignorado ou esquecido. Então, você ainda pode ficar no gancho por comunicar insuficientemente o risco, se algo der errado.

Informe o gerente de projeto sobre o problema encontrado e informe que você o documentará . Você precisa ser capaz de apontar para sua devida diligência.

Onde documentar e quem contar depende do seu ambiente de trabalho, mas definitivamente inclua seu chefe.

Identifique riscos e impactos

Você mencionou que o problema não é crítico, mas realmente não define o que isso significa. Explorar isso é o seu próximo passo.

Faça uma análise rápida de riscos e impactos, identificando o problema, qual a probabilidade de causar um problema (risco) e a gravidade das consequências se o risco der certo. Use termos bem definidos (que seu gerente de projeto deve conhecer) como os encontrados no link acima, mas também forneça uma descrição para fazer backup de sua análise.

Sua documentação também deve incluir o curso de ação recomendado. Sim , não há problema em levantar uma preocupação e ainda recomendar a continuação do lançamento. É correto identificar o risco .

Quando é o seu próximo lançamento?

Se, depois de concluir sua análise de risco / impacto, você ainda estiver em dúvida sobre o que recomendar, leve em consideração seu cronograma de liberação. Algum código imperfeito pode ser liberado se você puder incluir a correção em duas semanas.

Se houver a chance de corrigir a sua preocupação "desvalorizada" (ou seja, negligenciada em favor do próximo aprimoramento brilhante), esse é mais um motivo para documentar o problema o mais rápido possível depois que você o descobrir: se efetivamente "começar o relógio ”sobre o assunto.

Nesse caso, basta informar a todos e deixá-los decidir. Provavelmente não é o primeiro bug lançado.

O prazo é amanhã, mas você se encontra nesta situação:

gerente de projeto está de pé por cima do seu ombro e pressiona você para finalmente fazer uma compilação

Esta pode ser a exceção, portanto, não faça alterações drásticas no seu processo apenas porque um erro ocorreu. O que você deve fazer é implementar algumas medidas, para que você não faça builds no último minuto. Felizmente, você está fazendo builds com uma frequência regular o suficiente para lhe dar confiança de que terá sucesso. Ainda não é um motivo suficientemente bom para executá-los no último minuto. Ter as coisas bem testadas é outra peça para aumentar a confiança.

Apresente esse cenário para quem está liderando essa coisa.

• Determine que tipos de problemas devem ser apresentados.
• Identifique as opções.
• Quem toma a decisão
• Quando tudo isso deve ser decidido? Provavelmente será relativo à data de lançamento.

Embora isso não responda o que fazer com esse problema de última hora, ele oferece uma maneira de garantir que você possa lidar com eles no futuro. Especialmente quando há pressão para liberar, você quer ter uma maneira de lidar com as coisas de uma maneira que seja pensada e não movida por emoções.

Se houver um prazo, e seu gerente estiver logo atrás de você, olhando por cima do ombro, peça para ele ir embora. Ele vai embora ou você vai embora. Explique a ele que, sendo forçado a revisar sob pressão, você também não deve revisar o código.

Em uma situação como essa, você pode ter certeza de que algum bug crítico será solucionado.

Você pode estar em uma situação de sorte, como enviar para a App Store da Apple, onde você tem alguns dias para retirar uma nova versão. Mas se o seu código for enviado aos clientes, é uma receita para o desastre. Na próxima vez, espero que seu gerente planeje melhor.

Outras respostas se concentram no problema de seu gerente tentar flexionar seu processo de qualidade.

No entanto, acho que você está perguntando como lidar com o fato de que a revisão de código requer pelo menos 2 pessoas e, portanto, introduz atrasos significativos. Por exemplo, se uma tarefa leva 2h para implementar e 2h para revisar, geralmente há uma longa pausa entre as duas atividades. Em tempo real, a tarefa pode levar 2 ou 3 dias para ser concluída.

Esse é um problema clássico de taxa de transferência versus latência. Em máquinas de produção de software (seres humanos), as alternâncias de contexto são caras, portanto, antecipar o trabalho de alguém para fazer uma revisão imediata não deve ser uma prática comum.

Aqui estão algumas dicas para atenuar o problema:

• Enquanto estiver trabalhando em uma tarefa, envie o código em pequenas partes, para que o revisor não precise reservar longos e contínuos períodos de tempo.
• Promova uma cultura de alta prioridade para revisões de código. Não pare sua unidade de trabalho atual quando receber uma solicitação, mas quando estiver se perguntando o que fazer a seguir, escolha sempre uma revisão da sua fila.
• Aproveite a diferença de fuso horário em suas equipes, se houver uma.
• Não comprometa uma única pessoa a revisar apenas o código. É contraproducente. Ele não será capaz de lidar com a carga, se quiser levar a sério sua tarefa. Seu gerente não aceitará a idéia de alguém ficar ocioso, apenas para potencialmente economizar um dia.