Manter a agilidade com a política de zero bug / defeito

Em nosso projeto, trabalhamos com uma metodologia de erro zero (também conhecido como defeito zero). A idéia básica é que os bugs são sempre mais prioritários que os recursos. Se você estiver trabalhando em uma história e ela tiver um bug, ela deverá ser resolvida para que a história seja aceita. Se um bug for encontrado durante o sprint para uma história mais antiga, precisamos colocá-lo em nosso backlog e resolvê-lo - a principal prioridade.

A razão pela qual estou dizendo resolver é que nem sempre corrigimos o bug. Em algum momento, apenas declaramos que "não vai consertar", pois não é tão importante. Tudo em tudo parece ótimo. Estamos enviando produtos de alta qualidade e não carregamos "uma corcunda" na forma de uma enorme lista de pendências de bugs.

Mas não tenho certeza se essa abordagem está correta. Costumo concordar que sempre precisamos corrigir bugs sérios o mais rápido possível e precisamos jogar bugs não interessantes. Mas e os bugs que são importantes, mas não tão importantes quanto os novos recursos? Costumo pensar que eles devem ser arquivados no backlog com uma prioridade adequada.

Vou dar um exemplo para que fique mais claro - no meu projeto, trabalhamos com uma interface do usuário escrita em flex. Temos uma tela de assistente que é aberta no mesmo tamanho para todas as resoluções de tela. Acontece que, quando estendemos a janela do assistente, uma das páginas não parece boa (há uma barra de rolagem vertical que não desaparece, embora o assistente agora possa apresentar tudo e não exija a barra de rolagem). Eu acho que esse bug é feio. Tenho certeza que deve ser corrigido. Mas estamos com um cronograma apertado e temos muitos recursos que tememos que não entrem no corte e entrem no lançamento. Eu sinto que podemos viver com esse bug. Ele precisa ser corrigido, mas com prioridade mais baixa do que outros recursos (portanto, caso não consigamos concluí-lo, pelo menos não deixamos de lado os recursos mais importantes). Mas,

Eu adoraria ouvir opiniões sobre como gerenciar com bugs que não quero marcar como "não vou consertar", mas também não são da maior importância.

A correção de erros antes de escrever um novo código é, na verdade, um dos doze pontos do teste de Joel . Joel também explica por que isso é um must-have:

Em geral, quanto mais você esperar antes de corrigir um bug, mais caro (em tempo e dinheiro) será corrigido.

Você tem uma escolha:

• Você implementa um recurso altamente solicitado e atrasa a correção de um bug, o que inevitavelmente aumentará o custo da correção,

• Ou você conserta o bug no momento, considerando que os clientes ficarão desapontados por você ser tão lento em fornecer o recurso que eles precisam tanto.

Se o erro não for muito importante, enquanto o recurso for, o gerenciamento estará inclinado a pedir para implementar o recurso primeiro e, em seguida, consertá-lo. Em termos de negócios, essa é uma opção perfeitamente válida, na medida em que a gerência entende claramente as conseqüências, ou seja, seria mais difícil corrigir o bug mais tarde do que agora.

Aderir a "nenhum novo recurso até que todos os bugs sejam corrigidos" pode não ser a melhor opção comercial. Você já mencionou suas limitações, portanto não há necessidade de explicá-lo.

Dito isto, o risco de permitir que recursos muito importantes sejam implementados antes de corrigir bugs menores tem um risco: onde colocar os limites? Um recurso solicitado por 1 000 clientes é mais importante do que um bug encontrado por 100 clientes? Como avaliar se um determinado recurso deve ser feito antes de corrigir um determinado bug?

Sem regras rígidas e se o gerenciamento não entender muito bem o processo de desenvolvimento, você poderá se ver em alguns anos com uma lista de pendências cheia de bugs que não foram considerados importantes o suficiente para serem corrigidos antes de apenas outro recurso sofisticado.

Além de mergulhar em detalhes específicos de baixo nível da sua situação, é melhor garantir que você tenha as coisas básicas e fundamentais certas.

A esse respeito, acredito que é muito importante ressaltar que a política mencionada, "os bugs são sempre mais prioritários que os recursos", particularmente a palavra sempre se desvia de pelo menos dois dos quatro princípios declarados no Manifesto Ágil :

Indivíduos e interações sobre processos e ferramentas

Respondendo a mudanças após seguir um plano

Não insisto em que você mude de política, porque acredito firmemente que é preciso ser ágil quanto à aplicação de princípios ágeis.

Mas você deve estar pelo menos consciente quando se desviar e entender se e como o desvio é justificado . Simplificando, é melhor garantir que o que você chama de "ágil" não se torne realmente falso, tão eloquentemente coberto no Manifesto Ágil Half-Arsed :

Indivíduos e interações sobre processos e ferramentas
e temos processos e ferramentas obrigatórios para controlar como esses indivíduos (preferimos o termo 'recursos') interagem

Trabalhar software em documentação abrangente
, desde que esse software esteja documentado de maneira abrangente

Colaboração do cliente sobre negociação de contratos
dentro dos limites de contratos rígidos, é claro, e sujeito a rigoroso controle de alterações

Responder à mudança após seguir um plano,
desde que exista um plano detalhado para responder à mudança e seja seguido com precisão

Por uma questão de competência, não são apenas os princípios ágeis dos quais a política de erro zero parece se desviar.

Nos projetos não-ágeis que participei, geralmente foi considerado incorreto gastar tempo dos programadores na correção de bugs que não são importantes o suficiente para justificar o atraso na liberação de recursos de alta prioridade.

Por esse motivo, a gerência normalmente gastava (talvez fosse mais preciso dizer investido ) alguns esforços para decidir quais erros poderiam esperar até o próximo lançamento.

• ^{Por acaso, você trabalha em software de missão crítica? Eu pergunto, porque nesse caso, a política de zero bug faz muito sentido e vale a pena comprometer os princípios ágeis / não-ágeis / quaisquer que sejam. Embora eu tenha dificuldade em imaginar um processo ágil neste caso.}

Você sabe, a menos que trabalhe em software de missão crítica, eu recomendaria avaliar mais de perto as habilidades e habilidades de pensamento de sua gerência.

Quero dizer, pelo que você descreve, parece que eles são simplesmente incapazes de priorizar adequadamente bugs e recursos. Se for esse o caso, se eles não conseguem lidar com uma tarefa tão rotineira, do que mais eles não são capazes? Fornecer salário competitivo? oportunidades de crescimento na carreira? condições de trabalho?

Como você indica com razão, uma política de erro zero corre o risco de que problemas não críticos sejam ignorados ou empurrados para baixo do tapete, porque agora não é o melhor momento para resolvê-los.

O que você pode fazer é, quando um novo problema for relatado, tomar uma decisão de três vias:

1. É um bug genuíno e deve ser corrigido o mais rápido possível: coloque no topo da lista de pendências
2. É um bug genuíno, mas não é crítico para o funcionamento do aplicativo: transforme-o em uma história regular e deixe que o proprietário do produto o priorize.
3. Não é um bug, ou é uma duplicata ou não vale a pena o esforço para resolver: rejeite pela razão apropriada.

Dessa forma, as questões menos importantes não serão totalmente esquecidas, mas também não estão forçando todos os novos recursos brilhantes do próximo sprint. O 'transformá-lo em uma história' é apenas para que o gerenciamento possa continuar afirmando que você está seguindo uma política de zero bug e o proprietário do produto deve poder equilibrar a importância do problema com a importância dos recursos do backlog.

Observe que, com este procedimento, problemas como a barra de rolagem que você mencionou ainda podem não ser resolvidos no final do projeto, mas foi porque ninguém achou que fosse importante o suficiente (incluindo os clientes), não porque não havia momento em que o problema foi encontrado.

Eu gosto do seu esquema, no entanto, como você identificou, ele precisa de apenas um pequeno ajuste para fazê-lo funcionar - Como você observou, a realidade é frequentemente um novo recurso que supera uma correção de bug .....

Minha sugestão é forçar a prioridade do bug a aumentar cada sprint. Digamos que você tenha um bug no nível 5 (escala 1-alta, 5 = baixa). Começa com 5, 4 sprints depois, é um bug de nível 1. No entanto, a mentalidade necessária para o cálculo de prioridade é "Prioridade atual - Número de sprints", em vez de "Aumentar a prioridade de erros pendentes no final de cada sprint" - isso impede que a prioridade seja "redefinida" para baixa para adiá-la ainda mais.

Os erros de nível 1 devem ser abordados no próximo sprint ......

É simples de explicar, fácil de implementar ....

Agora, na medida em que, para apresentar solicitações, talvez uma taxa diferente. Depois de um tempo, a solicitação deve ser tratada - concluída ou descartada, impedindo um acúmulo de recursos que não têm valor ......

Você fica com problemas quando tenta ser muito literal ou inflexível sobre qualquer coisa no desenvolvimento de software, tanto quanto todos realmente queremos que as coisas sejam cortadas e secas. Os erros devem ser corrigidos antes que novos recursos sejam adicionados, mas eu ainda consideraria a importância de cada um ao tomar essa decisão, juntamente com o escopo do problema. Há exceções para tudo.

Alguns aplicativos são tão grandes que possuem seções que não são relacionadas. Não vejo por que todos os novos recursos do módulo de contas a pagar precisam ser retidos, porque há alguns bugs irritantes na GUI dos funcionários. Se algum incômodo com a GUI da etapa do assistente estiver localizado na seção de compras do site da empresa, corrija-o, mas muitos bugs talvez precisem ser corrigidos se o recurso adicionado for resultado de uma segurança adicional, necessidade comercial e principalmente alterações nos regulamentos.

Além de uma grande discrepância no tempo e nos recursos para concluir qualquer um deles, é melhor obter algumas informações do usuário / cliente. Se eles podem conviver com o bug, se isso significa obter o novo recurso, adicione o recurso. O objetivo deve ser o de evitar que os bugs se acumulem, para que haja uma lacuna de parada. Em algum momento, muitos pequenos problemas se tornam graves.

Escrever testes para mostrar o erro ao executar o teste é um bom começo para corrigir os erros. Mas, ao tentar corrigir os bugs com a menor prioridade, devemos pensar duas vezes antes de prosseguir. Eu não quis pular de consertá-lo. Mas podemos usar recursos não críticos para corrigir esses bugs. Digamos, na minha equipe, treinamos os novos recursos com os bugs menos priorizados na lista de bugs. Dessa forma, temos a chance de treinar o novo recurso, além de transmitir um tom de confiança neles de que eles corrigiram sua entrada no aplicativo. Isso certamente os tornará voluntários para a próxima tarefa priorizada.

Espero que isto ajude :)