Metodologia Agil

Metodologia Àgil de Desenvolvimento de Software... http://www.artigonal.
com/print/2887376
Metodologia Àgil de Desenvolvimento de Software

Por: Manoel de Jesus Nogueira | Publicado em : 23/07/2010
1-Introdução
Com o crescimento das atividades de todas as economias a busca por

informação se torna cada vez maior, e junto com isso vem os softwares
indispensáveis para o armazenamento dos dados e para o desenvolvimento das
empresas, escolas, hospitais.
Hoje tudo no mundo dos negócios depende da tecnologia não existe um

grande projeto que não precise de um programa automatizado para ser um
sucesso, a velocidade e a carência no mundo globalizado e capitalista andam
juntos, carência de tecnologia e velocidade para lançar um produto novo no
mercado, para alimentar o consumismo e as finanças das empresas.
Desenvolvimento de software é complexo em muitos casos quando o projeto

termina já não atende as necessidades da sua finalidade ou o motivo pelo qual
foi criado.
Aí voltamos á história de grandes estudiosos que buscaram a maximização e

padronização dos processos industrias, no mundo super competitivo começou
a se buscar a melhor forma e processos de desenvolvimento de sistemas.
A metodologia tradicional foi utilizada como principal recurso para

desenvolvimento de sistemas,essa metodologia e composta pelas seguintes
fases: levantamento de requisitos, análise de requisitos, desenho da
arquitetura, implementação, testes, produção e manutenção.
Muitos desenvolvedores consideram as como ultrapassada pois é considerada

extremamente rígida quanto aos seus padrões e não tem mais atendido as
expectativas de clientes em relação a sistemas, pois ela torna o processo de
desenvolvimento muito lento e grande parte dos clientes necessitam de um
sistema com maior rapidez.
Com esse cenário alguns programadores questionaram e se opuseram a uma
1 de 17 29-09-2010 23:07
Metodologia Àgil de Desenvolvimento de Software... http://www.artigonal.com/print/2887376
série de práticas adotadas em abordagens tradicionais de engenharia de

software e gerência de projetos, como resultados disso em 2001 assinaram um
manifesto que buscava um desenvolvimento ágil de sistemas.
A manifestação dos desenvolvedores para desenvolvimento ágil de sistemas tem

como objetivo satisfazer os clientes entregando com rapidez e com maior
freqüência versões do sistema conforme necessidades do mesmo. Os princípios
do manifesto ágil Segundo Beck 2004 são:
Pessoas e interações são mais importantes que processos e ferramentas;
O Software funcionando é mais importante do que documentação completa e

detalhada;
Colaboração do cliente é mais importante do que negociação de contratos;
Ser flexível á mudanças é mais importante do que seguir o plano inicial;
Programação Extrema foi uma das soluções de metodologia encontrada para

alcançar os objetivos da manifestação e hoje é um dos principais meios de
desenvolvimento ágil de sistemas.
O XP ou Programação Extrema é um processo de desenvolvimento de software

Segundo Beck 2004 para:
Projetos cujos requisitos são complexos que mudam com freqüência ;
Desenvolvimento de sistemas orientado a objetos;
2 de 17 29-09-2010 23:07
Equipes pequenas;
Desenvolvimento incremental e iterativo com o cliente.
2- A metodologia XP é composta de quatro valores: comunicação, simplicidade,

feedback e coragem.Esses quatro valores tem como seguintes
princípios:feedback rápido, assumir simplicidade, mudanças incrementais e
trabalho de qualidade.
Os valores e princípios durante o processo de desenvolvimento software no XP

são segundo Beck 2004:
Cliente Presente
Jogo de Planejamento
Stand Up Meeting
Programação em Par
Desenvolvimento guiado pelos testes
Refatoração
Código Padronizado
3 de 17 29-09-2010 23:07
Projeto Simples
Código Coletivo
Metáfora
Ritmo Sustentável
Integração Continua
Pequenas Versões
Vamos detalhar cada um destes no trabalho.
3-São quatro variáveis que controlam o desenvolvimento de software.
Escopo
Custo
Escopo
Tempo
Qualidade
4 de 17 29-09-2010 23:07
Custo
Tempo
Qualidade
Escopo é a variável que mostra o cenário das necessidades do cliente, que

quanto mais claro fica mais fácil de entender as funcionalidades do sistema, ele
pode mudar ao longo do desenvolvimento para atender alguma necessidade do
financiador do projeto.As mudanças são exatamente uma solicitação do cliente
ou do próprio negocio.Com as entregas das primeiras versões o cliente percebe
a importância da nitidez do escopo para as próximas versões e assim
sucessivamente.
Custo é uma variável que mostra para o cliente o que ele vai pagar, e em
alguns casos é um fator primordial no fracasso de um projeto pela ausência de
recursos, ou por projetos que se tornam muito caros ao longo do
desenvolvimento, com a prioridade do cliente em suas necessidades ele recebe
parte do projeto e já começa a faturar, com isso pode pagar mais facilmente o
restante do projeto.
Tempo é a variável mais complexa pois é difícil prever nos projetos, e causam
muita insatisfação dos clientes, é sempre bom negociar de forma clara com o
seu cliente para que esteja sempre consciente dos impactos ao longo do
projeto, o atraso no desenvolvimento compromete a satisfação do cliente e do
negocio.
Qualidade é atender a necessidade do cliente, ao longo do desenvolvimento

com o código simples e mais eficiente, com essas duas situações podemos
5 de 17 29-09-2010 23:07
afirmar que um projeto atendeu com qualidade ao seu cliente, caso contrário a
insatisfação do cliente com o projeto, que não atende suas expectativas é um
fracasso, os testes que são feitos antecipadamente antes da codificação
contribui para a conformidade do sistema, é exatamente com a participação
física ou virtual do cliente que a metodologia Extreme Programming contribui
para o sucesso do projeto segundo [ Manhães Teles 2004].
4- O Extreme programming tem seu desenvolvimento entre quatro valores que

se interagem.
Comunicação:
A comunicação esta presente em todas as etapas de desenvolvimento neste

método, pois a comunicação se da através da solicitação do cliente e entre a
equipe de desenvolvimento.
Feedback:
É exatamente o retorno da comunicação entre o cliente e a equipe de

desenvolvimento, é um meio muito eficiente de entender o que o cliente está
solicitando ou necessitando no processo do projeto. Contribui assim para que o
cliente conduza o desenvolvimento e deixe a equipe centrada na solução para
êxito desse sistema.
Simplicidade:
O XP recomenda que, ao implementar uma solução, você a implemente da

forma mais simples. Qualquer complexidade adicional virá ao seu encalço
depois. Virá na forma de maiores dificuldades para localizar erros e
acrescentar funções, mais tempo de manutenção e maior custo de propriedade
e, ao final, uma vida útil mais curta para o sistema (quando os custos de
mantê-lo excedem os benefícios de ter em produção). Tanto pior quanto mais
vital for o produto para o cliente.
6 de 17 29-09-2010 23:07
Coragem:
Coragem é agir de forma efetiva em face do medo. Certamente é verdade que

as pessoas envolvidas no desenvolvimento de software sentem medo. É como
elas lidam com seus medos que vai influenciar na qualidade do trabalho ou
não.
Coragem manifesta-se como uma propensão a uma ação. Se você souber qual é
o problema, faça algo sobre ele. Às vezes coragem manifesta-se como paciência.
Se você sabe que há um problema mas, não sabe a solução, é preciso coragem
para esperar o problema tornar-se claro Beck 2004..
Os valores da XP trabalham melhor em conjunto e em muitos casos são

essenciais uns aos outros. O feedback é melhor com comunicação e
simplicidade. A simplicidade é melhor com comunicação e feedback. A
comunicação é melhor com simplicidade e feedback. Com o valor coragem não
é diferente.
5-Princípios do Extreme Programming
O processo de troca de informações, relacionadas ao que é produzido e

consumido durante um projeto, entre o cliente e a equipe de desenvolvimento
e vice-versa. Este processo de troca não foi criado com a XP. Ele existe no
desenvolvimento tradicional, mas com uma grande diferença em relação aos
tempos de realização, pois no desenvolvimento tradicional é normal existir uma
grande defasagem entre os ciclos de produção e consumo, no XP isso não é
permitido Beck 2004.
Mudanças incrementais:
É sempre muito difícil de controlar dentro de um projeto de desenvolvimento,

no XP os processos são alterados gradualmente.
Simplicidade Presumida:
O problema será resolvido da forma mais simples.
Com o XP o cliente presente ajuda o cliente a entenderem os desenvolvedores

e o software.
As práticas do XP segundo Beck 2004.
Jogo do Planejamento:
Uma vez por semana os desenvolvedores se reúnem com o cliente para

priorizar um pequeno conjunto de funcionalidades que, para que possam ser
7 de 17 29-09-2010 23:07
implementadas e testadas na mesma semana.
Stand Up Meeting:
Realiza-se uma reunião no início de cada dia, cujo objetivo é atualizar todos os
membros da equipe a respeito dos fatos do dia anterior.
Programação em Par:
Programação em Par é uma prática das mais conhecidas e mais utilizadas em

projetos XP. Quando é concebida, todo e qualquer código produzido no projeto
é implementado por duas pessoas juntas, na mesma estação de trabalho,com o
revezamento entre um e outro.
Desenvolvimento Orientado a Testes:
Testes automatizados e implementados antes de cada funcionalidade, de cada

classe e de cada método criados no sistema. Quando isso é feito, germina-se o
mecanismo automatizado que aponta os problemas assim que eles são
introduzidos reduzem o tempo.
Refatoração:
Para evitar que a aplicação se transforme local sujo e, desorganizado e difícil

de manter, equipes XP utilizam a prática de refatoração. Frequentemente,
sempre que encontram uma oportunidade para melhorar o código o sistema é
alterado em pequenas partes.
Código Coletivo:
Os desenvolvedores têm acesso a todas as partes do código e podem

modificá-lo (refactoring) se necessário, sem pedir permissão a outras pessoas.
Código Padronizado:
A equipe deve estabelecer padrões de codificação.Identificação do código

comentários, variáveis e métodos.
Design Simples:
Não criar generalizações, ou seja, não tente prever o futuro codificar o

suficiente para a funcionalidade ser implementada.
Metáforas:
8 de 17 29-09-2010 23:07
Com o poder de transmitir idéias complexas de forma simples, facilita a

comunicação entre a equipe e o cliente.
Ritmo Sustentável:
Trabalhar com satisfação oito horas por dia. Experimente evitar horas
extras.Realizar uma coisa de cada vez.
Integração Contínua:
Os pares devem integrar seus códigos com o restante do sistema diversas vezes
ao dia. Para assegurar que ele continue funcionando, executam-se os testes
unitários em busca de falhas.
Releases Curtos:
Release é um conjunto reduzido de funcionalidades que a equipe coloca em

produção rapidamente, geralmente em meses, para o cliente utilizar. O cliente
não espera o fim do projeto para utilizar o sistema.
Características da equipe gerente de projeto:
É responsável pelos assuntos administrativos do projeto Coach: é o responsável

técnico do projeto.
Analista de Teste:
É responsável por ajudar o cliente a escrever os testes de aceitação, detectar

defeitos no sistema.
Redator Técnico:
Ajuda a equipe de desenvolvimento a documentar o sistema. Desenvolvedor: é

a pessoa que analisa, projeta e codifica o sistema.
Programador:
O programador é o coração da equipe ele é responsável por tornar a aplicação

mais simples e mais rápida.
Cliente:
9 de 17 29-09-2010 23:07
Ele também faz parte da equipe do projeto e define que funcionalidades serão
implementadas, ele precisa tomar decisões para o andamento do sistema.
Regra 20-80:
Conhecida como principio que diz que 80% do que uma pessoa realiza no
trabalho vem de 20% do tempo gasto nesta realização.Os 80% do esforço
consumido para todas as finalidades. A metodologia XP o sistema que está
sendo desenvolvido precisa ter controles relativamente independentes uns dos
outros. XP utiliza dessa regra para adiar otimização, pois ele faz primeiramente
que tiver de mais valor para o cliente, isto é, implementa as funcionalidades
mais importantes do sistema.
6-Estudo de caso
O estudo de caso foi realizado aplicando-se as práticas e valores do Extreme

Programming a um projeto de pequeno porte da Procuradoria Regional do
Trabalho da 2ª Região (PRT2). Devido ao pouquíssimo tempo disponível, foi
executada apenas uma iteração com duração de uma semana.
Introdução
As atividades desenvolvidas dentro da Procuradoria Regional do Trabalho

estão divididas em basicamente duas áreas distintas: área fim e área meio. A
área fim é constituída pelas atividades jurídicas, que é a finalidade principal do
órgão, já a área meio funciona como suporte às atividades principais, sendo
incluídos nesse segmento todos os procedimentos administrativos.
Atualmente, todos os sistemas computacionais relacionados à área fim são

desenvolvidos de forma centralizada em Brasília, nas Regionais são
desenvolvidos principalmente sistemas destinados à área administrativa, tais
como patrimônio, almoxarifado e, no caso de nosso estudo, convênio médico.
PLAN-ASSISTE
O Programa de Saúde e Assistência Social do Ministério Público da União -

PLAN-ASSISTE - é um conjunto integrado de ações destinado a proporcionar
aos membros e servidores, ativos e inativos, e respectivos dependentes, bem
10 de 17 29-09-2010 23:07
como aos pensionistas, um sistema de serviços e benefícios sociais, dentre eles

assistência médica e hospitalar. A instituição firma convênios com clínicas,
profissionais especializados, hospitais, laboratórios e outros estabelecimentos
de saúde aprovados para prestar serviços aos seus associados.
Atualmente, as informações dos profissionais ou entidades conveniadas, como

endereço, telefone e especialidades são disponibilizadas na intranet da
Procuradoria, em uma página HTML. Um dos grandes problemas apontados
pela chefia do Departamento Pessoal, responsável pelos convênios, é o tempo
de espera para a publicação, uma vez que deve ser encaminhado um email à
Divisão de Tecnologia da Informação (DTI) solicitando alteração na página da
intranet. Geralmente esse tipo de solicitação é tratada com baixa prioridade
pela equipe da DTI, causando uma espera demasiadamente longa ao solicitante
dependendo das circunstâncias.
A solução encontrada foi o desenvolvimento de uma ferramenta que permita o

gerenciamento e publicação dos conveniados na intranet, sem a necessidade
de intervenção da DTI, dessa maneira os próprios funcionários do
Departamento Pessoal poderiam controlar as informações, disponibilizando aos
associados instantaneamente.
Análise de Cada Prática do XP no Projeto
Cliente Presente
O cliente, representado por um funcionário do setor de Departamento Pessoal,

esteve próximo e disposto a ajudar, sempre que solicitado.
O fato de ser um projeto pequeno e ter demandado pouco tempo de trabalho

diário facilitou essa relação, uma vez que foram poucas as ocasiões em que
precisamos consultá-lo. Outro fator importante para o sucesso da prática foi o
físico, já que o Departamento Pessoal é um setor localizado no mesmo prédio,
um andar acima da DTI.
No final da primeira iteração foi notável o comprometimento do cliente em

relação ao projeto, como participou mais ativamente, sempre perguntava como
andava o projeto, mesmo quando encontrava o pessoal do desenvolvimento nos
corredores da instituição.
11 de 17 29-09-2010 23:07
Jogo do Planejamento
Como já dito anteriormente, o projeto teve apenas uma iteração de uma

semana, iniciado em uma segunda-feira e finalizado na sexta-feira.
No primeiro dia o cliente participou da reunião de planejamento onde escreveu

as histórias, totalizando dez cartões com uma história cada um. Os
desenvolvedores analisaram e estimaram o tempo necessário para a
implementação de cada história. Foi definido com o cliente que seriam
escolhidas apenas duas histórias, com no máximo um dia de trabalho cada,
devido ao pouco tempo diário disponível para o projeto. Nestas condições, o
cliente definiu as histórias "Cadastrar Estabelecimento" e "Cadastrar
Especialidade" como prioritárias. Após a priorização, os cartões foram
colocados em um mural improvisado, em uma mesa sem uso, dispostos de
acordo com seu nível de prioridade e disponível a qualquer tempo ao cliente.
Ao final da iteração, sexta-feira, o cliente utilizou todas as funcionalidades

implementadas para verificar se estavam de acordo com o descrito nos cartões
de história. Felizmente não foi necessário fazer nenhuma alteração. O que
ajudou muito para tal acontecimento foi a presença do cliente em todos os
momentos de dúvida da equipe de desenvolvimento.
Stand Up Meeting
No início dos trabalhos de cada dia, foram realizadas reuniões rápidas para
levantamento do que foi feito no dia anterior e alinhamento e priorização das
atividades a serem realizadas no dia atual.
O tamanho reduzido da equipe facilitou muito as reuniões em pé, tudo foi

definido em menos de dez minutos diários.
Desenvolvimento Orientado a Testes
Foi a prática mais difícil de ser aplicada. A equipe teve dificuldades em

entender o sentido do teste antes da implementação do código, assim como
utilizar ferramenta para testes automáticos de unidade.
O primeiro passo foi encontrar uma ferramenta gratuita e de fácil uso para
automatizar os testes. Como a linguagem utilizada foi PHP, a melhor opção
dentre as pesquisadas foi a SimpleTest. Os programadores leram a
12 de 17 29-09-2010 23:07
documentação e tutoriais para entender o funcionamento e forma de uso da

ferramenta.
Um bom exemplo da utilização foram os testes criados para o método setNome

da classe Estabelecimento. Antes mesmo de programar o método e até mesmo a
própria classe foram criados os casos de testes. Ficou definido que o atributo
nome só poderia assumir valor do tipo string, não poderia receber valor em
branco e que deveria iniciar obrigatoriamente por uma letra. Os testes foram
programados e testados individualmente, todos falhando, conforme esperado,
uma vez que a classe testada sequer havia sido implementada.
A classe e seu método foram criados resolvendo cada um dos problemas por
vez. Cada teste foi executado individualmente, desta vez obtendo sucesso. Após
sucesso em todos testes individuais, também foram executados todos de uma
vez, também obtendo sucesso em todos os casos.
Aos poucos, principalmente com a prática, a equipe passou a entender a

importância da programação orientada a testes. De início não é tão notável a
vantagem, pelo contrário, só é percebido o tempo a mais gasto antes da etapa
de programação, porém quando a programação é terminada, dificilmente terá
de ser revisada, já que os maiores problemas foram previamente tratados.
Refatoração
A refatoração foi aplicada de forma natural pelos programadores. A

programação em par juntamente com o desenvolvimento orientado a testes
teve grande contribuição para tal fato. Num primeiro momento o código foi
criado para satisfazer os casos de teste, depois, sob um olhar mais atento dos
dois programadores, partes dos programas eram reescritas de forma mais clara
e sucinta, mantendo todas suas funcionalidades originais.
Releases Curtos
As funcionalidades definidas pelo cliente como prioritárias entraram em

produção logo após a primeira iteração. Em nosso projeto, as histórias
"Cadastrar Estabelecimento" e "Cadastrar Especialidade" foram entregues
completamente implementadas no prazo de uma semana, conforme previsto na
reunião de planejamento. A partir desse momento o sistema encontra-se pronto
para incorporar as funcionalidades restantes.
13 de 17 29-09-2010 23:07
Código Coletivo
Por se tratar de uma equipe pequena, apenas dois programadores, e devido à

prática da programação em par, o código tornou-se coletivo automaticamente.
Os dois programadores trabalharam tendo acesso a todo código do projeto
simultaneamente, caso não fosse possível a presença de algum deles, o outro
poderia continuar o trabalho, pois tinha conhecimento do todo.
Código Padronizado
Como a instituição já possuía uma documentação referente ao padrão de

codificação a ser utilizada em seus projetos, seguimos essa orientação. Na
documentação havia padronização para nomes de variáveis, classes, métodos,
documentação e comentários dentro do código, nomenclatura de tabelas e
campos em banco de dados.
A adoção dessa padronização foi muito simples e ajudou na sintonia entre os

programadores na programação em par, pois todos estavam escrevendo da
mesma forma.
Design Simples
Tudo foi feito pensando nas especificações do cliente, nada mais que isso. O
programador mais experiente do grupo relutou em aceitar tal método de início,
pois a tendência em querer prever o futuro e definir funcionalidades mesmo
antes de solicitadas pelo cliente é algo difícil de ser deixado de lado. Já para o
outro membro da equipe de programação, o menos experiente, não tivemos
problemas.
Integração Contínua
Apesar do pequeno tamanho da equipe de programadores, foi utilizada a

ferramenta de controle de versões padrão da Procuradoria, o CVS (Concurrent
Version System). Dessa maneira, mesmo se houvesse outro par trabalhando
isoladamente no mesmo trecho de código, poderiam integrá-lo na versão mais
recente em produção. O CVS também auxiliaria na descoberta de conflitos o
14 de 17 29-09-2010 23:07
mais breve possível.
Metáfora
A equipe definiu, no início do projeto, uma metáfora para facilitar a

comunicação não só entre a equipe de desenvolvimento, mas também com o
cliente, ela foi chamada de "ficha de credenciados". Tal metáfora foi definida
observando-se como os dados dos credenciados eram mantidos atualmente, sem
uso de sistemas computacionais.
O cliente mostrou-se visivelmente mais à vontade nas conversas com o uso da

metáfora, ao invés de outros termos mais técnicos.
Ritmo Sustentável
Por se tratar de um projeto secundário e experimental, a equipe trabalhou

apenas duas horas diárias, dessa forma todos puderam oferecer máximo
rendimento. Foi notável que apesar do pouco tempo, cada minuto foi altamente
produtivo, pois não havia tempo para distrações, e a equipe não chegava a se
esgotar mental ou fisicamente.
Quadro de Acompanhamento Diário
7-Conclusão
A utilização da metodologia em projetos pequenos foi comprovadamente um

sucesso a bateria de testes o acompanhamento próximo do cliente no
desenvolvimento contribuiu para satisfação do projeto, a simplicidade, a
comunicação, o feedback, a coragem, são práticas responsáveis pelo êxito da
equipe no processo do software, os pontos negativos são exatamente a ausência
de documentação, fica muito difícil substituir um membro na equipe caso seja
necessário, a iteração desse funcionário pode atrasar o andamento do projeto e
comprometer toda as boas práticas,a metodologia apresenta também como
15 de 17 29-09-2010 23:07
ponto fraco resolução de problemas presentes, sem a preocupação com

manutenção futura.
Referências
[1] Kon, Fabio. Programação Extrema. Departamento de
Ciência da Computação IME/USP, 2006.
[2] Manhães Teles, Vinícius. Extreme Programming. 1. ed.
Novatec Editora, 2004.
[3] Beck, Kent. Programação Extrema explicada: acolha as
mudanças. 1. ed. Bookman, 2004.
[4] Manhães Teles, Vinícius. Um estudo de caso da adoção
das práticas e Valores do Extreme Programming.
Dissertação (mestrado em informática) - Universidade
Federal do Rio de Janeiro - UFRJ, IM / DCC, 2005.
16 de 17 29-09-2010 23:07
Perfil do autor
Pós - Graduado em Engenharia de Software
Impresso de http://www.artigonal.com/tecnologia-artigos/metodologia-agil-de-
desenvolvimento-de-software-2887376.html
Voltar ao artigo
17 de 17 29-09-2010 23:07

Metodologia Agil

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Metodologia Agil

Enviado por

Direitos autorais:

Formatos disponíveis

Metodologia Àgil de Desenvolvimento de Software... http://www.artigonal.

Metodologia Àgil de Desenvolvimento de Software

Com o crescimento das atividades de todas as economias a busca por

Hoje tudo no mundo dos negócios depende da tecnologia não existe um

Desenvolvimento de software é complexo em muitos casos quando o projeto

Aí voltamos á história de grandes estudiosos que buscaram a maximização e

A metodologia tradicional foi utilizada como principal recurso para

Muitos desenvolvedores consideram as como ultrapassada pois é considerada

Com esse cenário alguns programadores questionaram e se opuseram a uma

série de práticas adotadas em abordagens tradicionais de engenharia de

A manifestação dos desenvolvedores para desenvolvimento ágil de sistemas tem

Pessoas e interações são mais importantes que processos e ferramentas;

O Software funcionando é mais importante do que documentação completa e

Colaboração do cliente é mais importante do que negociação de contratos;

Ser flexível á mudanças é mais importante do que seguir o plano inicial;

Programação Extrema foi uma das soluções de metodologia encontrada para

O XP ou Programação Extrema é um processo de desenvolvimento de software

Projetos cujos requisitos são complexos que mudam com freqüência ;

Desenvolvimento de sistemas orientado a objetos;

Desenvolvimento incremental e iterativo com o cliente.

2- A metodologia XP é composta de quatro valores: comunicação, simplicidade,

Os valores e princípios durante o processo de desenvolvimento software no XP

Desenvolvimento guiado pelos testes

Vamos detalhar cada um destes no trabalho.

3-São quatro variáveis que controlam o desenvolvimento de software.

Escopo é a variável que mostra o cenário das necessidades do cliente, que

Qualidade é atender a necessidade do cliente, ao longo do desenvolvimento

4- O Extreme programming tem seu desenvolvimento entre quatro valores que

A comunicação esta presente em todas as etapas de desenvolvimento neste

É exatamente o retorno da comunicação entre o cliente e a equipe de

O XP recomenda que, ao implementar uma solução, você a implemente da

Coragem é agir de forma efetiva em face do medo. Certamente é verdade que

Os valores da XP trabalham melhor em conjunto e em muitos casos são

5-Princípios do Extreme Programming

O processo de troca de informações, relacionadas ao que é produzido e

É sempre muito difícil de controlar dentro de um projeto de desenvolvimento,

O problema será resolvido da forma mais simples.

Com o XP o cliente presente ajuda o cliente a entenderem os desenvolvedores

As práticas do XP segundo Beck 2004.

Uma vez por semana os desenvolvedores se reúnem com o cliente para

implementadas e testadas na mesma semana.

Programação em Par é uma prática das mais conhecidas e mais utilizadas em

Desenvolvimento Orientado a Testes:

Testes automatizados e implementados antes de cada funcionalidade, de cada

Para evitar que a aplicação se transforme local sujo e, desorganizado e difícil

Os desenvolvedores têm acesso a todas as partes do código e podem

A equipe deve estabelecer padrões de codificação.Identificação do código

Não criar generalizações, ou seja, não tente prever o futuro codificar o

Com o poder de transmitir idéias complexas de forma simples, facilita a

Release é um conjunto reduzido de funcionalidades que a equipe coloca em

Características da equipe gerente de projeto:

É responsável pelos assuntos administrativos do projeto Coach: é o responsável

É responsável por ajudar o cliente a escrever os testes de aceitação, detectar

Ajuda a equipe de desenvolvimento a documentar o sistema. Desenvolvedor: é

O programador é o coração da equipe ele é responsável por tornar a aplicação

O estudo de caso foi realizado aplicando-se as práticas e valores do Extreme

As atividades desenvolvidas dentro da Procuradoria Regional do Trabalho

Atualmente, todos os sistemas computacionais relacionados à área fim são

O Programa de Saúde e Assistência Social do Ministério Público da União -

como aos pensionistas, um sistema de serviços e benefícios sociais, dentre eles

Atualmente, as informações dos profissionais ou entidades conveniadas, como

A solução encontrada foi o desenvolvimento de uma ferramenta que permita o

Análise de Cada Prática do XP no Projeto