A correção de bugs é uma parte tediosa, mas obrigatória, de qualquer desenvolvimento, e nem todo mundo quer fazê-lo. Como transformar correções de bugs em algo emocionante? Organize uma competição! Neste post, falaremos em detalhes sobre a nossa "maratona de correções" de 24 horas - desde a preparação preliminar até a coleta dos últimos commits após a premiação dos vencedores.
Infectado com a ideia
A escala de desenvolvimento de nosso aplicativo Sberbank Online aumentou significativamente no ano passado. Junto com isso, pequenos bugs começaram a se acumular, o que não se refletia de forma alguma nas principais métricas. Mas entendemos que esta é uma bomba-relógio e algo precisa ser feito com ela.
Ficamos inspirados em como nossos colegas da
Avito resolvem esses problemas e decidimos organizar um ataque maciço a bugs no formato bagaton - levando em consideração nossa estrutura de desenvolvimento, cultura e especificidades do fluxo.
Era necessário organizar tudo para que os próprios rapazes quisessem participar de um bagaton e provar sua frieza sem as diretrizes de cima. Para fazer isso, a competição deve ter uma atmosfera legal. Decidimos criar um estilo especial, algo reconhecível sobre bugs. Bugs são bugs. Quem destrói bugs na vida cotidiana? Os desinfetadores são homens de terno amarelo de proteção química. Onde eles foram acesos nos últimos anos? Em uma série popular sobre um professor de química. Existe uma base, terminamos com atividades. Eles organizaram um torneio de videogame, um questionário com prêmios, indicações individuais legais ... e, claro, muita comida deliciosa. Mas o principal, seja o que for que se diga, é a competição pela eliminação de bugs. Isso lembrou um painel com uma interface da web, mostrando o progresso das equipes, suas posições atuais, número de pontos, etc. Discutimos tudo com os líderes de equipe - eles aprovaram nossos planos.
Android vs iOS - tão desonesto
Primeiro, queríamos pressionar os desenvolvedores do Sberbank Online Android com seus colegas do iOS, a jogar na rivalidade das plataformas. Porém, no processo, as organizações perceberam que essa não é a melhor solução, porque tecnicamente as plataformas funcionam em condições desiguais. Aconteceu que no iOS, as compilações são mais rápidas e os autotestes são executados.
Em seguida, mudamos o formato e criamos equipes mistas: cinco desenvolvedores para Android e iOS cada. Anteriormente, os capitães eram escolhidos entre desenvolvedores proativos para ajudar a formar equipes. Foram nove equipes. E apesar do fato de termos descoberto a questão do hardware do ponto de vista do fair play, ainda tínhamos que garantir que outras restrições não atrapalhassem o nosso exército de consertadores de bugs.
A próxima missão foi a escolha da data do bagaton. As datas de lançamento para cada plataforma são diferentes - elas foram selecionadas para que todos ficassem à vontade. Tentamos tornar a data o mais próxima possível da data em que o candidato a liberação foi designado.
Além disso, a bagaton carrega pesadamente infra-estruturas de plataforma. Quando há uma competição, que corrige bugs mais rapidamente, o número de solicitações de recebimento decola. Outro mês e meio antes da bagaton, havia o risco de que nossos equipamentos não pudessem lidar com os picos previstos. Mas, naquele momento, esperávamos ferro novo, que chegou bem a tempo. Conseguimos conectar, configurar e fortalecer a infraestrutura de largura de banda de ambas as plataformas várias vezes.
Pipeline - como não abaixar tudo em um tubo
Tudo foi feito aqui da seguinte forma: imediatamente antes do início do bagaton do nosso desenvolvimento, assumimos o ramo em que as equipes tinham que trabalhar. Um monte de solicitações pull com bugs corrigidos foi derramado durante a bagaton. Os autotestes foram executados em cada um deles, os desenvolvedores revisaram as solicitações pull e os testadores verificaram novas construções para corrigir o erro. E assim, todas as 24 horas da competição.
Também foi necessário distribuir a carga dos testadores. Fizemos um gráfico horário do número previsto de solicitações pull no intervalo de bagaton de 24 horas - dependendo do número de participantes, carga do servidor, atividades de terceiros, etc. Comparado com o desempenho médio dos testadores e o número de horas efetivas de cada bagaton acompanhante. Distribuímos o "dever" para que, na manhã de sábado, as filas fossem o menor possível. Em geral, eles ficaram confusos.
Ao mesmo tempo, levamos em conta que, após o bagaton, era necessário iniciar imediatamente o teste de regressão para avaliar a qualidade do ramo o mais rápido possível e decidir sua infusão no ramo dev. Esse é um ônus adicional para os testadores.
Revisão de Recursos
Foi muito importante para nós não apenas corrigir bugs, mas fazê-lo qualitativamente. Três procedimentos fornecem a verificação do código enviado pelos desenvolvedores em solicitações pull. Para que o código se encaixe, eles devem passar com êxito:
- Três desenvolvedores experientes revisaram e aprovaram o código.
- o código normalmente falhou e não falhou nos autotestes;
- Após a construção e a infusão, o erro na montagem nas condições descritas não é retomado.
Temíamos que, no modo competitivo, ninguém se revelasse. E dentro da equipe, você não pode deixar um comentário. Portanto, eles decidiram não inventar nada e agir no fluxo padrão, como no modo de trabalho: uma revisão cruzada arbitrária - quem quer que seja livre, ele assume o processo.
Também era necessário rastrear para que as críticas não fossem para a fila. Para garantir a segurança, atraímos assinantes para a revisão (mesmo aqueles que não participaram do próprio bagaton) e lembramos ativamente os participantes da orientação sobre qualidade. Um desenvolvedor sênior de iOS, paralelamente à correção de bugs para sua equipe, em um dia recebeu 80 solicitações pull - ele leu e entendeu. Isso é realmente muito!
Selecionamos e avaliamos bugs
Pegamos bugs de baixa prioridade, eliminamos o lixo óbvio por rótulos e datas. No total, 490 bugs acabaram - principalmente pequenos e médios, que as mãos não alcançaram por causa de tarefas mais importantes. Estes são todos triviais e menores sãos:
- erros que foram movidos repetidamente de versão para versão
- erros acabaram em solicitações de usuários
- acidente mais recente
- erros de regressão
- bugs que afetam o UX
Todos os bugs foram divididos em três ondas de acordo com a prioridade de fechamento:
- A primeira onda - cerca de 230 bugs
- A segunda onda - cerca de 150 bugs
- A terceira onda (reserva) - cerca de 110 bugs
Os defeitos foram avaliados não pela complexidade, mas pela criticidade para os negócios. Os mais críticos são "artificialmente" e temporariamente colocados em prioridade "bloqueador" e "crítico". Quanto maior a prioridade do bug, mais pontos serão concedidos por ele. A complexidade não foi levada em consideração - aconteceu que o bloqueador de bugs foi fechado em 20 minutos e o trivial - em 4 horas. Por um bug, você pode ganhar de 1 a 7 pontos.
Mantemos a pontuação de cada equipe para erros fechados, de acordo com seu valor nas regras de bagaton. Se as equipes tivessem tempo, levariam ao trabalho o seguinte defeito. A motivação através do valor tornou possível fechar, em primeiro lugar, os erros mais críticos.
Como fechar bugs
Dividimos a primeira onda de bugs em 11 grupos (com margem), iguais em número de pontos e na proporção de Android e iOS. A primeira onda é de bugs "caros", prioritários com aumento de custo. Para uma pesquisa conveniente em Jira, atribuímos a eles os rótulos apropriados. Cerca de 20 erros foram lançados em cada grupo.
No início da bagaton, reunimos capitães de equipe e tocamos em selos. Além disso, os capitães em seus filtros designaram o rótulo desejado e distribuíram os erros correspondentes dentro da equipe. Então, conseguimos eliminar a correção caótica de bugs, onde os caras simplesmente aceitavam o que é mais compreensível para eles.
Nas primeiras quatro horas, as equipes ganharam pontos apenas por bugs com os rótulos do grupo que tinham caído para definir um ritmo específico. Quando o tempo acabou, os bugs ainda abertos passaram para a segunda onda, aumentando os outros que faziam sentido fechar dentro do bagaton.
Às 19:00, todos os bugs não fechados foram para a terceira onda - além dos bugs que já estavam planejados lá. Como resultado, durante a noite, tivemos bugs "rápidos" que fechariam no fluxo usual: caches e atuais, descarregados literalmente um dia antes da bagaton, bem como bugs com a menor prioridade. Todas as três ondas foram trabalhar. Como resultado, 286 dos 493 bugs selecionados foram fechados para bagaton.
Bagaton une
A sede da Bagaton estava localizada em nossa sala de conferências, também havia testes e um torneio de videogame. As equipes não eram limitadas, espalhadas sempre que conveniente para elas. Como resultado, todo o banco descobriu o bagaton. Um vendedor de produtos do quarto andar disse: “Vou me encontrar no 14º andar, procurando a sala de reunião certa. De repente, entendo que acabei de ver rostos familiares, estou voltando - meus desenvolvedores estão sentando figuras com poder e principal, e sem nenhuma atenção para mim. Ha - eu acho - eles não vão se esconder do dono do produto e, em 10 andares, tudo bem, sente-se, a correção de bugs é uma coisa certa. ”
Havia uma equipe na qual apenas um Android chegou ao mercado e, ao mesmo tempo, seis fortes desenvolvedores de iOS. Nós, excepcionalmente, eliminamos esse time de outro pacote com bugs do iOS.
Além disso, sete desenvolvedores das regiões chegaram ao bagaton. Alguns conheceram suas equipes pela primeira vez, o que haviam visto anteriormente apenas por videoconferência. Foi muito legal ver como esses caras se juntaram ativamente ao processo.
Como os resultados foram avaliados?
Para quase uma centena de desenvolvedores, tínhamos apenas 15 testadores. E à noite há quatro. Como todos não eram suficientes, os testes continuaram no dia seguinte. Foram os testadores que atribuíram pontos às equipes, então os removemos da equipe para eliminar o viés. Em um fluxo de trabalho normal, o testador pode ligar para o desenvolvedor e descobrir: "Escute, cara, existe um problema ...". Na bagaton, era rigoroso: os testadores deveriam envolver tudo o que não passa claramente.
Portanto, pudemos ver que alguns desenvolvedores não estão trabalhando no fluxo aceito. Hackathon se tornou um tipo de catalisador para todos os desvios. Aqueles que trabalham claramente no fluxo conseguiram passar nos testes na primeira onda e ganhar pontos. Todo mundo que realmente não se correspondia entrou na fila, que eles já haviam buscado após bagaton. Tem 60 bugs.
Incidentes
Em geral, tudo correu normalmente, os incidentes eram típicos e resolvidos em perfeitas condições. Quando algo quebrou, alguns dos Signatários imediatamente mudaram da correção de bug para a eliminação do incidente.
Houve um incidente engraçado. Ao preparar o painel, descrevemos os possíveis riscos: acesso ao Jira, atualizações contínuas etc. Eles notificaram a todos os administradores que, durante o período de bagatela, era necessário suspender todos os trabalhos de manutenção, atualizações do Jira e servidores. Criou contas de backup para acessar o Jira. E, de repente, por volta das 18:00, percebemos que o painel parou de coletar dados. Pressupostos eram diferentes. Talvez eles não levassem em conta algum tipo de protocolo de segurança? O motivo foi inesperado. Nossa organização é muito grande, nem sempre é possível obter informações completas sobre todos os processos planejados. Nosso painel foi implantado em uma máquina virtual em um dos servidores secundários. Aconteceu que foi neste dia, sexta-feira à noite, que este servidor, de acordo com um plano desconhecido, foi desconectado fisicamente da tomada, carregado no carro e enviado para residência permanente em nosso novo data center. Como resultado, na manhã de sábado, tivemos que coletar todos os dados e calcular pontos no modo manual.
Mesclar ramificações e outros resultados
No modo de operação normal, toda a ramificação é acionada manualmente por mais de 800 casos de teste. Uma equipe completa de testadores realiza nossos testes de regressão em tempo integral em duas semanas. Não podíamos continuar desenvolvendo inalterados por tanto tempo. Para reduzir o tempo de teste, selecionamos os principais casos de teste da saúde do aplicativo - cerca de 107. Até o final de segunda-feira, eles dirigiam 80% do iOS, 50% do Android e não revelavam um único erro crítico. Decidimos que as filiais podem ser mescladas.
Dos 286 bugs fechados no bagaton, 182 bugs foram corrigidos. O restante são redjacks que não são relevantes por várias razões, bugs (em algum lugar o design ou funcionalidade já foi alterado). Esses erros não são críticos, mas agora não precisam mais ser distraídos e você pode se concentrar com calma em tarefas importantes.
Além disso, muitos, seguindo os resultados do bagaton, tinham uma pergunta: quantos bugs fizemos? Apenas oito erros no iOS e sete erros no Android.
É importante para nós que os desenvolvedores se sintam responsáveis pelo código do produto em igualdade de condições com outros membros da equipe. Isso é importante em qualquer desenvolvimento, mas no desenvolvimento distribuído, ele se torna um pré-requisito para um trabalho bem-sucedido. E, em nossa opinião, conseguimos aumentar o nível dessa mesma propriedade e espírito de equipe. O resultado foi uma história com muito lucro: em pouco tempo, consertamos vários bugs, atrasos não carregados, aprimoramos as habilidades da equipe e conseguimos muitos fãs.
Material preparado pela equipe do Sberbank Digital Business Platform