Como podemos melhorar a comunicação usando a técnica dos “Três Amigos”

Três amigos
Três Amigos

Hoje o termo Ágil é muito utilizado e defendido dentro das empresas de TI. Além disso, vemos o DevOps, DevSecOps e tantas outras culturas que agilizam o processo de entrega do produto aos nossos clientes.

Dentre estas culturas, percebemos em vários momentos a falta de maturidade da equipe ao utilizar estes conceitos quando migram do modelo cascata para o modelo ágil.

Infinitas possibilidades, como devo me organizar neste momento?
Infinitas possibilidades, como devo proceder agora?

No modelo cascata uma fase ocorria após a outra e cada uma delas possuía um prazo para ser concluída. É de suma importância ressaltar que não existia comunicação entres as áreas e existiam silos (havia o time de requisitos, o de desenvolvimento, o de testes, etc), e a comunicação mais concreta se dava através de artefatos. Como a fase de testes ficava no final ciclo, seu tempo acabava ficando menor do que o previsto, devido a atrasos nas fases anteriores, o que causava menos tempo para testar e corrigir bugs.

O modelo ágil muda o conceito da forma de entrega fazendo com que o processo fique menos moroso e ele entrega pílulas que agregam valor ao cliente a cada quinze dias. Mas como fazer para com os entregáveis? Já que o prazo de concepção, desenvolvimento, testes e entrega reduziu, de quem é a responsabilidade da “qualidade do sistema”?

Dentro do ágil, os entregáveis diminuíram, mas as responsabilidades aumentaram, pois precisamos nos comunicar mais e trabalhar em conjunto o tempo todo. A disponibilidade e acesso uns aos outros para adquirir conhecimento é constante. Como melhorar a comunicação sem causar stress entre as áreas?

Qualidade não é responsabilidade somente do time de QA, é responsabilidade do time todo! Desde o momento que chega uma demanda dentro da empresa até o aceite do cliente, todo o time é responsável por garantir a qualidade e agregar valor de ponta a ponta.

Eu, Danielle França, ao participar da turma 6 do curso PTQS com o Júlio de Lima, tive uma aula que brilhou os meus olhos quando foi falado o termo “Three Friends”, que na nossa língua madre é “Três Amigos”. Na hora veio o pensamento E SE MINHA EQUIPE UTILIZASSE DESTE METODO? SERÁ QUE ESTA SERIA A MELHOR FORMA DE DERRUBAR OS SILOS?

Para ter uma visão mais clara, fui pesquisar mais sobre este termo na internet, e encontrei o artigo “Se você não automatizar os testes de aceitação?”, escrito em meados de 2009 por George Dinwiddie, onde o termo “três amigos” foi originalmente usado. Esta prática é conhecida também como “The thriand” (O Trio), ou “Story Kick-off” (lançamento da história).

George Dinwiddie fez três perguntas para explicar o termo:

Se você não usa testes de aceitação automatizados, como você comunica claramente os desejos (“requisitos”) entre a empresa, os desenvolvedores e os testadores?

Se você não usa testes de aceitação automatizados, como você monitora o progresso do desenvolvimento?

Se você não usa testes de aceitação automatizados, como mantém a confiança de que o sistema ainda funciona?

George Dinwiddie fez estas três perguntas para iniciar uma discursão na qual intitulou como “Três Amigos” e usou como base intrínseca os três pilares dentro da empresa “negócio”, “desenvolvimento” e “teste”. Existem vários artigos sobre esta visão e me baseei em um trecho do artigo de Vinicius Pessoni que traduz o que foi citado acima.

  • Negócio: geralmente representado pelo analista de negócio ou dono do produto;
  • desenvolvimento: representado pelos desenvolvedores, arquitetos;
  • Teste: representado pelos engenheiros de teste.

Apesar de chamar 3 amigos, essas discussões podem, e por diversas vezes devem, conter mais que literalmente somente 3 pessoas.

Uma maneira de ilustrar como a má comunicação pode afetar o resultado final do software desenvolvido é mostrada na figura abaixo. Veja que ninguém entendeu o que o cliente queria, o que fez com que o software desenvolvido não atendesse às suas necessidades.

Comunicação ineficaz
Comunicação ineficaz

O conceito principal dos três amigos é trabalhar a comunicação em prol de minimizar os erros futuros. E uma vez unindo as três frentes, PO, Dev e QA, teremos uma melhor comunicação para alcançar um resultado mais assertivo.

O intuito do três amigos é fazer com que a comunicação seja bem fluida e com mais clareza entre as partes, iniciando deste a concepção da história, até o aceite final. Visando sempre a qualidade, o QA tem como contribuir com as demais áreas e assim já trabalhar a monitoria e fazendo um exercício para que na falta de alguém, o processo não seja executado por falta de conhecimento ou falta de compreensão. Este é o foco principal dos três amigos, ajudar a tornar o processo mais maduro, trabalhando a maturidade do time através da melhoria da comunicação, para alcançar entregas mais assertivas para o cliente, mantendo-o mais interessado no produto e curioso de como será a próxima entrega.

No início acrescentaremos uma reunião a mais nos ritos tradicionais do processo, trazendo a dúvida: Mas não seria mais oneroso? Sim, no início será, mas a partir do momento que o conceito e a maneira de trabalhar for compreendido, mitigaremos ruídos de comunicação e ganharemos mais agilidade nos processos futuros.

Um outro ponto que acho que vale a pena destacar é que ao aplicar esta técnica, estaremos possibilitando uma melhor especificação das histórias, ou seja, estaremos atuando em um ponto do processo onde é muito mais barato corrigir erros. É muito mais barato corrigir erros na especificação do que ter que fazer mudanças posteriores no software que não foi construído como o cliente queria.

Três amigos PO, Dev e QA
PO, Dev e QA juntos se comunicando e trabalhando a maturidade evolutiva de equipe.

Em, suma a partir do momento que entendermos o quão importante é manter a qualidade no inicio do processo (concepção), tomaremos consciência de que mais barato fica a correção. O “Três Amigos” proporciona esta facilidade, pois o PO com o conhecimento da regra de negócio, o Dev com o conhecimento técnico e o QA, que sabe como aplicar as regras de negócio no sistema, podem juntos tornar a história do usuário mais assertiva. Isso impactará diretamente na escrita do código que também será mais eficaz e provavelmente com menos e menos bugs, porque a regra de negócio foi muito melhor compreendida.

Hoje eu, Danielle França, compreendo que a comunicação é a alma do negócio. Como QA, tenho ciência que garantir a qualidade sozinha não é meu papel, mas sim de todos os colaboradores (empresa) para com o sistema (cliente final). Ciente da minha responsabilidade e visando viver a qualidade na etimologia da palavra, sei o quanto é benéfico o método dos três amigos e venho introduzindo o conceito na empresa que trabalho.

O ganho maior não está sendo simplesmente na qualidade dos entregáveis, mas na compreensão e na dinâmica de que o QA é visto não mais como um ditador ou apontador de erros, mas sim como uma pessoa que agrega valor e faz valer a frase de que “Quando algum comportamento persiste, existe um ciclo de feedback” (George Dinwiddie).

--

--