Slides da disciplina de metodologias ágeis da pós em Governança em TI do UNIBH. Tratam de métodos ágeis, abordando os seguintes tópicos: Manifesto Ágil, Valores ágeis, Scrum, XP, Estudos de Caso.

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 Pontes ● Projetos de 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 anos
mil 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

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

9. E aí!?

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

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

12. 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
● :-))

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

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

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

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

17. Manifesto Ágil
● Responding to change over following a plan

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

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

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

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

22. 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 )

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

24. Scrum – Visão Geral

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

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

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

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

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

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

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

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

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

34. Scrum - Artefatos
●
Burndown Chart – quanto mais VERTICAL, melhor
● Acima da linha significa atraso

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

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

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

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

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

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

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

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

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

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

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

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

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

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
49

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
50

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
51

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

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

54. XP
● Práticas :: Planning Game – Jogo do
Planejamento
54

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?)
55

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

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

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

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
59

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
60

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

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
62

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”
63

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

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
65

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
66

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
67

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
68

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

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
70

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

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
72

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

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

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
75

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
76

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
77

78. XP – Estudos de Caso
78

79. XP – Estudos de Caso
79

80. XP – Estudos de Caso
80

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]
81

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%
82

83. XP - Documentação
XP tem documentação, SIM SENHORES!
Mas só o suficiente!
83

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

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)
85

86. XP - Documentação
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
86

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”.
87

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?
88

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