Três amigos (Three Amigos) é uma técnica de discussão e definição de algo que será feito, podendo ser uma feature, incremento ou correção.
O termo surgiu no meio ágil em 2009 com o principal objetivo de colher pontos de vista de diferentes perspectivas e áreas:
negócio: geralmente representado pelo analista de negócio ou dono do produto;
desenvolvimento: representado pelos desenvolvedores, arquitetos;
e teste: representador 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.
Por quê utilizar essa técnica?
Obter opiniões compartilhadas de diferentes expertises ajuda a definir melhor o que deve ser feito, evitando mau entendidos e falhas de comunicação.
Além disso, utilizar essa técnica contribui nos seguintes aspectos:
Definição de “qual o problema queremos resolver?”: muito antes de criar código, wireframes ou mesmo testes, é necessário entender bem o que precisa ser feito. Se não entendemos qual o problema queremos resolver com a nova funcionalidade ou correção, corremos um grande risco de entregar algo totalmente fora do real ou pretendido (Alguém aí já passou por isso? ver uma função ser discutida, desenvolvida, testada, e ao final do ciclo não ter nada a ver com o inicialmente pretendido);
Definição de pronto para ser desenvolvido (Definition of Ready): como sabemos se algo está bem definido o suficiente para começar a ser desenvolvido? o que entendemos por pronto para ser desenvolvido? – já discutimos, detalhamos o que deve ser feito, descrevemos em algum lugar, colocamos as estimativas e está pronto para ser pego por algum desenvolvedor para ser desenvolvido;
O mais comum é utilizar nas reuniões de refinamento de backlog (grooming/pbr).
Mas nada impede o uso dessa técnica durante o desenvolvimento – para sanar dúvidas de algo que está sendo desenvolvido, ou também depois que algo foi desenvolvido – para traçar melhores formas de teste. Pode ser utilizada até antes mesmo de uma reunião formal para definição de itens do backlog.
O intuito é ter sempre pessoas advindas de diferentes áreas discutindo e chegando a um consenso sobre o que deve ser feito.
Como isso influencia na qualidade do produto
A participação de testers desde as fases mais iniciais do ciclo de desenvolvimento é sempre benéfico pois eles serão capazes de levantar questões sobre testabilidade e sobre a qualidade do que deve ser produzido.
Além disso, as discussões que levam em consideração diferentes pontos de vista são mais ricas para originar cenários de uso.
Mais contribuições significam uma maior cobertura de possíveis cenários, possibilidades e restrições.
Com base nessa informação, os testers podem então aprender mais sobre o que cada área espera do software e traçar casos de teste mais eficazes, contribuindo para uma melhor qualidade do produto.
Mas isso quer dizer que sua boca não funciona corretamente? ou que suas mãos deixaram de lhe ser úteis? ou que seus pés esqueceram como é caminhar e devem ser substituídos?
Certamente não!
Morder a língua ou a bochecha de vez em quando não quer dizer que sua boca esqueceu como é mastigar e por isso não lhe serve mais. Nem que precisa de uma boca 2.0.
Deixar cair algo de vez em quando não significa que nossas mãos deixaram de nos ser úteis e por isso abandonamos seu uso.
Tropeçar de vez em quando não prova que seus pés esqueceram como é caminhar e perderam a serventia
Essas “pequenas falhas” simplesmente revelam a nossa natureza humana: somos falhos por definição.
Mas ainda assim, pisamos na lua, descobrimos a cura para diversas doenças, voamos, fazemos transplantes de órgãos tão importantes quanto um coração. Dentre outras realizações que seriam enxergadas como mágica ou impossíveis há não muitos séculos atrás.
E conseguimos tudo isso sendo seres imperfeitos. Realizamos várias maravilhas.
Nesse sentido, como na vida em geral, precisamos rever a definição debom o bastante no contexto de produzir software. A perfeição não é um estado em um determinado momento, estático. Pelo contrário, a perfeição é um processo de aprimoramento e correção constante.
Grandes empresas já entenderam o que é bom o bastante. Aquelas que mudaram a forma como comunicamos, nos relacionamos e até vivemos como Google, LinkedIn, Apple, Microsoft, Nokia.
E é também graças a esse reconhecimento da falibilidade que chegaram onde chegaram. Softwares imperfeitos foram colocados em produção, para todo mundo usar. O ciclo de correção foi encurtado apoiado pelos métodos ágeis, automação, CICD, DevOps.
E assim, iniciando com produtos bom o bastante, diversas empresas conquistaram grandes mercados e uma gama sem fim de realizações.
Como desenvolvedores de software de qualidade precisamos nos lembrar disso frequentemente, para não corrermos os risco de focarmos em padrões inalcançaveis e atrasar o lançamento do produto a tal ponto de não ser relevante.
Se você é um profissional de TI certamente já ouviu falar em abordagens ágeis quando se trata de como uma equipe que desenvolve software deve funcionar.
É bem provável que a empresa que você trabalhe aplique ou tente aplicar métodos ágeis em alguma profundidade.
Em maior ou menor instância, do jeito certo ou nem tanto, é bem provavel que sua empresa não funcione num processo cascata ou nos moldes clássicos. Ou pelo menos não deveria, a menos que seja realmente adequado para a realidade dos produtos que produzem.
Mas o que é ser ágil?
Resumidamente e simplificadamente, ser ágil consiste em respeitar um conjunto de 4 valores e 12 princípios descritos nomanifesto ágil em 2001visando construir um produto de melhor qualidade. Apesar dessa filosofia ter surgido com o desenvolvimento de software, hoje pode ser aplicado para desenvolver outros produtos também.
Existem diversas formas de aplicar os valores e princípios ágeis, e utilizar o SCRUM (que é um método ágil de funcionamento de equipes) é uma dessas formas. Mas existem outros métodos de trabalho para que uma equipe seja entendida como ágil como: XP, kanBan, lean, Crystal etc.
E se quem desenvolve software está usando SCRUM (como é o caso da maioria das empresas que desenvolvem software),
onde é que o gerente de teste está?
O gerente de teste, no SCRUM, não está em lugar nenhum. Isso acontece porque nesse método, não existe a figura dos gerentes, tão pouco do gerente de testes. No entanto, é possível verificar sua existência em muitas empresas que ainda estejam migrando para um funcionamento totalmente ágil.
Se não tem gerente de testes, quem gerencia os testes?
Numa equipe ágil (entenda-se scrum, pois é o método que a maioria das empresas aplica ou tenta aplicar), a função de gerenciamento é de toda a equipe.
A proposta é ter equipes auto gerenciáveis. Não há uma figura responsável por gerenciar algo dentro de uma equipe scrum. Pelo não com os títulos clássicos “gerentes”.
Lembre-se que o papel de gerenciar também não é do scrum master (que possui a função de manter a equipe funcionando da melhor forma possível, mas não de gerenciar o que cada um faz com um gerente tradicional).
Ao desenvolver uma nova função de software ou modificar algo existente, precisamos ter uma forma de dizer que o trabalho está finalizado.
Como dizer que algo que a equipe se comprometeu entregar está terminado? ou seja, pronto?
Observe as diferentes respostas que podemos obter ao perguntar para diferentes membros de uma equipe ágil:
desenvolvedores: eu entendo como finalizado quando não há mais o que ser codificado, e meus testes unitários e de integração foram codificados e estão rodando com sucesso;
testers (QA/QE): eu finalizari a codificação dos tester automatizados, os testes foram executados e passaram com sucesso e nenhum defeito severo foi encontrado;
product owner: eu entendo como pronto quando o que eu pedi foi desenvolvido, foi testado e está em produção funcionando corretamente.
Durante o ciclo de desenvolvimento de software, uma função em desenvolvimento pode receber diversos status que simbolizem em qual momento do processo ela está, por exemplo:
em codificação, pronta para teste, em teste, bloqueado, etc.
No entanto, o status final que ela recebe deve ser bem conhecido e entendido por toda a equipe.
Mas então, quem está certo? quando dizemos que uma função está pronta (finalizada/entregue)?
No contexto de equipes ágeis, especialmente as que utilizam Scrum, que é o método ágil mais popularmente utilizado, é necessário que a equipe entre em acordo sobre o que é dizer que algo está pronto.
Seja uma nova função, ou modificação de funções existentes, essa definição de pronto (definition of done) é muito importante para que todos falem a mesma língua e estejam alinhados sobre o término de algo que a equipe entrega.
Se você é um profissional de TI certamente já ouviu falar em abordagens ágeis quando se trata de como uma equipe que desenvolve software deve funcionar. 
