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.
Os analistas de requisitos reúnem os requisitos, descrevendo-os em algum formato e passam para os desenvolvedores.
Os desenvolvedores desenvolvem o produto e enviam para os testers testarem.
Os testers realizam os testes, encontram um defeito e a guerra se inicia:
-DEV: isso não é um defeito, VOCÊ que não entendeu isso direito.
__TESTER: claro que é! olha aqui a descrição que o analista passou. VOCÊ esqueceu esse pequeno detalhe.
Dev “buffa” de raiva, diz AHRAM, e vai corrigir o defeito. O tester, sai com a alegria e orgulho de um “trabalho bem feito“. Com ar de herói, e que se não fosse ELE, o código estaria explodindo em produção.
UFA, pensa o tester, salvei a equipe de teste receber uma métrica ruim.
A tensão entre dev e testers aumenta a cada release e defeito encontrado. Nesse ambiente não há muito espaço para amizade, em uma guerra não tão fria que segue instalada. Testers trabalham isoladamente dos desenvolvedores, cada um em seu silo. O sentimento entre devs e testers é sempre o de inimigos mortais.
Esse cenário lhe soa familiar?
Em equipes que se dizem ágeis esse cenário não deveria mais existir.
Em equipes ágeis NÃO EXISTEM HERÓIS.
Melhores Amigos
Em equipes verdadeiramente ágeis as responsabilidades são compartilhadas pelos membros da equipe. Não existe aquela velha divisão em que cabe a célebre frase “isso não é meu trabalho”.
As linhas de divisão de trabalho estão cada vez mais tênues. Testers não só desenvolvem e realizam testes, mas participam ativamente desde a concepção das features. Revisam código em pull requests, chamam a atenção para possíveis problemas. Testers e devs sentam-se juntos para programar algo, ou resolver algum problema que um ou outro sozinho não conseguiria resolver.
Em ambientes verdadeiramente ágeis, realizar entregas frequentes e de qualidade é responsabilidade de toda a equipe. E para tanto, faz toda a diferença estarem genuinamente juntos, colaborando diariamente.
Como as outras características de software, a qualidade não é somente trabalho dos testers e muito menos de qualquer indivíduo isoladamente.
Testers, developers, donos do produto discutem os requisitos juntos. Existe até um nome para essa técnica, conhecida como 3 amigos. Os cenários são descritos de forma clara e testável, falei sobre o formato de descrevê-los usando BDD nesse texto aqui.
Assim, focando em como podemos entregar software de qualidade frequentemente, devemos nos fazer duas perguntas:
1. Qual o problema estou resolvendo?
2. Quais os problemas eu deveria estar resolvendo e como isso impacta no resultado da minha equipe como um todo?
Certamente que partindo dessas duas premissas, sem focar em culpados por detalhes específicos, encontraremos formas de contribuir em nossas equipes. E isso significa, controbuit muito além da área específica em que fomos contratados para atuar.
Se você é de computação, a não ser que estivesse congelado ou vivendo em uma caverna isolado do mundo nos últimos 18 anos pelo menos (o manifesto ágil é de 2001), já ouviu falar de métodos ágeis.
Muito se fala em ser ágil e como as equipes devem se adaptar as adversidades do dia a dia. O cliente muda de ideia diversas vezes, o cronograma e orçamentos são apertados e ainda tem os defeitos para divertir nossa vida.
Porém, com isso, vejo ainda muita confusão sobre o que é ser ágil.
Nesse contexto, gostaria de dizer o que NÃO é ser ágil, para eliminar alguns absurdos que ouvimos por aí e auxiliar no melhor entendimento.
Ser ágil NÃO É
deixar de documentar: seja o software em si, a arquitetura, os testes. Não precisamos ter manuais do tamanho dos senhor dos anéis, com 500 páginas para explicar como iniciar um pagamento em nosso sistema. O sistema deve ser intuitivo e levar ao usuário o que ele precisa da forma mais forma possível. Mas isso não signigica que não precisamos fazer qualquer tipo de documentação. Documentação é necessária, e ao nível que a equipe concordará que será útil. Seja em testes que documentam como o software funciona, documentação automática baseada no código, ou mesmo diagramas, desde que sejam úteis para a equipe.
deixar de ter um processo: desenvolver software sem processo, mesmo que ágil, significa apenas que sua empresa será uma bagunça mais rápida. Ser ágil não significa a ausência de processos e métodos de trabalho. Pelo contrário. É justamente primando por essa agilidade, que todos devem saber exatamente como trabalhar e em que fase cada tarefa está claramente para agir de acordo com a necessidade do momento.
deixar de ter fazer testes, principalmente os end-to-end: “Ahh aqui a gente é ágil, então o programador mesmo já codifica e testa. A gente não precisa de quality assurance nem tester não, isso é perda de tempo”. A qualidade, como um todo, deve ser pensada desde o início do produto. Devemos pensar em teste desde a concepção do que queremos fazer no software. Vamos discutir sobre a nova funcionalidade? chama os testers, QAs, QEs, pra conversa e discussão. A pirâmide de teste deve ser levada em consideração.
ter uma arquitetura má definida: “Vamos começar a desenvolver logo, mostrar pro cliente e ouvir o feedback”. Lindo essa idéia de design sprint. E concordo que funciona muito bem para alguns contextos. Mas serve para tudo? Se o software é complexo e crítico, inevitavelmente precisamos gastar um tempo definindo a arquitetura dele e discutindo os detalhes e limitações. Dificilmente teremos tudo definido no início (coisa de método cascata), mas pelo menos precisamos ter alguma consistência ao começar a construir o software.
evitar reuniões a todo custo: sim, sabemos que em muitas empresas gastamos muito tempo com reuniões infinitas que saem de lugar nenhum para nenhum lugar. Mas isso não significa que todas elas são inúteis ou irrelevantes. Uma das dicas do agile é colocar um tempo limite para elas. Sempre ter uma agenda e mediador também ajuda muito.
colocar qualquer coisa em produção: a ideia dos métodos ágeis é colocar um produto em produção o mais rápido possível, para que com isso, consigamos reunir as experiências e feedbacks dos usuários e evoluir o produto. No entanto, essa corrida para colocar o código em produção não significa despachar algo ruim, mal feito, cheio de defeitos básicos e que não cumpra o que os usuários querem. Idealmente, começamos com funções simples, mas que façam um mínimo de fluxo que agregue valor para os clientes. A partir do uso e respostas, evoluímos o produto para a maturidade.
ficar mudando os requisitos durante a sprint: usar métodos ágeis significa “abraçar mudanças” e se adaptar a elas quando aparecem. Mas nem por isso significa que iremos cumprir todo e qualquer requisito que aparece durante uma sprint. Se estamos usando scrum, devemos blindar a equipe durante as sprints para que consigamos entregar o que foi acordado no planejamento da sprint. Caso precisemos mudar o escopo ou cancelar o que está sendo feito, devemos entrar em acordo com a equipe (pois todos concordaram quanto ao que seria feito anteriormente).
No planejamento da sprint, uma das maiores dificuldades que enfrentei (e enfrento) é como estimar o trabalho que faremos em cada unidade de trabalho.
Ter conhecimento do projeto de antemão, familiaridade com a lingaugem e tecnologias usadas, e até mesmo a interação entre os membros da equipe influenciam na estimativa de uma determinada feature.
Mas, o que é uma feature?
Para o Scrum, uma feature é um item do backlog. Algo que deve ser feito e que foi identificado em algum momento, e foi registrado para posterior priorização.
Para o XP, uma featura é uma story (Apesar de que dificilmente encontraremos um lugar que aplica scrum ou XP puramente. Então o pessoal da sua empresa pode chamar o pedaço de trabalho de srotory tranquilamente).
Simplificanto, uma featuredeve ser:
um pedaço de trabalho que contribui com valor de negócio: pode ser algo novo, correção de algum defeito ou modificação de uma funcionalidade, desde que possua valor para o negócio (o usuário vai fazer algo com isso, possui valor para ele);
estimável: conseguimos dizer de alguma forma o quão difícil/demorado/complexo ela é;
testável: possuir formas de ser testada.
Tipos de Estimativa
Existem várias formas de estimar o trabalho que faremos no contexto ágil, mas as mais comuns são:
T-shirt sizing (método do tamanho das camisetas): dividimos as features entre P (pequenas), M (médias) e G (grandes). É uma forma mais simplista e menos granular de ser estimar os tamanhos do que deve ser feito.
Story points: consiste em dar pontos para as histórias, de acordo com sua complexidade. Considero essa forma uma das mais legais – por poder ter mais granularidade, e mais opções de tamanhos. Mas também é uma das que mais geram discussões – porque precisamos “ignorar” a noção de tempo e focarmos na complexidade ao darmos os números para cada história. Assim, uma história que contenha 1 story point é menos complexa do que uma que seja dada 5 story points.
Observe que em cada uma dessas formas, não é uma pessoa sozinha quem classifica as histórias, mas a equipe é quem chega num consenso sobre isso.
Em geral, isso é feito ou no refinamento do backlog ou no planejamento da sprint em uma reunião que tenha os donos do produto, testers, developers, etc.
