-
Processos geisAprenda o que so processos geisConhea 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 TradicionaisO 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 iterao2. Anlise dos
riscos3. Desenvolvimento4. 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 geisAs
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 gilAo 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. ScrumNo 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 geisSegundo 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. ConclusoNeste 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: Manifesto para
Desenvolvimento gil de Software. Acesso em 26 de julho de 2011.
Disponivel em
Agile Software Development. Acesso em 29 de julho de 2011.
Disponvel em: Comparao entre Metodologias geis e Tradicionais para
o Desenvolvimento de Software. Acesso em 28 de julho de 2011.
Disponvel em:
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. 112-125. June, 2010. Disponvel em:
Leonardo Simas ([email protected]) graduando em
Sistemas de Informao pela Universidade do Estado da Bahia (UNEB) e
estagirio no Instituto Recncavo de Tecnologia.
Osias Carneiro ([email protected]) graduando em Sistemas
de Informao pela Universidade do Estado da Bahia (UNEB) e estagirio
no Instituto Recncavo de Tecnologia.
-
Vagner Fonseca ([email protected]) 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 ([email protected]) graduando em Sistemas
de Informao pela Universidade do Estado da Bahia (UNEB) e estagirio
na Wcs Design.