menu

A Saga para aumentar o volume das entregas (parte II)

Por

No último episódio falamos como foi o caminho que levou à conclusão de que o projeto estava afundando em débitos técnicos. Nesse episódio vou discorrer sobre as ações tomadas para melhorar a situação e aumentar as entregas do projeto.

Escrevendo este artigo lembrei de duas referências que, apesar de não conhece-las na época, refletem as filosofias aplicadas. A primeira vem de uma entrevista com o Rodrigo Yoshima, publicada aqui mesmo no Kudoos, onde Yoshima fala que o maior impacto sobre a velocidade vem das interrupções não planejadas e que a variação do tamanho das histórias não tem um impacto tão grande assim. A outra referência vem da Mary Poppendieck, no Agile Tour — “Do not map bug fixing process, find out why bugs are happening and how to prevent bugs.”  (Não mapeie o processo de correção de defeitos, descubra a razão que está levando os defeitos a serem criados e como prevení-los)

A forma de trabalhar da equipe na época era do Product Owner (PO) escrevendo histórias, um arquiteto de software orientando o desenvolvimento, a equipe de desenvolvedores e mais um analista de qualidate (QA) realizando testes e auxiliando o PO na aceitação das histórias. Esta forma de trabalho garantia que a reação a defeitos encontrados durante a sprint ou após a entrega fosse rápida e eficiente, mas no lado da prevenção de defeitos tínhamos apenas testes unitários, a aceitação e integração eram manuais. Isso nos levava a um cenário onde estávamos constantemente corrigindo defeitos em produção e essas constantes paradas corroiam a velocidade do time.

A solução era evitar que os defeitos surgissem, assim as interrupções no trabalho do time diminuiriam e a velocidade aumentaria. É fácil falar, mas não tão fácil assim de fazer.

Começamos repensando o conceito de qualidade. Dividimos em Qualidade Reativa e Qualidade Preventiva. A primeira teria o objetivo evitar que o time fosse interrompido por um defeito em produção ou que um defeito em tempo de desenvolvimento atrasasse a entrega de uma história. A segunda teria o objetivo de evitar a geração de defeitos de modo que a primeira não fosse acionada.

A parte da qualidade reativa de tratar os defeitos encontrados em produção foi surpreendentemente a mais fácil de implantar. Basicamente quando o defeito era reportado em produção, a prioridade era encontrar um workaround que permitisse ao cliente continuar seu trabalho. Em um site de notícias como o nosso, o fluxo de publicação de matérias não podia parar, então, qualquer coisa que fizéssemos que fosse capaz de garantir isso nos permitiria colocar o defeito no backlog para que fosse priorizado pelo PO mais tarde, ou seja, o defeito transformou-se de uma surpresa em algo planejado. Claro, se o cliente não conseguisse realizar seu trabalho o fluxo de desenvolvimento era interrompido e o defeito atacado imediatamente.

Essa determinação levou a uma mudança interessante da mentalidade em relação aos defeitos em produção. Antes qualquer defeito em produção era considerado um problema que deveria ser resolvido imediatamente. A adoção desta estratégia nos ensinou muito sobre o modo de pensar do cliente principalmente sobre o quanto ele estava disposto a suportar contanto que pudesse cumprir seu objetivo de publicar uma notícia e o usuário final pudesse lê-la.

A parte da qualidade preventiva tinha uma complexidade extra para ser aplicada, pois envolvia mudanças culturais da equipe e precisava ser conduzida com cuidado.

O publicador, chamado Alexandria, é um sistema de sistemas e apesar de cada um deles ter uma boa cobertura de testes unitários, os testes de integração entre sistemas eram manuais e a criatividade dos QAs não conseguia dar conta de todas as possíveis interações entre eles deixando defeitos escaparem para produção. Os testes de integração tinham que ser automatizados, mas o débito era grande. Lembrei de um dos gráficos do curso Kanban com David Anderson que mostra o custo de um débito de automatização de testes com o tempo gasto sem implementá-los, o gráfico é uma exponencial.

Parar o desenvolvimento para resolver o débito de testes de integração estava fora de questão e aí é que entramos com a parte delicada. A solução foi alocar um dos QAs ( a equipe contava com dois deles na época ) para desenvolver os testes restantes, focados em uma determinada Release, enquanto o resto do time continuava com o trabalho. A ideia era que depois que o débito fosse pago, a responsabilidade da manutenção dos testes passaria a ser da equipe inteira, mas chegarei nesse ponto já já.

A questão que provavelmente está passando pela sua cabeça cabeça neste momento é: “se o desenvolvimento continuava, então o débito dos testes de integração nunca seria pago, pois a equipe estaria sempre adicionando funcionalidades enquanto os QAs pagavam o débito”. Teoricamente sim, mas aí é que entra a segunda frente para implantar a qualidade preventiva.

Como mencionado anteriormente, o time trabalhava da maneira tradicional, PO escreve histórias, os desenvolvedores (Dev) desenvolvem e QAs testam. Este método volta e meia gerava um efeito colateral, como o QA só considerar a história como completa quando todos os seus testes passavam, frequentemente ciclos de test + correção + testes se extendiam demasiadamente comendo tempo de desenvolvimento que poderia ser usado em outra história.

O centro do problema estava na interpretação diferente do texto da história pelo QA e pelo desenvolvedor. O QA testava comportamentos que o Dev não tinha implementado nem nos testes unitários, nem na funcionalidade, gerando ciclos de retrabalho. Para este problema buscamos inspiração no BDD. Os Devs e QAs negociavam com o PO o comportamento da funcionalidade e o QA entregava para o Dev um roteiro de testes que servia como um acordo to tipo “é assim que eu vou testar”.

Até aí o processo de trabalho continuava da mesma forma, agora viriam as mudanças. Desde o inicio fui catequizando a equipe da mudança que viria, depois que o QA terminasse a cobertura de testes seria responsabilidade do Dev mantê-la. Com o roteiro de testes gerado pelo QA,  o Dev seria responsável em adicionar o teste à pilha de testes e garantir que a história só fosse enviada ao QA quando todos os testes passassem. Esta abordagem difere um pouco do BDD, pois este defende que o PO deve escrever os testes de aceitação. Eu prefiro deixar o PO com as tarefas mais de negócio e os devs/qa com as tarefas mais voltadas para desenvolvimento.

Os testes, claro, ficaram mais complexos, pois tinham que cobrir questões de aceitação e integração. As histórias também ficaram maiores, pois passaram a considerar a evolução dos testes pelos devs, mas nessa abordagem os ciclos de retrabalho desapareceram e o lead time das histórias diminuiu, pois resolvemos um problema de comunicação que existia entre Dev e QA. Trocando em miúdos, o QA e o Dev entraram em acordo sobre como as funcionalidades novas seriam testadas e como seria a verificação de que as antigas continuavam funcionando.

O QA deixou de ser um mero testador e passou a ser responsável pela manutenção do ecosistema de testes. O DoD foi evoluído de modo a declarar a história como “Done” depois que os testes passavam. Os QAs não abandonaram os testes manuais, mas passaram a acontecer por amostragem.

Com essas mudanças, ao longo de seis meses, conseguimos diminuir a quantidade de defeitos entrando em produção e a velocidade do time aumentou consideravelmente.

Um ponto importante no processo de mudança cultural é que o conjunto de testes não é final, ele também evolui. Como mencionei anteriormente, a complexidade de um sistema de sistemas era maior que a criatividade do QA para cobrir todos os pontos de forma que resolvemos definir um alvo de cobertura.

Durante minhas andanças pelo mundo da gestão ágil e todas as leituras que fiz, encontrei muitas soluções interessantes para problemas que a maioria de nós passa todos os dias, mas todas elas são declarações de objetivo. Algo que acredito que falte é um guia de como sair de um nível não perfeito e chegar nas receitas descritas nos livros. Espero que com este post eu tenha ajudado o leitor a chegar lá.

Nos vemos por ai.

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top