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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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.
Prof. Ayrton Menitto Cinquini 12
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
18
O que est por trs deste modelo?
Custo de mudanas
requisitos desenho testes anlise implementao produo
2011 Prof. Ayrton Menitto Cinquini 19
2011
Prof. Ayrton Menitto Cinquini
20
Gostei, mas ser que d para chegar o prdio um pouquinho para a direita?
2011
Prof. Ayrton Menitto Cinquini
21
Software
Mundo Fsico
2011
Prof. Ayrton Menitto Cinquini
22
Caractersticas do Software
Abstrato
nico
Sua complexidade cresce rapida
mente
NO fabricado. criado como um romance ou uma nova receita
Prof. Ayrton Menitto Cinquini 23
2011
Caractersticas do Software
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
Prof. Ayrton Menitto Cinquini
24
Como desenvolvemos Software
viso
projeto conceitual arquitetura
cdigo
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
26
Desenvolvimento de Software
2011
Prof. Ayrton Menitto Cinquini
27
Mudanas um risco ou uma oportunidade?
2011
Prof. Ayrton Menitto Cinquini
28
E se a realidade hoje em dia fosse outra?
Custo de mudanas
tempo
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
35
Caractersticas dos Projetos de Software
2011
Prof. Ayrton Menitto Cinquini
63
2011
Prof. Ayrton Menitto Cinquini
64
Imagina se......
Gostei, mas ser que d para chegar o prdio um pouquinho para a direita?
2011
Prof. Ayrton Menitto Cinquini
65
Afinal
Software
Mundo Fsico
2011
Prof. Ayrton Menitto Cinquini
66
Caractersticas do Software
Sua complexidade cresce rapida Abstrato nico
mente
2011
Prof. Ayrton Menitto Cinquini
67
Caractersticas do Software
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
70
Em projetos de Software o que melhor?
2011
Prof. Ayrton Menitto Cinquini
71
Princpios Bsicos de XP
2011
Prof. Ayrton Menitto Cinquini
73
Princpios Bsicos de XP
Feedback
rpido
Simplicidade
Comunicao
Coragem
2011
Prof. Ayrton Menitto Cinquini
74
Qual a melhor maneira?
Qual o melhor para a aprendizagem:
Exerccio e correo imediata ou Exerccio e correo posterior?
Por que?
2011
Prof. Ayrton Menitto Cinquini
75
Feedback
Do cliente para a equipe de desenvolvimento e vice-versa De forma rpida
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini 78
2011
Entendendo o cliente
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
82
As Prticas de XP
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
84
Cliente Presente
2011
Prof. Ayrton Menitto Cinquini
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).
Prof. Ayrton Menitto Cinquini 86
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
Prof. Ayrton Menitto Cinquini
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.
Prof. Ayrton Menitto Cinquini 88
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
Prof. Ayrton Menitto Cinquini
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.
Prof. Ayrton Menitto Cinquini 91
2011
Cliente Presente
O que fazer quando o cliente no pode participar em tempo integral?
....
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
93
Estimativas Jogo do Planejamento
Cartas
Todos fazem estimativas para todos as estrias As estimativas so individuais
Tempo
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
97
Reunio em P (ou stand up meeting)
2011
Prof. Ayrton Menitto Cinquini
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.
Prof. Ayrton Menitto Cinquini 99
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
102
Programao em Pares
Programar + Testar
Revisar
... e se ?
Programar + Testar + Revisar
Prof. Ayrton Menitto Cinquini 103
2011
Programao em Pares
Todo o cdigo Um digita, outro revisa Reduo de bugs Disseminao do conhecimento Presso do par Simplicidade Velocidade
Prof. Ayrton Menitto Cinquini 104
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
107
Programao em Pares
Principais obstculos:
Mobilirio
Viso errnea. Achar perda de tempo. Relacionamento entre desenvolvedores Competio dentro da equipe
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
109
2011
Prof. Ayrton Menitto Cinquini
110
Refatorao (Refactoring)
O que fazer com um cdigo que est funcionando mas pouco legvel?
2011
Prof. Ayrton Menitto Cinquini
111
Refatorao (Refactoring)
Uma [pequena] modificao no sistema que no altera o seu comportamento funcional
Mas que melhora alguma qualidade nofuncional:
simplicidade flexibilidade clareza desempenho
2011
Prof. Ayrton Menitto Cinquini
112
Refatorao (Refactoring)
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
Prof. Ayrton Menitto Cinquini
113
Refatorao (Refactoring)
Refatorao anda junto com cdigo coletivo
Porm tem um preo: risco do cdigo parar de funcionar!
O que fazer ento???
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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?
2011 Prof. Ayrton Menitto Cinquini 116
Desenvolvimento Guiado por Testes - TDD
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
Prof. Ayrton Menitto Cinquini
117
Desenvolvimento Guiado por Testes - TDD
Quais as vantagens de preparar os testes antes de comear a codificao?
2011
Prof. Ayrton Menitto Cinquini
118
Desenvolvimento Guiado por Testes - TDD
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
Prof. Ayrton Menitto Cinquini
119
Desenvolvimento Guiado por Testes - TDD
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
Prof. Ayrton Menitto Cinquini
120
Desenvolvimento Guiado por Testes - TDD
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
122
Desenvolvimento Guiado por Testes
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
Prof. Ayrton Menitto Cinquini
123
Desenvolvimento Guiado por Testes
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
Prof. Ayrton Menitto Cinquini
125
Desenvolvimento Guiado por Testes
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
Prof. Ayrton Menitto Cinquini
126
Desenvolvimento Guiado por Testes
Testes de aceitao:
Devem ser escritos antes de cada iterao O cliente deve participar ativamente
2011
Prof. Ayrton Menitto Cinquini
127
Cdigo Coletivo
Quem manda aqui sou eu.
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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!
Prof. Ayrton Menitto Cinquini 133
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
Prof. Ayrton Menitto Cinquini
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 ;
Prof. Ayrton Menitto Cinquini 135
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;
Prof. Ayrton Menitto Cinquini 136
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
141
RITMO SUSTENTVEL
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
143
Ritmo Sustentvel
O trabalho na indstria no exige criatividade na mesma intensidade que exigida para o desenvolvimento de software.
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini 145
2011
Integrao Contnua
Problemas de integrao so freqentes no desenvolvimento de software:
As interfaces convencionadas no foram respeitadas; Falta de compreenso de interfaces.
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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.
Prof. Ayrton Menitto Cinquini 149
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
151
Ambiente de Trabalho
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
Prof. Ayrton Menitto Cinquini
152
Ambiente de Trabalho
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
Prof. Ayrton Menitto Cinquini
153
Ambiente de Trabalho
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
156
Documentao
O que importa o sistema funcionando;
Documentao em excesso consome esforo e gera dificuldades para ser mantida atualizada e consistentes.
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
164
Introduzindo Mtodos geis nas Organizaes
2011
Prof. Ayrton Menitto Cinquini
165
Introduzindo Mtodos geis nas Organizaes
A forma como um Mtodo gil introduzido em uma organizao
O sucesso ou o fracasso da iniciativa
Os cuidados tomados durante este processo
2011
Prof. Ayrton Menitto Cinquini
166
Introduzindo Mtodos geis nas Organizaes
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
Prof. Ayrton Menitto Cinquini
167
Introduzindo Mtodos geis nas Organizaes
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
Prof. Ayrton Menitto Cinquini
168
Introduzindo Mtodos geis nas Organizaes
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
Prof. Ayrton Menitto Cinquini
169
Introduzindo Mtodos geis nas Organizaes
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.
Prof. Ayrton Menitto Cinquini 170
2011
Introduzindo Mtodos geis nas Organizaes
Uma caminhada cheia de muitas dvidas e medos
2011
Prof. Ayrton Menitto Cinquini
171
Introduzindo Mtodos geis nas Organizaes
Uma caminhada cheia de muitas dvidas e medos
processos clssicos de desenvolvimento
Mtodos geis
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
175
Limitaes dos Mtodos geis
Nenhum processo gil uma bala de prata. meu!
2011
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini 177
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
Prof. Ayrton Menitto Cinquini
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
Prof. Ayrton Menitto Cinquini
179
Portanto
XP no para todo mundo.
Mas todo mundo pode aprender com o XP.
2011
Prof. Ayrton Menitto Cinquini
180
Mais Informaes
Extreme Programming, Teles, Vincius Manhes, novatec, 2004. [Link] [Link]/~xp [Link]
2011
Prof. Ayrton Menitto Cinquini
182
Prticas do XP
2011
Prof. Ayrton Menitto Cinquini
183