1. 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

2. 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.

3. 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.

4. 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:

5. 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.

6. 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.

7. - 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.

8. 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.

9. 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.

10. 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.

11. 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

12. 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

13. 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

14. 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.

15. 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.

16. 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.

17. 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

18. 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.

19. 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.