Você sabe o que é Metodologia Ágil?

metodologia agil
27 de maio de 2018
Última modificação: 27 de maio de 2018

Autor: Virgilio F. M. dos Santos
Categorias: Blog

Metodologia Ágil

Nos últimos anos, uma nova maneira de criar software levou o seu desenvolvimento e o mundo dos testes à tona: Agile.

De fato, de acordo com o State of Agile Report da VersionOne, a partir de 2017, 94% das organizações praticam o Agile de alguma forma. No entanto, os entrevistados relatam que essa adoção nem sempre é difundida em suas empresas, o que significa que ainda há um longo caminho a percorrer em termos de adoção e maturidade.

Então, o que exatamente é o Agile e por que ele se tornou tão popular tão rapidamente? Vamos explorar exatamente o que as metodologias ágeis envolvem e como introduzi-las em sua organização com mais detalhes. Especificamente, abordaremos:

  • Como o teste se encaixa nas metodologias ágeis?
  • Quais são as diferentes maneiras de testar em uma equipe ágil?

Pronto para mergulhar? Vamos!

Sobre a metodologia Agile

A metodologia ágil conquistou o mundo do desenvolvimento de software e rapidamente cimentou seu lugar como “o padrão ouro”. Todas as metodologias ágeis começaram com base em quatro princípios básicos, conforme descrito no Manifesto Ágil. Essas metodologias estão enraizadas no planejamento adaptativo, na entrega antecipada e na melhoria contínua, tudo com o objetivo de poder responder às mudanças de maneira rápida e fácil. Como resultado, não é surpresa que 88% dos entrevistados no Relatório de Estado Ágil do VersionOne de 2017 classificaram a capacidade de se adaptar à mudança como o benefício número um de adotar o Agile.

No entanto, à medida que mais e mais equipes de desenvolvimento adotam uma filosofia Ágil, os testadores têm lutado para manter o ritmo. Isso ocorre porque a adoção generalizada do Agile levou as equipes a lançarem versões e softwares totalmente não documentados com mais frequência, que forçou os testadores a mudar quando eles realizam testes, como eles trabalham com desenvolvedores e BAs e até mesmo quais testes eles conduzem, tudo isso mantendo padrões de qualidade.

O que significa testar em uma equipe ágil?

Os princípios ágeis se baseiam em ser colaborativo, flexível e adaptável. Ele se baseia na premissa de que o mundo agora muda regularmente e isso significa que as equipes de software não têm mais anos para lançar novos produtos no mercado. Nesse tempo, as ofertas do concorrente ou as expectativas do cliente podem mudar e a equipe corre o risco de ser irrelevante. O Agile minimiza esse risco ajudando as equipes a colaborarem mais, adaptando-se ao que a equipe precisa para ser bem-sucedida. Isso é feito incentivando as equipes a exibir regularmente seu trabalho e coletar feedback para que possam se adaptar rapidamente às mudanças.

Ao estreitar os testes, o ritmo acelerado do desenvolvimento do Agile levou a vários imperativos para os testadores:

  1. Priorizar os requisitos com base no risco, pois não é possível testar tudo;
  2. Automatizar testes para aumentar a eficiência;
  3. Aumentar o uso de testes exploratórios para acelerar o tempo da entrega do código até a conclusão do teste e enfatizar a necessidade de criar um código que funcione;
  4. Adaptar as mudanças de sprint para sprint

O quarto imperativo – adaptabilidade – é particularmente importante porque requer que os testadores tenham habilidades de teste mais amplas e inter funcionais, o que representa um afastamento das habilidades de testes mais estreitas, frequentemente necessárias em um ambiente em cascata. Além disso, ao contrário de um ambiente em cascata, os testadores que seguem uma metodologia Ágil precisam permanecer em contato próximo com os desenvolvedores para colaborar em testes durante todo o ciclo de vida de desenvolvimento de software.

Nas metodologias Waterfall, muitas vezes há um grande documento de requisitos testados. Esse documento não muda com frequência, por isso os testadores podem existir de forma bastante independente dos desenvolvedores. No entanto, a maioria das metodologias Ágeis é leve na documentação e os requisitos para um novo recurso só podem estar em um ticket em um sistema de rastreamento de requisitos sem todos os casos de borda listados. Os testadores nesses cenários precisam ser altamente comunicativos com as equipes de desenvolvimento e de negócios, pois os testes que eles escreveram há algumas semanas podem se tornar obsoletos rapidamente.

Para ter sucesso, os testadores precisam ser flexíveis e capazes de se adaptar a alvos móveis.

Em geral, existem quatro princípios centrais do Manifesto Ágil que são importantes para os testadores se lembrarem:

  1. Indivíduos e interações sobre processos e ferramentas;
  2. Software de trabalho sobre documentação abrangente;
  3. Respondendo a mudar depois de um plano;
  4. Colaborar com os clientes em relação à negociação de contratos;

O ponto principal de tudo isso é que todos – testadores, desenvolvedores e outros – devem evoluir para abraçar um estilo Ágil de trabalho.

Agile não é um tamanho único para todos

Cada organização é única e enfrenta fatores internos diferentes (ou seja, tamanho da organização e partes interessadas) e fatores externos (por exemplo, clientes e regulamentos). Para ajudar a atender às diversas necessidades de diferentes organizações, existem várias metodologias Ágeis e vários tipos diferentes de testes que você pode fazer enquanto trabalha em uma dessas metodologias Ágeis. A combinação certa para a sua equipe dependerá de seus fatores, necessidades e objetivos internos e externos. Vejamos o que algumas das metodologias e métodos de teste mais populares do Agile implicam, incluindo:

  • Scrum;
  • Kanban;
  • Métodos de Teste;
  • Desenvolvimento Orientado por Comportamento (BDD);
  • Desenvolvimento Orientado a Testes de Aceitação (ATDD);
  • Teste exploratório;
  • Teste baseado em sessão.

Dois tipos de Metodologia Ágil

1) Scrum

O que é?

Uma das mais populares metodologias de teste de software (usada por 58% das organizações que adotaram o Agile, de acordo com o VersionOne), o Scrum adota uma abordagem altamente iterativa que se concentra na definição dos principais recursos e objetivos antes de cada sprint. Ele é projetado para reduzir o risco e, ao mesmo tempo, fornecer valor rapidamente.

O Scrum começa com um requisito ou uma história de usuário que descreve como os recursos devem ser executados e testados. A equipe, em seguida, percorre uma série de sprints para fornecer pequenas explosões de valor rapidamente. Para ajudar a equipe a trabalhar dessa maneira flexível e evitar a mudança de prioridades, o Scrum requer que as perguntas sejam respondidas desde o início.

Como isso é diferente da Waterfall?

Enquanto a esta inclui vários ciclos de teste e correção de bugs antes de lançar um produto, o Scrum é muito mais colaborativo e iterativo. Uma das maiores diferenças é que a Waterfall exige documentação pesada desde o início, o que dificulta a troca de recursos à medida que o processo avança, podendo ser negativo em alguns ambientes (como software para consumidor) e positivo em outros (como aqueles em que a equipe está tentando lançar um foguete, ninguém quer requisitos para algo perigoso mudando frequentemente). Dito isso, você pode pensar em Scrum como muitas “mini-cachoeiras”, já que os requisitos são bem definidos no início de cada sprint e não devem mudar dentro dele. A diferença é que os requisitos detalhados para o próximo sprint não são definidos com meses de antecedência.

Mergulhando mais fundo, o Scrum exige mais colaboração regular entre testadores, desenvolvedores e BAs, geralmente na forma de levantamentos diários e retrospectivas de sprint, para garantir a comunicação e o alinhamento adequados. Além disso, existe um Scrum Master que ajuda a manter o projeto na tarefa, removendo os bloqueadores da equipe para garantir que eles sejam mais eficazes. O Scrum Master pode ser qualquer pessoa da equipe, como um desenvolvedor ou um testador.

O que a adoção implica?

O Scrum oferece uma das transições mais fáceis para equipes provenientes de um ambiente do Waterfall, pois é baseado em tempo com sprints e os lançamentos ainda podem ser planejados com antecedência. Dito isto, exige iterações mais rápidas e colaboração mais forte.

Para quem é recomendado?

Por causa de suas iterações rápidas, o Scrum é mais adequado para equipes cujos clientes e partes interessadas desejam estar ativamente envolvidos, vendo regularmente produtos de trabalho em reuniões de demonstração. Essa colaboração permite que a equipe faça alterações para as próximas vitrines. Os principais membros da equipe que devem estar envolvidos ao adotar uma abordagem Scrum incluem:

  • Dono do produto;
  • Scrum Master;
  • Desenvolvedores;
  • Engenheiros de Automação;
  • Testadores;
  • Stakeholders.

Quais são as melhores práticas?

Além de uma forte comunicação, colaboração e adaptabilidade, outras práticas recomendadas para testadores seguindo uma metodologia Scrum incluem:

  • Determinar os critérios de aceitação com base na comunicação (normalmente na forma de uma história do usuário) de um representante de vendas ou cliente;

Nota: essa conexão direta deve ajudar a reduzir as falhas de comunicação.

  • Utilizar os critérios de aceitação para desenvolver código e garantir a sua aprovação pela equipe.

Testar o código em ambientes semelhantes à sandbox, bem como em ambientes semelhantes à produção, antes de implantá-lo em produção.

2)Kanban

O que é?

O Kanban é uma metodologia muito simples baseada no Agile, baseada na fabricação, visto que foi desenvolvida pela Toyota para ajudar a aumentar a produtividade nas fábricas. Em essência, o Kanban pode ser considerado uma grande lista de tarefas prioritárias. Como no Scrum, os requisitos nessa metodologia são rastreados pelo estágio atual no processo (tarefas, no desenvolvimento, no teste, concluído).

Ao contrário do Scrum, o Kanban não é baseado no tempo. Pelo contrário, baseia-se apenas na prioridade. Quando um desenvolvedor está pronto para a próxima tarefa, ele o puxa da lista de tarefas. Como há menos reuniões de planejamento, essa abordagem significa que a equipe precisa estar extremamente próxima. Nesse tipo de ambiente, se os desenvolvedores trabalharem muito mais rápido que os testadores, os gargalos vão surgir. Nessas situações, qualquer pessoa da equipe deve entrar e ajudar em diferentes áreas. É claro que atender a essa necessidade requer muita flexibilidade e adaptabilidade.

Como isso é diferente da Waterfall?

O Kanban ainda tem requisitos como o Waterfall, mas eles podem mudar, pois a equipe de testes não começa a pensar em testar cada requisito até que o desenvolvedor o selecione na parte superior do backlog. Em contraste, a Waterfall é fortemente baseada no tempo, com muita sobrecarga no planejamento. O planejamento pesado que vem em um ambiente do Waterfall é ótimo em alguns casos, como ao criar itens caros, mas nem sempre é necessário. Com o Kanban, os lançamentos ainda são planejados, mas as equipes geralmente não prometem recursos a determinadas datas, a menos que o item em questão esteja próximo do topo do backlog.

O que a adoção implica?

O Kanban oferece uma transição simples para as equipes certas. Para fazer uma transição suave para o Kanban, os analistas de negócios, desenvolvedores, testadores e partes interessadas devem se sentar juntos e se comunicar regularmente. Ao fazer a transição para o Kanban, é importante lembrar que essa metodologia oferece a maneira mais rápida de levar o código à produção, mas é provável que o código tenha alguma dívida técnica. Isso porque desenvolver sem sempre saber o que virá a seguir não se presta necessariamente à produção do código mais reutilizável.

Para quem é recomendado?

O Kanban é mais adequado para pequenas equipes ou equipes que não produzem recursos para o público e/ou prometem determinadas datas para lançamentos. Além disso, é uma excelente metodologia de escolha para quaisquer produtos ou equipes focados principalmente no trabalho de manutenção, já que os bugs nem sempre são diretos e geralmente exigem pesquisas para serem resolvidas, o que dificulta o gerenciamento do tempo. Equipes que não podem minimizar a quantidade de planejamento para problemas provavelmente estarão em melhor situação seguindo uma metodologia Scrum ou Waterfall.

Os principais membros da equipe que devem estar envolvidos em um ambiente Kanban incluem:

  • Dono do produto;
  • Gestor de projeto;
  • Desenvolvedores;
  • Engenheiros de Automação;
  • Testadores;

Quais são as melhores práticas?

Além de manter a visibilidade e priorizar a colaboração, as práticas recomendadas para os testadores que seguem uma metodologia Kanban incluem:

  • Manter linhas de comunicação muito abertas entre os proprietários de empresas, desenvolvedores e testadores;
  • Garantir que a equipe tenha flexibilidade para assumir outras funções fora de suas principais responsabilidades, a fim de ajudar a eliminar gargalos;
  • Fazer de todos um proprietário do produto para que eles se importem com o resultado.

Deixe seu comentário

Deixe uma resposta

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