Mtodos geis

Diego Molz - 42103

1
,Rafael Zingler 43953
1
, Roberto Arajo 74300, Rodrigo
Maus 72567
1
, Rodrigo Vasconcelos 42585
1
1
Cincia da Computao Universidade de Santa Cruz do Sul (UNISC)
diegomolz@gmail.com, rafaelzingler@gmail.com, robaraujo404@gmil.com,
rodrigo.maus@gmail.com, rreginatto@gmail.com
Abstract: Entrepreneurial environments are changing every day faster and
professionals in the field of information technology must keep pace with these
changes, it takes increasingly employing Agile methodologies in project
development.
Resumo: Ambientes empresarias esto mudando a cada dia mais rapidamente e
os profissionais da rea de tecnologia da informao devem acompanhar estas
mudanas, isto leva cada vez mais o emprego de metodologias geis no
desenvolvimento de projetos.
1. Introduo
A expresso mtodos geis vem se tornando cada vez mais comum entre os
desenvolvedores de software, porm os mais tradicionais confundem a mesma com falta
de controle e anarquia, porm devemos levar em considerao que ser gil nos dias de
hoje o diferencial em relao aos concorrentes e ao contrrio exige muita disciplina e
organizao.
Agilidade a habilidade de criar e responder a mudanas com respeito ao
resultado financeiro do projeto em um turbulento ambiente de negcios. Agilidade a
habilidade de balancear flexibilidade com estabilidade (HIGHSMITH, 2004).
2.Mtodos geis
O termo Metodologias geis tornou-se popular em 2001 quando um grupo de
dezessete especialistas em processos de desenvolvimento de software decidiu se reunir
para discutir maneiras de melhorar o desempenho de seus projetos.
Embora cada um possua uma maneira prpria de desenvolver com sucesso
utilizando diferentes tipos de metodologias (Scrum, Extreme Programming (XP) entre
outros), todos concordavam que, em suas experincias prvias, um pequeno conjunto
de princpios sempre parecia ter sido respeitado quando os projetos davam certo.
Foi criada ento a Aliana gil e o estabelecimento do Manifesto gil, que se
baseia em quatro conceitos:
Indivduos e interao entre eles so mais que processos e ferramentas:
os softwares so construdos por uma equipe ento elas precisam
trabalhar juntas (incluindo programadores, testers, projetistas e tambm o
cliente). Processos e ferramentas so importantes, mas no so to
importantes quanto trabalhar juntos.
Software em funcionamento mais que documentao abrangente: a
documentao deve existir para ajudar pessoas a entender como o
sistema foi construdo, mas muito mais fcil entender como o
funcionamento vendo o sistema funcionar do que atravs de diagramas
que descrevem o funcionamento ou abstraem o uso.
Colaborao com o cliente mais que negociao de contratos: somente o
cliente pode dizer o que ele espera do software e normalmente eles no
sabem explicar exatamente o que eles esperam e ainda, eles mudam de
ideia ao longo do tempo e conforme eles vm o software funcionando.
Ter um contrato importante para definir as responsabilidades e direitos
mas no deve substituir a comunicao. Trabalhos desenvolvidos com
sucesso tm constante comunicao com o cliente para entender suas
necessidades e ajuda-los a descobrir a melhor forma de express-las.
Responder a mudanas mais que seguir um plano: mudanas uma
realidade no ambiente de negcios e elas acontecem por inmeras
razes: as regras e leis sofrem alteraes, as pessoas mudam de idia e a
tecnologia evolui. O software precisa refletir essas mudanas. Um
projeto de software certamente deve ter um plano mas ele deve ser
flexvel o suficiente para comportar as mudanas quando elas
aparecerem, seno ele se torna irrelevante.
O Manifesto gil no rejeita os processos e ferramentas, a documentao, a
negociao de contratos ou o planejamento, mas simplesmente mostra que eles tm
importncia secundria quando comparado com os indivduos e interaes, com o
software funcionando, com a colaborao com o cliente e as respostas rpidas a
mudanas e alteraes.
3. Principais mtodos geis empregados
O grande foco dos mtodos geis so simplicidade, rapidez, envolvimento da
equipe. Entre eles se destacam o Scrum, Metodologia Crystal, Desenvolvimento
Voltado a Funcionalidades e XP (eXtreme Programming).
3.1. Scrum
O Scrum baseado nos seguintes princpios: equipes pequenas (no mximo 7
pessoas), requisitos pouco estveis ou desconhecidos e iteraes curtas para promover
visibilidade para o desenvolvimento.
Scrum divide o desenvolvimento em partes de 30 dias. Suas equipes so
formadas geralmente por projetistas, programadores, engenheiros e gerentes de
qualidade. Tais equipes trabalham em cima da funcionalidade definidas no incio de
cada parte.
Diariamente so feitas reunies de 15 minutos onde o time expe gerncia o
que ser feito no prximo dia e os gerentes podem levantar os fatores de impedimento, e
o progresso geral do desenvolvimento.
dividido em trs fases:
1) Pr-planejamento: os requesitos so descritos e priorizados, inclui tambm a
estimativa de esforo para cada requesito, definio da equipe de desenvolvimento, as
ferramentas a serem usadas, os possveis riscos do projeto, as necessidades de
treinamento e uma proposta de arquitetura de desenvolvimento baseada na lista de
tarefas.
2) Desenvolvimento: o software desenvolvido em ciclos, que podem levar de uma a
quatro semanas. Neste perodo, cada equipe recebe uma parte do backlog (perodo de
tempo necessrio para que um grupo de manuteno execute todas as atividades
pendentes) para desenvolvimento e sempre apresenta um produto executvel ao final.
a) Reunio Diria: durao mxima de quinze minutos; Gerenciada pelo lder de cada
equipe; Benefcios: maior integrao da equipe, rpida soluo de problemas, progresso
medido continuamente;
b) Reviso: Apresentao do produto ao cliente; O produto pode ser lanado no
mercado; Benefcios: apresentar resultados concretos ao cliente, integrar e testar boa
parte do software, motivao da equipe.
3) Ps-planejamento: iniciada quando todos os tpicos so satisfatrios (tempo,
competitividade, requisitos, qualidade, custo). Atividades: testes de integrao, testes de
sistema, documentao do usurio, preparao de material de treinamento, preparao
de material de marketing.
3.2. Famlia Crystal de Metodologia (Crystal Family of Methodologies)
Inclui grande nmero de mtodos diferentes que so selecionados de acordo com
as caractersticas do projeto a ser desenvolvido. Hoje em dia, apenas dois dos quatro
mtodos propostos mantm o desenvolvimento de novas prticas para cobrir diferentes
tipos de projetos.
Existem algumas caractersticas comuns famlia Crystal, tais como o
desenvolvimento incremental com ciclos de no mximo quatro meses, nfase maior na
comunicao e cooperao das pessoas, no limitao de quaisquer prticas de
desenvolvimento, ferramentas ou produtos de trabalho e incorporao de objetivos para
reduzir produtos de trabalho intermedirios e desenvolv-los como projetos evoludos.
O ciclo de vida desta famlia de metodologia baseado nas seguintes prticas:
Staging: Planejamento do prximo incremento do sistema. A equipe seleciona os
requisitos que sero implementados na iterao e o prazo para sua entrega;
Edio e reviso: Construo, demonstrao e reviso dos objetivos do
incremento;
Monitoramento: O processo monitorado com relao ao progresso e
estabilidade da equipe. medido em marcos e em estgios de estabilidade;
Paralelismo e fluxo: Em Crystal Orange as diferentes equipes podem operar com
mximo paralelismo. Isto permitido atravs do monitoramento da estabilidade
e da sincronizao entre as equipes;
Inspees de usurios: so sugeridas duas a trs inspees feitas por usurios a
cada incremento;
Workshops refletivos: so reunies que ocorrem antes e depois de cada iterao
com objetivo de analisar o progresso do projeto.
Local matters: so os procedimentos a serem aplicados, que variam de acordo
com o tipo de projeto.
Work Products (Produtos de Trabalho): seqncia de lanamento, modelos de
objetos comuns, manual do usurio, casos de teste e migrao de cdigo.
Especificamente para o Clear: casos de uso e descrio de funcionalidade;
Especificamente para o Orange: documento de requisitos.
Standards (padres): padres de notao, convenes de produto, formatao e
qualidade usadas no projeto.
Tools: ferramentas mnimas utilizadas. Para Crystal Clear: compiladores,
gerenciadores de verso e configurao, ferramentas de verso, programao,
teste, comunicao, monitoramento de projeto, desenho e medio de
performance.
3.3. Desenvolvimento Voltado a Funcionalidades
No atende a todo o processo de desenvolvimento, sendo elaborado para ser
trabalhado junto com outros mtodos de desenvolvimento. um mtodo iterativo que
enfatiza tpicos de qualidade e inclui entregas frequentes de artefatos para monitorar o
progresso do projeto.
definido como sendo mais apropriado a projetos iniciais, atualizao de
cdigo existente, criao de uma segunda verso, ou ainda substituio de um
sistema inteiro em partes. Diferentemente de outros mtodos geis, o FDD possui
caractersticas especficas para desenvolver sistemas crticos.
Principais etapas do desenvolvimento voltado a funcionalidades:
- Desenvolver um modelo geral (Develop an overall model): Definio do
domnio do sistema, contexto e requisitos para a construo, assim como uma
documentao em forma de casos de uso ou uma especificao das funcionalidades. O
domnio do projeto dividido em domnios menores e mais especficos, que sero
modelados por um grupo de desenvolvedores.
- Construir uma lista de funcionalidades (Build a features list): Construo de
uma lista de funcionalidades. Cada conjunto de funcionalidades uma funo para uma
rea de domnio estudado. A lista revisada pelos usurios e patrocinadores do sistema
para sua aprovao.
- Planejar por funcionalidade (Plan By Feature): Criao de um plano de alto
nvel, no qual as funes so seqenciadas de acordo com a prioridade e a dependncia
de cada uma, e ento designadas ao lder de programadores.
- Projetar por funcionalidade (Design by feature) e Construir por funcionalidade
(Build by feature): Consistem a parte iterativa do mtodo. Um pequeno grupo de
funcionalidade selecionado, assim como as funes necessrias para o
desenvolvimento desse grupo. Esses processos podem levar alguns dias, no mximo 2
semanas para serem realizados.
3.4. XP (eXtreme Programming)
uma metodologia gil para equipes pequenas e mdias e que iro desenvolver
software com requisitos vagos e em constante mudana.
Os quatro valores fundamentais da metodologia XP so: comunicao,
simplicidade, feedback e coragem. A partir desses valores, possui como princpios
bsicos: feedback rpido, presumir simplicidade, mudanas incrementais, abraar
mudanas e trabalho de qualidade.
Dentre as variveis de controle em projetos (custo, tempo, qualidade e escopo), h um
foco explcito em escopo. Para isso, recomenda-se a priorizao de funcionalidades que
representem maior valor possvel para o negcio. Desta forma, caso seja necessrio
diminuio de escopo, as funcionalidades menos valiosas sero adiadas ou canceladas.
A XP incentiva o controle da qualidade como varivel do projeto, pois o pequeno ganho
de curto prazo na produtividade, ao diminuir qualidade, no compensado por perdas
(ou at impedimentos) a mdio e longo prazo.
Prticas utilizada na metodologia XP, onde os pontos fracos de uma so superados pelos
pontos fortes de outra.
Algumas prticas XP:
- Jogo de Planejamento (Planning Game): O desenvolvimento feito em iteraes
semanais. No incio da semana, desenvolvedores e cliente renem-se para priorizar as
funcionalidades. Essa reunio recebe o nome de Jogo do Planejamento. Nela, o cliente
identifica prioridades e os desenvolvedores as estimam. O cliente essencial neste
processo e assim ele fica sabendo o que est acontecendo e o que vai acontecer no
projeto. Como o escopo reavaliado semanalmente, o projeto regido por um contrato
de escopo negocivel, que difere significativamente das formas tradicionais de
contratao de projetos de software. Ao final de cada semana, o cliente recebe novas
funcionalidades, completamente testadas e prontas para serem postas em produo.
- Pequenas Verses (Small Releases): A liberao de pequenas verses funcionais do
projeto auxilia muito no processo de aceitao por parte do cliente, que j pode testar
uma parte do sistema que est comprando. As verses chegam a ser ainda menores que
as produzidas por outras metodologias incrementais, como o RUP.
- Metfora (Metaphor): Procura facilitar a comunicao com o cliente, entendendo a
realidade dele. O conceito de rpido para um cliente de um sistema jurdico diferente
para um programador experiente em controlar comunicao em sistemas em tempo real,
como controle de trfego areo. preciso traduzir as palavras do cliente para o
significado que ele espera dentro do projeto.
- Projeto Simples (Simple Design): Simplicidade um princpio da XP. Projeto
simples significa dizer que caso o cliente tenha pedido que na primeira verso apenas o
usurio "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o
sistema, voc vai fazer o cdigo exato para que esta funcionalidade seja implementada,
sem se preocupar com sistemas de autenticao e restries de acesso. Um erro comum
ao adotar essa prtica a confuso por parte dos programadores de cdigo simples e
cdigo fcil. Nem sempre o cdigo mais fcil de ser desenvolvido levar a soluo mais
simples por parte de projeto. Esse entendimento fundamental para o bom andamento
do XP. Cdigo fcil deve ser identificado e substitudo por cdigo simples.
- Time Coeso (Whole Team): A equipe de desenvolvimento formada pelo cliente e
pela equipe de desenvolvimento.
- Testes de Aceitao (Customer Tests): So testes construdos pelo cliente e conjunto
de analistas e testadores, para aceitar um determinado requisito do sistema.
- Ritmo Sustentvel (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo
de trabalho saudvel (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras so
permitidas quando trouxerem produtividade para a execuo do projeto. Outra prtica
que se verifica neste processo a prtica de trabalho energizado, onde se busca trabalho
motivado sempre. Para isto o ambiente de trabalho e a motivao da equipe devem estar
sempre em harmonia.
- Reunies em p (Stand-up Meeting): Reunies em p para no se perder o foco nos
assuntos, produzindo reunies rpidas, apenas abordando tarefas realizadas e tarefas a
realizar pela equipe.
- Posse Coletiva (Collective Ownership): O cdigo fonte no tem dono e ningum
precisa solicitar permisso para poder modificar o mesmo. O objetivo com isto fazer a
equipe conhecer todas as partes do sistema.
- Programao em Pares (Pair Programming): a programao em par/dupla num
nico computador. Geralmente a dupla formada por um iniciante na liguagem e outra
pessoa funcionando como um instrutor. Como apenas um computador, o novato que
fica frente fazendo a codificao, e o instrutor acompanha ajudando a desenvolver
suas habilidades. Desta forma o programa sempre revisto por duas pessoas, evitando e
diminuindo assim a possibilidade de erros (bugs). Com isto busca-se sempre a evoluo
da equipe, melhorando a qualidade do cdigo fonte gerado.
- Padres de Codificao(Coding Standards): A equipe de desenvolvimento precisa
estabelecer regras para programar e todos devem seguir estas regras. Desta forma
parecer que todo o cdigo fonte foi editado pela mesma pessoa, mesmo quando a
equipe possui 10 ou 100 membros.
- Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os
testes unitrios (unit tests) e depois crie o cdigo para que os testes funcionem. Esta
abordagem complexa no incio, pois vai contra o processo de desenvolvimento de
muitos anos. S que os testes unitrios so essenciais para que a qualidade do projeto
seja mantida.
- Refatorao (Refactoring): um processo que permite a melhoria continua da
programao, com o mnimo de introduo de erros e mantendo a compatibilidade com
o cdigo j existente. Refabricar melhora a clareza (leitura) do cdigo, divide-o em
mdulos mais coesos e de maior reaproveitamento, evitando a duplicao de cdigo-
fonte;
- Integrao Contnua (Continuous Integration): Sempre que produzir uma nova
funcionalidade, nunca esperar uma semana para integrar verso atual do sistema. Isto
s aumenta a possibilidade de conflitos e a possibilidade de erros no cdigo fonte.
Integrar de forma contnua permite saber o status real da programao.
7. Concluso
A intensiva competitividade na rea de desenvolvimento de software faz com
que as empresas busquem sempre o aperfeioamento de seus servios para poder vencer
a concorrncia. Embora no seja a soluo para todos os problemas, a metodologia gil
mostra uma maneira de trabalhar bastante organizada e iterativa, podendo inclusive
contribuir para um ambiente de trabalho mais amigvel, portanto uma boa opo para
se obter os diferencias desejados.
A respeito da anlise comparativa de mtodos geis, podemos concluir que
existe bastante semelhanas entre si, entretanto, algumas particularidades foram
notadas como dupla de programadores e escrita dos testes antes da implementao no
XP, entre outros pontos semelhantes.
Referencias
http://www.devmedia.com.br/introducao-a-metodos-ageis/24526 acessado em
08/10/2014.
http://www.devmedia.com.br/metodos-ageis-parte-01/9426 acessado em 08/10/2014.
http://www.devmedia.com.br/metodos-ageis-parte-02/9443 acessado em 08/10/2014.
http://www.devmedia.com.br/metodos-ageis-parte-03/9477 acessado em 08/10/2014.
h ttp://www.brq.com/metodologias-ageis/ acessado em 08/10/2014.
http://www.ft.unicamp.br/liag/Gerenciamento/monografias/monogafia_metodos_ageis.p
df acessado em 08/10/2014.