Mtodos Ageis

Luis Carlos Scherer Artur Rafael da Silveira Rodrigo Scmidt Marlon

O Manifesto gil
Criado em 2001 por um grupo de profissionais americanos na rea de software. Teve como base o fato de que sempre um conjunto de princpios era seguido e respeitado quando um projeto dava certo. A partir disso, surge o termo Desenvolvimento gil, que passou a descrever abordagens de desenvolvimento que seguissem tais princpios.

Princpios do Manifesto gil

Indivduos e interao entre eles mais que processos e ferramentas; Software em funcionamento mais que documentao abrangente; Colaborao com o cliente mais que negociao de contratos; Responder a mudanas mais que seguir um plano. Ou seja, como disseram os fundadores, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda .

 Os mtodos geis so mtodos de desenvolvimento que visam diminuir o ciclo de vida de um software e como consequncia acelerar o seu desenvolvimento.

Inicia da construo de uma verso mnima do projeto para, seguidamente, integrar as demais funcionalidades.

 A origem dos mtodos geis se deve ao fato de o cliente muitas vezes estar incapacitado para definir de maneira completa todas as suas reais necessidades logo no incio do projeto.

O termo gil refere-se capacidade de adaptao tanto s mudanas de contexto bem como s modificaes de especificaes durante o processo de desenvolvimento.

Princpios dos Mtodos geis

Garantir a satisfao do consumidor entregando rapidamente softwares funcionais, isto , entregues em semanas ao invs de meses; Mudanas tardias de escopo de projeto so bem-vindas; Simplicidade e rpida adaptao s mudanas; Software funcional mais do que documentao extensa; O cliente no vai pagar mais pelo software que possuir a arquitetura mais bonita, mas vai gostar mais do software que for entregue mais cedo.

SCRUM

Introduo
um processo para gerenciamento de projetos e desenvolvimento gil de software, utilizado para trabalhos complexos nos quais torna-se impossvel prever tudo o que poder ocorrer ao longo do processo.

Principais caractersticas do SCRUM

Clientes tornam-se parte da equipe de desenvolvimento, obtendo-se transparnica no processo e no planejamento; Entregas frequentes e intermedirias das funcionalidades do sistema; Discusses dirias com a equipe de desenvolvimento e reunies frequentes com os stakeholders; Problemas no so ignorados.

 O Scrum permite a criao de equipes autoorganizadas, incentivando uma comunicao entre todos os membros da equipe que esto envolvidos no projeto;

Da surgiu o nome SCRUM: vem de uma jogada de Rugby, onde os jogadores devem se encaixar para formar uma muralha;

 Alm disso aceita que o problema no pode ser totalmente entendido e definido;

Focando, ento, na capacidade de sua equipe de responder de forma gil aos novos desafios que emergem no projeto.

Por tratar-se de uma metodologia de desenvolvimento gil, no Scrum a equipe de trabalho cria um produto entregvel;

No importa o quo fundamental ele , desenvolvendo, assim, somente as funcionalidades mais essenciais do sistema;

Para que a cada entrega possa-se incrementar o projeto com as necessidades emergentes.

Termos caractersticos do SCRUM

Sprint: no mtodo Scrum a produo se limita a um ciclo de trabalho regular e repetitivo, conhecido como sprint;

Em geral, um sprint dura 30 dias, porm a durao varivel de acordo com cada equipe de trabalho, analisando as vantagens e desvantagens de se ter um sprint mais longo ou um mais curto;

Elementos
Scrum Master: est no lugar de um gerente de projeto e procura garantir que a equipe siga os princpios e as prticas do Scrum. Scrum Team: a equipe de desenvolvimento. Nela, no preciso necessariamente existir uma diviso de funes em cargos tradicionais, como programador ou analista de testes. Todos trabalham juntos no projeto visando completar o conjunto do trabalho com o qual se comprometeram, realizando anlise do projeto, implementao, testes, etc.;

Elementos
Product Owner: o proprietrio do produto, representando os stakeholders e o negcio em si, definindo as funcionalidades desejadas para o produto; Product Backlog: uma lista que contm todas as funcionalidades do produto e definida pelo Product Owner. Essa lista no necessita estar completa no incio de um projeto, podendo-de comear com aquilo que mais bvio. Somente com o tempo que o Product Backlog cresce medida que se obtm mais conhecimento sobre o produto e sobre seus usurios.

Elementos
Sprint Planning Meeting: uma reunio na qual esto presentes o Product Owner, o Scrum Master e todo o Scrum Team;

Sprint Backlog: uma lista de tarefas que o Scrum Team se compromete a fazer em um determinado Sprint. Os itens do Sprint Backlog so providos do Product Backlog pela equipe, de acordo com as prioridades estabelecidas pelo Product Owner;

Elementos
Daily Scrum: tambm conhecida por daily standup ( reunio em p ), uma reunio diria realizada pela equipe que tem como objetivo compartilhar o conhecimento sobre o que foi feito no dia anterior, identificar incidentes ou algum impedimento e priorizar o trabalho a ser realizado no dia que se inicia.

Elementos
Sprint Review Meeting: uma reunio realizada ao final de cada Sprint, para que o Scrum Team mostre o que foi alcanado durante o determinado Sprint. Sprint Retrospective: sempre ocorre ao final de um Sprint e serve para que se possa identificar o que funcionou corretamente, o que pode ser melhorado, bem como que medidas sero tomadas para melhorar.

Scrum: transaes

Vantagens
Programadores motivados: como h um perodo de tempo pr-definido para a entrega do trabalho (Sprint), os programadores se comprometem com aquilo que assumiram fazer, aumentando, ento, a motivao, a responsabilidade e tambm o seu desempenho; Visibilidade do projeto: como em todo incio de um Sprint h uma reviso do que deve ser feito, a compreenso e a visibilidade do projeto ficam mais claras para os membros da equipe;

 Diminuio de bugs: menos preocupao com o prazo de entrega do projeto e mais qualidade de trabalho, possvel reservar um tempo para a verificao de erros, diminuindo, assim, possveis retrabalhos;

Possibilidade de alterao: se o cliente no possui o exato conhecimento daquilo que deseja e do que mais importante, sem problema nenhum podem ser inseridos novos tpicos no projeto, que sempre estar aberto para novas alteraes.

SCRUM: Desvantagens
Por se tratar de uma metodologia inovadora e bastante flexvel, causa nas pessoas certa resistncia ao novo;

Informalidade com que o Scrum trabalha a parte de documentao, uma vez que no possui a preocupao de documentar, prevalecendo o foco no que ser desenvolvido;

 Como no Scrum so permitidas mudanas de escopo, isso pode fazer com que se obtenha projetos bastante duradouros, gerando, ento, dificuldade para estimar o custo bem como o tempo de andamento do projeto; Alm disso, nesse mtodo de desenvolvimento, necessrio que o cliente tenha uma viso bem clara daquilo que deseja; O perfil do cliente de extrema importncia e isso nem sempre pode ser alcanado facilmente.

Motivos para utilizar o SCRUM

As mudanas a serem feitas no projeto so aceitas e no fazem com que a produtividade do grupo seja afetada; Os patrocinadores (stakeholders do sistema) podem ter participao nas reunies feitas a respeito do desenvolvimento do sistema; O time desenvolvedor vai produzindo de acordo com o que foi previsto anteriormente. Dessa forma, a equipe pode ir verificando os resultados obtidos a cada dia.

 Todos os que esto envolvidos no projeto tero conhecimento do que ir ser feito;

Ao fazer uso desse mtodo gil, todo o time pode se focar no que vai realmente ser importante e necessrio, fazendo com que se aumente a produo ao no destinar tanto tempo para relatrios, somente.

XP

Extreme Programing
XP uma metodologia para desenvolvimento de software gil, com qualidade e que atenda as necessidades do cliente. Alguns praticantes definem a XP como a prtica e a perseguio da mais clara simplicidade, aplicado ao desenvolvimento de software. Uma metodologia voltada para projetos cujos requisitos mudem com freqncia, utilizem desenvolvimento orientado a objetos, equipes de at 12 desenvolvedores

Valores
Feedback:O cliente aprende com o sistema que utiliza e com este aprendizado consegue reavaliar o produto recebido, com isso pode realimentar a equipe de desenvolvimento com as suas reais necessidades. Com o feedback , o cliente conduz o desenvolvimento do seu produto, estabelece prioridades e informa aquilo que realmente importante. Simplicidade: A lei : faa a coisa mais simples que pode funcionar. Com esta filosofia, o cliente ter a funcionalidade rapidamente e da forma desejada, dando um feedback instantaneamente evitando especulaes. O desenvolvedor deve implementar apenas o necessrio para que o cliente tenha seu pedido atendido.

XP exige que os desenvolvedores tenham coragem para: Desenvolver software de forma incremental; Manter o sistema simples; Permitir que o cliente defina prioridades; Fazer desenvolvedores trabalharem em pares: Expor cdigo a todos os membros da equipe; Integrar o sistema diversas vezes ao dia; Propor contratos de escopo varivel; Colocar desenvolvedores e clientes frente a frente; Implantar uma nova verso do sistema no cliente semanalmente; Modelar e documentar apenas quando for de extrema necessidade.

Prticas
Cliente disponvel ou presente: As funcionalidades do sistema so descritas brevemente em estrias em conjunto com os testes conceituais e sero estes os indicadores para uma boa implementao. No momento que os desenvolvedores iro implementar as estrias nada mais eficaz do que dialogar com o cliente para entender a estria, fazendo-se necessria a presena do cliente no ambiente de desenvolvimento. Stand up meeting: uma reunio rpida pela manh, com aproximadamente 20 minutos de durao e onde seus integrantes permaneam preferencialmente em p, tem por objetivo atualizar a equipe sobre o que foi implementado no dia anterior e trocar experincias das dificuldades enfrentadas. Neste momento tambm so decididas as estrias que sero implementadas no dia e em conjunto definir os responsveis por cada uma delas.

Prticas
Programao em par: O XP exige que todo e qualquer cdigo implementado no projeto seja efetuado em dupla, chamada de programao em par. uma tcnica onde dois desenvolvedores trabalham no mesmo problema, ao mesmo tempo e no mesmo computador. Um deles responsvel pela digitao (condutor) e outro acompanhando o trabalho do parceiro (navegador). Cdigo coletivo: Cada desenvolvedor tem acesso a qualquer parte do sistema e tem liberdade para alter-la a qualquer momento e sem qualquer tipo de aviso. Esta prtica tem como conseqncia um cdigo revisado por diversas pessoas e caso algo no esteja claro, com certeza ser alterado por alguma pessoa (refactoring ) para que o mesmo torne-se legvel.

Prticas
Padres de desenvolvimento: O XP recomenda a adoo de um padro desde o incio do projeto, preferencialmente padres utilizados pela comunidade da linguagem de desenvolvimento.

Equipe
Gerente de projeto: Pessoa responsvel pelos assuntos administrativos do projeto, mantendo um forte relacionamento com o cliente para que o mesmo participe das atividades do desenvolvimento. Coach: Pessoa responsvel pelas questes tcnicas do projeto, recomenda-se que esta pessoa seja a com maior conhecimento do processo de desenvolvimento, dos valores e prticas do XP. Analista de teste: Pessoa responsvel em garantir a qualidade do sistema atravs dos testes escritos. Ele deve ajudar o cliente a escrever os casos de testes e no final de cada iterao verificar se o software atende todos os casos de testes.

Equipe
Redator tcnico: Pessoa responsvel em documentar o sistema, evitando um forte trabalho dos desenvolvedores neste tipo de atividade, permitindo uma maior dedicao ao trabalho de codificao. Desenvolvedor: Pessoa responsvel em analisar, projetar e codificar o sistema. No XP no existe diferena entre analista, projetista e programador uma vez que em vrios momentos do projeto o desenvolvedor estar exercendo alguma destas atividades. Naturalmente existe nveis distintos de desenvolvedores dentro de uma equipe, mas com as prticas do XP, como pair programming , a tendncia a equipe se tornar uniforme em suas habilidades.