Metodologias ágeis

Em meados da década de 1990, novos processos para o desenvolvimento desoftware surgiram, criando métodos com maior concordância à atividade realizada, diferentemente dos recursos já existentes, os quais eram considerados pesados por serem sistemáticos, demorados e com excesso de documentos (PRIKLADNICKI; WILLI; MILANI, 2014).

De acordo com Prikladnicki, Willi e Milani (2014), a popularização das novas técni-cas ocorreu no início do ano de 2001, quando receberam a nomenclatura de metodologias ágeis, após dezessete especialistas se reunirem em busca de melhorias no desempenho dos projetos, criando o Manifesto Ágil, onde foram definidos alguns valores e princípios.

Com apenas quatro valores, Beck et al. (2001) afirmam que “mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda”, conforme elencados abaixo:

• “Indivíduos e interação mais que processos e ferramentas”;

• “Software funcionando mais que documentação abrangente”;

• “Colaboração com o cliente mais que negociação de contratos”;

• “Responder a mudanças mais que seguir um plano”.

Complementando os valores acima, a fim de formar um suporte para as metodologias ágeis, Beck et al. (2001) definiram 12 princípios:

1. “Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado”;

2. “Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas”;

3. “Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo”;

2.4. Metodologias ágeis 37

4. “Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto”;

5. “Construir projetos em torno de indivíduos motivados. Dando a eles o ambiente e o suporte necessário, e confiando neles para fazer o trabalho”;

6. “O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face”;

7. “Software funcionando é a medida primária de progresso”;

8. “Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefi-nidamente”;

9. “Contínua atenção à excelência técnica e bom design aumentam a agilidade”;

10. “Simplicidade: a arte de maximizar a quantidade de trabalho não realizado é essencial”;

11. “As melhores arquiteturas, requisitos edesigns emergem de times auto-organizáveis”;

12. “Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo”.

Portanto, o Manifesto Ágil defende que o processo de desenvolvimento de software deve ser ajustado de acordo com cada equipe, tendo como única regra a melhoria contínua, buscando aprender com os erros, analisar o que funcionou e fortalecer o que está sendo executado (PRIKLADNICKI; WILLI; MILANI, 2014).

A partir da criação do Manifesto Ágil, as metodologias ágeis foram ganhando espaço e, atualmente, são mais utilizadas que os métodos tradicionais. Dentre as metodologias mais comuns, como Lean Development, Feature-Driven Development (FDD), Extreme Programming (XP) e Scrum, destacam-se as duas últimas como as mais conhecidas e aplicadas. Portanto, serão apresentadas a seguir.

2.4.1 Extreme Programming

Extreme Programming (XP) é uma metodologia conhecida por ser utilizada em projetos pequenos, com duração máxima de 36 meses, equipe reduzida e com requisitos instáveis. Foi criada no ano de 1997 em um projeto para uma fabricante de veículos norte-americana. No nome da metodologia, ressalta-se o fato de que o Extreme indica que são empregadas ao extremo as boas práticas da Engenharia de Software (JEFFRIES et al., 2001).

38 Capítulo 2. Fundamentação Teórica

De acordo com Jeffries et al. (2001), tal metodologia busca garantir que o cliente sempre receba o máximo de valor de cada dia de trabalho da equipe. Portanto, é baseada em cinco valores fundamentais: feedback, comunicação, simplicidade, respeito e coragem.

A XP é adaptável e dinâmica; todavia, necessita de muita disciplina para que seja aplicada com sucesso em um projeto. Visando definir seu uso, a metodologia possui doze práticas, que são consideradas como ciclos. Segundo Nunes (2017), as boas práticas são:

1. Cliente presente: é fundamental que o cliente participe ativamente do desenvolvimento do projeto, estando presente em todas as etapas.

2. Jogo do planejamento: o cliente coloca, em pequenos cartões, chamados de user story, quais funcionalidades deverão constar no sistema e qual a prioridade para que sejam desenvolvidas, garantindo que a equipe mantenha o foco no que é mais importante para o cliente.

3. Programação em par: dois desenvolvedores escolhem qualuser story irão implementar e fazem a codificação juntos, sendo que o programador com menor experiência assume o controle e conduz a programação, enquanto o outro revisa o código, questiona as decisões e busca soluções mais simples para o problema. Essa prática permite que o código seja constantemente inspecionado e facilita a difusão do conhecimento entre as duplas, nivelando a equipe.

4. Releases curtos: o cliente recebe versões atualizadas do sistema à medida que as interações são concluídas, o que facilita a validação do que está sendo implementado e permite que as alterações sejam identificadas antes da entrega do produto final.

5. Desenvolvimento guiado pelos testes: antes da codificação das funcionalidades, os testes necessários são definidos. Eles são realizados pelos desenvolvedores e pelo cliente antes de validar o software.

6. Refactoring: é realizada a otimização do código-fonte sem que ocorram modificações na funcionalidade, facilitando a leitura e a identificação de erros.

7. Código coletivo: todos os desenvolvedores têm acesso ao código-fonte, podendo modificá-lo ou atualizá-lo, caso seja necessário. Se forem encontrados erros, o código passa pelo processo de refactoring.

8. Código padronizado: para que os desenvolvedores manipulem o código com maior facilidade, são utilizados padrões de codificação.

9. Integração contínua: sempre que determinada funcionalidade estiver finalizada, ela deve ser integrada ao código geral, de forma que as atividades estejam sincronizadas.

2.4. Metodologias ágeis 39

10. Ritmo sustentável: a equipe deverá trabalhar com qualidade dentro da carga horária prevista, evitando horas extras e sobrecarga de trabalho.

11. Metáfora: a comunicação entre cliente e desenvolvedor deve ser clara, utilizando um vocabulário comum entre eles.

12. Stand Up Meeting: a equipe deverá se reunir todos os dias antes de iniciar as atividades, informando aos colegas o que foi implementado no dia anterior e o que será feito no dia.

Desta forma, a metodologia XP é focada em entregar um produto que atenda às necessidades do cliente, prezando pela qualidade do software, que passa por testes e validações durante todo o processo de desenvolvimento (NUNES, 2016).

2.4.2 Scrum

Desenvolvido no início de 1990 por Ken Schwaber e Jeff Sutherland,Scrum é um framework estrutural que busca melhorias no desenvolvimento de projetos. Seu foco é gerenciar a criação de produtos complexos e flexíveis, sendo considerado leve e de fácil entendimento, porém de difícil domínio (SCHWABER; SUTHERLAND, 2013).

De acordo com Schwaber e Sutherland (2013), a teoria do Scrum para controle de processos é o empirismo, onde o conhecimento é resultado da experiência, aplicando uma abordagem iterativa e incremental para prever, monitorar e reduzir os riscos. Para resultar em uma implementação do controle de processo empírico de sucesso, é indicado que se utilize como apoio a transparência, a inspeção e a adaptação. Estes três pilares, se combinados ao comprometimento, à coragem, ao foco, à transparência e ao respeito, estabelecem a confiança necessária entre todos os membros da equipe.

O funcionamento do Scrum se dá de acordo com as regras, artefatos, eventos e papéis associados ao Time Scrum, os quais estão especificados nas subseções seguintes.

2.4.2.1 Papéis

O framework Scrum é caracterizado por uma pequena quantidade de pessoas, tornando a equipe versátil e autogerenciável, formando juntas, o Time Scrum, divido em três papéis: Product Owner, Scrum Master e Time de Desenvolvimento (SCHWABER;

SUTHERLAND, 2013).

Segundo Schwaber e Sutherland (2013), oProduct Owner é responsável por guiar a equipe em todo o projeto de desenvolvimento do produto. Ele é a única pessoa encarregada por gerir o Product Backlog, indicando e ordenando os itens de acordo com a prioridade, além de garantir que todos da equipe entendam, de forma clara e objetiva, as funcionalidades do produto.

40 Capítulo 2. Fundamentação Teórica

O Time de Desenvolvimento é formado por um grupo de pessoas que realizam as tarefas definidas no Product Backlog. Os colaboradores devem possuir habilidades necessárias para desenvolver todas as funcionalidades do projeto, sejam elas análises, execuções, implementações ou testes. O Time de Desenvolvimento deve ser constituído por, no mínimo, três e, no máximo, nove integrantes, visto que a equipe deve se manter ágil e capaz de concluir um trabalho que demanda maior esforço (SCHWABER; SUTHERLAND, 2013).

OScrum Master é a pessoa responsável por prestar assistência a todos os papéis do Scrum e à organização. Ele gerencia e organiza os eventos, promove a interação entre os membros da equipe e auxilia na remoção de obstáculos entre eles, além de possibilitar o entendimento de todos sobre a teoria, as práticas, os valores e as regras doScrum, a fim de alcançar os melhores resultados possíveis (SCHWABER; SUTHERLAND, 2013).

2.4.2.2 Eventos

NoScrum, alguns eventos padrões são estabelecidos, visando inspecionar e transpa-recer o desenvolvimento do projeto. Tais eventos possuem um tempo máximo para sua duração e objetivam manter os encontros regulares entre o TimeScrum.

O principal evento do Scrum é conhecido como Sprint e consiste na divisão do processo de desenvolvimento do projeto em ciclos, com duração entre duas e quatro semanas, onde as funcionalidades presentes noProduct Backlog serão construídas. Ao final de cada ciclo, uma nova Sprint é iniciada até que o projeto seja concluído (SCHWABER;

SUTHERLAND, 2013).

A Sprint Planning é outro evento onde todo o Time Scrum se reúne para planejar o trabalho que será realizado na Sprint. Este evento tem duração máxima de oito horas, com o objetivo de definir quais funcionalidades serão desenvolvidas durante aSprint e o que deverá ser feito para concluí-las (SCHWABER; SUTHERLAND, 2013).

A Daily Scrum é uma reunião diária realizada entre o Time de Desenvolvimento com duração de quinze minutos, onde os participantes determinam as atividades a serem realizadas no dia e comentam o que foi feito no dia anterior. Tal reunião promove a melhoria da comunicação entre a equipe e remove prováveis impedimentos no desenvolvimento do produto (SCHWABER; SUTHERLAND, 2013).

A Sprint Review é realizada ao final de cada Sprint, de forma que o Time de Desenvolvimento apresentará as funcionalidades desenvolvidas no período da Sprint, identificando quais impedimentos surgiram e como foram solucionados. OProduct Owner e Scrum Master deverão participar da reunião, garantindo um feedback ao restante da equipe. A duração máxima deste evento é de quatro horas (SCHWABER; SUTHERLAND, 2013).

De acordo com Schwaber e Sutherland (2013), a Sprint Retrospective consiste em um evento para identificar os processos de desenvolvimento do produto que funcionaram,