Uma visão geral sobre Metodologia Ágil

Metodologias ágeis existem há anos, desde a década de 80, mas algumas informações passam por distorções, fato que dificultou no início a utilização das metodologias. Por conseguinte, desenvolvedores passaram a entender a metodologia ágil como algo que tudo se pode, ou seja, podemos desenvolver sem documentação, sem padrão e sem cuidado. Isto não é verdade, as metodologias ágeis podem trazer sucesso ao projeto, e são utilizadas inclusive na indústria. Como exemplo temos o modelo de produção enxuta da Toyota, que é uma forma ágil de produção e que evita o desperdício. Apesar das metodologias existirem, foi em 2001 que um grupo formado por Kent Beck e mais dezesseis renomados desenvolvedores assinaram o Manifesto para o Desenvolvimento Ágil de Software e o grupo foi batizado de aliança dos ágeis.

O Manifesto Ágil possui a seguinte base:

• Os indivíduos e as interações são mais importantes do que os processos e as ferramentas;
• O software funcionando é mais importante do que uma documentação completa;
• A colaboração com e dos clientes acima de apenas negociações de contratos e;
• Respostas a mudanças acima de seguir um plano.

Isso não quer dizer que documentação não seja importante e que os processos e as ferramentas sejam inúteis, significa que o item a esquerda é mais valorizado, apenas isto.

A engenharia de software ágil combina filosofia com um conjunto de princípios de desenvolvimento. A filosofia defende a satisfação do cliente e a entrega de incremental prévio; equipes de projetos pequenas e altamente motivadas; métodos informais; artefatos de engenharia de software mínimos e, acima de tudo, simplicidade no desenvolvimento geral. Os princípios de desenvolvimento priorizam a entrega mais que a análise e projeto (embora essas atividades não sejam desencorajadas); também priorizam a comunicação ativa e contínua entre desenvolvedores e clientes. (Pressman, 2011)

Pressman cita que uma das prioridades é a entrega, mas qual é o cerne de ser ágil?

Segundo Ivar Jacobson Atualmente, agilidade tornou-se a palavra da moda quando se descreve um moderno processo de software. Todo mundo é ágil. Uma equipe ágil é aquela rápida e capaz de responder apropriadamente a mudanças. Mudanças têm muito a ver com desenvolvimento de software. Mudanças no software que está sendo criado, mudanças nos membros da equipe, mudanças devido a novas tecnologias, mudanças de todos os tipos que poderão ter um impacto no produto que está em construção ou no projeto que cria o produto. Suporte para mudanças deve ser incorporado em tudo o que fazemos em software, algo que abraçamos porque é o coração e a alma do software. Uma equipe ágil reconhece que o software é desenvolvido por indivíduos trabalhando em equipes e que as habilidades dessas pessoas, suas capacidades em colaborar, estão no cerne do sucesso do projeto.

Um projeto envolve pessoas e mudanças, principalmente quando falamos de entregas constantes. Desta forma as metodologias ágeis trabalham com equipes altamente motivadas e suporte a mudanças durante o processo de desenvolvimento, mas como fazer isto?

O desenvolvimento ágil é incremental, ou seja, não se faz um plano completo com tudo que devemos fazer para depois iniciar o desenvolvimento, muito menos, desenvolvemos o produto sem contato com o cliente, ao invés disso, desenvolvemos incrementalmente, ou seja, o produto é feito aos poucos e entregue constantemente, desta forma, toda mudança é bem-vinda, pois o projeto está em desenvolvimento e não foi concluído por completo.

Segundo Sommerville, os incrementos iniciais do sistema podem fornecer uma funcionalidade de alta prioridade, de forma que os clientes logo poderão obter valor do sistema durante seu desenvolvimento. Os clientes podem assim ver os requisitos na prática e especificar mudanças para serem incorporadas nos releases posteriores do sistema.

Aqui podemos ver a importância de saber escolher o que será feito, ou seja, funcionalidade que tenham alta prioridade, desta forma o cliente já pode usufruir de recursos do sistema. O que antes demoraria meses, em semanas ele terá acesso, podendo assim verificar erros e especificar novas mudanças ou melhorias, não necessitando chegar ao final do desenvolvimento para ver os problemas. O contato constante com o cliente também gera conhecimento, pois a equipe vai entendendo o negócio, para ao desenvolver, faze-lo com maior velocidade e precisão, e em caso de erros, a equipe não terá perdido um ano de desenvolvimento, terá perdido apenas o tempo de desenvolvimento do incremento, podendo corrigir rapidamente.

Mas o desenvolvimento ágil necessita de práticas ágeis, entre elas podemos citar:

• Utilização de TDD: o TDD é a técnica que permite fazer testes contínuos e não apenas na conclusão do sistema, melhorando a qualidade técnica do produto;
• Planejamento Incremental: ao invés de planejar o software como um topo, podemos planejar de forma sistêmica, ou seja, definir o todo, mas planejar em etapas, realizando um planejamento por incremento. Os requisitos do incremento podem ser registrados em cartões, que algumas metodologias denominam de histórias do usuário, aqui determinamos a prioridade que o cliente define e também o tempo que os desenvolvedores definem como necessário para o desenvolvimento;
• Incrementos desenvolvidos em tempo reduzido: releases pequenos, entregando funcionalidades em meses ou semanas, ao invés de anos;
• Utilização de refatoração: melhorando o código e tornando-o mais fácil de manter constantemente;
• Integração continua: quando o incremento está pronto, ele é integrado ao sistema como um todo, ou seja, isto é feito diariamente.

Os pontos acima são base para quase todas as metodologias ágeis, mas o principal ponto nestas metodologias, além dos citados acima, é a possibilidade de a equipe ser auto gerenciável, ou seja, não há necessidade de um gerente e sim um líder, que tem o papel de facilitador. A equipe e a comunicação entre os membros da equipe e o cliente é crucial para o sucesso das metodologias ágeis, e para isso as equipes pequenas tornam-se fatores de sucesso. As equipes pequenas reduzem problemas de conflitos, comunicação entre outros. Mike Cohn afirma que equipes pequenas possuem menos ociosidade social, melhoram a interação construtiva, menor tempo na coordenação, ninguém fica para trás, pois todos apreendem em conjunto, há maior satisfação entre os membros do grupo e é menos provável que ocorra excesso de especialização, pois todos devem conhecer o projeto.

Outro ponto que foi notado por Cohn é que o tamanho não indica realmente maior produtividade, pois equipes grandes não são necessariamente mais produtivas, pois há menos comunicação e maior número de conflitos. Segundo Cohn não é de se surpreender que equipes menores concluem os projetos com um esforço total menor, equipes maiores demandam mais esforços e custos. Equipes entre 5 a 8 integrantes têm maior chance de sucesso, pois é mais fácil a comunicação, mais fácil criar uma integração do que equipes com 20 a 30 integrantes. Equipes muito pequenas podem sofrer problemas de falta de pessoal. O Scrum e outras metodologias ágeis indicam que equipes pequenas tem maior chance de concluir o projeto do que equipes grandes.

Isto por quê?

Bem, primeiramente, nas equipes pequenas o líder nota as deficiências, podendo atacá-las com maior facilidade utilizando capacitação, integração etc.

A equipe pequena consegue rapidamente uma boa comunicação, facilitando o desenvolvimento, mas há um problema: como a equipe é pequena, a perda de um integrante pode prejudicar o grupo como um todo, para isso, não há grande especialização na equipe, ou seja, todos devem ser responsáveis pelo projeto e não por apenas uma tarefa, o que torna a equipe elástica, caso algum integrante saia do projeto.

Para entender mais sobre produtividade e times, é indicada a leitura do livro Teamwork: what must go right/what can go wrong. Sage Publications de Larson e Frank, publicado em 1989.

Conclusão

Aqui vimos o conceito básico de metodologia ágil, que visa melhorar a produtividade. Vimos que o importante das metodologias ágeis é o foco na comunicação contínua com o cliente, na entrega constante e na equipe de desenvolvimento. Nota-se que muda um pouco o conceito tradicional, em que primeiro planejamos todo o produto, com uma análise completa, requisitos funcionais e não funcionais de todo o produto, para depois iniciar o desenvolvimento, o que pode acarretar problemas, pois um requisito mal entendido só será notado quando o produto for entregue meses depois. Na metodologia ágil, planeja-se apenas o que será feito naquele incremento, com detalhes, de forma que possamos desenvolver e entregar ao cliente. Caso o requisito tenha sido mal interpretado, pode ser rapidamente corrigido, pois o tempo do incremento é curso e a correção é rápida, diferente de quando o produto foi entregue completo, e que aparece muitos erros de requisitos, muitas coisas a serem corrigidas e melhoradas, levando tempo da equipe e a desmotivação.

Outro ponto que discutimos é que as equipes ágeis são equipes pequenas, pois é mais fácil manter a equipe motivada, integrada e com boa comunicação.

Quer ser ágil?

Para ser ágil, pense: comunicação com a equipe e com o cliente; desenvolvimento com testes constantes (TDD), integração continua estes são alguns pontos chaves.