Post on 05-Dec-2014
description
Desenvolvimento ágil de Software
● Motivação
● Manifesto Ágil e Conceitos
● SCRUM
● Extreme Programming (XP)
Motivação Interna – “Dor”
http://www.youtube.com/watch?v=1lqxORnQARw
● Projetos de Pontes● Prazo – OK ( menos no
Brasil )
● Orçamento – OK
● Quase nenhuma cai
● Ciência Antiga – 4 a 6 mil anos
Motivação Interna - Chaos Report
● Projetos de Software● Prazo – estoura
● Orçamento – estoura
● Têm problemas com freqüência
● Ciência nova – 50 anos
Motivação Interna - Chaos Report
Aspectos críticos● Projetos de ponte são engessados e ninguém dá “pitaco”
● Projetos de software normalmente precisam suportar mudanças nas regras de negócio
● Pontes 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 Mercado
● RAD – Rapid Application Development – anos 90.
● Métodos iterativos (ciclos) e evolucionários (bottom-up)
● Empresas buscam produtos de TI como forma de diferenciação
● Frustração com planejamentos
Motivação do Mercado
● Necessidade de atendimento a modelos de maturidade – CMMI, MPS.BR
● Alternativas à é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 – SCRUM
● Alistair Cockburn – Crystal – Metodologia sob demanda
● 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 documentation
● Software bem organizado e documentado● Alguma documentação existe. Apenas o suficiente e
não conta como produto, resultado de trabalho.
Manifesto Ágil
● Customer collaboration over contract negotiation
● Cliente deve estar 'infiltrado' na equipe de desenvolvimento.
Manifesto Ágil
● Responding to change over following a plan
Método x Processos
● XP 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 desenvolvimento de software e gestão de projeto de software
Scrum
● O nome vem do rugby. Reinício da partida.
● Baseado na teoria de controle de processo industrial
● Auto-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
Scrum
● Empirismo
● Conhecimento a partir da experiência e tomada de decisões
● Pilares
● Transparência
– Linguagem comum sobre o processo– Definição de “Pronto”
Scrum
● Pilares
● Inspeção
– Artefatos e progresso são inspecionados sempre– Não pode atrapalhar a execução das tarefas– Detecção de variações indesejáveis que prejudiquem o
objetivo
Scrum
● Pilares
● Adaptação
– Ocorre quando qualquer aspecto sai dos limites aceitáveis
– O processo ou material produzido deve ser ajustado– Ajuste deve ser breve para minimizar impactos e
desvios– Ex.: primeira iteração atrasada em 30%– Scrum descreve atividades formais para inspeção e
adaptação ( daqui a pouco veremos )
Scrum
● Ajuda a controlar projetos de desenvolvimento de software
● Não garante sucesso completo do projeto
● Garante que o trabalho é dedicado aos resultados de maior valor agregado
● Se o recurso for cortado, cliente sempre vai ter algo em mãos com alguma utilidade.
● Requisitos importantes nunca ficam para o final
Scrum – Visão Geral
Scrum● Obtém-se do backlog o que
é de mais valor
● Planeja-se a iteração
● Faz-se acompanhametno diário
● Entrega acréscimo de funcionalidades ao fim da iteração.
Scrum - Time
● Times auto-organizáveis e multifuncionais
● Escolhem a melhor forma para completar o trabalho● Possuem, em conjunto, todas as competências para
realizar TODO o trabalho● Modelo visa aperfeiçoar flexibilidade, criatividade e
produtividade
● Entregas
● Interativa e Incremental
– Oportunidades de feedback– Produto “Pronto” sempre disponível para o cliente usar
Scrum - Time
● Product Owner (CLIENTE – Interno ou Externo)
● Responsável por Maximizar o valor do produto● Responsável por Maximizar a produtividade do time● Ordenar os itens do Backlog, garantindo o valor do
trabalho – planejamento de Sprints e Releases● Garantir que a Equipe de Desenvolvimento entenda
os itens de Backlog no nível necessário● Traz informações e expectativas do cliente ao time● Deve estar integrado a equipe (história do táxi).
Scrum - Time
● Team (EQUIPE)
● Profissionais responsáveis por entregar uma versão usável que potencialmente incrementa o produto
● Existe somente o Desenvolvedor – nenhum outro título é atribuído
● Auto-gerido e auto-organizado (experiência)● Multi-funcional ( programador, testador, arquiteto, etc).
As responsabilidades são sempre do time todo● Devem ter de 3 a 9. Equipes menores não vão
conseguir entregar um incremento e maiores será difícil de coordenar
Scrum - Papéis
● Scrum Master
● Ensinar Scrum aos outros envolvidos● Manter o método nos “trilhos”● Respeitar 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 - Papéis
● Scrum Master
● Apoia o PO no gerenciamento do Backlog● Comunicação do Backlog(visão e objetivo) ao Time● Treina a equipe de desenvolvimento – auto-
gerenciamento e interdisciplinaridade● Remover impedimentos para o progresso da equipe● Facilitação das atividades do Scrum● Planejamento, liderança e organização da
Implantação do Scrum
Scrum - Papéis
● Scrum Master x Gerente de Projetos
● Autoridade indireta, baseada no conhecimento do SM sobre Scrum
● Papel de facilitador: ajuda o PO a selecionar os itens do backlog de maior valor, ajuda o TIME a transformar o backlog em funcionalidade
Scrum - Artefatos
● Product backlog
● Requisitos do sistema ou produto sendo desenvolvido
● O PO é responsável pelo conteúdo, priorização e disponibilidade do backlog
● Evolui a medida que o produto e o ambiente de aplicação evoluem
● Dinâmico visando que o produto seja útil e competitivo
Scrum - Artefatos
● Sprint backlog
● Derivado a partir do product backlog● Detalha os itens do product backlog em tarefas para
que se possa criar um incremento ao produto● Só o time pode alterar o Sprint Backlog● Alta visibilidade. Acompanhamento diário da evolução
do status de cada tarefa
Scrum - Artefatos
● Burndown Chart – quanto mais VERTICAL, melhor
● Acima da linha significa atraso
Scrum - Artefatos
● Incremento de funcionalidade de produto potencialmente 'entregável'
● Esse incremento deve ser levantado em cada sprint● CLIENTE 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 - Regras
● Sprint
● Período de no máximo 30 dias – time-boxed● Grande o suficiente para o time construir algo de valor
significante para o cliente● Pequeno o suficiente para o cliente não perde o
interesse no progresso● Pequeno o suficiente para não ser necessário incluir
documentações para o processo
Scrum - Regras
● Sprint – 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 - Regras
● Sprint Planning Meeting – parte inicial – 4 horas
● 4 horas definindo itens mais importantes e empacotáveis do backlog de produto
● Todos os papéis participam● Backlog deve ser preparado antes pelo Product
Owner(de preferência) ou Scrum Master(pior)
● Sprint Planning Meeting – parte final – 4 horas
● Scrum Master responde perguntas da EQUIPE nas 4 horas finais para detalhamento de tarefas
● Ao final, tem-se o Sprint Backlog
Scrum - Regras
● Daily Scrum Meeting
● 15 minutos independente do número de membros● Muita rigidez com presença e pontualidade● Trê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● Participação de todos, seja por telefone ou skype
Scrum - Regras
● Sprint Review Meeting
● 4 horas● Apresentar funcionalidades ao Cliente e stakeholders● Artefatos 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 ouvidos● Ao final, o próximo Sprint Review Meeting é agendado
Scrum - Regras
● Sprint Retrospective Meeting
● 3 horas● SM, 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 respostas● TM prioriza a ordem de melhoras em potencial para
discutir
Scrum
● Definição de “Pronto”
● Status final de um item do backlog ou um incremento● Pode variar entre diferentes times de Scrum● Entendimento compartilhado do que significa o
trabalho estar completo● A definição orienta os times no planejamento.
Quantas coisas “prontas” cabem em uma iteração?● Com o ganho de maturidade, os times incrementam a
definição de “pronto” com critérios de qualidade
Scrum
● Exemplo de História de Usuário Pronta
● Descrição obedece a: O que? Quem? Por que?● Todos os campos das interfaces descritos e todos os
comandos da interface detalhados● Diagramas de caso de uso e interação elaborados
● Exemplo de funcionalidade / incremento pronto
● Implementado● Casos de testes automatizados e bem sucedidos● Manual de Instalação● Manual de Usuário incrementado com o feature liberado
Scrum
● Envolvimento x Comprometimento
● História do empreendimento de um porco e uma galinha.
45
EXtreme Programming - XP
● “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.
46
XP
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.
47
XP
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.
48
XP● 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.
49
XP
● 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
50
XP
● Valores :: Simplicidade
● Posicione-se: onde está e para onde quer ir?● Qual é o jeito mais simples(barato, legal) de se
mover?
● Valores :: 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
51
XP● 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.
● Valores :: Respeito
● Comprometimento. Senso de responsabilidade
● (Edição de 2004 do Embrance Change)
● Respeite o seu time, respeite o que outros fazem
● Respeite o projeto, cuide dele
52
XP
● Prática :: 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.
53
XP
● Prática :: 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.
54
XP
● Práticas :: Planning Game – Jogo do Planejamento
55
XP
● Prática :: 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?)
56
XP● Prática :: 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.
57
XP
● Prática :: 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.
58
XP● Prática :: 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.
59
XP
● Prática :: 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
60
XP
● Prática :: Coding Standards – Código padronizado
● Já que todo mundo pode mexer...● Agilidade na refatoração● Facilidade de Leitura
● Exemplo:
– http://pear.php.net/manual/en/standards.php
61
XP
● Prática :: 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.
62
XP
● Prática :: 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
63
XP
● Prática :: 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”
64
XP
● Prática :: 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.
65
XP
● Prática :: 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ínuos (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
66
XP – Desafios para Implantação
● 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
67
XP – Desafios para Implantação
● 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
68
XP – Desafios para Implantação
● 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
69
XP – Desafios para Implantação
● 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.
70
XP – Desafios para Implantação
● Utilizar XP não vai mudar seus problemas
● Atitudes do cliente● Prazos mal negociados● Orçamentos.
● Mas pode 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
71
XP – Desafios para Implantação
● 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.
72
XP – Desafios para Implantação
● 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
73
XP – Desafios para Implantação
● 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.
74
XP – Estudos 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 testar suspeitas.
75
XP – Estudos 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
76
XP – Estudos 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
77
XP – Estudos 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
78
XP – Estudos de Caso
79
XP – Estudos de Caso
80
XP – Estudos de Caso
81
XP – Estudos 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]
82
XP – Estudos 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%
83
XP tem documentação, SIM SENHORES!
Mas só o suficiente!
XP - Documentação
84
XP - Documentação
● 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.
85
XP - Documentação
● 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)
86
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
XP - Documentação
87
XP - Escalabilidade● 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”.
88
XP - 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?
89
BibliografiaManhaes 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.