Este material foi preparado pelo nosso parceiro, Equio .
Comprando um produto de TI para resolver vários problemas corporativos, os clientes corporativos costumam pensar em seu custo, funcionalidade, conveniência, recursos de integração etc. Essas não são questões tão óbvias, como a qualidade e o nível do suporte técnico, que já estão pensando em segundo lugar.
Mas a qualidade do produto final depende, em grande parte, de como o desenvolvedor organizou o processo de teste, identificação e correção de bugs, entre desenvolvedores conhecidos como "bugs" (do bug em inglês - um bug, qualquer inseto, vírus, gíria que geralmente significa erro) no programa). Esta pergunta é feita por muito poucos clientes empresariais individuais.
Queremos falar sobre como os desenvolvedores identificam e corrigem bugs, são adequados para teste. Uma abordagem é baseada na Política de Zero Bug.
Spoiler! Vamos dizer em que os desenvolvedores realmente gastam tempo e por que eles não corrigem todos os bugs. 
Sete babás
Há uma piada bem conhecida dedicada ao anúncio do novo lançamento "Desempenho otimizado de aplicativos, correções de bugs, novas adicionadas". De fato, corrigir bugs e adicionar novos é um processo eterno, bugs antigos são corrigidos, mas não surgem menos novos.
Isso é especialmente perceptível quando um grande número de desenvolvedores ou mesmo várias equipes de projeto trabalham em um produto de software, em uma única base de código. É muito difícil sincronizar seus esforços e obter o código completamente livre de erros de saída. Por exemplo, uma equipe salvou as alterações na ramificação principal, ou seja, na versão principal do código no repositório (repositório). Por sua vez, a outra equipe enfrenta um grande número de conflitos e está tentando corrigi-los. Como resultado, tudo isso entra no lançamento, ou seja, na versão final do produto, adequada para usuários comuns, e aqui uma quantidade incrível de bugs aparece. E isso está repleto de perda de dinheiro, clientes e, mais importante, uma ameaça à reputação do desenvolvedor.
Então, o que fazer nesta situação? Você pode colocar toda a sua força e recursos na correção de erros, mas como então você pode se envolver no desenvolvimento de produtos, melhorar os existentes e adicionar novas funções?
Fora de vista, saída em atraso
Uma grande empresa de TI teve um problema semelhante. Graças à recomendação de um dos especialistas que trabalhava na empresa, decidiu-se aplicar a abordagem da
Política de Zero Bug . Infelizmente, pouco foi escrito sobre ele em russo ainda.
Sua essência é a seguinte. Quando os testadores ou usuários encontram algum bug no produto e informam os desenvolvedores sobre o mesmo, estes decidem se esse bug será corrigido ou não afetará o desempenho do produto e, portanto, sua correção poderá ser atrasada ou completamente excluída. da lista de pendências (lista de tarefas). Esse bug recebe o status Won't Fix, após o qual desaparece para sempre do campo de visão dos desenvolvedores. Em alguns casos, os erros com esse status são colocados no final do backlog. Isso significa que os desenvolvedores "colocarão as mãos em" para corrigi-los somente quando todas as outras tarefas forem resolvidas.
Mas voltando à empresa de TI já mencionada. Seus funcionários analisaram toda a lista de bugs detectados e classificaram os problemas encontrados. Quase metade dos erros foram resolvidos em um futuro próximo e mais da metade recebeu o status Won't Fix. Todo esse trabalho levou cerca de dois meses, após os quais a empresa decidiu adotar a
Política de Zero Bug continuamente. Até o momento, esta empresa não possui mais de 10 tarefas abertas no backlog. Isso permite que você se concentre na implementação de novos recursos.
Especialistas em bugs
Como os bugs são classificados? Quem toma a decisão de que um erro é crítico e precisa ser corrigido, enquanto no outro é possível continuar vivendo em paz ou adiar sua correção para mais tarde?
Informaremos como esse processo é organizado usando o conceito de gerenciamento flexível de projetos (Agile). Todo mundo sabe que o Agile inclui várias técnicas. Tomaremos um deles como exemplo, o SCRUM, pois é mais usado no mundo do desenvolvimento de software.
O proprietário do produto ou Scrum Product Owner é um dos principais membros da equipe do projeto. É ele quem representa os interesses dos usuários finais e faz todos os esforços para maximizar o valor do produto. Ele também é responsável, desde o início até o fim, pelo backlog do produto. Toda a equipe de desenvolvimento participa da classificação de bugs, mas a última palavra é sempre para o Product Owner. Determina qual erro será corrigido e qual será marcado como Não será corrigido.
De fato, tudo é dinheiro. Por exemplo, se a correção de um bug não traria nenhum retorno financeiro para a empresa, mas, ao mesmo tempo, demandasse muito tempo e recursos, seria melhor que um bug desse tipo recebesse o status Won't Fix e adie a correção para tempos melhores. De fato, o "proprietário do produto" é responsável por priorizar e pelo status dos erros encontrados.
Em outras palavras, todo mundo tem "esqueletos no armário". Mas se eles não afetarem o desempenho do produto, não impedem as ações do usuário ou dificultam os processos de integração, eles podem ser completamente ignorados.
Critérios de seleção
Esses erros "menores" estão nos produtos de qualquer desenvolvedor.
Por exemplo, na interface administrativa do sistema de gerenciamento de conteúdo, é impossível inserir um título muito longo para uma seção, artigo etc. Os desenvolvedores decidem não corrigir esse bug. Afinal, a correção leva tempo, recursos e você pode simplesmente pegar e reduzir o nome para um determinado número de caracteres. Basta avisar o usuário que nomes com mais de 30 caracteres não são suportados.
O botão está um pouco na cor errada, os elementos da interface estão localizados dois pixels à esquerda do que é necessário - todos esses são erros que não afetam a usabilidade ou o desempenho do aplicativo. Portanto, eles podem ser atribuídos ao Won't Fix.
Os erros críticos são principalmente aqueles que são tratados por muitos clientes que lideram ou podem levar ao fato de que os clientes perdem dinheiro devido a falhas nos programadores. Tudo isso define o Dono do produto, que é obrigado a conhecer o produto como as costas da mão, e não apenas para entender sua funcionalidade, mas também para entender como os clientes de negócios o usam, quais cenários de aplicativos existem em uma empresa específica.
Mente coletiva
A Política de Zero Bug geralmente é associada a um SLA (Service Level Agreement). Normalmente, os desenvolvedores têm várias linhas de suporte técnico.
O primeiro recebe uma mensagem de erro do usuário e coleta todos os dados necessários para sua reprodução e análise e depois transfere todas essas informações para a segunda linha. Os especialistas da segunda linha reproduzem esse erro em estações de trabalho ou servidores nos quais a mesma versão do produto está instalada como o usuário. Se o erro for reproduzido, como afirma o usuário, as informações sobre ele caem no sprint ativo, ou seja, uma lista de tarefas para os desenvolvedores.
A primeira e a segunda linhas de suporte técnico, assim como os desenvolvedores, têm SLAs. Quanto mais crítico o bug, mais rigorosos os padrões de SLA para corrigi-lo. Também existe um SLA geral para solução de problemas: do contato do cliente à obtenção do código corrigido na produção. A decisão sobre atribuir ou não um status de bug ao Won't Fix ou não atribuir é tomada pela segunda linha de suporte técnico. No entanto, seu veredicto não é final. Antes de tudo, seus funcionários são guiados pelos princípios e regras do sprint atual. Além disso, há uma coleção de expectativas dos desenvolvedores, dos clientes e do departamento de desenvolvimento de negócios.
Se surgir uma situação controversa quando todos esses fatores forem levados em consideração, a última palavra estará exatamente atrás da segunda linha de suporte e, é claro, do Product Owner.
Satisfeito significa produtivo
Por que tudo isso uma empresa de desenvolvimento precisa? Um dos motivos é o aumento da motivação dos desenvolvedores. A correção de bugs é um trabalho rotineiro e desagradável, que nem todo mundo gosta de fazer. A implementação de novos recursos é muito mais interessante do que corrigir os erros de seus colegas. Isso aumenta a produtividade e a produtividade. Por fim, dessa maneira, sem sacrificar a qualidade, é possível economizar seriamente na manutenção dos testadores, deixando um ou dois especialistas na empresa, em vez de um departamento inteiro.
Por que usuários e clientes comerciais precisam disso? O negócio está em desenvolvimento, está constantemente enfrentando novos desafios que precisam ser enfrentados com a ajuda de produtos de TI. E se os desenvolvedores passarem a maior parte do tempo eliminando erros insignificantes, em vez de melhorar a funcionalidade de suas criações, correm o risco de ficar para trás dos concorrentes. Os negócios escolherão aqueles que estão avançando, mantendo a barra de qualidade em alto nível.
Só isso. Mais informações sobre a
empresa "Equio" podem ser encontradas no site oficial.
E no
site da Otus, você pode se familiarizar com nossos cursos e participar de
seminários on
-line gratuitos que lhe interessam.