Desenvolvimento Ágil

19
MINISTÉRIO DA EDUCAÇÃO – MEC SECRETARIA DE EDUCAÇÃO PROFISSIONAL E TECNOLÓGICA – SETEC INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA CATARINENSE – CÂMPUS CONCÓRDIA CURSO TÉCNICO EM INFORMÁTICA Gefferson Vivan Desenvolvimento Ágil – XP CONCÓRDIA-SC 2014

Transcript of Desenvolvimento Ágil

Page 1: Desenvolvimento Ágil

MINISTÉRIO DA EDUCAÇÃO – MEC SECRETARIA DE EDUCAÇÃO PROFISSIONAL E TECNOLÓGICA – SETEC

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA CATARINENSE – CÂMPUS CONCÓRDIA

CURSO TÉCNICO EM INFORMÁTICA

Gefferson Vivan

Desenvolvimento Ágil – XP

CONCÓRDIA-SC

2014

Page 2: Desenvolvimento Ágil

Resumo Executivo

É possível desenvolver um software em total harmonia com as

necessidades reais de um cliente, cujo prazos, equipes e funcionalidades são

respeitadas?

Ser ágil é possuir bom senso e práticas baseadas em valores como: fácil

adaptação, simplicidade, comunicação, reflexão, observação, entre outros.

Page 3: Desenvolvimento Ágil

Descrição do projeto

Aplicar práticas de desenvolvimento ágil utilizando técnicas de

Programação Extrema (XP) com o propósito de facilitar o seu progresso, bem

como gerar valores para equipe e clientes envolvidos.

Page 4: Desenvolvimento Ágil

Desenvolvimento tradicional

Atualmente, ao longo da evolução, e em meio a debates sobre busca de

lucros em maior escala, demanda de bem estar no trabalho e foco no produto,

várias empresas continuam espelhando seu método de trabalho em modelos

utilizados por setores fabris implantados no século XX.

Estes modelos se baseiam em:

Determinismo

A matéria prima passa por um processo de transformação e gera

determinado resultado previamente conhecido. Quanto mais determinístico

for o método, maior é a eficiência da fábrica.

Especialização

Para obter uma organização no processos de fabricação, trabalhadores

são divididos em inúmeras atividades especializadas. O produto final é a

integração de partes oriundas dos mais variados setores.

Foco na Execução

Contratempos ou complicações durante o processo de fabricação são

ignorados, desde que o produto final atinja seu objetivo, priorizando a linha

de produção.

As empresas desenvolvedoras de software também são fisgadas por

este método de produção, pois são determinadas a criar produtos feitos por

especialistas, cada qual em sua área, e em uma etapa final, unificando partes.

Este formato assume riscos por elaborar aplicativos que, ao entrar no

mercado com prazos ultrapassados, necessitam de atualizações e, em muitos

casos não atendem as necessidades do cliente.

Desde 1994, o Standish Group International publica um estudo

intitulado de Chaos Research [STANDISH, 2001] que consolida as informações

de uma grande pesquisa sobre sucessos e fracassos dos projetos de software

(figura 0.1). Neste estudo, os resultados dos projetos são enquadrados em

uma das seguintes categorias:

Page 5: Desenvolvimento Ágil

Bem sucedidos – O projeto é finalizado no prazo, dentro do orçamento e

contendo todas as funcionalidades especificadas.

Comprometidos – O projeto é finalizado e um software operacional é

entregue, porém, o orçamento e o prazo ultrapassam os limites estipulados e,

além disso, o software entregue possui menos funcionalidades do que o

especificado.

Fracassados – O projeto é cancelado em algum momento durante o

desenvolvimento.

Figura 0.1 – Resultados dos estudos Chaos Research

De acordo com os estudos, apesar de um aumento considerável nos

projetos bem sucedidos, o desenvolvimento tradicional, tal como

desenvolvimento em cascata, que se baseiam em análise, design,

implementação, teste, implantação e manutenção, não tem se mostrado

eficaz para desenvolvimento de softwares, pois a soma de fracassados e

comprometidos ultrapassa 60% do total de projetos desenvolvidos.

Desenvolvimento ágil

Para frear esta constante, empresas buscam alternativas para alinhar

uma integração que atenda as reais necessidades do cliente, obtendo lucro e

equipes com foco no projeto como um todo, sem comprometer qualquer

parte envolvida.

Page 6: Desenvolvimento Ágil

Após buscas e pesquisas por produtos ou soluções para resolver estes

obstáculos, empresas ou funcionários se deparam com técnicas de

desenvolvimento ágil, que se baseiam na organização, no desenvolvimento, na

implementação em meio a testes e finalizações, e entrega do produto como

um todo ou parte dele.

O desenvolvimento ágil apresenta várias técnicas ou maneiras de

evoluir como equipe e empresa. Neste trabalho será exposta a prática com o

XP (Extreme Programing) Programação Extrema.

Extreme Programing, XP

Coincidentemente, equipes de XP desenvolvem várias atividades ao

mesmo tempo. Projetos são separados por releases. A cada semana, a equipe

faz análises, testes, desenvolve, codifica e implementa parte do projeto.

Estas partes são chamadas de interações ou cenários: partes do projeto

divididas por semana ou semanas. A cada semana são entregues vários

cenários, nos qual a equipe toda trabalha em todas as fases de seu

desenvolvimento. No prazo final de cada cenário, é implementado a versão

final do software para revisão e planejado os próximos cenários ou interações.

Valores da XP

- Comunicação

Proporciona uma comunicação rápida entre os membros da equipe, desde

gerentes, analistas, clientes, entre outros.

- Feedback

Permite trabalhar com respostas rápidas sobre a funcionalidade do produto.

O cliente ou usuário testa, sugere e também recebe sugestões sobre o que é

possível fazer para um melhor funcionamento do sistema.

- Coragem

Coragem de seguir uma nova métrica. Coragem de confiar nos membros da

equipe. Coragem de escrever testes antes de implementar códigos.

- Simplicidade

Desenvolver um produto que em sua simplicidade, atenda a proposta do

cliente.

Page 7: Desenvolvimento Ágil

- Respeito

Manter respeito entre membros da equipe e cliente.

As 12 práticas de XP

1 – Planejamento

São feitos planejamentos de curto, médio e longo prazo. O planejamento a

curto prazo é mais relevante. Nesta fase o projeto é dividido em releases,

segundo as necessidades do cliente.

2 – Fases pequenas

Período de normalmente 02 duas semanas, onde são implementados partes

do programa e toda semana é entregue uma funcionalidade do software para

o cliente.

3 – Metáfora

Para facilitar a comunicação da equipe é utilizada uma linguagem comum.

4 – Design simples

Menos é mais. Quanto mais simples, melhor.

5 – Teste

Todo o código deve passar por testes para garantir sua simplicidade e

funcionalidade.

06 – Refatoração

Reestruturar o sistema para novas funcionalidades, tornando-o simples para

ser manipulado.

07 – Programação em par

Todo o código deve ser escrito em pares de desenvolvedores.

08 – Propriedade coletiva

Todos são proprietários do código e tem acesso total a ele.

09 – Integração contínua

Trabalhar com repositório de código fonte único, com a versão atualizada.

10 – Semana de 40 horas

Ritmo sustentável, em que a equipe não sofra desgastes por demasia de

trabalho.

11 – Cliente junto ao desenvolvimento

Feedback instantâneo, conforme o andamento do projeto, problemas são

solucionados imediatamente.

Page 8: Desenvolvimento Ágil

12 – Padronização de códigos

Formas iguais de escrever códigos.

Equipe da XP

Cliente On-site

É a pessoa que faz parte da empresa que contratou sua equipe para

desenvolver seu software. É peça fundamental para o andamento do projeto,

pois ele é quem escreve as estórias e define junto com a equipe quais cenários

serão implementados. Da mesma forma, sua presença se faz necessária para

eventuais dúvidas que programadores ou membros da equipe possam ter para

com o funcionamento do software. Se sanada estas dúvidas no momento da

implementação, muito tempo perdido em programação desnecessária e

resolução de futuros problemas deixam de existir. A principal função do

cliente on-site é o feedback com a equipe de desenvolvimento para um

melhor desenvolvimento do produto.

Gerente de produtos

É o responsável por definir qual a melhor forma de desenvolver o

produto. É quem define as prioridades juntamente com o cliente on-site.

Orienta a equipe baseado em feedback obtidos com o cliente on-site da

mesma forma que repassa ao cliente on-site orientações sugeridas pela

equipe, e acompanha a realização geral dos trabalhos.

Gerentes de domínio

São responsáveis pelo conhecimento total e específico na área a qual o

software é planejado. Seu papel é esclarecer dúvidas e detalhes sobre cada

cenário em processo de implementação.

Em equipes reduzidas, o gerente de produtos também age como

gerente de domínio.

Projetista de interação

Responsável pela interface do usuário. Ajudam a definir como ficará a

IU (interface do usuário), baseados nas necessidades do usuário e sua

interação com o produto. Para chegar a um produto final, realizam testes de

usuários e notam o comportamento do mesmo perante o software.

Page 9: Desenvolvimento Ágil

Programadores

Desempenham a função de programar e implementar os cenários de

forma efetiva. Responsáveis por fornecer estimativas e alternativas através

do jogo de planejamento para a criação de cenários. Nesta área,

programadores são citados de forma genérica, pois dependendo do projeto,

podem existir engenheiros de software, especialistas em redes, banco de

dados, entre outros que sejam necessários para o seu desenvolvimento.

Testadores

Possui a função de avaliar a qualidade da aplicação. É responsável por

todas as atividades dentro do processo de desenvolvimento que garantem a

qualidade e eficiência do sistema que está sendo desenvolvido.

Entendendo a XP

No método XP, todos da equipe participam do projeto. Não existe

ambientes separados por paredes ou divisórias. Entende-se que quanto maior

a interação do grupo, melhores serão os resultados, pois dúvidas são

esclarecidas imediatamente, sem deixar para outra ocasião a solução da

mesma.

O ambiente de trabalho é rodeado por quadros que permitem a

anotação de todos os itens relevantes para o desenvolvimento do projeto.

Desde ideias, possíveis soluções, datas de reuniões e rabiscos sobre o projeto

são escritos, de forma que todos tenham acesso a todo o processo de

desenvolvimento.

O projeto é dividido em releases. Estes releases são fracionados em

interações ou cenários, que são baseados nas estórias descritas pelo cliente e

tratados pela equipe em um tempo determinado pela mesma. Normalmente o

tempo utilizado para resolução de todos os cenários dentro de uma interação

é de 2 a 3 semanas. Ao término de cada interação, a mesma é implementada

para uso do cliente.

Release

Projetos são divididos em releases. Cada release representa um

conjunto de cenários ou interações.

Page 10: Desenvolvimento Ágil

Na figura 0.2, o projeto de 10 meses é dividido em 4 release de 10

semanas cada.

Figura 0.2

Para o cliente obter ganho imediato, o release deve ter curta duração.

Algo em torno de dois meses. Releases reduzidos também oferecem ganho

para a equipe, que obtém feedback dos usuários finais, permitindo ajustes no

projeto.

Em projetos tradicionais, o escopo é fechado no início do projeto,

proporcionando opiniões e sugestões sobre o mesmo somente em seu

término. Na XP, o escopo existe, mas não é fechado.

Cada release pode ser alterado conforme seu desenvolvimento,

levando em consideração o aprendizado do cliente.

Em XP, os releases são fracionados em iterações para um menor espaço

de tempo.

Iterações

Iterações ou cenários são derivados de uma parte do release. Baseado

nas estórias escritas pelo cliente on-site, são criadas as interações. Para o

início de cada iteração é realizada uma reunião que define as estórias que

serão implementadas. As iterações são colocadas em um quadro branco,

escritas ou coladas em post-its conforme figura 0.3, e são definidas por ordem

de prioridade pelo cliente on-site.

Page 11: Desenvolvimento Ágil

Figura 0.3

Estórias

As estórias são as funções do projeto. O cliente on-site descreve passo

a passo, priorizando somente as estórias referentes a iteração que será

iniciada. Estórias pertencentes a outra iteração são deixadas de lado, pois

serão tratadas posteriormente.

Exemplo de estória:

Figura 0.4 com Post-it contendo uma estória que faz parte de uma iteração.

Figura 0.4

Page 12: Desenvolvimento Ágil

Planejando as iterações

Para planejar as iterações, a equipe precisa saber quantos pontos é

capaz de implementar. 01 ponto equivale a um dia ideal de um par de

programadores trabalhando.

Para saber a quantidade de pontos, pode-se efetuar uma operação

simples:

Tamanho da iiteração = 2 semanas = 10 dias úteis

Deve-se descontar:

01 dia para reuniões de planejamento da iteração.

01 dia para reunião de enceramento da iteração.

Sobram 08 dias úteis para desenvolvimento.

Se tivermos 6 desenvolvedores divididos em pares, temos 03 pares de

desenvolvedores.

01 dia / 01 par de desenvolvedores equivale a 01 ponto.

01 par em 08 dias de desenvolvimento = 08 pontos

03 pares desenvolvendo em 08 dias úteis = 24 pontos

Para calcular a próxima iteração, a equipe se baseia na iteração passada.

Supondo que a equipe nesta primeira iteração conseguiu entregar 20 dos 24

pontos planejados, sua próxima interação assumirá que o máximo de pontos

desta interação será 20 pontos. Se ao final não foi possível entregar todos os

cenários ou interações, eles serão anexados a próxima interação. Se ao final

todos os cenários foram completados, e tem sobra de tempo para o término

da iteração, deve-se solicitar ao cliente on-site mais estórias para o

desenvolvimento.

Obs. Deve-se levar em consideração que para atingir 01 ponto ao dia,

um par de desenvolvedores deve estar envolvido somente com o

desenvolvimento das estórias, não se preocupando com outras tarefas. Se

necessário for deslocar desenvolvedores para resolução de tarefas

secundárias, deve-se descontar o tempo proposto para sua resolução,

subtraindo do tempo total da iteração.

Jogo de planejamento

Para se chegar a um consenso sobre quantas iterações podem ser feitas

por dia, os programadores juntamente com o cliente on-site estimam quantos

Page 13: Desenvolvimento Ágil

pontos leva para implementar cada estória. Se todos, incluindo o cliente on-

site concordam com a quantidade de pontos, a história é colocada como item

da iteração. Se houver discórdia entre as partes ou o período estimado tiver

um grande espaço de pontos entre a opinião dos desenvolvedores, é discutido

para se chegar a um consenso e saber se a estória se encaixa nesta interação

ou será colocada na próxima.

Desenvolvimento em par

Para se obter uma melhor performance e aproveitamento, a XP propõe

que desenvolvedores sentem em pares para programar. Em quanto um

assume como piloto, digitando códigos, o outro assume como navegador,

orientando e prestando atenção ao que é implementado.

Neste formato, o código é revisado permanentemente pelos 02

desenvolvedores, tornando-o mais simples e eficaz, pois surgem vários

métodos de resolução sobre um problema.

Testes

Para entregar softwares com alta qualidade, a XP exige que técnicas

como TDD, test driven development (desenvolvimento guiado por testes) seja

utilizados.

Testes são escritos antes de implementar cada estória. Isto aprofunda a

necessidade de atender somente as necessidades propostas pelo cliente,

escrevendo códigos limpos e que deixam o sistema mais simples.

Utilizando o XP

Para dar início a um projeto XP, começamos com um planejamento

interativo. Vamos desenvolver uma proposta de ambiente web para controle

de projetos de extensão para um determinado instituto.

Nossa equipe é formada por 01 gerente de produtos, 02

desenvolvedores e o cliente on-site. Os desenvolvedores também assumem o

papel de testadores.

Obs.: XP não é necessário seguir todos seus passos descritos por Kent

Back em seu primeiro livro (Programação Extrema (XP) Explicada, Bookman

Page 14: Desenvolvimento Ágil

Companhia Ed, 2004). Atualmente ele afirma que XP pode se adaptar ao

tamanho de sua empresa e de seu projeto.

Para tal projetos devemos analisa-lo como um todo e dividi-lo em

releases como mostra a figura 0.5

Figura 0.5

Agora, junto ao cliente on-site e desenvolvedores, montamos um

release a ser seguido, com duração estimada de 02 meses e interações de 02

semanas para cada release. Vamos fragmentar os releases e dividi-los em

iterações.

Planejando nossas iterações.

Sabemos que 01 ponto equivale a um dia ideal de um par de

programadores.

2 semanas = 10 dias

Devido a ser um projeto menor, vamos considerar meio dia para reunião

de planejamento e meio dia para reunião de finalização de iteração.

9 dias = 9 pontos

Para aplicar o jogo do planejamento, temos 09 pontos para cada

iteração. Nosso cliente on-site deverá apresentar as estórias pertencentes ao

release, para que junto aos desenvolvedores, eles possam calcular quantos

pontos cada estória irá ocupar.

Com o jogo de planejamento executado, chegamos ao resultado de que

08 iterações poderão ser executadas e entregues para o cliente ao final das

próximas 02 semanas conforme figura 0.6.

Page 15: Desenvolvimento Ágil

Figura 0.6

Para dar início ao projeto e a semana de implementação da primeira

iteração, recomenda-se pequenas reuniões todas as manhãs, chamadas de

Stand Up Meeting (Reunião em pé, em livre tradução) para que sejam avaliado

trabalhos do dia anterior e eleger o que será realizado durante o dia.

Presume-se que a equipe já esteja com padronização de códigos eleita,

tanto quanto o seu repositório configurado, e que seu ambiente de trabalho

esteja configurado para o desenvolvimento do projeto, conforme prevê a XP.

O início do desenvolvimento é para escrever e realizar testes. Os

desenvolvedores começam escrevendo testes simples, seguindo a prioridade

de iterações definidas pelo cliente on-site, mostrado na figura 0.7, e conforme

a necessidade, vão incrementando até chegar em um código que execute e

passe nos testes, atendendo às necessidades do cliente.

Page 16: Desenvolvimento Ágil

Figura 0.7

Tendo realizados os testes, os desenvolvedores começam a programar

em par linhas de código para o software, seguindo o que foi definido na

reunião de Stand Up Meeting pela manhã. A cada dúvida que surge, se o

cliente on-site estiver presente, elas poderão ser sanadas. Esta é uma das

vantagem de telo junto a sua equipe, pois fica fácil entender o que ele quer

para com o produto, e também para programadores esclarecerem o que é

viável em termos de programação para atender suas utilidades.

Se em meio ao desenvolvimento surgir alguma dúvida quanto à

funcionalidade ou a implementação, em um primeiro momento

programadores desenvolvendo em par tem uma troca mútua de informações

para a resolução do problema. Persistindo a incerteza, trabalhando em um

único ambiente proposto pela XP, a equipe pode dialogar, juntando

desenvolvedores, cliente on-site e gerente de produtos para que possam

chegar a uma solução.

A cada iteração terminada, atualiza-se o quadro de funcionalidades

conforme figura 0.8.

Page 17: Desenvolvimento Ágil

Figura 0.8

Atualizações, gráficos de evolução ou quaisquer informações

pertinentes ao projeto são expostas para que toda a equipe saiba como está o

andamento do projeto.

Repetindo este ciclo de reuniões, testes, programação em par,

feedback com cliente on-site e aplicando a refatoração se necessária, ao final

de 02 semana, com a reunião de finalização de iteração, o cliente já tem em

mãos 01 release de seu projeto pronto. Ao término de cada iteração, um novo

release é iniciado.

No projeto proposto, este release não servirá para o cliente utilizar em

sua empresa, já que Models são dependentes de outras partes para seu

funcionamento. Mas se a proposta for um site de e-commerce por exemplo, e

seu primeiro release proposto seja: Mostrar ao clientes que acessam o site

produtos que a loja ira dispor, este primeiro release já pode trazer benefícios

e agregar valores para o cliente.

Ao final de 02 meses, seguindo as premissas da XP, o cliente do projeto

de extensão tem seu produto pronto. Seus códigos foram escritos de forma

simples e robusta, permitindo futuras alterações. Com o cliente participando

ativamente do projeto, dúvidas quanto a funcionalidades foram resolvidas e o

custo não ultrapassou o planejado. Se fosse realizado com desenvolvimento

tradicional, o projeto se estenderia e, certamente ao seu final exigiria

Page 18: Desenvolvimento Ágil

mudanças. Não seria entregue com 100% de suas funcionalidades, talvez com

excesso delas. O cliente solicitaria alterações, o código não seria escrito de

forma simples e elegante, e ultrapassaria os custos planejados.

Vale ressaltar que para um projeto tenha sua trajetória de sucesso, é

necessário seguir os valores e as 12 práticas da XP, respeitando sua equipe,

seus limites, imprimindo um ritmo sustentável de trabalho, dando condições e

enriquecendo o contato e feedback com todos.

Page 19: Desenvolvimento Ágil

Conclusão

Em tempos que não se permitem erros, buscar mecanismos e modelos

de organização para aliar lucro, tempo, sucesso e bem-estar se tornou o

objetivo de várias empresas.

Produzir softwares não dependem exclusivamente de programação,

mas sim de organização de equipe e estratégias que agreguem ganho ao

grupo e ao cliente.

Apesar da resistência e ceticismo quanto a métodos de

desenvolvimento ágil, estes modelos tem conquistado uma parcela maior do

mercado. Companhias tem obtido ótimos resultados migrando para esta

plataforma. Projetos são entregues dentro do período, e gastos excessivos

são evitados.

Ao passo que a tecnologia se reinventa diariamente, falhas resultam em

fracasso. Agilidade produz benefícios.