Metodologias Ágeis no desenvolvimento de apps

Tem pouco mais de duas décadas que as ditas “metodologias ágeis” surgiram no mercado de software e, desde então, são alvo de estudos e tentativas muitas vezes infrutíferas de tornar o sonho da agilidade em realidade. Com processos pouco ortodoxos, os métodos ágeis primam pela simplicidade e dinamismo, frente aos processos burocráticos e tediosos das metodologias mais tradicionais para gerenciamento de projetos de software.

Entretanto, muitas são as metodologias disponíveis atualmente, causando grande confusão na comunidade de desenvolvimento de software. Maior ainda é a incerteza sobre quais cenários elas se aplicam melhor, tamanho de projetos suportados, vantagens e desvantagens, etc. Este estudo comparativo elucida alguns desses questionamentos enquanto provê um estudo sucinto sobre a aplicabilidade de tais métodos sobre o desenvolvimento de aplicações para dispositivos móveis.

Este post está estruturado da seguinte forma: a seção 2 apresenta uma breve definição sobre as metodologias ágeis. A seção 3 apresenta o estudo comparativo entre os métodos mais famosos da atualidade. A seção 4 apresenta alguns fatores motivacionais para adoção de tais metodologias no desenvolvimento de aplicações para dispositivos móveis, também destacando alguns desafios. E por fim, algumas conclusões são apresentadas sobre o trabalho e as referências bibliográficas são disponibilizadas no final deste artigo.

Querendo mais informações sobre o assunto, recomendo a leitura do meu livro.

Metodologias Ágeis

Desde o ano de 1968 que a comunidade mundial de desenvolvimento de software passou oficialmente a buscar soluções mais produtivas, de maior qualidade e reproduzíveis para a forma como se vinha desenvolvendo produtos de software. Segundo [BAUER, 1968], a emergente Engenharia de Software se basearia nas demais áreas de engenharia para tornar o processo de desenvolvimento de software menos artesanal (artistic endeavour no original) e mais reproduzível, aumentando drasticamente a qualidade do produto final, com métricas de produtividade e prazos de entrega mais precisos. Tais estudos originaram as primeiras metodologias, ditas tradicionais, para desenvolvimento de software.

O uso de tais metodologias profissionalizou o processo de desenvolvimento, ao mesmo tempo que burocratizava, algumas vezes em demasia, o trabalho dos desenvolvedores, criando muitas vezes papéis até então inexistentes nas equipes de software (CRAIN, 2005): engenheiros, arquitetos, etc. Além disso, a abordagem linear de desenvolvimento proposta por [ROYCE, 1970], com análise, desenvolvimento e testes em um único sentido, executada pela imensa maioria de fábricas de software foi se mostrando ao longo das décadas como algo ineficaz no que tange à adaptabilidade às mudanças de requisitos e principalmente, gerando produtos muitas vezes insatisfatórios ao cliente final. Para um desenvolvimento mais rápido de software, a menor custo e maior resposta às mudanças de escopo, era necessário que essa forma tradicional de desenvolvimento fosse evoluída, evolução esta que foi se dar algumas décadas depois.

Em 2001, formou-se a chamada Aliança Ágil, constituída por profissionais e estudiosos de software para a construção de “regras” para uma construção de software com maior qualidade, maior valor ao cliente, menor custo e em menor tempo. O chamado “Manifesto Ágil”, constitui-se das seguintes prerrogativas, segundo [BECK, 2001]:

Indivíduos e interações mais que processos e ferramentas
Software em funcionamento 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

Os autores ainda afirmam que ([BECK, 2001]): “…mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”. Sobre tal manifesto, vários dos autores voltaram suas atenções à construção de seus frameworks de desenvolvimento ágil, também conhecidos como metodologias ou métodos ágeis. Seja no Scrum de Ken Schwaber e Jeff Sutherland ou no Extreme Programming de Kent Beck, as metodologias ágeis parecem ser à evolução adequada frente às necessidades atuais de desenvolvimento de software rápido, de baixo custo e alta qualidade ([FOWLER, 2005]).

Estudo comparativo entre metodologias ágeis

Frente aos desafios do cotidiano moderno nas empresas de software, as metodologias ágeis surgem como as sucessoras aos desenvolvimento tradicional, guiadas pelas interações entre as pessoas e pela satisfação do cliente ([BECK, 2001]). Vários dos pensadores integrantes da Aliança Ágil, no decorrer das últimas duas décadas, criaram seus frameworks ou metodologias de desenvolvimento de software embasados nos princípios do que se tornou o Manifesto Ágil. Dentre essas metodologias, algumas alcançaram certa popularidade em âmbito mundial e, dentre elas, três foram alvo deste estudo, que visa elucidar suas características principais para podermos compará-las: Extreme Programming, Scrum (que eu detalhei neste post) e Crystal Clear.

Extreme Programming (XP)

Segundo [WELLS, 2009], o primeiro projeto XP iniciou em 1996. Desde então ele teve sua eficácia comprovada pro diversas empresas de diferentes tamanhos pelo mundo afora. Ainda segundo [WELLS, 2009], XP é um sucesso pois tensiona o projeto à satisfação do cliente. Criada (principalmente) por Kent Beck, esta metodologia é extremamente prática, tendo sido concebida em meio a situações reais e lapidada com base no que funciona e no que não funciona em times de desenvolvimento de software.

Como principais características do XP podemos citar (segundo [WELLS, 2009]):

Planejamento das releases baseado em histórias do usuário e não em casos de uso;
Entrega frequente de pequenas releases em períodos de tempo chamados iterações;
Reuniões diárias em pé, de poucos minutos;
Jamais permite a adição de funcionalidades mais cedo do que o necessário;
Todo código deve ser escrito por duas pessoas trabalhando juntas;
Cliente sempre disponível para atender a equipe;
TDD, o teste deve ser escrito antes do código e todo código deve ter um teste;

Scrum

Segundo [SCHWABER, 2011], Scrum (criado em 1991) é um framework para desenvolvimento de produtos complexos. Ainda segundo a definição dos autores do Scrum, ele é: “leve, simples de entender e extremamente difícil de dominar”. Isso significa que o Scrum é uma metodologia ágil muito fácil de pôr em prática mas que exige muita disciplina e uma mudança cultural nas equipes que trabalharão com ele. E por fim, o Scrum é fundamentado em três pilares: transparência, inspeção e adaptação.

Como principais características do Scrum podemos citar ([SCHWABER, 2011]):

Apenas três papéis no “time Scrum”, que deve se manter entre 5 e 9 integrantes: Scrum Master, Product Owner e Equipe de Desenvolvimento;
Entrega contínua de software funcionando em iterações curtas de 2 a 4 semanas;
Quatro reuniões com durações pré-definidas: Sprint Planning, Daily Meeting, Sprint Review e Sprint Retrospective;
Poucos artefatos: Burndown Chart (de Release e de Sprint), Product Backlog (de Release e de Sprint) e Definição de Pronto;
A Equipe de Desenvolvimento decide quanto tempo demora para construir cada requisito do sistema;
Não define títulos para os membros da Equipe de Desenvolvimento, deixando em aberto quem fará o quê para a equipe se auto-gerenciar;

Crystal Clear

A família de metodologias Crystal Light foi criada por Alistair Cockburn na década de 90 (mais precisamente de 1991 a 1999) enquanto este era funcionário da IBM ([COCKBURN, 2001]) e sua fundamentação é toda sobre as experiências de dezenas de equipes nos mais variados projetos, em diferentes regiões do mundo e com graus variados de sucesso. Cockburn constatou que o uso de processos tradicionais no projeto de software não garantiam o sucesso do mesmo, e que muitas vezes a comunicação entre os membros da equipe entre si e com o cliente eram o fator decisivo, a despeito do que as formalidades de software bem-documentado exigiam. [COCKBURN, 2001] dividiu a família Crystal Light de acordo com o tamanho e obejtivos das equipes, sendo que o método Crystal Clear é o mais indicado para pequenas equipes, de 2 a 6 pessoas ([COCKBURN, 2004]), que geralmente compreendem a imensa maioria dos times de desenvolvimento mobile.

Como principais características do método Crystal Clear podemos citar ([COCKBURN, 2001]):

Interações face-a-face ao invés de documentação escrita;
As equipes são mantidas pequenas, com duas a seis pessoas;
Times não precisam de processos complicados para serem bem-sucedidos;
Crystal foca-se em ser de fácil adoção, admitindo que pode-se se obter melhores resultados com XP, se os times tiverem disciplina para segui-lo;
As entregas de funcionalidades devem ocorrer a cada mês ou bimestres;
A estrutura ideal para as equipes deve ser todos trabalhando em uma mesma sala com quadros brancos e nenhuma distração;

Desenvolvimento de software para dispositivos móveis usando metodologias ágeis

O cenário de desenvolvimento de software para dispositivos móveis é um dos mais vorazes da atualidade, segundo [MCMILLAN, 2010], uma pesquisa demonstrou que 35% das empresas de TI consideram o recrutamento de profissionais para trabalhar em projetos de computação móvel como uma das três prioridades da empresa. Além disso, a mesma pesquisa revelou que 95% das empresas consideram o mercado mobile extremamente competitivo. Um dos motivos, ainda segundo [MCMILLAN, 2010] é o fato de que todos querem versões portáteis de seus softwares desktop.

Em um mercado com crescimento tão vertiginoso fica difícil de manter processos gerenciais mais burocráticos sem perder o time-to-market para empresas mais ágeis. Ainda que as matodologias tradicionais forneçam inúmeros artefatos para controles, previsões e métricas no desenvolvimento de software, nada disso tem valor algum contra um software funcionando antes da concorrência ou contra uma aplicação construída em um mês por um garoto de 14 anos ([JEFFRIES, 2011]) que ultrapassou o famoso Angry Birds em número de downloads. A solução nestes casos, pode estar nas metodologias ágeis.

Dentre as metodologias estudadas podemos destacar duas categorias: metodologias empíricas que requerem alta disciplina e metodologias mais “soltas” que dão maior valor à comunicação do que aos processos em si. O quadro abaixo mostra um cruzamento entre as metodologias estudadas e suas características em comum, facilitando a adoção da metodologia que mais se adequar ao perfil de equipe que irá trabalhar no projeto.

	XP	Scrum	Crystal Clear
Times Pequenos (-10)	Sim	Sim	Sim
Muita disciplina	Sim	Sim	Não
Definição de Títulos	Não	Não	Não
Prazos curtos (- 1 mês)	Sim	Sim	Não necessariamente
Fácil Adoção	Não	Não	Sim
Reuniões Diárias	Sim	Sim	Não
Programação em Pares	Sim	Não	Não
Exige Cliente presente	Sim	Não necessariamente	Não

Enquanto que as primeiras produzem melhores resultados, a última é a mais indicada para equipes iniciantes que nunca trabalharam com metodologias ágeis ou que possuem uma longa experiência com metodologias tradicionais e tem uma forte barreira cultural a romper. Como o próprio [COCKBURN, 2001] cita: “Um time pode começar com Crystal Clear e avançar para o XP. Um time que falhe com XP pode voltar ao Crystal Clear.”. Entretanto, a desvantagem em produtividade e controle da metodologia Crystal citada por [COCKBURN, 2001] pode ser um empecilho para equipes em projetos críticos ou que já se encontram em atraso, neste caso, devendo utilizar a metodologia Scrum ou XP, conforme a sua preferência.

Conclusões

Muito se evoluiu no desenvolvimento de software profissional da década de 60 para cá. A necessidade de aumento de produtividade e qualidade aliado à redução dos custos devido à satisfação dos clientes com o produto entregue foi o que norteou a criação de processos de software cada vez mais precisos e controladores, o que teve como efeito colateral um incremento exponencial em complexidade e burocracia. Desde o waterfall de 1970 até o RUP de 1987, o incremento de qualidade sempre veio atrelado a um aumento significativo de documentação e recuo na agilidade do desenvolvimento. Embora se encaixem perfeitamente às grandes empresas ou aos softwares mantidos por dezenas de pessoas, as metodologias tradicionais não se aplicam tão bem no desenvolvimento de pequena escala ou onde o curto prazo de lançamento é a chave para o sucesso ou fracasso da empreitada.

Para estes casos, metodologias mais soltas, desde o simplíssimo (mas não simplório) Crystal Clear de Cockburn até os extremamente disciplinados Scrum e XP, podem ser a chave para se obter software de qualidade entregue em prazos curtos e com equipes reduzidas. Considerando as características da maioria dos projetos de software para dispositivos móveis, tais como: equipes reduzidas, prazos curtos e baixo orçamento; utilizar uma metodologia ágil no processo de desenvolvimento parece uma escolha óbvia, ficando apenas a dúvida sobre qual usar, dentre as diversas existentes no mercado.

Pelos estudos efetuados com três das mais utilizadas metodologias do mercado, pôde-se constatar que para equipes iniciantes no desenvolvimento ágil de software e que podem se dar ao luxo de prazos não tão apertados em um primeiro momento, o Crystal Clear pode ser a solução ideal. É importante ressaltar que devido às limitações da própria metodologia o ideal é que tão logo a equipe se sinta confortável, migre-se para uma metodologia mais completa e que permita um maior controle dos processos sem abrir mão da agilidade, é claro, como Scrum e XP. Para as demais equipes que já tenham tido experiências com metodologias tradicionais e/ou não se sintam intimidadas com “regras” como programação em pares, TDD, reuniões diárias, etc, adotar Scrum ou XP significará um aumento de qualidade e produtividade em seus projetos.

Para mais informações especificamente sobre o Scrum, minha metodologia favorita, leia este post.

Referências

BAUER, F.L. et all; Software Engineering, 1968. Disponível em: < http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF>. Acesso em: 12 maio 2012

CRAIN, A.; Understanding RUP Roles, 2005. Disponível em: <http://www.ibm.com/developerworks/rational/library/apr05/crain/>. Acesso em: 12 maio 2012

ROYCE, W.; Managing the Development of Large Software Systems, 1970. Disponível em: <http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf>. Acesso em: 12 maio 2012

BECK, K. et all; Manifesto for Agile Software Development, 2001. Disponível em: <http://agilemanifesto.org/>. Acesso em: 12 maio 2012

FOWLER, M.; The New Methodology, 2005. Disponível em: <http://martinfowler.com/articles/newMethodology.html>. Acesso em: 12 maio 2012

WELLS, D.; Extreme Programming: A Gentle Introduction, 2009. Disponível em: <http://www.extremeprogramming.org/>. Acesso em: 12 maio 2012

SCHWABER, K. e SUTHERLAND, J.; The Scrum Guide, 2011. Disponível em: <http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf>. Acesso em: 12 maio 2012

COCKBURN, A.; Crystal Light Methods, 2001. Disponível em: <http://alistair.cockburn.us/Crystal+light+methods>. Acesso em: 12 maio 2012

COCKBURN, A.; Crystal Clear Distilled, 2004. Disponível em: <http://alistair.cockburn.us/Crystal+Clear+distilled>. Acesso em: 12 maio 2012

MCMILLAN, D.; Tech Companies see Dearth of Mobile-Software Developers, 2010. Disponível em: <http://www.businessweek.com/technology/content/oct2010/tc20101020_639668.htm>. Acesso em: 12 maio 2012

JEFFRIES, A.; 14-Year Old’s iPhone App Beats Out Angry Birds, 2011. Disponível em: <http://www.observer.com/2011/01/14year-olds-iphone-app-beats-out-angry-birds/>. Acesso em: 12 maio 2012

Autor

Artigo escrito por Luiz Fernando Duarte Junior, graduado em Ciência da Computação (Ulbra, 2010) e pós-graduado em computação mobile (Unisinos, 2013), professor na Faculdade de Tecnologia de Porto Alegre (FAQI), autor do livro Scrum e Métodos Ágeis: Um Guia Prático.