Aula03 04 agile_scrum_xp
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Aula03 04 agile_scrum_xp

  • 847 views
Uploaded on

Conceitos Gerais sobre métodos ágeis e introdução os métodos Scrum E XP.

Conceitos Gerais sobre métodos ágeis e introdução os métodos Scrum E XP.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
847
On Slideshare
846
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
18
Comments
0
Likes
0

Embeds 1

https://www.linkedin.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Desenvolvimento ágil deSoftware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 ReportProjetos queterminam 31% Termina m 16% Prazo e Orçamento Não terminam OK69% 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çãoProgramadores estão Sofrendo ao Redor do MundoVersã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çãoRelató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 desenvolversoftware” - Kent BeckRecomendado 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 XPDefine um conjunto de valores, práticas erecomendações que se seguidos em conjuntolevarão ao desenvolvimento de um produtocom alta qualidade e o menor custopossível, além de valorizar as pessoasenvolvidas nas atividades de construção doproduto. 37
  • 38. :.: 1.2 – Muito Prazer, Eu sou XPPremissa compartilhada com outrosmétodos ÁgeisO cliente deve estar integrado a equipe dedesenvolvimento e aprenderá sobre suasnecessidades a medida em que puder manipularversões intermediárias durante odesenvolvimento. 38
  • 39. :.: 1.2 – Muito Prazer, Eu sou XPXP não é:Um software ou ferramenta de gestão deprojetosUm 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 - ValoresComunicaçãoAlgué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 - ValoresSimplicidadePosicione-se: onde está e para onde quer ir?Qual é o jeito mais simples(barato, legal) de se mover?FeedbackTimes XP se esforçam para dar o máximo de feedback eo mais rápido possívelOpinem sobre ideias, sobre a qualidade do código-fonte,diga se os testes foram fáceis de implementar e seexecutaram sem problemas 43
  • 44. :.: 2.1 - ValoresCoragemVocê não precisa ser um bombeiro ou policial para sercorajosoCoragem não é inconsequência – seja equilibradoTenha coragem para jogar uma parte do sistema fora. Oupara escrever pouca documentação.Respeito (Edição de 2004 do Embrance Change).Respeite o seu time, respeite o que outros fazemRespeite o projeto, cuide dele 44
  • 45. :.: 2.2 - PráticasPlanning Game – Jogo do PlanejamentoTé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áticasPlanning Game – Jogo do PlanejamentoNo JP, o cliente é responsável por definir quais são asfuncionalidades – histórias – a serem entregues nopróximo release – prioriza o que tem maior valor.Histórias de Usuário são as funcionalidades descritasem cartões – post-its. Responsabilidade do usuário.Tempo para desenvolvimento da História medido empontos. 46
  • 47. :.: 2.2 - PráticasPlanning Game – Jogo do Planejamento 47
  • 48. :.: 2.2 - PráticasStandup Meeting – Reunião em péReunião diária para acompanhamento das tarefas. Eladeve ser rápida e objetiva (por isso a turma não podesentar)No Scrum, sugere-se para o Daily Meeting:15 minutos | O que você fez de ontem para hoje? | O quevocê fará até amanhã? | Quais dificuldades têmenfrentado? (Qual valor do XP?) 48
  • 49. :.: 2.2 - PráticasPair Programming – Programação em ParesDois 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áticasTest Driven Development – Desenvolvimento Dirigidopor TestesXP e outros métodos ágeis tem foco em alta qualidade.Antes de se programar uma funcionalidade, programa-seum teste para ela. A funcionalidade tem que passar noteste.Dessa forma aprimora-se a análise (há mais tempo paraentender o que é necessário) e investe-se mais tempo nodesenho do software – Interfaces. Menor retrabalho. 50
  • 51. :.: 2.2 - PráticasRefactoring – RefatoraçãoModificações contínuas no código-fonte sem alterar afuncionalidade implementada.Deixar o código mais simples, com melhor desempenho,mais modularizado, mais fácil de se integrar a outrosmódulos.Os testes (Test Driven Development) ajudam a garantirque nada para de funcionar após uma mudança. 51
  • 52. :.: 2.2 - PráticasShared Code – Código Compartilhado/ColetivoNão existe segmentação de partes do sistema entre osdesenvolvedores. Todos podem acessar qualquer partedo código fonte, sem pedir autorização.Aumento de Qualidade – Verificação e revisão de códigoA qualquer momento um programador (ou um par) poderefatorar um código que achar que pode ser melhorado 52
  • 53. :.: 2.2 - PráticasCoding Standards – Código padronizado Já que todo mundo pode mexer, “né” ?Agilidade na refatoraçãoFacilidade de LeituraExemplo:http://pear.php.net/manual/en/standards.php 53
  • 54. :.: 2.2 - PráticasSimple Design – Design(Desenho) Simples Faça hoje o que você precisa para hoje.Motivação: feedback rápido, entrega de funcionalidadesde valor para o cliente.Assume-se que será possível refatorar o código aqualquer momento para comportar novas funcionalidades.Talvez a prática mais criticada pelos tradicionalistas. 54
  • 55. :.: 2.2 - PráticasMetaphor – Metáfora do ProdutoRelacionar o desenvolvimento do produto com abstraçõesdo cotidiano.Importante estar com a mente “oxigenada”.Crie metáforas para as funcionalidades como se nãoexistissem computadores. E talvez esta seja a mais difícil de explicar 55
  • 56. :.: 2.2 - Práticas40-hour week – 40h semanais / Ritmo SustentávelXP depende de pessoas praticarem XPToda a qualidade do produto e dos elementos utilizadospara desenvolvê-lo depende da qualidade das pessoasEvitar horas extras.Cuidado com os FREELAS... 56
  • 57. :.: 2.2 - PráticasContinuos Integration – Integração ContínuaOs pares integram seus códigos ao sistema todo várias vezesao dia.O processo de integração consiste em adicionar o incrementodo software e testar todo o sistema.Dessa forma a integração não acrescenta erros ao sistemaFerramentas: CruiseControl, Jenkins, Hudson, Bamboo,BuildMaster, Teamcity, etc.Desenho de ambiente. 57
  • 58. :.: 2.2 - PráticasShort Releases – Releases CurtosO principal objetivo desta prática é fazer com que o clientetenha acesso ao valor do produto o mais cedo possível.E esses incrementos de valor devem ser contínos (ex.: acada 2 meses uma nova versão)Favorece o feedback por parte do cliente de formaprecoce. Diminui atrasos em entregas, aumentaassertividade, e aumenta a taxa de aproveitamento doproduto 58
  • 59. :.: 2.2 – PráticasFrequência de Utilização das PráticaslEntendimento em 4 cicloshttp://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 GerenciaisConflitos de Processo de DesenvolvimentoMesclar 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 GerenciaisConflitos de Processo de DesenvolvimentoSistemas 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 GerenciaisConflitos de Processo de NegócioRecursos 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 GerenciaisConflitos de PessoasAtitudes: 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 XPUtilizar 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 testeEncontre um patrocinador executivo de peso 66
  • 67. :.: 3.2 – Adoção de XPMude e em seguida provoque a mudançaAprenda TDD, depois ensine a toda equipeSua 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 XPEscolha um coachPessoa com experiência em XP → Mais fácil aprender com o erro alheioNormalmente trabalha em equipe mas tem suas próprias atividades → é quem lidera tentativas de melhoriasUm evangelizador → Mantém todo mundo praticando XP 68
  • 69. :.: 3.2 – Adoção de XPQuando não adotar XPEscute os valores → Se os valores da organização não forem alinhados não vai dar certo.Sistemas de Premiação IndividuaisContratos de Escopo Fechado → Dificultam mudanças e utilização otimizada do XP. Catequize o cliente. 69
  • 70. :.: 3.3 – Estudo de CasoConsiderações importantes sobre estudos de casos:Um caso de estudo não é um experimento formal, mais focado e com base em variáveis de contextoTesta-se teorias (hipóteses) em uma configuraçãoCada 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 CasoSabre Airline Solutions → Resultados apontam aumento de produtividade e qualidade.Empresa que desenvolve software para cias. AéreasEquipe 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 CasoSabre 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 XPA 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 CasoHipóteses:Qualidade do pré-release → defeitos detectados antes de liberar o softwareQualidade do pós-release → defeitos após release detectados pelos usuáriosProdutividade dos programadores → medidas qdt de histórias e linhas de código por programador-mêsSatisfação do cliente → Medido por entrevistas e feedbackSatisfaçã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 CasoOutros 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 CasoOutros 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 XPXP tem documentação, SIM SENHORES! Mas só o suficiente! 79
  • 80. :.: 3.4 – Documentação em XPDocumentaçõ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çãoRefatoraçã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 XPVisã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 atualizadosE ainda há uma grande dificuldade de se manter toda documentação tradicional atualizada e coerente (rastreabilidade) 81
  • 82. :.: 3.4 – Documentação em XPExemplos 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 XPNúmero de pessoas → divida o problema em vários times pequenos e trate a integraçãoRelaçã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 outroMissão Crítica → Adicione auditorias. Não só no final. Faça um “Continuous Auditing”. 83
  • 84. :.: 3.6 – DebateComo é 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. :.: 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 deJaneiro. 2005.Beck, K. & Andres, C. (2004). Extreme Programming Explained: Embrace Change. Addison Wesley, 2a edição. ISBN 0-321-27865-8Boehm, 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.129Lucas Layman, Laurie Williams , Lynn Cunningham, Exploring Extreme Programming in Context: AnIndustrial Case Study, Proceedings of the Agile Development Conference (ADC04), p.32-41, June 22-26,2004W. 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 EUROMICROConference. Belek, Turkey: IEEE, 2003.D. J. Reifer, "How to Get the Most out of Extreme Programming/Agile Methods," in 2nd XP and 1st AgileUniverse 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 ExtremeProgramming," presented at Proceedings of the Eighth International Conference on Empirical Assessment inSoftware Engineering (EASE 04), 2004, in press. 85