Upload
joaquim-lopes-junior
View
554
Download
1
Embed Size (px)
DESCRIPTION
Conceitos Gerais sobre métodos ágeis e introdução os métodos Scrum E XP.
Citation preview
Desenvolvimento ágil de SoftwareMotivaçãoManifesto Ágil e ConceitosSCRUMExtreme Programming (XP)
Motivação Interna – “Dor”
http://www.youtube.com/watch?v=1lqxORnQARw
Projetos de PontesPrazo – OK ( menos no
Brasil )Orçamento – OKQuase nenhuma caiCiência Antiga – 4 a 6
mil anos
Motivação Interna - Chaos Report
Projetos de SoftwarePrazo – estouraOrçamento – estouraTêm problemas com
freqüênciaCiência nova – 50
anos
Motivação Interna - Chaos Report
Aspectos críticosProjetos de ponte são engessados e ninguém dá
“pitaco”Projetos de software normalmente precisam
suportar mudanças nas regras de negócioPontes que caem têm relatórios de erros. Softwares
são mascarados e ignorados. Não há aprendizado
Motivação Interna - Chaos Report
69%
31%
TerminamNão terminam
16%
84%
SimNão
Projetos que terminam
Prazo e Orçamento OK
Motivação Interna - Chaos Report
42%
58%
SimNão
Requisitos presentes ao final
Motivação do MercadoRAD – Rapid Application Development – anos
90.Métodos iterativos (ciclos) e evolucionários
(bottom-up)Empresas buscam produtos de TI como forma
de diferenciaçãoFrustração com planejamentosNecessidade de atendimento a modelos de
maturidade – CMMI, MPS.BRAlternativas à época com baixa tolerância a
mudanças de requisitos
E aí!?
E aí!?Desenvolvimento ágil não garante
necessariamente que o projeto terá mais ou
menos sucesso :-(
E aí!?Desenvolvimento ágil não garante
necessariamente que o projeto terá mais ou menos sucesso :-(
Mas ajuda!!! Como?
E aí!?Desenvolvimento ágil não garante
necessariamente que o projeto terá mais ou menos sucesso :-(
Mas ajuda!!! Como?Ajuda a descobrir antes que algo não está
indo bem – ITERAÇÕES CURTAS E ENVOLVIMENTO DO CLIENTE PARA VALIDAÇÃO
:-))
Manifesto Ágil
Encontro de 17 agilistas – Utah – Fevereiro – 2001
Kent Beck – XP (Extreme Programming)Ken Schwaber – SCRUMAlistair Cockburn – Crystal – Metodologia sob
demandaChegaram a conclusões:
www.agilemanifesto.org
Manifesto Ágil
Individuals and interactions over processes and tools Uma descrição mínima de processo é
necessária para se começar a trabalhar.Cliente sempre presente
Manifesto Ágil
Working software over comprehensive documentationSoftware bem organizado e documentadoAlguma documentação existe. Apenas o
suficiente e não conta como produto, resultado de trabalho.
Manifesto Ágil
Customer collaboration over contract negotiationCliente deve estar 'infiltrado' na equipe de
desenvolvimento.
Manifesto Ágil
Responding to change over following a plan
Método x ProcessosXP e SCRUM não são processos
Processos definem fluxo, entradas saídas, papéis.
São métodos (ou metodologias)Esse entendimento facilita a adoção de
práticas ágeis em processos tradicionais já definidos – não precisa substituir o processo
Importante diferenciar também processo de software e gestão de projeto de software
SCRUMO nome vem do rugby. Reinício da partida.Baseado na teoria de controle de processo
industrialAuto-organização e emergência
Utilizado há 15 anos com sucesso em milhares de projetos, centenas de organizações
É gerencial. Não serve apenas para projetos de software
SCRUMAjuda a controlar projetos de
desenvolvimento de softwareNão garante sucesso completo do projetoGarante que o trabalho é dedicado aos
resultados de maior valor agregadoSe o recurso for cortado, cliente sempre
vai ter algo em mãos com alguma utilidade.
Requisitos importantes nunca ficam para o final
SCRUMObtém-se do backlog o
que é de mais valorPlaneja-se a iteraçãoFaz-se acompanhametno
diárioEntrega acréscimo de
funcionalidades ao fim da iteração.
SCRUM - PapéisProduct Owner (CLIENTE)
Lista de requisitos (product backlog)Objetivos de ROIPlanejamento de Releases (priorizar)
Team (EQUIPE)Desenvolvimento de funcionalidadesAuto-gerido e auto-organizado (experiência)Multi-funcional ( programador, testador,
arquiteto, etc)
SCRUM - PapéisScrumMaster
Ensinar Scrum aos outros envolvidosManter o método nos trilhosRespeitar cultura da organização x
Entregar benefícioS CULTURA é uma das principais barreiras a
serem vencidas
Garantir que os outros envolvidos sigam as regras e práticas do SCRUM
SCRUM – Visão Geral
SCRUM - ArtefatosProduct backlog
Sempre evoluiSprint backlog
Derivado a partir do product backlogDetalha os itens do product backlog em tarefas
SCRUM - ArtefatosBurndown Chart – quanto mais horizontal,
melhor
SCRUM - ArtefatosIncremento de funcionalidade de produto
potencialmente 'empacotável'Esse incremento deve ser levantado em cada sprintCLIENTE pode querer implantar ( Antecipação ao
release. Furo no SCRUM? Equipe estará apta? )O que é um incremento CONCLUÍDO? (done)
Testado Código bem escrito e bem estruturado Disponível em um executável Com documentação de usuário
SCRUM - RegrasSprint Planning Meeting – parte inicial – 4 horas
4 horas definindo itens mais importantes e empacotáveis do backlog de produto
Todos os papéis participamBacklog deve ser preparado antes pelo Product
Owner(de preferência) ou ScrumMaster(pior)Sprint Planning Meeting – parte final – 4 horas
SCRUMMASTER responde perguntas da EQUIPE nas 4 horas finais para detalhamento de tarefas
Ao final, tem-se o Sprint Backlog
SCRUM - RegrasDaily Scrum Meeting
15 minutos independente do número de membros
Muita rigidez com presença e pontualidadeTrês questões
O que você fez desde a última conversa? O que você vai fazer de agora até a próxima? O que lhe impede de fazer o seu trabalho o mais
eficientemente possível?
Exigem respostas rápidas
SCRUM - RegrasSprint – duração sugerida: 30 dias
Itens de Backlog de sprint CONGELADOS durante a execução do sprint
Atendimento a mudanças de requisitos garantida pela continuidade de alterações no backlog de produtos
ScrumMaster pode abortar o sprint (casos extremos)Team pode consultar ao P. Owner o que retirar do
backlog quando for constatada impossibilidade de finalizá-lo por completo. O contrário (acrescentar funcionalidades) também é aceito.
SCRUM - RegrasSprint Review Meeting
4 horasApresentar funcionalidades ao Cliente e
stakeholdersArtefatos não podem ser apresentados como
produtos de trabalho (Forma de policiar o contrato? Afinal o que tem valor é software funcional – valor ágil )
Stakeholders são ouvidosAo final, o próximo Sprint Review Meeting é
agendado
SCRUM - RegrasSprint Retrospective Meeting
3 horasSM, TM e PO (opcional)Perguntas ao TM
O que foi bom no último sprint? O que não foi bom? Melhorar práticas
SM cataloga as respostasTM prioriza a ordem de melhoras em potencial
para discutir
Gostaram do SCRUM?Falamos de Gestão de ProjetoAgora 'tá' na hora de práticas de
desenvolvimentoVamos falar de XP
33
:.: :.: ÍÍNDICENDICE
1.1 Motivação
1.2 Muito Prazer, eu sou XP
34
:.: 1.1 - Motivação:.: 1.1 - Motivação
Programadores estão Sofrendo ao Redor do Mundo
Versão Original
( http://www.youtube.com/watch?v=SE7gzecA43U )
Versão Legendada
( http://www.youtube.com/watch?v=W-188Z-xgjo0 )
35
:.: 1.1 - Motivação:.: 1.1 - Motivação
Relatório do Caos – Chaos Report
36
:.: 1.2 – Muito Prazer, Eu sou :.: 1.2 – Muito Prazer, Eu sou XPXP
“Jeito leve, eficiente, de baixo risco, flexível, previsível, científico e divertido de desenvolver software” - Kent Beck
Recomendado para:
– Projetos com requisitos vagos e que mudam frequentemente
– Desenvolvimento Orientado a Objetos– Equipes Pequenas(não superiores a 12 pessoas)– Desenvolvimento Incremental – Interativo, com
versões intermediárias até se chegar a versão final.
37
:.: 1.2 – Muito Prazer, Eu sou :.: 1.2 – Muito Prazer, Eu sou XPXP
Define um conjunto de valores, práticas e
recomendações que se seguidos em conjunto
levarão ao desenvolvimento de um produto
com alta qualidade e o menor custo
possível, além de valorizar as pessoas
envolvidas nas atividades de construção do
produto.
38
:.: 1.2 – Muito Prazer, Eu sou :.: 1.2 – Muito Prazer, Eu sou XPXP
Premissa compartilhada com outros métodos Ágeis
O cliente deve estar integrado a equipe de
desenvolvimento e aprenderá sobre suas
necessidades a medida em que puder manipular
versões intermediárias durante o
desenvolvimento.
39
:.: 1.2 – Muito Prazer, Eu sou :.: 1.2 – Muito Prazer, Eu sou XPXP
XP não é:
Um software ou ferramenta de gestão de projetos
Um processo de desenvolvimento de software – Não prevê fases, artefatos, papéis formais, etc.
40
Metodologias Ágeis: Metodologias Ágeis: Extreme Extreme ProgrammingProgramming
2 – Elementos de 2 – Elementos de Extreme Extreme ProgrammingProgramming..
Professor: Joaquim Lopes Júnior Professor: Joaquim Lopes Júnior ([email protected])([email protected])
41
:.: :.: ÍÍNDICENDICE
2.1 Valores
2.2 Práticas
42
:.: 2.1 - Valores:.: 2.1 - Valores
Comunicação
Alguém no time saberá a solução para seu problema. Mas você precisa avisar!
Ao se deparar com um problema, avalie se ele teria sido evitado se alguém tivesse “contado” alguma coisa.
A partir disso, melhore a comunicação e defina como parte do processo
43
:.: 2.1 - Valores:.: 2.1 - Valores
Simplicidade
Posicione-se: onde está e para onde quer ir?
Qual é o jeito mais simples(barato, legal) de se mover?
Feedback
Times XP se esforçam para dar o máximo de feedback e o mais rápido possível
Opinem sobre ideias, sobre a qualidade do código-fonte, diga se os testes foram fáceis de implementar e se executaram sem problemas
44
:.: 2.1 - Valores:.: 2.1 - Valores
Coragem
Você não precisa ser um bombeiro ou policial para ser corajoso
Coragem não é inconsequência – seja equilibrado
Tenha coragem para jogar uma parte do sistema fora. Ou para escrever pouca documentação.
Respeito (Edição de 2004 do Embrance Change).
Respeite o seu time, respeite o que outros fazem
Respeite o projeto, cuide dele
Planning Game – Jogo do Planejamento
Técnicas de planejamento para manter o foco no que é mais importante (maior valor) para o cliente.
Ocorre sempre no início de uma iteração ou release.
– Releases (~8 semanas) : Entrega de módulo do software que represente valor.
– Iteração (~2 semanas) : Implementação de conjunto de funcionalidades. Marco do release.
45
:.: 2.2 - Práticas:.: 2.2 - Práticas
Planning Game – Jogo do Planejamento
No JP, o cliente é responsável por definir quais são as funcionalidades – histórias – a serem entregues no próximo release – prioriza o que tem maior valor.
Histórias de Usuário são as funcionalidades descritas em cartões – post-its. Responsabilidade do usuário.
Tempo para desenvolvimento da História medido em pontos.
46
:.: 2.2 - Práticas:.: 2.2 - Práticas
Planning Game – Jogo do Planejamento
47
:.: 2.2 - Práticas:.: 2.2 - Práticas
Standup Meeting – Reunião em pé
Reunião diária para acompanhamento das tarefas. Ela deve ser rápida e objetiva (por isso a turma não pode sentar)
No Scrum, sugere-se para o Daily Meeting:
15 minutos | O que você fez de ontem para hoje? | O que você fará até amanhã? | Quais dificuldades têm enfrentado? (Qual valor do XP?)
48
:.: 2.2 - Práticas:.: 2.2 - Práticas
49
:.: 2.2 - Práticas:.: 2.2 - Práticas
Pair Programming – Programação em Pares
Dois desenvolvedores compartilhando uma estação.
Análise, Desenho, Programação e Testes.
Um mantém o outro motivado e no foco.
50
:.: 2.2 - Práticas:.: 2.2 - Práticas
Test Driven Development – Desenvolvimento Dirigido por Testes
XP e outros métodos ágeis tem foco em alta qualidade.
Antes de se programar uma funcionalidade, programa-se um teste para ela. A funcionalidade tem que passar no teste.
Dessa forma aprimora-se a análise (há mais tempo para entender o que é necessário) e investe-se mais tempo no desenho do software – Interfaces. Menor retrabalho.
51
:.: 2.2 - Práticas:.: 2.2 - Práticas
Refactoring – Refatoração
Modificações contínuas no código-fonte sem alterar a funcionalidade implementada.
Deixar o código mais simples, com melhor desempenho, mais modularizado, mais fácil de se integrar a outros módulos.
Os testes (Test Driven Development) ajudam a garantir que nada para de funcionar após uma mudança.
52
:.: 2.2 - Práticas:.: 2.2 - Práticas
Shared Code – Código Compartilhado/Coletivo
Não existe segmentação de partes do sistema entre os desenvolvedores. Todos podem acessar qualquer parte do código fonte, sem pedir autorização.
Aumento de Qualidade – Verificação e revisão de código
A qualquer momento um programador (ou um par) pode refatorar um código que achar que pode ser melhorado
53
:.: 2.2 - Práticas:.: 2.2 - Práticas
Coding Standards – Código padronizado
Já que todo mundo pode mexer, “né” ?
Agilidade na refatoração
Facilidade de Leitura
Exemplo:
http://pear.php.net/manual/en/standards.php
54
:.: 2.2 - Práticas:.: 2.2 - Práticas
Simple Design – Design(Desenho) Simples
Faça hoje o que você precisa para hoje.
Motivação: feedback rápido, entrega de funcionalidades de valor para o cliente.
Assume-se que será possível refatorar o código a qualquer momento para comportar novas funcionalidades.
Talvez a prática mais criticada pelos tradicionalistas.
55
:.: 2.2 - Práticas:.: 2.2 - Práticas
Metaphor – Metáfora do Produto
Relacionar o desenvolvimento do produto com abstrações do cotidiano.
Importante estar com a mente “oxigenada”.
Crie metáforas para as funcionalidades como se não existissem computadores.
E talvez esta seja a mais difícil de explicar
56
:.: 2.2 - Práticas:.: 2.2 - Práticas
40-hour week – 40h semanais / Ritmo Sustentável
XP depende de pessoas praticarem XP
Toda a qualidade do produto e dos elementos utilizados para desenvolvê-lo depende da qualidade das pessoas
Evitar horas extras.
Cuidado com os FREELAS...
57
:.: 2.2 - Práticas:.: 2.2 - Práticas
Continuos Integration – Integração Contínua
Os pares integram seus códigos ao sistema todo várias vezes
ao dia.
O processo de integração consiste em adicionar o incremento
do software e testar todo o sistema.
Dessa forma a integração não acrescenta erros ao sistema
Ferramentas: CruiseControl, Jenkins, Hudson, Bamboo,
BuildMaster, Teamcity, etc.
Desenho de ambiente.
58
:.: 2.2 - Práticas:.: 2.2 - Práticas
Short Releases – Releases Curtos
O principal objetivo desta prática é fazer com que o cliente tenha acesso ao valor do produto o mais cedo possível.
E esses incrementos de valor devem ser contínos (ex.: a cada 2 meses uma nova versão)
Favorece o feedback por parte do cliente de forma precoce. Diminui atrasos em entregas, aumenta assertividade, e aumenta a taxa de aproveitamento do produto
59
:.: 2.2 – Práticas:.: 2.2 – Práticas
lFrequência de Utilização das Práticas
Entendimento em 4 ciclos
http://blogs.msdn.com/b/jmeier/archive/2010/04/04/the-four-circles-of-xp-extreme-programming.aspx
60
Metodologias Ágeis: Metodologias Ágeis: Extreme Extreme ProgrammingProgramming
3 – Implantação de XP nas 3 – Implantação de XP nas OrganizaçõesOrganizações
Professor: Joaquim Lopes Júnior Professor: Joaquim Lopes Júnior ([email protected])([email protected])
61
:.: :.: ÍÍNDICENDICE
3.1 Desafios Gerenciais
3.2 Adoção de XP
3.3 Estudo de Caso
3.4 Documentação em XP
3.5 Escalando XP
3.6 Debate
62
:.: 3.1 – Desafios Gerenciais:.: 3.1 – Desafios Gerenciais
Conflitos de Processo de Desenvolvimento
Mesclar agilidade com processos tradicionais: ou se perde agilidade ou se joga fora muito esforço em definição de processo.
Variabilidade: Equipes ágil e não ágil no mesmo produto nem sempre vão se falar bem. Tomadas de decisões e documentos serão muito diferentes.
Ciclo de Vida: Entrega Imediata x Evolução a longo prazo
63
:.: 3.1 – Desafios Gerenciais:.: 3.1 – Desafios Gerenciais
Conflitos de Processo de Desenvolvimento
Sistemas Legados: Difícil de refatorar.
Requisitos: Histórias de Usuários precisarão ser “inchadas” com requisitos não funcionais de performance e segurança para ficar compatível
64
:.: 3.1 – Desafios Gerenciais:.: 3.1 – Desafios Gerenciais
Conflitos de Processo de Negócio
Recursos Humanos: Traz desafios para gerir pessoas que não se enquadram em uma única função. Gestão de bem estar e gestão de tempo para imprevistos.
Gestão de Progresso: Contratos e técnicas tradicionais (milestones) podem não suportar um desenvolvimento em XP. Muda a forma de negociar pagamento, por exemplo.
Medida de Maturidade: CMMI e MPS.BR
65
:.: 3.1 – Desafios Gerenciais:.: 3.1 – Desafios Gerenciais
Conflitos de Pessoas
Atitudes: Processos evolutivos muito formalizados dificultam atitude multitarefa.
Logística: Um time de XP deve trabalhar unido (Comunicação).
Gestão da Mudança: Pessoas com resistência a mudanças irão se comportar de forma resistente.
Sugestões: Eduque, enfatize o valor para o cliente, escolha as pessoas certas, recompense valores individuais e junto a equipe.
66
:.: 3.2 – Adoção de XP:.: 3.2 – Adoção de XP
Utilizar XP não vai mudar seus problemas
– Atitudes do cliente
– Prazos mal negociados
– Orçamentos.
Vai mudar a forma como você os resolve.
Seja suave para não ter que abortar o processo
– O gerente vai pedir para a equipe trabalhar mais
– O programador vai escrever código sem teste
Encontre um patrocinador executivo de peso
67
:.: 3.2 – Adoção de XP:.: 3.2 – Adoção de XP
Mude e em seguida provoque a mudança
Aprenda TDD, depois ensine a toda equipe
Sua equipe aprende a estimar e desenvolver com base nas histórias, depois convide os clientes internos a apresentar histórias (comece sempre por um projeto interno)
Sua empresa aprende a entregar software de qualidade no prazo, então convide clientes externos para fazer parte do planejamento.
68
:.: 3.2 – Adoção de XP:.: 3.2 – Adoção de XP
Escolha um coach
Pessoa com experiência em XP → Mais fácil aprender com o erro alheio
Normalmente trabalha em equipe mas tem suas próprias atividades → é quem lidera tentativas de melhorias
Um evangelizador → Mantém todo mundo praticando XP
69
:.: 3.2 – Adoção de XP:.: 3.2 – Adoção de XP
Quando não adotar XP
Escute os valores → Se os valores da organização não forem alinhados não vai dar certo.
Sistemas de Premiação Individuais
Contratos de Escopo Fechado → Dificultam mudanças e utilização otimizada do XP. Catequize o cliente.
70
:.: 3.3 – Estudo de Caso:.: 3.3 – Estudo de Caso
Considerações importantes sobre estudos de casos:
Um caso de estudo não é um experimento formal, mais focado e com base em variáveis de contexto
Testa-se teorias (hipóteses) em uma configuração
Cada projeto tem características próprias. Validade questionável cientificamente. Difícil generalizar
Útil pois apresenta informações para a indústria de software. Ajudam a validar suspeitas.
71
:.: 3.3 – Estudo de Caso:.: 3.3 – Estudo de Caso
Sabre Airline Solutions → Resultados apontam aumento de produtividade e qualidade.
Empresa que desenvolve software para cias. Aéreas
Equipe tinha características favoráveis ao XP. Não foi necessário redimensionar ou ajustar o XP.
Comparação entre 2 releases do mesmo produto.
– Um release imediatamente antes da adoção
– Outro após aprox. 2 anos de utilização
72
:.: 3.3 – Estudo de Caso:.: 3.3 – Estudo de Caso
Sabre Airlines Solutions → Resultados apontam aumento de produtividade e qualidade.
Desenvolveram um framework para avaliação de XP → Fatores de Contexto, Métricas de Aderência ao XP, Métricas de Resultados do XP
A aplicação consiste em um sistema de desenvolvimento de interfaces para outros Sws.
O sucesso da utilização de XP fez com que mais de 200 pessoas em 30 times utilizassem o método
73
:.: 3.3 – Estudo de Caso:.: 3.3 – Estudo de Caso
74
:.: 3.3 – Estudo de Caso:.: 3.3 – Estudo de Caso
Hipóteses:
Qualidade do pré-release → defeitos detectados antes de liberar o software
Qualidade do pós-release → defeitos após release detectados pelos usuários
Produtividade dos programadores → medidas qdt de histórias e linhas de código por programador-mês
Satisfação do cliente → Medido por entrevistas e feedback
Satisfação da equipe → Medida por meio de pesquisa interna
75
:.: 3.3 – Estudo de Caso:.: 3.3 – Estudo de Caso
76
:.: 3.3 – Estudo de Caso:.: 3.3 – Estudo de Caso
77
:.: 3.3 – Estudo de Caso:.: 3.3 – Estudo de Caso
Outros Estudos de Casos:
– NASA testou XP para validá-lo para projetos de missão crítica e tiveram 2x mais produtividade [Wood & Kleb, 2003]
– Caso de Estudo de XP no Instituto de Pesquisa da Finlândia: precisão de estimativas +26%, produtividade + 12 linhas de código/hora, taxa de defeitos não variou. [Abrahamsson, 2003]
78
:.: 3.3 – Estudo de Caso:.: 3.3 – Estudo de Caso
Outros Estudos de Casos:
– Williams et. al. [2004] fez uma aplicação do framework na IBM, em um projeto onde o XP foi adotado parcialmente:
• Aumento de produtividade e queda de defeitos no pós-release da ordem de 40%
79
:.: 3.4 – Documentação em XP:.: 3.4 – Documentação em XP
XP tem documentação, SIM SENHORES!
Mas só o suficiente!
80
:.: 3.4 – Documentação em XP:.: 3.4 – Documentação em XP
Documentações, testes de unidade e aceitação dão suporte ao código gerado (principal entrega).
Documenta-se apenas o suficiente para que futuros desenvolvedores possam dar manutenção
Refatoração, Código Coletivo e Prog. Em pares contribuem para se ter código mais limpo e simples, reduzindo esforço de documentar.
81
:.: 3.4 – Documentação em XP:.: 3.4 – Documentação em XP
Visão tradicional → custo de alterar o software cresce exponencialmente ao longo do ciclo de vida. Preferível manipular docs do que corrigir código.
Visão ágil → Orientação a objetos e ferramentas de apoio a devel tornam mais barato corrigir código do que manter documentos atualizados
E ainda há uma grande dificuldade de se manter toda documentação tradicional atualizada e coerente (rastreabilidade)
82
:.: 3.4 – Documentação em XP:.: 3.4 – Documentação em XP
Exemplos de documentos:
Histórias - Testes de Aceitação - Testes de Unidade -
Documentação de APIs - Modelo de Classes -
Modelo de Dados - Processos de Negócio -
Manual do Usuário - Acompanhamento Diário -
Acompanhamento do Projeto - Fotos
83
:.: 3.5 – Escalando XP:.: 3.5 – Escalando XP
Número de pessoas → divida o problema em vários times pequenos e trate a integração
Relação com a parte não ágil da empresa → Tenha um GP experiente. Não esconda nada. Não condene.
Projetos de Longa Duração → Não descuide dos testes e continue utilizando XP.
Complexidade dos problemas → Tenha um time de especialistas faça um conhecer o trabalho do outro
Missão Crítica → Adicione auditorias. Não só no final. Faça um “Continuous Auditing”.
84
:.: 3.6 – Debate:.: 3.6 – Debate
Como é a cultura da sua organização?
Você consegue identificar um primeiro projeto para utilizar XP?
Você teria apoio da diretoria para usar XP?
Você acha que as pessoas gostariam de usar XP?
O seu cliente faria parte da sua equipe?
85
:.: BIBLIOGRAFIA:.: BIBLIOGRAFIA
Manhaes Teles, Vinicius. Um estudo de caso da adoção das práticas e valores do Extreme Programming. 2005. 180 f. Dissertação (Mestrado em Informática) - Universidade Federal do Rio de Janeiro, Rio de Janeiro. 2005.
Beck, K. & Andres, C. (2004). Extreme Programming Explained: Embrace Change. Addison
Wesley, 2a edição. ISBN 0-321-27865-8
Boehm, B. & Turner, R. (2005). Management Challenges to Implementing Agile Processes in
Traditional Development Organizations. IEEE Softw. 22, 5 (Sep. 2005), 30-39. DOI= http://dx.doi.org/10.1109/MS.2005.129
Lucas Layman, Laurie Williams , Lynn Cunningham, Exploring Extreme Programming in Context: An Industrial Case Study, Proceedings of the Agile Development Conference (ADC'04), p.32-41, June 22-26, 2004
W. Wood, W. Kleb, "Exploring XP for Scientific Research," IEEE Software, vol. 20, pp. 30-36, 2003.
P. Abrahamsson, "Extreme Programming: First Results from a Controlled Case Study," in 29th EUROMICRO Conference. Belek, Turkey: IEEE, 2003.
D. J. Reifer, "How to Get the Most out of Extreme Programming/Agile Methods," in 2nd XP and 1st Agile Universe Conference. Chicago, IL: Springer LNCS 2418, August 2002, pp. 185-196.
L. Williams, W. Krebs, L. Layman, and A. Antón, "Toward a Framework for Evaluating Extreme Programming," presented at Proceedings of the Eighth International Conference on Empirical Assessment in Software Engineering (EASE 04), 2004, in press.