XP PDF

Mtodos geis Programao eXtrema (XP)
Conceitos Bsicos
Ayrton Menitto Cinquini
Toda manh, na frica, um leo acorda. Ele sabe que dever correr mais rpido do que a gazela, ou morrer de fome.
Quando o sol surge no horizonte, no importa se voc o leo ou a gazela melhor que voc esteja preparado para correr.
Adaptao de um Ditado Popular Italiano
Ayrton Menitto Cinquini / 2010
2011
Prof. Ayrton Menitto Cinquini
Problemas
Com metodologias de desenvolvimento

Supem que possvel prever o futuro Pouca interao com os clientes nfase em burocracias (documentos, formulrios, processos, controles rgidos, etc.) Avaliao do progresso baseado na evoluo da burocracia e no do cdigo Grande quantidade de erros Falta de flexibilidade
Com software

2011
Como resolver esse impasse?
Melhores Tecnologias

Padres de Projeto (reutilizao de idias) Componentes (reutilizao de cdigo)
Melhores Metodologias

Mtodos geis outras... (RUP, relacionadas a CMM, etc.)
2011
Mtodos geis de Desenvolvimento de Software
Movimento iniciado por programadores experientes e consultores em desenvolvimento de software. Questionam e se ope a uma srie de mitos / prticas adotadas em abordagens tradicionais de Engenharia de Software e Gerncia de Projetos. Manifesto gil:
Assinado por 17 desenvolvedores em Utah em fevereiro/2001.
2011
O Manifesto do
Desenvolvimento gil de Software
Indivduos e interaes so mais importantes que processos e ferramentas.

Software funcionando mais importante do que documentao completa e detalhada. Colaborao com o cliente mais importante do que negociao de contratos. Adaptao a mudanas mais importante do que seguir o plano inicial.
Prof. Ayrton Menitto Cinquini 9
2011
Princpios do Manifesto gil
Objetivos:
satisfazer o cliente entregando, rapidamente e com freqncia, sistemas com algum valor.
Entregar verses funcionais em prazos curtos. Estar preparado para requisitos mutantes.
Para isso, adotar as seguintes tticas:
Pessoal de negcios e desenvolvedores juntos.

Troca de informaes atravs de conversas diretas.
2011
10
Os Doze Princpios do Agile Software
Nossa maior prioridade satisfazer o cliente atravs da entrega inicial e contnua de software valioso. Mudana de requisitos so bem vindas, mesmo tarde no desenvolvimento.
Agile processo de mudana para aproveitar a vantagem competitiva do cliente.
Entregar software funcionando frequentemente, de um par de semanas a alguns meses, com preferncia para o prazo mais curto. Pessoas de negcios e desenvolvedores devem trabalhar juntos durante todo o projeto. Construir projetos em torno de indivduos motivados.
D-lhes o ambiente e o apoio de que precisam, e confiar neles para fazer o trabalho.
O mtodo mais eficiente e eficaz de transmitir informaes para e dentro de uma equipe de desenvolvimento conversao face-a-face.
2011
11
Os Doze Princpios do Agile Software

Software funcionando a medida primria de progresso.
Processos geis promove o desenvolvimento sustentvel.
Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente.
Ateno contnua para a excelncia tcnica e bom design aumenta a agilidade. Simplicidade - a arte de maximizar a quantidade de trabalho no feito - essencial. As melhores arquiteturas, requisitos, e projetos emergem de equipes auto-organizveis. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, depois sintoniza e ajusta seu comportamento em conformidade.
2011
Principais Mtodos geis

Programao eXtrema (XP) Crystal (uma famlia de mtodos) Scrum Adaptive Software Development Feature Driven Development etc.
2011 Prof. Ayrton Menitto Cinquini 13
Programao eXtrema XP
Metodologia de desenvolvimento de software aperfeioada nos ltimos 10 anos. Ganhou notoriedade a partir da OOPSLA2000.
Nome principal: Kent Beck
Tambm importante: Ward Cunningham
2011
14
eXtreme Programming
Kent Beck Estados Unidos 1999
XP leve XP focado no desenvolvimento de software
XP se adapta bem a requisitos vagos e que mudam rapidamente
2011
15
Reaes a XP
A maioria das pessoas no entendem ou no acreditam ou tem um chefe que no entende. Fora o [mau] programador a se comportar de uma forma similar ao bom programador.
2011
16
Premissas Bsicas do Modelo Tradicional
necessrio fazer uma anlise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema. necessrio fazer um estudo minucioso e elaborar uma descrio detalhada da arquitetura antes de comear a implement-la. necessrio testar o sistema completamente antes de mandar a verso final para o cliente.
2011
18
O que est por trs deste modelo?

Custo de mudanas
requisitos desenho testes anlise implementao produo

2011
20
Gostei, mas ser que d para chegar o prdio um pouquinho para a direita?
2011
21
Software
Mundo Fsico
2011
22
Caractersticas do Software
Abstrato
nico
Sua complexidade cresce rapida
mente
NO fabricado. criado como um romance ou uma nova receita

2011
NO fabricado. criado como um romance ou uma nova receita Dificilmente o usurio sabe de incio todos os detalhes,
no mximo, ele tem uma idia geral.
2011
24
Como desenvolvemos Software
viso
projeto conceitual arquitetura
cdigo
2011
25
Um usurio tpico
Eu no sei exatamente o que eu quero mas na hora em que eu ver o sistema eu vou saber o que eu quero. Eu tenho um problema e sei mais ou menos o que eu preciso para resolver esse problema mas s vou saber os detalhes quando o sistema estiver pronto.
2011
26
Desenvolvimento de Software
2011
27
Mudanas um risco ou uma oportunidade?
2011
28
E se a realidade hoje em dia fosse outra?

Custo de mudanas
tempo
2011
32
E se essa fosse a realidade?
A atitude dos desenvolvedores de software seria completamente diferente:
Tomaramos as grandes decises o mais tarde possvel.
Implementaramos agora somente o que precisamos agora.

No implementaramos flexibilidade desnecessria (no anteciparamos necessidades).
2011
34
E essa a nova realidade !

(pelo menos em muitos casos)
Orientao a Objetos: facilita e cria oportunidades para mudanas.

Tcnicas de Refatorao.
Testes automatizados: nos do segurana quando fazemos mudanas.

Prtica / cultura de mudanas: aprendemos tcnicas e adquirimos experincia em lidar com cdigo mutante.
2011
35
Caractersticas dos Projetos de Software
2011
63
2011
64
Imagina se......
Gostei, mas ser que d para chegar o prdio um pouquinho para a direita?
2011
65
Afinal
Software
Mundo Fsico
2011
66
Sua complexidade cresce rapida Abstrato nico
mente
2011
67
NO fabricado. criado como um romance ou uma nova receita Dificilmente o usurio sabe de incio todos os detalhes,
no mximo, ele tem uma idia geral.
2011
68
Um usurio tpico
Eu no sei exatamente o que eu quero mas na hora em que eu ver o sistema eu vou saber o que eu quero. Eu tenho um problema e sei mais ou menos o que eu preciso para resolver esse problema mas s vou saber os detalhes quando o sistema estiver pronto.
2011
70
Em projetos de Software o que melhor?
2011
71
Princpios Bsicos de XP
2011
73
Princpios Bsicos de XP

Feedback
rpido
Simplicidade
Comunicao
Coragem
2011
74
Qual a melhor maneira?
Qual o melhor para a aprendizagem:

Exerccio e correo imediata ou Exerccio e correo posterior?
Por que?
2011
75
Feedback
Do cliente para a equipe de desenvolvimento e vice-versa De forma rpida
2011
76
Simplicidade
Fazer de forma simples
S o que necessrio
Para:

Fazer rpido Obter feedback Corrigir o que for necessrio
no viajar no inventar necessidades

2011
Entendendo o cliente
2011
80
Comunicao
Fundamental para o Feedback
Deve ser face-a-face

A comunicao escrita deve ser usada somente para o que j foi decidido / feito Comunicao oral muito mais rica:

Gestos Expresso facial Tom da voz
2011
81
Coragem
necessrio ter coragem para:

Manter o sistema simples Trazer o cliente para perto da equipe Programar em pares Mexer em time que est ganhando Fazer refactoring Investir tempo em testes automatizados Abrir mo da documentao Tornar o cdigo coletivo !!!! Adotar contratos de escopo varivel
2011
82
As Prticas de XP
2011
83
As Prticas de XP
Cliente Presente Planejamento Reunies em P
Cdigo Coletivo
Cdigo Padronizado Design Simples
Programao em Par
Desenvolvimento guiado por testes Refatorao
Metfora
Ritmo Saudvel
Integrao Contnua
Releases Curtos
2011
84
Cliente Presente
2011
85
Cliente-Presente
Responsvel por escrever estrias.
Muitas vezes um programador ou representado por um programador do grupo. Trabalha no mesmo espao fsico do grupo.
Feedback do cliente essencial. Requisitos mudam (e isso no mau).
2011
Cliente Presente
Fator crtico de sucesso
Viabiliza a simplicidade do projeto

Permite:
Fazer pequenos ajustes <>carro na estrada Tirar dvidas rapidamente Aumento de confiana Fazer correes rapidamente
2011
87
Cliente escreve histrias

Estrias so escritas na linguagem natural

Estrias exprimem o comportamento de uma Funcionalidade geral Ex:
Realizar cadastro de Usurio no sistema. O sistema dever armazenar nome, telefone e email. O sistema dever permitir listagem, edio e excluso.
2011
Cliente-Presente
Recomenda-se 2 clientes-presentes (incluindo o gerente de produto) para cada 3 programadores Pode ser substitudo por:

Gerente de produto Especialistas de domnio Projetistas de interao Analista de negcio
2011
90
Exemplos de Estrias
Estria 1:
O sistema dever permitir a autenticao de usuros . Login antes de entrar no sistema e cadastro de novos usurios (nome, login, senha e e-mail)
Estria 2:
O sistema dever permitir aos usurios logados cadastrarem notcias. A notcia deve ter manchete, descrio e contedo. O sistema dever listar todas as notcias.
Estria 3:
A partir da listagem das notcias, o sistema dever permitir ao usurio enviar uma notcia para o e-mail de um usurio cadastrado.
2011
Cliente Presente
O que fazer quando o cliente no pode participar em tempo integral?
....
2011
92
Planejamento
O objetivo gerar o maior valor possvel para o cliente a cada dia de trabalho.
Projetos XP costumam ser divididos em releases

Cada release dura +/- 2 meses
Planejamento feito com base nas estrias escritas pelo cliente

As estimativas so feitas junto com o cliente.
2011
93
Estimativas Jogo do Planejamento
Cartas
Todos fazem estimativas para todos as estrias As estimativas so individuais

Tempo
2011
94
Estimativas Jogo do Planejamento
Setembro / 2003
Ayrton Menitto Cinquini
95
Planejamento
Apertando d? NO D!
Cada release dividida em iteraes

Cada iterao deve durar de uma a trs semanas XP no fecha escopo no inicio do projeto Mas fecha aps iniciado a iterao.
2011
97
Reunio em P (ou stand up meeting)
2011
98
Reunio em P
a forma mais simples para troca de informas

Projetos XP exige muita troca de informaes
Tudo o que est acontecendo, em qualquer parte do sistema, interessa a todos os membros da equipe
As pessoas precisam ficar sabendo o que acontecendo e quem fez o que. Quando mais cedo descobrimos os erros melhor Servem para medir o clima da equipe.
Muitas pessoas tm dificuldade de verbalizar suas preocupaes.

2011
Reunio em P
Com todos os desenvolvedores, todos os dias
Cerca de 10 (de 5 a 15) minutos

Visa:

Colocar todos a par do que est acontecendo Troca de experincias Obteno da viso do todo por todos
Todos devem poder falar
2011
100
Reunio em P
Na sua opinio qual o melhor hora para se fazer a Reunio em P? Por que? Como lidar com as pessoas que sempre chegam atrasadas? Por que? ...e com as pessoas que gostam de dominar a reunio? Por que?
2011
101
Programao em Pares
Isso parece desperdcio. Ou

no?
Um avio pode ser pilotado por uma nica pessoa. Certo?
Ento para que o co-piloto?
2011
102
Programao em Pares
Programar + Testar
Revisar
... e se ?
Programar + Testar + Revisar

2011
Programao em Pares

Todo o cdigo Um digita, outro revisa Reduo de bugs Disseminao do conhecimento Presso do par Simplicidade Velocidade
2011
Programao em Pares - Vantagens:
Erro de um pode ser detectado imediatamente pelo outro (grande economia de tempo).
Maior diversidade de idias, tcnicas, algoritmos.
Enquanto um escreve, o outro pensa em contraexemplos, problemas de eficincia, etc.

Vergonha de escrever cdigo feio (gambiarras) na frente do seu par. Pares de acordo com especialidades e/ou experincia.
Ex.: Sistema Multimdia Orientado a Objetos
2011
105
Programao em Pares
Pequenos erros so simples de serem corrigidos no ato
Depois consomem muito tempo.
Evita desviar a ateno com e-mails, mensagens instantneas, conversas etc.

Quando um est cansado o outro assume.
2011
106
Programao em Pares
E a produtividade?
Dois fazendo o trabalho de um. Certo?

No curto prazo a produtividade no muda muito
No longo prazo a diferena enorme.
Por que?
2011
107
Programao em Pares
Principais obstculos:
Mobilirio
Viso errnea. Achar perda de tempo. Relacionamento entre desenvolvedores Competio dentro da equipe
2011
108
Programao em Pares
Qual a melhor estratgia para implantar essa prtica? Que mudanas precisariam ser feitas na organizao para isso dar certo? Como fazer a avaliao individual dos profissionais, visando promoes etc?
2011
109
2011
110
Refatorao (Refactoring)
O que fazer com um cdigo que est funcionando mas pouco legvel?
2011
111
Uma [pequena] modificao no sistema que no altera o seu comportamento funcional

Mas que melhora alguma qualidade nofuncional:

simplicidade flexibilidade clareza desempenho
2011
112
Qualquer parte de cdigo poder ter que ser alterada no futuro, portanto quanto mais legvel melhor. Cdigo limpo e legvel pode ser alterado rapidamente e com mais segurana. O XP recomenda acabar com a baguna.
No XP isso no opcional, obrigatrio.
2011
113
Refatorao anda junto com cdigo coletivo
Porm tem um preo: risco do cdigo parar de funcionar!

O que fazer ento???
2011
114
Exemplos de Refatorao
Mudana do nome de variveis Mudanas nas interfaces dos objetos Pequenas mudanas arquiteturais Encapsular cdigo repetido em um novo mtodo
Generalizao de mtodos
raizQuadrada(float x) raiz(float x, int n)
2011
115
Desenvolvimento Guiado por Testes - TDD

Codificar Preparar os Testes .... e se? Testar
Preparar os Testes
Codificar
Testar
Parece que a mesma coisa. Ou a ordem dos fatores altera o produto?

Testes de Software:
Todo mundo sabe que so necessrios mas ningum quer fazer; So chatos e consomem tempo;
So deixados para o final;

Muitos aspectos precisam ser cercados.
2011
117
Quais as vantagens de preparar os testes antes de comear a codificao?
2011
118
Vantagens de se escrever os testes antes da codificao:

Auxilia na anlise, projeto e codificao; Projeto e implementao mais adequados, suficientes e simples; Ajuda que o cdigo seja o mais simples possvel; Ajudam a amadurecer mais rpido o projeto e a implementao.
2011
119
Quanto mais cedo um erro descoberto mais fcil ser a correo. mais barato prevenir do que remediar. Depurar um sistema processo extremamente custoso e demorado.
2011
120
Diretrizes do XP para testes de sistemas:
Os testes devem apontar erros tanto no que estamos fazendo no momento como tambm no que j est pronto; Devem ser gerados antes da implementao; Devem ser automatizados para poderem ser executados sempre que necessrio.
2011
121
Desenvolvimento Guiado por Testes
Testes de unidades (Unit tests)
escritos pelos programadores para testar cada elemento do sistema (e.g., cada mtodo de cada classe).
Testes de funcionalidades (Functional tests) ou Testes de Aceitao
escritos pelos clientes para testar a funcionalidade do sistema.
2011
122
Testes das unidades do sistema
Tem que estar sempre funcionando a 100%. So executados vrias vezes por dia. Executados noite automaticamente.
Testes das funcionalidades

Vo crescendo de 0% a 100%. Quando chegam a 100% acabou o projeto.
2011
123
No incio difcil criar e automatizar os testes de unidade. Ento:

Ir devagar; Ter disciplina e perseverana; Procurar conhecer tcnicas para simplificar a criao dos testes;
Usar uma ferramenta adequada;

Programao em par.
2011
125
Testes de Aceitao:

Procura simular a interao dos atores com o sistema; Uma funcionalidade pode ser implementada por uma ou mais classes;
So roteiros com as aes do ator e as respectivas respostas esperadas do sistema;

O ideal seria que fossem criados pelo cliente;

quem melhor conhece o sistema pretendido (deveria);

Um analista de testes pode ajudar com a ferramenta. Se no tiver disponibilidade de tempo, o analista de testes poderia escrever os testes e o cliente validar.
2011
126
Testes de aceitao:

Devem ser escritos antes de cada iterao O cliente deve participar ativamente
2011
127
Cdigo Coletivo
Quem manda aqui sou eu.
2011
129
Cdigo Coletivo
Problemas com as ilhas de conhecimento:
Gargalos no projeto; Srios problemas se o dono da ilha tiver que faltar; Cdigo de baixa qualidade ou legibilidade.
2011
130
Cdigo Coletivo
No XP:
No existem ilhas de conhecimento;

Cdigo coletivo;
Todos os desenvolvedores podem mexer em qualquer parte do sistema;

Quem cria o cdigo ir procurar faz-lo o mais legvel possvel.
2011
132
Cdigo Coletivo
Padres de estilo devem ser adotados pelo grupo inteiro.

O mais claro possvel.
XP no se baseia em documentaes detalhadas e extensas (perde-se sincronia).
Comentrios sempre que necessrios.

Comentrios padronizados. Programao em Par ajuda muito!
2011
Cdigo Coletivo
Se algum identifica uma oportunidade para simplificar, consertar ou melhorar cdigo escrito por outra pessoa, que o faa. Mas rode os testes!
Todos!
2011
134
Padro de Codificao
Diferenas de estilo costumam dificultar a compreenso de cdigos feitos por outros;
Um padro de codificao deve ser adotado logo no incio do projeto; O padro pode definido internamente ou adotado um j pronto; A Sun tem o Code Conventions for the Java Programming Language ;
2011
Padro de Codificao
Deve ser fcil, simples e eficaz.
Quando identificado um cdigo fora do padro:

A equipe deve ser alertada; Fazer a refatorao do cdigo.
No incio do projeto devem aparecer mais desvios; Tornar fcil o acesso aos padres;
2011
Padro de Codificao
Quando interessante deve-se adaptar o padro aos costumes dos programadores. Dificuldades:

Resistncias; Critrios para a seleo de um padro.
O padro em si no muito importante. De fato mais importante que todos adotem e utilizem o padro.
2011
137
Padro de Codificao
O que poderamos/deveramos padronizar?
Coloque por ordem de importncia do mais importante para o menos. Indique o que essencial e o que seria desejvel mas no imprescindvel.
2011
139
Projeto Simples
Antes.....
Se os custos de mudanas crescerem exponencialmente ao longo do projeto:
Tentar prever e resolver todos os problemas o mais cedo possvel;

Criar solues genricas.
Os projetos vo ser caros e demorados.
2011
140
Projeto Simples
Proposta do XP:
Implementar apenas aquilo que j se sabe que realmente necessrio; Evitar trabalho especulativo e
Possibilitar implementao mais rpida -> feedback mais rpido.
2011
141
RITMO SUSTENTVEL
2011
142
Ritmo Sustentvel
Prazo total do projeto
Horas extras:
Maior insero de defeitos no projeto e cdigo devido a desateno; S por poucos dias.
Horas/dia Apenas ilustrativo
2011
143
Ritmo Sustentvel
O trabalho na indstria no exige criatividade na mesma intensidade que exigida para o desenvolvimento de software.
2011
144
Ritmo Sustentvel
OK! Mas como convencer o

gerente?

Analisar o pagamento de horas extras; Estatsticas de erros custo de correes; Exemplos de outras empresas; Anlise de ausncias de funcionrios; Anlise de relatrios de demisses custo para reposio; Alvin Toffer, Domenico DeMasi e outros.
O CHEFE
2011
Integrao Contnua
Problemas de integrao so freqentes no desenvolvimento de software:
As interfaces convencionadas no foram respeitadas; Falta de compreenso de interfaces.
2011
146
Integrao Contnua
Quanto mais tarde for a integrao maior a probabilidade de problemas. Uai?
A integrao deve ser com a maior freqncia possvel diversas vezes por dia. Para isso importante manter baixo o tempo necessrio para fazer o build de todo o sistema.
2011
147
Releases Curtos
XP adota o desenvolvimento incremental com releases curtos. Em cada releases so entregues um conjunto de funcionalidades que representam valor bem definido para o cliente.
2011
148
Releases Curtos
Objetivos:

Acelerar o retorno do investimento; Possibilitar feedback rpido; Criar uma relao de confiana entre usurios e desenvolvedores;
Possibilitar a correo rpida de rumo;
Se necessrio abortar o projeto o quanto antes;
Acompanhamento mais confivel de projetos; Avaliao mais eficiente de riscos.

2011
Ambiente de trabalho
Se voc no tiver um ambiente razovel para trabalhar, seu projeto no ter sucesso (Kent Beck)
Quadro(s) brancos (nunca so demais) Post-it Cadeiras giratrias Jogos Comida e caf Folhas em branco Privacidade
2011
150
Ambiente de Trabalho
Algumas diretrizes:
Privilegiar o espao pblico

Se possvel reservar um pequeno espao para rea comum. Deixar a prpria equipe decidir como ser o espao fsico desde que respeitado as regras bsicas.
2011
151
Ambiente fsico adequado para trabalho altamente participativo; Mesas e cadeiras que permitam que duas pessoas trabalhem juntas;
Computadores velozes;
Rede rpida;
Monitores grandes e de alta qualidade;

Mural para colocao dos cartes de estrias.
2011
152
Telefones de fcil acesso
Telefones isolados para ligaes particulares
Recursos para tele-conferncia Quadro branco

+mquina fotogrfica digital Para apoiar discusses e debates Para modelagem em grupo
Comidas (sem exageros)
2011
153
Impactos Sociais
O que fazer quando um funcionrio no quer mudar do seu lugar conquistado aps longos anos?

Conscientizao ou Propor experincia por um determinado periodo de tempo.

Teles- 2004
2011
154
Documentao
XP no prega a no documentao. Por que?
Alguns projetos podem durar anos e nem sempre quem comeou fica at o final e... Para a manuteno eficiente e segura alguma documentao necessria.
2011
155
Documentao
Mas
Lembrar que documentao no o objetivo principal; Deve-se documentar apenas o necessrio para a manuteno; A documentao deve ser adequada, simples e apenas a necessria.
2011
156
Documentao
O que importa o sistema funcionando;
Documentao em excesso consome esforo e gera dificuldades para ser mantida atualizada e consistentes.
2011
157
Documentao
Quando documentar?
Antes, durante ou depois? Antes:

A documentao fica muito sujeita a modificaes; Apenas o mnimo necessrio
Depois o mais eficaz e prtico.
2011
158
Documentao
Poderia ser:

Estrias Testes de Unidade Testes de Aceitao Javadoc Modelo de Classes Modelo de Dados
Processos de Negcio Manual do Usurio Acompanhamento Dirio Acompanhamento do Projeto Fotos
2011
159
Documentao
Estrias

Descrio inicial da funcionalidade;

Escrita pelo cliente em cartes.
Testes de Unidade

Indicam o como cada deve se comportar

Informa qual o funcionamento esperado dos mtodos de cada classe.
Testes de Aceitao

Definem as respostas do sistemas; Fornecem um aprofundamento maior das estrias.
2011
160
Documentao
Javadoc
Gera automaticamente documentao das classes que compem o sistema;

C++ e Python tambm contam com ferramentas para gerao de documentao automtica.
Modelo de Classes
Pode ser gerada automaticamente com ferramenta de engenharia reversa do cdigo; Se for feita manualmente deve-se optar por uma documentao mais leve.
2011
161
Documentao
Modelo de Dados
De preferncia deve-se usar uma ferramenta para fazer a engenharia reversa das tabelas que compem o banco de dados.
Processos de Negcio
Devem abranger apenas os processos foco de automao.
Acompanhamento Dirio
Serve para o gerente acompanhar as pendncias do projeto.
2011
162
Documentao
Acompanhamento do Projeto

Atualizado semanalmente
Informa:

Estrias que fazem parte de iterao corrente; Estrias j concludas; Problemas encontrados; Motivos de atrasos e Riscos.
Fotos (digitais)
Registram os quadros brancos.
2011
163
Releases Curtos
Para isso importante que o cliente priorize as funcionalidades.
O desenvolvimento deve ser feito da forma mais simples possvel.
As funcionalidades mais importantes devem ser implementadas em primeiro lugar.
2011
164
Introduzindo Mtodos geis nas Organizaes
2011
165
A forma como um Mtodo gil introduzido em uma organizao
O sucesso ou o fracasso da iniciativa

Os cuidados tomados durante este processo
2011
166
No basta substituir ferramentas e tecnologias
Tem-se que considerar o impacto na estrutura, na cultura e nas prticas gerenciais
Antes de adotar e implementar qualquer um dos Mtodos geis fundamental que avalie:

a dimenso do impacto e a sua prontido para tal
2011
167
Valores Normas Padres
polticas rotinas da empresa e processos de tomada de deciso, estratgias de soluo de problemas, prticas voltadas inovao, filtros de informao, relacionamentos interpessoais negociaes.
2011
168
Necessidades:
Um champion,
Para que a equipe de desenvolvimento possa trabalhar com tranquilidade.
Formao de uma equipe especializada
Mudana radical na relao cliente fornecedor
2011
169

Os clientes devem:
Estar totalmente comprometidos com o projeto, trabalhar com esprito de colaborao, possuir o conhecimento necessrio,
Ser que vamos conseguir tudo isso?
ter autonomia para a tomada de decises,

estar disponveis para sanar as dvidas quando necessrio.
2011

Uma caminhada cheia de muitas dvidas e medos
2011
171

Uma caminhada cheia de muitas dvidas e medos
processos clssicos de desenvolvimento
Mtodos geis
2011
172
Lies Aprendidas
Os MAs podem ser aplicados a equipes de qualquer tamanho,
entretanto, deve-se ter em mente que quanto maior a equipe, maior a dificuldade de comunicao;
Experincia importante para que um projeto gil seja bem-sucedido,
mas a experincia tcnica em desenvolvimento de software muito mais importante que a experincia prvia com os Mtodos geis;
2011
173
Lies Aprendidas
Os Mtodos geis requerem menos treinamento formal que os mtodos clssicos.
Programao em pares minimizam a necessidade de treinamento
Um software crtico e de alta confiabilidade pode ser construdo com utilizao de MAs
fundamental que os requisitos de desempenho sejam explicitados logo no incio do projeto
2011
174
Lies Aprendidas
Os principais fatores crticos de sucesso para um projeto gil so:

cultura, pessoas e comunicao.
A documentao deve ser considerada um custo
Sua extenso deve ser determinada pelo cliente.
2011
175
Limitaes dos Mtodos geis

Nenhum processo gil uma bala de prata. meu!
2011
176
Limitaes para os Mtodos geis

obstculos, mas no intransponveis
Disperso geogrfica
Subcontratao
Grandes projetos e grandes equipes
Gerao de componentes
total ou parcialmente reutilizveis
Sistemas de misso crtica

Disponibilidade de clientes participativos e colaborativos
2011
Quando no usar XP

Quando o cliente no aceita as regras do jogo.

Quando o cliente quer uma especificao detalhada do sistema antes de comear.
Quando os programadores no esto dispostos a seguir (todas) as regras. Se (quase) todos os programadores do time so medocres.
2011
178
Quando no usar XP

Grupos grandes (>10 programadores). Quando feedback rpido no possvel:

sistema demora 6h para compilar. testes demoram 12h para rodar.
Quando o custo de mudanas essencialmente exponencial.

Quando no possvel realizar testes (muito raro).
2011
179
Portanto
XP no para todo mundo.
Mas todo mundo pode aprender com o XP.
2011
180
Mais Informaes
Extreme Programming, Teles, Vincius Manhes, novatec, 2004. www.agilealliance.org www.ime.usp.br/~xp www.extremeprogramming.org
2011
182
Prticas do XP
2011
183

XP PDF

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

XP PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Mtodos geis Programao eXtrema (XP)

Prof. Ayrton Menitto Cinquini

Com metodologias de desenvolvimento

Prof. Ayrton Menitto Cinquini

Como resolver esse impasse?

Padres de Projeto (reutilizao de idias) Componentes (reutilizao de cdigo)

Mtodos geis outras... (RUP, relacionadas a CMM, etc.)

Prof. Ayrton Menitto Cinquini

Mtodos geis de Desenvolvimento de Software

Prof. Ayrton Menitto Cinquini

Indivduos e interaes so mais importantes que processos e ferramentas.

Princpios do Manifesto gil

Para isso, adotar as seguintes tticas:

Pessoal de negcios e desenvolvedores juntos.

Prof. Ayrton Menitto Cinquini

Os Doze Princpios do Agile Software

Agile processo de mudana para aproveitar a vantagem competitiva do cliente.

Prof. Ayrton Menitto Cinquini

Os Doze Princpios do Agile Software

Software funcionando a medida primria de progresso.

Processos geis promove o desenvolvimento sustentvel.

Principais Mtodos geis

Nome principal: Kent Beck

Tambm importante: Ward Cunningham

Prof. Ayrton Menitto Cinquini

XP se adapta bem a requisitos vagos e que mudam rapidamente

Prof. Ayrton Menitto Cinquini

Prof. Ayrton Menitto Cinquini

Premissas Bsicas do Modelo Tradicional

Prof. Ayrton Menitto Cinquini

O que est por trs deste modelo?

requisitos desenho testes anlise implementao produo

Prof. Ayrton Menitto Cinquini

Prof. Ayrton Menitto Cinquini

Prof. Ayrton Menitto Cinquini

NO fabricado. criado como um romance ou uma nova receita

no mximo, ele tem uma idia geral.

Prof. Ayrton Menitto Cinquini

Como desenvolvemos Software

projeto conceitual arquitetura

Prof. Ayrton Menitto Cinquini

Prof. Ayrton Menitto Cinquini

Prof. Ayrton Menitto Cinquini

Mudanas um risco ou uma oportunidade?

Prof. Ayrton Menitto Cinquini

E se a realidade hoje em dia fosse outra?

Prof. Ayrton Menitto Cinquini

E se essa fosse a realidade?

A atitude dos desenvolvedores de software seria completamente diferente:

Tomaramos as grandes decises o mais tarde possvel.

Implementaramos agora somente o que precisamos agora.

Prof. Ayrton Menitto Cinquini

E essa a nova realidade !

Orientao a Objetos: facilita e cria oportunidades para mudanas.

Testes automatizados: nos do segurana quando fazemos mudanas.

Prof. Ayrton Menitto Cinquini

Caractersticas dos Projetos de Software

Prof. Ayrton Menitto Cinquini

Prof. Ayrton Menitto Cinquini

Prof. Ayrton Menitto Cinquini

Prof. Ayrton Menitto Cinquini

Sua complexidade cresce rapida Abstrato nico