Processos Ágeis
Aprenda o que são processos ágeis
Conheça as metodologias Scrum e Extreme Programming e quais as
diferenças entre as metodologias tradicionais e ágeis
Leonardo Simas, Osias Carneiro, Vagner Fonseca e Weslley Leandro
O desenvolvimento de tecnologias e a necessidade crescente de sistemas de informação vem
desafiando as empresas responsáveis pela criação de aplicações. É difícil acompanhar as mudanças
de tecnologias, as soluções cada vez mais complexas, as interferências do mundo externo, mudanças
nos requisitos, entre outros. Para tentar amenizar esses problemas, a Engenharia de Software procura
definir metodologias de desenvolvimento de software, que possibilitam uma organização nos
processos e etapas desde sua especificação até a implantação, como os processos ágeis.
Há diversas maneiras de se desenvolver um software de maneira rápida, por meio dos métodos ágeis
de desenvolvimento de software. Essa metodologia de desenvolvimento evoluiu a partir da metade
dos anos 90, com o fortalecimento da Engenharia de Software e com o surgimento de novas maneiras
de se pensar ao construir um software.
O objetivo deste artigo consiste em realizar uma abordagem a respeito das metodologias tradicionais
e as metodologias de processos ágeis, apresentando um breve histórico e focando nas duas principais
metodologias de desenvolvimento “Scrum” e “Extreme Programing (XP)”.
Metodologias Tradicionais
O modelo em Cascata, um dos mais utilizados até pouco tempo atrás (LEACH, 2000), definia etapas
que deveriam ser sequenciais, uma só deve ser iniciada após o termino da sua antecessora, como
observado na Figura 1.
Um modelo inflexível onde o cliente só poderia validar o que foi desenvolvido no final do processo
depois do software completamente desenvolvido, alterações na especificação eram difíceis ou
simplesmente impossíveis de serem realizadas durante o desenvolvimento. Muitas vezes gerava
o famoso “big bang” onde no final o software já não atendia as necessidades por mudanças no
ambiente externo ou precisava ser alterado e um novo fluxo se iniciaria.
O modelo em Espiral (Figura 2) sugere uma sequência de etapas mas, diferente do cascata, o
software é divido em versões chamadas de incremento. Possui quatro atividades:
1. Determinação dos objetivos da iteração
2. Análise dos riscos
3. Desenvolvimento
4. Validação, Testes e planejamento da próxima iteração
Figura 1. Etapas do modelo em cascata
Dessa forma é possível lidar melhor com alterações durante o projeto e a validação do que se está
desenvolvendo é melhor para o cliente, que acompanha o desenvolvimento. Mas assim como no
modelo em cascata não permite etapas sendo realizadas em paralelo ou que precisem de comunicação
com outras etapas.
Figura 2. Modelo em Espiral
O modelo Iterativo e Incremental apresenta um ciclo de vida iterativo baseado no aumento e no
refinamento sucessivo de um sistema através de múltiplos ciclos de desenvolvimento de análise, de
projeto, de implementação e de teste” (LARMAN, 2000).
Atualmente é o modelo mais utilizado, ou outros modelos baseados neste, que traz alguns benefícios
como (MARTINS, 1999):
● A redução de riscos com os custos e prazos planejados;
● A equipe fica focada com os objetivos de cada incremento, trabalhando de maneira mais
eficiente;
Um modelo emergente que combina um melhor gerenciamento e a preocupação com “como as
pessoas trabalham” (CANTOR, 1999).
Figura 3. Modelo Iterativo e Incremental
Processos Ágeis
As metodologias ágeis promovem o desenvolvimento com o trabalho em equipe, colaboração e
adaptabilidade durante o ciclo de vida do projeto. Assim como no modelo iterativo e incremental, o
software é dividido em versões, ou seja, possuem incrementos que são partes menores do software e
são realizados em torno de uma a quatro semanas, passando por todas as etapas desde especificação
até a fase de testes.
Com o objetivo de minimizar a quantidade dos possíveis erros a cada iteração, ela pode não gerar
uma versão com funcionalidade suficiente para o mercado e várias iterações podem ser necessárias
para lançar uma nova funcionalidade.
Há uma priorização na comunicação “cara a cara” entre os integrantes da equipe do que a
documentação (não quer dizer que não há documentação) e por isso sugere que todos trabalhem na
mesma sala.
É necessário um representante do cliente para que se possa tirar dúvidas e esclarecer questões que
possam surgir durante as iterações e que esteja disponível para atender os os demais participantes no
projeto do software.
Manifesto Ágil
Ao passar dos anos as organizações passaram a estar mais focadas em resultados rápidos e
precisos, contratando empresas de desenvolvedoras de software para agilizar os seus processos
institucionais e devido aos projetos de software sofrer diversas transformações, nos últimos tempos
metodologias de desenvolvimento, como o Scrum e o XP, se fortaleceram. Entre elas, a metodologia
de desenvolvimento ágil de software se consolidou no mundo de desenvolvimento de software e
em 2001 o “Manifesto Ágil” termo criado após a criação da Aliança Ágil onde foram apresentados
alguns métodos de desenvolvimento de software entre eles se destacam os métodos Scrum e Extreme
Programming (XP), e também foram fundamentados alguns princípios e características entre os
métodos. Esses métodos aumentam o desempenho e provendo mais qualidade ao produto final.
Scrum
No início do ano de 1986 Hirotaka Takeuchi e Ikujiro Nonaka, escreveram um artigo, foi observado
que equipes pequenas e com baixo nível de especialização, obtêm melhores resultados do que
equipes grandes, nisso há uma semelhança com uma equipe de rugby, quando uma falta é cometida,
eles se arranjam em uma formação coesa de nome Scrum.
O Scrum é uma metodologia ágil iterativa e incremental, pois trata-se de um framework que facilita a
visualização de problemas, mesmo os que possuem de dificuldade elevada.
Scrum tem por objetivo agregar o máximo de valor ao negócio com o menor tempo possível, focando
no Retorno de Investimento (ROI), administrando complexidade, imprevisibilidade e mudança por
meio da visibilidade, inspeção e adaptação (SUTHERLAND, 2002).
Quanto aos papéis executados o Scrum determina três (SCHWABER, 2009):
● Scrum Master - Tem a função de líder de equipe, protegendo-a de obstáculos e problemas
que a impeçam de realizar seu trabalho.
● Product Owner - Maximiza o trabalho do time Scrum, definir recursos, escolher datas de
lançamento, fornecer feedback dos processos e garantir que as regras Scrum sejam seguidas,
ou seja, é o cliente ou alguém que o represente.
● Time Scrum - Responsável pelo desenvolvimento do projeto, tem de 5 à 9 integrantes, define
tarefas e o esforço para realizar as tarefas com a qualidade desejada pelo Product Owner.
Para SUTHERLAND(2008) as princípais ferramentas do Scrum são o backlog do produto, backlog
do sprint, burndown para entrega e burndown do sprint.
SCHWABER(2009) define que o backlog do produto é um documento com requisitos separados por
prioridades que são indispensáveis ao produto. Backlog do sprint é a lista de tarefas que a equipe
executará para transformar o backlog do produto em um incremento entregavel ao cliente. Um
burndown de versão para entrega mede o backlog de produto restante ao longo do tempo de um plano
de entrega. O burndown de sprint mede os ítens do burndown de sprint restantes ao longo do tempo
de uma sprint.
O scrum utiliza-se de eventos de duração fixa, planejamento de versão para entrega, sprint, reunião
diária, revisão e retrospectiva da sprint
● Planejamento da versão: é onde os documentos que definem os requisitos do produto
são concebidos (backlog de produto), suas prioridades e a estimativa de esforço para cada
requisito.
● Reunião da sprint: aqui os requisitos são apresentados à equipe e são definidos, de acordo
com a habilidade de cada um, a tarefa que executarão (backlog da sprint) essa reunião tem em
média 3 a 12 horas dependendo da sprint.
● Sprint: para SCHWABER (2009) essa fase é a coroação do Scrum, com duração por volta de
30 dias, nesse momento os requisitos são desenvolvidos e implementados, ao final é entregue
um incremento funcional ao cliente.
● Revisão da sprint: Reunião entre a equipe com no máximo duas horas de duração onde os
resultados são apresentados, deve-se ter cuidado ao dizer “realizado” já que os resultados
serão apresentados ao cliente.
● Retrospectiva do sprint: Nessa reunião verifica-se o que foi feito de positivo e também
os pontos negativos, afim de revisar o que foi feito de errado para ser corrigido em versões
posteriores, atualizando-se o backlog do produto.
Figura 4. As etapas da metodologia Scrum e sua duração média
Extreme Programming (XP)
O Extreme Programming (XP), metodologia criada por Kent Beck, está voltado principalmente para
pequenas e médias equipes, visando o desenvolvimento de software que se baseiam em requisitos
vagos e que se modificam rapidamente (Beck, 1999). O método XP se diferencia dos demais devido
a uma abordagem incremental, fortalecendo a comunicação (feedback) entre as pessoas envolvidas no
processo de desenvolvimento.
O XP possui quatro valores fundamentais: comunicação, simplicidade, feedback e coragem (Beck,
1999). Para alcançar sucesso na utilização do XP, é preciso seguir todos esses valores.
● Comunicação: deve ocorrer da maneira mais direta (face-a-face) e eficaz possível, a fim
de oferecer agilidade aos assuntos tratados, esclarecendo dúvidas de imediato e evitando
especulações ou mal entendidos entre as partes. O cliente deve estar a disposição da equipe e
membros introvertidos devem ser evitados.
● Simplicidade: é preciso simplicidade no desenvolvimento das funcionalidades solicitadas.
O desenvolvedor deve implementar apenas o necessário para atender ao usuário, sem se
preocupar com funcionalidades que podem ser importantes no futuro, pois elas podem nunca
ser utilizadas.
● Feedback: com partes funcionais em mãos, o cliente estará apto a conduzir a equipe de
desenvolvimento, estabelecendo prioridades e identificando erros imediatamente. Em
contrapartida, o desenvolvedor poderá apontar riscos e estimativas.
● Coragem: por se tratar de uma metodologia nova, que contraria o modelo tradicional, a
equipe precisa de coragem para implantar os três valores anteriores. Nem todos possuem
facilidade de comunicação ou paciência para obter feedback constante do cliente.
Além dos quatro valores básicos, o XP baseia-se em diversas práticas (Figura 5). Para Beck (1999)
existem doze principais práticas de desenvolvimento, elencadas e descritas abaixo:
● Planejamento: consiste em definir o que será feito e o que será adiado. O foco deve estar nos
requisitos atuais e não nos futuros. A escolha deve gerar o máximo de valor para o cliente.
● Entregas frequentes: trata-se de construir um software simples e em seguida adicionar
funcionalidades conforme elas forem surgindo. Com isso, o feedback do cliente será mais
rápido e surpresas serão evitadas.
● Metáfora: são comparações e analogias utilizadas para explicar situações mais facilmente,
sem o uso de termos técnicos. Essa técnica facilita a comunicação e a fixação dos assuntos
entre as partes.
● Projeto simples: o software desenvolvido deve ser o mais simples possível para resolver
o problema atual do cliente, sem se preocupar com requisitos futuros. Esses devem ser
adicionados assim que forem realmente necessários.
● Testes: garantem resultados corretos das funcionalidades. Os testes devem ser feitos de
preferência antes do desenvolvimento (TDD - Test Driven Development).
● Programação em pares: dois desenvolvedores trabalharão em um único computador.
Enquanto um codifica o outro observa, buscando estratégias para otimizar o código do colega.
A troca de experiências e idéias é um dos grandes benefícios.
● Refatoração: consiste em reescrever um código ilegível, duplicado, despadronizado etc. sem
alterar o seu comportamento.
● Propriedade coletiva: o código pertence a toda a equipe. Dessa forma, qualquer
desenvolvedor que julgar necessário modificá-lo, poderá fazé-lo.
● Integração contínua: a integração entre as partes do software deve ser efetuada,
preferencialmente, várias vezes ao dia.
● 40 horas de trabalho semanal: mais de 40 horas semanais de trabalho significa problema
no projeto e deve ser resolvido com melhor planejamento, não com aumento de horas
trabalhadas.
● Cliente presente: o cliente deve estar sempre disponível para tirar dúvidas, evitando atrasos
na comunicação e implementações erradas. É interessante torná-lo parte da equipe de
desenvolvimento.
● Código padrão: seguir padrões previamente acordados de codificação reforça a comunicação
entre os programadores, facilitando o entendimento e a manutenção.
Figura 5. Valores, princípios e práticas do Extreme Programming
Relato - Implantação de Processos Ágeis
Segundo o estudo de caso realizado no Banco Central do Brasil (MELO e FERREIRA, 2010), a
implantação de processos ágeis pode solucionar questões que não são abordadas pelas metodologias
tradicionais. A empresa utilizava um processo derivado do Rational Unified Process (RUP), um
processo iterativo, mas robusto.
A empresa planejou dois projetos pilotos com duas equipes contendo 7 e 6 pessoas respectivamente,
sendo que a maioria dos desenvolvedores possuíam experiência de 2 ou mais anos na área de
desenvolvimento, mas poucos conheciam as metodologias a serem utilizadas ou sobre os conceitos
de processos ágeis.
No início do primeiro projeto foram apresentados os conceitos sobre métodos ágeis e as
metodologias Scrum e XP, para familiarização da equipe. Segundo o relato (MELO e FERREIRA,
2010), as equipes compreenderam e aplicaram facilmente as práticas de pares e de equipes do XP,
sendo que a programação em pares foi de fácil compreensão e absorção pela equipe e a prática
da “metáfora” a mais complexa de ser interpretada.
A prática de execução de testes pelo cliente bem como as entregas curtas, apesar de bem
compreendidas, não foram de fácil aplicação devido cultura do cliente. Mesmo que as entregas
agregassem funcionalidades de certo valor, a organização não tinha o costume de receber soluções
inacabadas.
A equipe relata que houve um ganho quanto a rapidez no aprendizado de tecnologias, conceitos e
padrões. A produtividade foi medida nos dois projetos pilotos utilizando, a medição por pontos de
função e pelas horas gastas nos mesmos. No primeiro houve um ganho de mais de 8% e no segundo
mais de 30% em relação a média da organização. O primeiro era mais complexo que o segundo e a
curva de aprendizado foi maior, pois foi a primeira vez que utilizaram processos ágeis e o segundo
aprendeu com os erros do primeiro.
Os clientes compararam os resultados obtidos com suas experiências passadas usando metodologias
tradicionais, com isso foi gerado uma nítida satisfação do cliente, pois foi possível observar
benefícios como:
● Redução no prazo de entrega
● Facilidade/possibilidade de alterações
● Entendimento aprimorado sobre os custos
● Maior segurança quanto aos testes realizados
A implantação de qualquer metodologia em uma organização é um processo lento, complexo e
exige mudanças na cultura organizacional da empresa, logo dois pilotos não foram suficientes para
a mudança. Mas os ganhos com produtividade e satisfação do cliente compensam tais custos e
obstáculos e favorece a implementação.
Conclusão
Neste artigo abordamos a respeito do Scrum e XP que são metodologias de desenvolvimento de
software utilizadas nos projetos piloto do Banco Central do Brasil. Aplicar um processo ágil em
uma organização requer uma mudança na cultura da mesma exigindo tempo e gerenciamento dessa
implantação. A organização deve precisa ter um ambiente favorável a comunicação, o tamanho do
projeto pode inviabilizar essa comunicação, são indicadas a formação de equipes de no máximo 20
ou 40 pessoas sendo ela composta por pessoas experientes. Os processos ágeis atendem muito bem
projetos e organizações que preenchem esses requisitos mas apesar de já proporcionarem resultados
de sucesso há aqueles que afirmam que ainda é preciso de mais resultados para comprovar o sucesso
desses métodos.
Referências
OLIVEIRA, Alexsandro; MATEUS, Andrade; VINICIUS, Corrêa; Uma Introdução às Metodologias
Ágeis de Desenvolvimento de Software. Salvador, Bahia.
SILVA, Maysa Alves da Conceição; FILHO, Heitor Roriz; SILVA, Helena de Fátima Nunes;
Análise do BA durante o processo Scrum. Artigo apresentado no XVII Simpósio de engenharia de
produção, Bauru, São Paulo, Brasil, 2010.
BONA, Cristina. Avaliação de Processos de Software: Um Estudo de Case em XP e ICONIX. 2002.
122 f. Dissertação (Mestrado em Engenharia de Produção) - Universidade Federal de Santa Catarina.
Florianópolis, 2002.
Agile Alliance. Acesso em: 25 de julho de 2011. Disponível em: <http://www.agilealliance.org>
Manifesto para Desenvolvimento Ágil de Software. Acesso em 26 de julho de 2011. Disponivel em
<http://agilemanifesto.org/iso/ptbr/>
Agile Software Development. Acesso em 29 de julho de 2011. Disponível em: <http://
en.wikipedia.org/wiki/Agile_software_development>
Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. Acesso
em 28 de julho de 2011. Disponível em:
<http://www.inf.ufrgs.br/~dsogari/material/S5/INF01127/Material/Comparacao-Metodos-AgeisTradicionais.pdf>
MELO, Claudia de O, FERREIRA, and Gisele R. M. Adoção de métodos ágeis em uma Instituição
Pública de grande porte - um estudo de caso., In Proceedings of the Brazilian Workshop for Agile
Methods (WBMA 2010) in the Brazilian Conference on Agile Methods (Agile Brazil 2010), pp. 112125. June, 2010. Disponível em: <http://www.agilcoop.org.br/files/WBMA_Melo_e_Ferreira.pdf>
Leonardo Simas ([email protected]) é graduando em Sistemas de Informação pela Universidade do Estado da Bahia
(UNEB) e estagiário no Instituto Recôncavo de Tecnologia.
Osias Carneiro ([email protected]) é graduando em Sistemas de Informação pela Universidade do Estado da Bahia
(UNEB) e estagiário no Instituto Recôncavo de Tecnologia.
Vagner Fonseca ([email protected]) é graduando em Sistemas de Informação pela Universidade do Estado da Bahia
(UNEB), foi coordenador do grupo de desenvolvimento da XI Escola Regional de Computação Bahia Alagoas Sergipe (XI ERBASE),
participou do projeto de desenvolvimento de agente para sistema de Segurança de Notebooks Leadership e estagiário da Gerência
de Informática da UNEB.
Weslley Leandro ([email protected]) é graduando em Sistemas de Informação pela Universidade do Estado da Bahia
(UNEB) e estagiário na Wcs Design.