Métodos Ágeis - Manifesto Ágil, Scrum e XP

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


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


69%

31%

TerminamNão terminam

16%

84%

SimNão

Projetos que terminam

Prazo e Orçamento OK


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


● 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


● 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


● 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


● 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


● 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


● 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


● 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


● 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


● 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


79


80


81


● 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


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

Technology

Métodos Ágeis - Manifesto Ágil, Scrum e XP