Quando a Microsoft estava fazendo a primeira versão do Word, o famoso editor de textos, os desenvolvedores estavam trabalhando como loucos. O pessoal passava muito do seu horário de trabalho e mesmo assim o primeiro release continuava sendo adiado, uma vez após a outra. Mas por quê?

Hoje a gente entende que o problema era pelos prazos malucos que eram estabelecidos. Os programadores não conseguiam cumpri-los ou, para entregar alguma coisa, escreviam um código correndo e que resultaria em inúmeros outros problemas. Como você deve imaginar, não dava para lançar nada porque havia muitos bugs.

Os programadores não conseguiam cumprir os prazos ou, para entregar alguma coisa, escreviam um código correndo e que resultaria em inúmeros outros problemas no cronograma do Microsoft Word.

“O cronograma era simplesmente uma checklist de recursos esperando para virarem bugs. Depois, essa situação foi chamada de metodologia das falhas infinitas“. Quem conta essa história é Joel Spolsky, hoje fundador do Stack Overflow e criador do Trello. Ele escreveu um artigo lá em 2000 com 12 passos para escrever um código melhor, que por sinal recomendo fortemente a leitura pelo fato de todos os passos ainda fazerem sentido mesmo agora em 2017. Spolsky começou a trabalhar na Microsoft em 1991, fazendo parte do time do Excel.

O que fazer para resolver o problema? Spolsky descreveu a metodologia de zero falhas, que foi adotada pela Microsoft na época. Esse nome gera uma baita controvérsia, porque logo imagina-se que o software não deve ter falha nenhuma e você deve trabalhar ativamente para consertá-las antes de qualquer coisa. Não é bem assim.

“Metodologia de zero falhas não resulta em zero falhas”

Primeiro, é totalmente contraproducente vasculhar indefinidamente o software em todos os cantos e de todas as formas para encontrar possíveis bugs. Sabemos que para detectarmos todos os bugs possíveis, teríamos que testar todas (sim, TODAS!) as possíveis combinações de uso do produto, o que nos tomaria muito mais que séculos de trabalho. Fora isso, o tempo que você gasta procurando falhas também poderia estar sendo usado para implementar novos recursos.

Computer Data Security Concept

Você precisa colocar na balança o que é preciso fazer antes de seguir em frente. Caso contrário, entra em um entrave pois seu projeto ficará parado porque você quer deixá-lo sem falha alguma. Acaba sendo um empecilho semelhante ao da Microsoft com o Word, em que o projeto acabava evoluindo, mas muitos bugs eram criados concomitantemente (acredito que a palavra “caos” define um pouco disso). Como consequência, o gestor nunca aprova o lançamento do produto, pois ele ainda possui muitos bugs em aberto.

Além disso, o próprio processo de parar qualquer desenvolvimento para consertar bugs pode ser exaustivo. Como aponta Michael Dubakov, fundador da TargetProcess, isso pode tirar a coragem de vasculhar por uma parte enorme, complexa, mas importante de código; ou até mesmo levar sua equipe a tomar decisões equivocadas para arrumar algo rapidamente (e sem a devida atenção), com o único objetivo de mover o projeto para frente.

A metodologia de zero falhas pode levar sua equipe a tomar decisões equivocadas para arrumar algo rapidamente e finalmente mover o projeto para frente.

Este argumento foi defendido inclusive por pessoas de dentro da Microsoft, como Larry Osterman, engenheiro da Microsoft há mais de 30 anos, que escreveu em 2004 um texto chamado “metodologia de zero falhas não resulta em zero falhas”.

Um outro fato curioso (por ser sobre um tema 100% diferente de software) é que, no exército dos Estados Unidos, esse pensamento de zero falhas também é considerado algo absurdo, se você entendê-lo como não tolerar nenhum erro sequer. Por lá, eles reconhecem que isso pode acabar sumariamente com qualquer iniciativa para ter sucesso no campo de batalha. Fora isso, trabalhar o tempo todo sob a pressão de não errar fomenta uma cultura de medos e receios que bloqueiam a criatividade do time (algo essencial na computação).

Dubakov também explica sobre a inevitabilidade de bugs: “até em indústrias previsíveis como a de hardware ou automóveis, vai ter um problema com alguma tomada ou peças que precisam ser substituídas”. Até porque, como escreve Jim Bird, chefe de tecnologia na BIDS Trading, quando sua equipe conserta um bug, corre o risco de introduzir novos problemas.

Como abordar a metodologia de zero falhas então?

Esse nome chega até a ser um pouco trapaceiro: você já deve ter percebido que a abordagem de zero falhas não significa literalmente só continuar o projeto se ele tiver zero falhas.

Spolsky argumenta que a prioridade máxima é eliminar os bugs conhecidos, fazendo o seu projeto rodar. Segundo ele, o melhor é consertar as falhas o quanto antes porque pode levar menos tempo e sua equipe conhece melhor o código que foi escrito recentemente. Isso faz muito sentido, afinal você lembra do código que escreveu em sua ferramenta predileta há 4 semanas atrás? E aquela parte do app de sua empresa codificada há 8 semanas?

Já Larry Osterman, engenheiro da Microsoft, diz que você pode aplicar apenas alguns conceitos dessa metodologia. Por exemplo, você define quais bugs precisam ser consertados no momento, como os que são mais críticos para a experiência do usuário ou que oferecem riscos de segurança. Aqui vemos claramente que o objetivo deve ser escolher muito bem quais bugs merecem ser corrigidos naquele momento.

Sobre o mesmo tema, Bird cita um artigo de Eric Sink, em que ele sugere uma estratégia para você e sua equipe decidirem o que corrigir e o que não corrigir. Sink sugere que os times tomem esta decisão utilizando quatro perguntas:

  1. Analise a gravidade do problema: “quando essa falha acontece, quão grave é o impacto?”
  2. Verifique a frequência: “quantas vezes esse bug acontece?”
  3. Veja o custo (não só o financeiro): “quanto tempo e energia vou demandar de minha equipe para corrigir isto?”
  4. Reflita sobre o risco das modificações: “qual o risco de consertar este bug? qual a chance das coisas piorarem e introduzirmos novos problemas?”

Também dá para limitar o número de bugs que cada desenvolvedor trata, o que adiciona flexibilidade no sentido de equilibrar bugs super antigos que precisam ser consertados, mas sem atrasar o desenvolvimento do produto. Dessa forma, um dos objetivos do time também passa a ser a redução, ao longo do tempo, da lista de bugs pendentes.

O que aprendemos com isso?

É uma discussão extensa, bem mais prática do que teórica, mas é importante planejar isso para o seu produto não sair do seu controle. Meu ponto de vista é que a decisão sempre deve ser escolher bem o que merece ser feito, ou seja, avaliar os riscos e priorizar. Coloco também outras dicas finais:

  1. Tenha um cronograma flexível: se você cometer o mesmo erro da Microsoft lá no desenvolvimento do Word, provavelmente terá resultados parecidos. Se você estabelecer prazos impraticáveis e forçar uma equipe a cumpri-los, pode ser que a qualidade do código caia bastante e você tenha vários bugs no final. Sem contar que trabalhar sob intensa pressão pode gerar ainda mais problemas (nem preciso falar sobre motivação, certo?).
  2. Equilibre isso com a produtividade: também não precisa fazer um cronograma de tartaruga e atrasar o seu lançamento. Como Osterman indicou, seja flexível, estipule limites e veja o que é prioridade em um determinado cronograma.
  3. Conserte bugs, mas não busque consertar todos: você pode conseguir consertar os bugs visíveis ou que não atrapalham o andar do seu projeto, mas dificilmente vai conseguir deixar tudo perfeito sem criar mais problemas. O ditado clichê vale aqui: o ótimo é inimigo do bom.
  4. Teste o seu projeto: nós já falamos no blog como o olhar viciado pode atrapalhar a própria visão dos bugs em algum software. Mas isso é normal: o teste independente de um projeto faz com que você tenha uma visão mais clara das falhas que ele tem e de quais precisam de prioridade.

Por aqui na One Day Testing, é praticamente um consenso de que uma das chaves mais importantes para você conseguir um código com poucas falhas é testá-lo complementando a estratégia que sua equipe já utiliza com um olhar externo especializado (sem introduzir ineficiência no processo atual). Um novo olhar sobre o seu software ajuda a entender o que mais pode ser aprimorado e incorporado ao seu processo atual. Ficou interessado? Basta enviar um e-mail para bruno.abreu@sofist.com.br ou ligue em (19) 3291-5321 para conversarmos. Será um prazer ajudá-lo! =)