Este documento fornece um resumo de três métodos ágeis de desenvolvimento de software: Scrum, Extreme Programming (XP) e seus principais conceitos e práticas. O Scrum é focado na gestão de projetos através de sprints curtos, reuniões diárias e feedback contínuo do cliente. O XP enfatiza valores como comunicação, simplicidade e coragem e práticas como programação em pares e desenvolvimento guiado por testes.

1. Desenvolvimento ágil de
Software
Motivação
Manifesto Ágil e Conceitos
SCRUM
Extreme Programming (XP)

2. Motivação Interna –
“Dor”
http://www.youtube.com/watch?
v=1lqxORnQARw

3. Motivação Interna -
Chaos Report
Projetos de Projetos de
Pontes Software
 Prazo – OK ( menos no  Prazo – estoura
Brasil )  Orçamento – estoura
 Orçamento – OK  Têm problemas com
 Quase nenhuma cai freqüência
 Ciência Antiga – 4 a 6  Ciência nova – 50
mil anos anos

4. 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

5. Motivação Interna -
Chaos Report
Projetos que
terminam
31%
Termina
m
16% Prazo e Orçamento
Não
terminam OK
69%
Sim
Não
84%

6. Motivação Interna -
Chaos Report
Requisitos presentes
ao final
42% Sim
Não
58%

7. 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
Necessidade de atendimento a modelos de
maturidade – CMMI, MPS.BR
Alternativas à época com baixa tolerância a
mudanças de requisitos

8. E aí!?

9. E aí!?
Desenvolvimento ágil não garante
necessariamente que o projeto terá mais ou
menos sucesso :-(

10. E aí!?
Desenvolvimento ágil não garante
necessariamente que o projeto terá mais ou
menos sucesso :-(
Mas ajuda!!! Como?

11. 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
:-))

12. Manifesto Ágil
Encontro de 17 agilistas – Utah – Fevereiro –
2001
Kent Beck – XP (Extreme Programming)
Ken Schwaber – SCRUM
Alistair Cockburn – Crystal – Metodologia sob
demanda
Chegaram a conclusões:
www.agilemanifesto.org

13. 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

14. 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.

15. Manifesto Ágil
Customer collaboration over contract
negotiation
Cliente deve estar 'infiltrado' na equipe de
desenvolvimento.

16. Manifesto Ágil
Responding to change over following a plan

17. 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
software e gestão de projeto de software

18. 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

19. 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

20. 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.

21. SCRUM - Papéis
Product Owner (CLIENTE)
Lista de requisitos (product backlog)
Objetivos de ROI
Planejamento de Releases (priorizar)
Team (EQUIPE)
Desenvolvimento de funcionalidades
Auto-gerido e auto-organizado (experiência)
Multi-funcional ( programador, testador,
arquiteto, etc)

22. SCRUM - Papéis
ScrumMaster
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

23. SCRUM – Visão Geral

24. SCRUM - Artefatos
Product backlog
Sempre evolui
Sprint backlog
Derivado a partir do product backlog
Detalha os itens do product backlog em tarefas

25. SCRUM - Artefatos
Burndown Chart – quanto mais horizontal,
melhor

26. SCRUM - Artefatos
Incremento de funcionalidade de produto
potencialmente 'empacotá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

27. 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 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

28. 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

29. 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.

30. 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

31. 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

32. Gostaram do SCRUM?
Falamos de Gestão de Projeto
Agora 'tá' na hora de práticas de
desenvolvimento
Vamos falar de XP

33. :.: ÍNDICE
1.1 Motivação
1.2 Muito Prazer, eu sou XP
33

34. :.: 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 )
34

35. :.: 1.1 - Motivação
Relatório do Caos – Chaos Report
35

36. :.: 1.2 – Muito Prazer, Eu sou 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.
36

37. :.: 1.2 – Muito Prazer, Eu sou 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.
37

38. :.: 1.2 – Muito Prazer, Eu sou 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.
38

39. :.: 1.2 – Muito Prazer, Eu sou 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.
39

40. Metodologias Ágeis: Extreme
Programming
2 – Elementos de Extreme
Programming.
Professor: Joaquim Lopes Júnior
(joaquimlopesjr@gmail.com)
40

41. :.: ÍNDICE
2.1 Valores
2.2 Práticas
41

42. :.: 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
42

43. :.: 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
43

44. :.: 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
44

45. :.: 2.2 - Práticas
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

46. :.: 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

47. :.: 2.2 - Práticas
Planning Game – Jogo do Planejamento
47

48. :.: 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

49. :.: 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.
49

50. :.: 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.
50

51. :.: 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.
51

52. :.: 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
52

53. :.: 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
53

54. :.: 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.
54

55. :.: 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
55

56. :.: 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...
56

57. :.: 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.
57

58. :.: 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
58

59. :.: 2.2 – Práticas
Frequência de Utilização das Práticas
l
Entendimento em 4 ciclos
http://blogs.msdn.com/b/jmeier/archive/2010/04/04/the-
four-circles-of-xp-extreme-programming.aspx
59

60. Metodologias Ágeis: Extreme
Programming
3 – Implantação de XP nas
Organizações
Professor: Joaquim Lopes Júnior
(joaquimlopesjr@gmail.com)
60

61. :.: ÍNDICE
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
61

62. :.: 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
62

63. :.: 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
63

64. :.: 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
64

65. :.: 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.
65

66. :.: 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
66

67. :.: 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.
67

68. :.: 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
68

69. :.: 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.
69

70. :.: 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.
70

71. :.: 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
71

72. :.: 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
72

73. :.: 3.3 – Estudo de Caso
73

74. :.: 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
74

75. :.: 3.3 – Estudo de Caso
75

76. :.: 3.3 – Estudo de Caso
76

77. :.: 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]
77

78. :.: 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%
78

79. :.: 3.4 – Documentação em XP
XP tem documentação, SIM SENHORES!
Mas só o suficiente!
79

80. :.: 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.
80

81. :.: 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)
81

82. :.: 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
82

83. :.: 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”.
83

84. :.: 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?
84

85. :.: 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.
85