terça-feira, 15 de fevereiro de 2022

Correção de Bug não agrega valor! Será?

 Certa feita, ouvi um Agile Coach dizer muito enfaticamente: "Correção de Bug não agrega valor para o cliente". Imediatamente pensei: "Se ele soubesse o que aconteceu na Metabook, não falaria isso". E, para explicar o motivo deste meu pensamento, vou contar um "causo".

 Esta história aconteceu no sistema solar de uma estrela chamada Sol, num planeta chamado Terra, um país chamado Brasil, no estado do Rio de Janeiro, na cidade de Nova Iguaçu. Se eu não dissesse que foi num universo paralelo você jamais acreditaria que este é um caso real.

 Na verdade, em relação a nós, este planeta Terra está localizado nos mesmos pontos das três dimensões de espaço e da dimensão de tempo, mas num local diferente na dimensão da probabilidade. Nesta Terra, coisas absolutamente improváveis para nós acontecem frequentemente. Para fim de desambiguação, chamarei o planeta de Terra 2.0.

 Na Terra 2.0, a cidade de Nova Iguaçu/RJ abrigava uma das maiores empresas de TI do país. Nesta empresa, chamada Metabook, João Bonsenso foi trabalhar como Scrum Master.

 Durante uma Sprint Planning, a PO do time dispara:

– Vamos paralisar todas as Melhorias e Evoluções para focar na estabilidade do sistema. A meta da Sprint é recuperar a confiança dos clientes no produto, reduzindo o número de bugs e aumentando a cobertura de testes.

Imediatamente os Desenvolvedores se insurgiram.

– De jeito nenhum! Nós somos desenvolvedores de soluções, não bombeiros.

 João Bonsenso poderia terminar a discussão em 2 minutos, mas preferiu criar polêmica. Simplesmente pediu aos desenvolvedores para explicarem porque pensavam desta forma.

– Um time ágil é criador de soluções, não apagador de incêndios!

– Nós não somos tarefeiros, não queremos fazer número com o suporte!

– Correção de Bug não agrega valor!

 Bonsenso retomou a palavra e perguntou:

– Por que você diz que time ágil não é apagador de incêndios?

– Porque está no "É - Não É - Faz - Não Faz" do time. Aqui, ó! – Respondeu o Dev.

 Bonsenso seguiu:

– Por que vocês associam essa meta a "tarefeiros" e "número com o suporte"?

 E choveram respostas...

– Porque número de bugs é uma Métrica de Vaidade.

– Isso mesmo, é Métrica Tóxica!

(...), (...), (...) 

 Mais uma vez Bonsenso levantou uma questão:

– Por que vocês acreditam que correção de bug não agrega valor?

– Porque a própria Milena disse, quando implantou a metodologia ágil!

– E ela explicou o motivo? – Indagou Bonsenso.

– É porque bug não acrescenta nada de novo no sistema.

 Agora Bonsenso passa a palavra para a PO:

– Por que você acredita que aumentar a estabilidade é o maior valor que podemos entregar na Sprint?

– Porque um sistema de escrituração fiscal que erra no cálculo do imposto não tem valor nenhum. Não existe nada pior para o contador do que mandar o cliente pagar o valor errado. 

 Com as palavras da PO os desenvolvedores bugaram e a sala ficou silenciosa por alguns minutos, até que as mentes dos devs fosse reiniciada. Em seguida, os desenvolvedores concordaram que a melhor opção era fazer a "Sprint de Debug" e perguntaram a João Bonsenso se isso não seria contra o Mindset Ágil.

– Vamos por partes: Em primeiro lugar, o "É - Não É - Faz - Não Faz" tem que refletir a realidade do time e não o time se ajustar ao que diz o quadro. Se "apagar incêndios" é parte da rotina do time, e vocês sabem que é, isso tem que sair da coluna "Não Faz"; jamais o contrário.

 Segundo: não existem métricas de vaidade, nem métricas tóxicas, apenas métricas. Métricas são fatos e todos os fatos são neutros. O que atribui significado, seja positivo ou negativo, a um fato é a interpretação dada a ele. O que define se uma métrica é produtiva ou vaidosa não é o número, é o uso que você faz dele.

 Medir quantidade de bugs para dizer "Reduzi de 1.000 bugs para menos de 10!", é pura vaidade. Acompanhar o número de bugs para identificar se a cada versão o sistema tem se tornado mais instável e se a experiência dos usuários está fortemente comprometida pelos erros, é essencial.

 Terceiro: o Agile Galaxy Manifest diz que a principal medida de progresso é software funcionando. O Scrum Guide of Agile Galaxies diz que o time deve entregar um incremento de produto potencialmente utilizável no final da Sprint.

 Nenhum dos dois fala em entregar "algo novo", ambos falam em entregar algo que funcione. Se corrigir um bug vai fazer uma funcionalidade finalmente funcionar... a entrega incrementa o produto e, portanto, atende plenamente aos requisitos.

 Quarto: a principal responsabilidade do papel de PO é nos indicar como gerar mais valor. Se a nossa PO diz que o maior valor é a estabilidade do sistema, vamos trabalhar na estabilidade do sistema. Não há nada de "anti-ágil" nisso.

 E foi assim que João Bonsenso ensinou ao seu time que correção de bug pode sim acrescentar valor ao produto e evitou a falência do modelo ágil na Metabook e, posteriormente, num efeito borboleta, em toda a Terra 2.0.


Destaco que esta é uma obra de ficção, sem qualquer relação com fatos ocorridos nas empresas nas quais trabalhei ou trabalho atualmente. 

Nenhum comentário:

Postar um comentário

Scrum - You're doing it the right way! Or... maybe... not at all

     Once upon a time, a long time ago, in a galaxy far, far away, there was a human called John Goodsense. John was a senior Scrum Master, ...