Processos geis

Aprenda o que so processos geis

Conhea as metodologias Scrum e Extreme Programming e quais as
diferenas 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 informao vem

desafiando as empresas responsveis pela criao de aplicaes. difcil acompanhar as mudanas
de tecnologias, as solues cada vez mais complexas, as interferncias do mundo externo, mudanas
nos requisitos, entre outros. Para tentar amenizar esses problemas, a Engenharia de Software procura
definir metodologias de desenvolvimento de software, que possibilitam uma organizao nos
processos e etapas desde sua especificao at a implantao, como os processos geis.
H diversas maneiras de se desenvolver um software de maneira rpida, por meio dos mtodos 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 histrico 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 atrs (LEACH, 2000), definia etapas
que deveriam ser sequenciais, uma s deve ser iniciada aps o termino da sua antecessora, como
observado na Figura 1.
Um modelo inflexvel onde o cliente s poderia validar o que foi desenvolvido no final do processo
depois do software completamente desenvolvido, alteraes na especificao eram difceis ou
simplesmente impossveis de serem realizadas durante o desenvolvimento. Muitas vezes gerava
o famoso big bang onde no final o software j no atendia as necessidades por mudanas no
ambiente externo ou precisava ser alterado e um novo fluxo se iniciaria.
O modelo em Espiral (Figura 2) sugere uma sequncia de etapas mas, diferente do cascata, o

software divido em verses chamadas de incremento. Possui quatro atividades:

1. Determinao dos objetivos da iterao
2. Anlise dos riscos
3. Desenvolvimento
4. Validao, Testes e planejamento da prxima iterao

Figura 1. Etapas do modelo em cascata

Dessa forma possvel lidar melhor com alteraes durante o projeto e a validao do que se est
desenvolvendo melhor para o cliente, que acompanha o desenvolvimento. Mas assim como no
modelo em cascata no permite etapas sendo realizadas em paralelo ou que precisem de comunicao
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 atravs de mltiplos ciclos de desenvolvimento de anlise, de
projeto, de implementao e de teste (LARMAN, 2000).
Atualmente o modelo mais utilizado, ou outros modelos baseados neste, que traz alguns benefcios
como (MARTINS, 1999):

 A reduo 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 preocupao 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, colaborao e
adaptabilidade durante o ciclo de vida do projeto. Assim como no modelo iterativo e incremental, o
software dividido em verses, ou seja, possuem incrementos que so partes menores do software e
so realizados em torno de uma a quatro semanas, passando por todas as etapas desde especificao
at a fase de testes.
Com o objetivo de minimizar a quantidade dos possveis erros a cada iterao, ela pode no gerar
uma verso com funcionalidade suficiente para o mercado e vrias iteraes podem ser necessrias
para lanar uma nova funcionalidade.
H uma priorizao na comunicao cara a cara entre os integrantes da equipe do que a
documentao (no quer dizer que no h documentao) e por isso sugere que todos trabalhem na
mesma sala.
necessrio um representante do cliente para que se possa tirar dvidas e esclarecer questes que
possam surgir durante as iteraes e que esteja disponvel para atender os os demais participantes no
projeto do software.

Manifesto gil
Ao passar dos anos as organizaes passaram a estar mais focadas em resultados rpidos e

precisos, contratando empresas de desenvolvedoras de software para agilizar os seus processos

institucionais e devido aos projetos de software sofrer diversas transformaes, 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 aps a criao da Aliana gil onde foram apresentados
alguns mtodos de desenvolvimento de software entre eles se destacam os mtodos Scrum e Extreme
Programming (XP), e tambm foram fundamentados alguns princpios e caractersticas entre os
mtodos. Esses mtodos aumentam o desempenho e provendo mais qualidade ao produto final.

Scrum
No incio do ano de 1986 Hirotaka Takeuchi e Ikujiro Nonaka, escreveram um artigo, foi observado
que equipes pequenas e com baixo nvel de especializao, obtm melhores resultados do que
equipes grandes, nisso h uma semelhana com uma equipe de rugby, quando uma falta cometida,
eles se arranjam em uma formao coesa de nome Scrum.
O Scrum uma metodologia gil iterativa e incremental, pois trata-se de um framework que facilita a
visualizao de problemas, mesmo os que possuem de dificuldade elevada.
Scrum tem por objetivo agregar o mximo de valor ao negcio com o menor tempo possvel, focando
no Retorno de Investimento (ROI), administrando complexidade, imprevisibilidade e mudana por
meio da visibilidade, inspeo e adaptao (SUTHERLAND, 2002).
Quanto aos papis executados o Scrum determina trs (SCHWABER, 2009):
Scrum Master - Tem a funo de lder de equipe, protegendo-a de obstculos e problemas
que a impeam de realizar seu trabalho.
Product Owner - Maximiza o trabalho do time Scrum, definir recursos, escolher datas de
lanamento, fornecer feedback dos processos e garantir que as regras Scrum sejam seguidas,
ou seja, o cliente ou algum que o represente.
Time Scrum - Responsvel pelo desenvolvimento do projeto, tem de 5 9 integrantes, define
tarefas e o esforo para realizar as tarefas com a qualidade desejada pelo Product Owner.
Para SUTHERLAND(2008) as princpais ferramentas do Scrum so 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 so indispensveis 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 verso 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 durao fixa, planejamento de verso para entrega, sprint, reunio
diria, reviso e retrospectiva da sprint
Planejamento da verso: onde os documentos que definem os requisitos do produto
so concebidos (backlog de produto), suas prioridades e a estimativa de esforo para cada
requisito.
Reunio da sprint: aqui os requisitos so apresentados equipe e so definidos, de acordo
com a habilidade de cada um, a tarefa que executaro (backlog da sprint) essa reunio tem em
mdia 3 a 12 horas dependendo da sprint.
Sprint: para SCHWABER (2009) essa fase a coroao do Scrum, com durao por volta de
30 dias, nesse momento os requisitos so desenvolvidos e implementados, ao final entregue
um incremento funcional ao cliente.
Reviso da sprint: Reunio entre a equipe com no mximo duas horas de durao onde os
resultados so apresentados, deve-se ter cuidado ao dizer realizado j que os resultados
sero apresentados ao cliente.
Retrospectiva do sprint: Nessa reunio verifica-se o que foi feito de positivo e tambm
os pontos negativos, afim de revisar o que foi feito de errado para ser corrigido em verses
posteriores, atualizando-se o backlog do produto.

Figura 4. As etapas da metodologia Scrum e sua durao mdia

Extreme Programming (XP)

O Extreme Programming (XP), metodologia criada por Kent Beck, est voltado principalmente para
pequenas e mdias equipes, visando o desenvolvimento de software que se baseiam em requisitos
vagos e que se modificam rapidamente (Beck, 1999). O mtodo XP se diferencia dos demais devido
a uma abordagem incremental, fortalecendo a comunicao (feedback) entre as pessoas envolvidas no
processo de desenvolvimento.
O XP possui quatro valores fundamentais: comunicao, simplicidade, feedback e coragem (Beck,
1999). Para alcanar sucesso na utilizao do XP, preciso seguir todos esses valores.

 Comunicao: deve ocorrer da maneira mais direta (face-a-face) e eficaz possvel, a fim
de oferecer agilidade aos assuntos tratados, esclarecendo dvidas de imediato e evitando
especulaes ou mal entendidos entre as partes. O cliente deve estar a disposio da equipe e
membros introvertidos devem ser evitados.
Simplicidade: preciso simplicidade no desenvolvimento das funcionalidades solicitadas.
O desenvolvedor deve implementar apenas o necessrio para atender ao usurio, sem se
preocupar com funcionalidades que podem ser importantes no futuro, pois elas podem nunca
ser utilizadas.
Feedback: com partes funcionais em mos, 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 trs valores anteriores. Nem todos possuem
facilidade de comunicao ou pacincia para obter feedback constante do cliente.
Alm dos quatro valores bsicos, o XP baseia-se em diversas prticas (Figura 5). Para Beck (1999)
existem doze principais prticas 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 no nos futuros. A escolha deve gerar o mximo 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
rpido e surpresas sero evitadas.
Metfora: so comparaes e analogias utilizadas para explicar situaes mais facilmente,
sem o uso de termos tcnicos. Essa tcnica facilita a comunicao e a fixao dos assuntos
entre as partes.
Projeto simples: o software desenvolvido deve ser o mais simples possvel para resolver
o problema atual do cliente, sem se preocupar com requisitos futuros. Esses devem ser
adicionados assim que forem realmente necessrios.
Testes: garantem resultados corretos das funcionalidades. Os testes devem ser feitos de
preferncia antes do desenvolvimento (TDD - Test Driven Development).
Programao em pares: dois desenvolvedores trabalharo em um nico computador.
Enquanto um codifica o outro observa, buscando estratgias para otimizar o cdigo do colega.
A troca de experincias e idias um dos grandes benefcios.
Refatorao: consiste em reescrever um cdigo ilegvel, duplicado, despadronizado etc. sem
alterar o seu comportamento.
Propriedade coletiva: o cdigo pertence a toda a equipe. Dessa forma, qualquer
desenvolvedor que julgar necessrio modific-lo, poder faz-lo.
Integrao contnua: a integrao entre as partes do software deve ser efetuada,
preferencialmente, vrias 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, no com aumento de horas
trabalhadas.
Cliente presente: o cliente deve estar sempre disponvel para tirar dvidas, evitando atrasos
na comunicao e implementaes erradas. interessante torn-lo parte da equipe de
desenvolvimento.
Cdigo padro: seguir padres previamente acordados de codificao refora a comunicao
entre os programadores, facilitando o entendimento e a manuteno.

Figura 5. Valores, princpios e prticas do Extreme Programming

Relato - Implantao de Processos geis

Segundo o estudo de caso realizado no Banco Central do Brasil (MELO e FERREIRA, 2010), a
implantao de processos geis pode solucionar questes que no so 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 possuam experincia 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 incio do primeiro projeto foram apresentados os conceitos sobre mtodos geis e as
metodologias Scrum e XP, para familiarizao da equipe. Segundo o relato (MELO e FERREIRA,
2010), as equipes compreenderam e aplicaram facilmente as prticas de pares e de equipes do XP,
sendo que a programao em pares foi de fcil compreenso e absoro pela equipe e a prtica

da metfora a mais complexa de ser interpretada.

A prtica de execuo de testes pelo cliente bem como as entregas curtas, apesar de bem
compreendidas, no foram de fcil aplicao devido cultura do cliente. Mesmo que as entregas
agregassem funcionalidades de certo valor, a organizao no tinha o costume de receber solues
inacabadas.
A equipe relata que houve um ganho quanto a rapidez no aprendizado de tecnologias, conceitos e
padres. A produtividade foi medida nos dois projetos pilotos utilizando, a medio por pontos de
funo e pelas horas gastas nos mesmos. No primeiro houve um ganho de mais de 8% e no segundo
mais de 30% em relao a mdia da organizao. 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 experincias passadas usando metodologias
tradicionais, com isso foi gerado uma ntida satisfao do cliente, pois foi possvel observar
benefcios como:
Reduo no prazo de entrega
Facilidade/possibilidade de alteraes
Entendimento aprimorado sobre os custos
Maior segurana quanto aos testes realizados
A implantao de qualquer metodologia em uma organizao um processo lento, complexo e
exige mudanas na cultura organizacional da empresa, logo dois pilotos no foram suficientes para
a mudana. Mas os ganhos com produtividade e satisfao do cliente compensam tais custos e
obstculos e favorece a implementao.

Concluso
Neste artigo abordamos a respeito do Scrum e XP que so metodologias de desenvolvimento de
software utilizadas nos projetos piloto do Banco Central do Brasil. Aplicar um processo gil em
uma organizao requer uma mudana na cultura da mesma exigindo tempo e gerenciamento dessa
implantao. A organizao deve precisa ter um ambiente favorvel a comunicao, o tamanho do
projeto pode inviabilizar essa comunicao, so indicadas a formao de equipes de no mximo 20
ou 40 pessoas sendo ela composta por pessoas experientes. Os processos geis atendem muito bem
projetos e organizaes 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 mtodos.

Referncias

OLIVEIRA, Alexsandro; MATEUS, Andrade; VINICIUS, Corra; Uma Introduo s Metodologias

geis de Desenvolvimento de Software. Salvador, Bahia.
SILVA, Maysa Alves da Conceio; FILHO, Heitor Roriz; SILVA, Helena de Ftima Nunes;
Anlise do BA durante o processo Scrum. Artigo apresentado no XVII Simpsio de engenharia de
produo, Bauru, So Paulo, Brasil, 2010.
BONA, Cristina. Avaliao de Processos de Software: Um Estudo de Case em XP e ICONIX. 2002.
122 f. Dissertao (Mestrado em Engenharia de Produo) - Universidade Federal de Santa Catarina.
Florianpolis, 2002.
Agile Alliance. Acesso em: 25 de julho de 2011. Disponvel 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. Disponvel em: <http://
en.wikipedia.org/wiki/Agile_software_development>
Comparao entre Metodologias geis e Tradicionais para o Desenvolvimento de Software. Acesso
em 28 de julho de 2011. Disponvel em:
<http://www.inf.ufrgs.br/~dsogari/material/S5/INF01127/Material/Comparacao-Metodos-AgeisTradicionais.pdf>
MELO, Claudia de O, FERREIRA, and Gisele R. M. Adoo de mtodos geis em uma Instituio
Pblica 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. Disponvel em: <http://www.agilcoop.org.br/files/WBMA_Melo_e_Ferreira.pdf>

Leonardo Simas (leosimasgoncalves@gmail.com) graduando em Sistemas de Informao pela Universidade do Estado da Bahia
(UNEB) e estagirio no Instituto Recncavo de Tecnologia.

Osias Carneiro (osiascarneiro@hotmail.com) graduando em Sistemas de Informao pela Universidade do Estado da Bahia
(UNEB) e estagirio no Instituto Recncavo de Tecnologia.

Vagner Fonseca (vagner.fonseca@gmail.com) graduando em Sistemas de Informao pela Universidade do Estado da Bahia
(UNEB), foi coordenador do grupo de desenvolvimento da XI Escola Regional de Computao Bahia Alagoas Sergipe (XI ERBASE),
participou do projeto de desenvolvimento de agente para sistema de Segurana de Notebooks Leadership e estagirio da Gerncia
de Informtica da UNEB.

Weslley Leandro (weslleyleandro@gmail.com) graduando em Sistemas de Informao pela Universidade do Estado da Bahia
(UNEB) e estagirio na Wcs Design.