Desenvolvimento ágil                       de Software●   Motivação●   Manifesto Ágil e Conceitos●   SCRUM●   Extreme Prog...
Motivação Interna –                     “Dor”http://www.youtube.com/watch?v=1lqxORnQARw
Motivação Interna -                           Chaos Report●   Projetos de Pontes           ●   Projetos de Software    ●  ...
Motivação Interna -                      Chaos Report                  Aspectos críticos●   Projetos de ponte são engessad...
Motivação Interna -                        Chaos ReportProjetos queterminam               31%                     Termina ...
Motivação Interna -                Chaos ReportRequisitos presentesao final        42%                  Sim               ...
Motivação do                              Mercado●   RAD – Rapid Application Development – anos 90.    ●   Métodos iterati...
Motivação do                           Mercado●   Necessidade de atendimento a modelos de    maturidade – CMMI, MPS.BR●   ...
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!!!...
E aí!?●   Desenvolvimento ágil não garante necessariamente    que o projeto terá mais ou menos sucesso :-(●   Mas ajuda!!!...
Manifesto Ágil●   Encontro de 17 agilistas – Utah – Fevereiro – 2001●   Kent Beck – XP (Extreme Programming)●   Ken Schwab...
Manifesto Ágil●   Individuals and interactions over processes and    tools    ●   Uma descrição mínima de processo é neces...
Manifesto Ágil●   Working software over comprehensive    documentation    ●   Software bem organizado e documentado    ●  ...
Manifesto Ágil●   Customer collaboration over contract negotiation    ●   Cliente deve estar infiltrado na equipe de      ...
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...
Scrum●   O nome vem do rugby. Reinício da partida.●   Baseado na teoria de controle de processo industrial    ●   Auto-org...
Scrum●   Empirismo    ●   Conhecimento a partir da experiência e tomada de        decisões●   Pilares    ●   Transparência...
Scrum●   Pilares    ●   Inspeção        –   Artefatos e progresso são inspecionados sempre        –   Não pode atrapalhar ...
Scrum●   Pilares    ●   Adaptação        –   Ocorre quando qualquer aspecto sai dos limites            aceitáveis        –...
Scrum●   Ajuda a controlar projetos de desenvolvimento de    software●   Não garante sucesso completo do projeto●   Garant...
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●   Entre...
Scrum - Time●   Times auto-organizáveis e multifuncionais    ●   Escolhem a melhor forma para completar o trabalho    ●   ...
Scrum - Time●   Product Owner (CLIENTE – Interno ou Externo)    ●   Responsável por Maximizar o valor do produto    ●   Re...
Scrum - Time●   Team (EQUIPE)    ●   Profissionais responsáveis por entregar uma versão        usável que potencialmente i...
Scrum - Papéis●   Scrum Master    ●   Ensinar Scrum aos outros envolvidos    ●   Manter o método nos “trilhos”    ●   Resp...
Scrum - Papéis●   Scrum Master    ●   Apoia o PO no gerenciamento do Backlog    ●   Comunicação do Backlog(visão e objetiv...
Scrum - Papéis●   Scrum Master x Gerente de Projetos    ●   Autoridade indireta, baseada no conhecimento do SM        sobr...
Scrum - Artefatos●   Product backlog    ●   Requisitos do sistema ou produto sendo        desenvolvido    ●   O PO é respo...
Scrum - Artefatos●   Sprint backlog    ●   Derivado a partir do product backlog    ●   Detalha os itens do product backlog...
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 ...
Scrum - Regras●   Sprint    ●   Período de no máximo 30 dias – time-boxed    ●   Grande o suficiente para o time construir...
Scrum - Regras●   Sprint – duração sugerida: 30 dias    ●   Itens de Backlog de sprint CONGELADOS durante a        execuçã...
Scrum - Regras●   Sprint Planning Meeting – parte inicial – 4 horas    ●   4 horas definindo itens mais importantes e     ...
Scrum - Regras●   Daily Scrum Meeting    ●   15 minutos independente do número de membros    ●   Muita rigidez com presenç...
Scrum - Regras●   Sprint Review Meeting    ●   4 horas    ●   Apresentar funcionalidades ao Cliente e stakeholders    ●   ...
Scrum - Regras●   Sprint Retrospective Meeting    ●   3 horas    ●   SM, TM e PO (opcional)    ●   Perguntas ao TM        ...
Scrum●   Definição de “Pronto”    ●   Status final de um item do backlog ou um incremento    ●   Pode variar entre diferen...
Scrum●   Exemplo de História de Usuário Pronta    ●   Descrição obedece a: O que? Quem? Por que?    ●   Todos os campos da...
Scrum●   Envolvimento x Comprometimento    ●   História do empreendimento de um porco e uma        galinha.
EXtreme                          Programming - XP●   “Jeito leve, eficiente, de baixo risco, flexível, previsível,    cien...
XP        Define um conjunto de valores, práticas erecomendações que se seguidos em conjunto levarão aodesenvolvimento de ...
XP Premissa compartilhada com outros métodos Ágeis       O cliente deve estar integrado a equipe dedesenvolvimento e apren...
XP●   XP não é:    ●   Um software ou ferramenta de gestão de projetos    ●   Um processo de desenvolvimento de software –...
XP●   Valores :: Comunicação    ●   Alguém no time saberá a solução para seu problema.        Mas você precisa avisar!    ...
XP●   Valores :: Simplicidade    ●   Posicione-se: onde está e para onde quer ir?    ●   Qual é o jeito mais simples(barat...
XP●   Valores :: Coragem    ●   Você não precisa ser um bombeiro ou policial para ser        corajoso    ●   Coragem não é...
XP●   Prática :: Planning Game – Jogo do    Planejamento    ●   Técnicas de planejamento para manter o foco no que        ...
XP●   Prática :: Planning Game – Jogo do    Planejamento    ●   No JP, o cliente é responsável por definir quais são      ...
XP●   Práticas :: Planning Game – Jogo do    Planejamento                                          54
XP●   Prática :: Standup Meeting – Reunião em pé    ●   Reunião diária para acompanhamento das tarefas.        Ela deve se...
XP●   Prática :: Pair Programming – Programação em    Pares    ●   Dois desenvolvedores compartilhando uma estação.    ●  ...
XP●   Prática :: Test Driven Development –    Desenvolvimento Dirigido por Testes    ●   XP e outros métodos ágeis tem foc...
XP●   Prática :: Refactoring – Refatoração    ●   Modificações contínuas no código-fonte sem alterar a        funcionalida...
XP●   Prática :: Shared Code – Código    Compartilhado/Coletivo    ●   Não existe segmentação de partes do sistema entre  ...
XP●   Prática :: Coding Standards – Código    padronizado    ●   Já que todo mundo pode mexer...    ●   Agilidade na refat...
XP●   Prática :: Simple Design – Design(Desenho)    Simples    ●   Faça hoje o que você precisa para hoje.    ●   Motivaçã...
XP●   Prática :: Metaphor – Metáfora do Produto    ●   Relacionar o desenvolvimento do produto com        abstrações do co...
XP●   Prática :: 40-hour week – 40h semanais / Ritmo    Sustentável    ●   XP depende de pessoas praticarem XP    ●   Toda...
XP●   Prática :: Continuos Integration – Integração    Contínua    ●   Os pares integram seus códigos ao sistema todo     ...
XP●   Prática :: Short Releases – Releases Curtos    ●   O principal objetivo desta prática é fazer com que o        clien...
XP – Desafios para                          Implantação●   Conflitos de Processo de Desenvolvimento    ●   Mesclar agilida...
XP – Desafios para                           Implantação●   Conflitos de Processo de Desenvolvimento    ●   Sistemas Legad...
XP – Desafios para                         Implantação●   Conflitos de Processo de Negócio    ●   Recursos Humanos: Traz d...
XP – Desafios para                          Implantação●   Conflitos de Pessoas    ●   Atitudes: Processos evolutivos muit...
XP – Desafios para                           Implantação●   Utilizar XP não vai mudar seus problemas    ●   Atitudes do cl...
XP – Desafios para                          Implantação●   Mude e em seguida provoque a mudança    ●   Aprenda TDD, depois...
XP – Desafios para                          Implantação●   Escolha um coach    ●   Pessoa com experiência em XP → Mais fác...
XP – Desafios para                          Implantação●   Quando não adotar XP    ●   Escute os valores → Se os valores d...
XP – Estudos de Caso●   Considerações importantes sobre estudos de casos:    ●   Um caso de estudo não é um experimento fo...
XP – Estudos de Caso●   Sabre Airline Solutions → Resultados apontam    aumento de produtividade e qualidade.    ●   Empre...
XP – Estudos de Caso●   Sabre Airlines Solutions → Resultados apontam    aumento de produtividade e qualidade.    ●   Dese...
XP – Estudos de Caso●   Hipóteses:    ●   Qualidade do pré-release → defeitos detectados        antes de liberar o softwar...
XP – Estudos de Caso                78
XP – Estudos de Caso                79
XP – Estudos de Caso                80
XP – Estudos de Caso●   Outros Estudos de Casos:    ●   NASA testou XP para validá-lo para projetos de        missão críti...
XP – Estudos de Caso●   Outros Estudos de Casos:    ●   Williams et. al. [2004] fez uma aplicação do        framework na I...
XP - DocumentaçãoXP tem documentação, SIM SENHORES!        Mas só o suficiente!                                     83
XP - Documentação●   Documentações, testes de unidade e aceitação dão    suporte ao código gerado (principal entrega).●   ...
XP - Documentação●   Visão tradicional → custo de alterar o software    cresce exponencialmente ao longo do ciclo de vida....
XP - DocumentaçãoExemplos de documentos:Histórias - Testes de Aceitação - Testes de Unidade -      Documentação de APIs - ...
XP - Escalabilidade●   Número de pessoas → divida o problema em vários times    pequenos e trate a integração●   Relação c...
XP - Debate●   Como é a cultura da sua organização?●   Você consegue identificar um primeiro projeto para    utilizar XP?●...
Bibliografia Manhaes Teles, Vinicius. Um estudo de caso da adoção das práticas e valores do ExtremeProgramming. 2005. 180 ...
Upcoming SlideShare
Loading in …5
×

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

2,645 views

Published on

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.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,645
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
89
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

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

  1. 1. Desenvolvimento ágil de Software● Motivação● Manifesto Ágil e Conceitos● SCRUM● Extreme Programming (XP)
  2. 2. Motivação Interna – “Dor”http://www.youtube.com/watch?v=1lqxORnQARw
  3. 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. 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. 5. Motivação Interna - Chaos ReportProjetos queterminam 31% Termina m 16% Prazo e Orçamento Não terminam OK69% Sim Não 84%
  6. 6. Motivação Interna - Chaos ReportRequisitos presentesao final 42% Sim Não 58%
  7. 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. 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. 9. E aí!?
  10. 10. E aí!?● Desenvolvimento ágil não garante necessariamente que o projeto terá mais ou menos sucesso :-(
  11. 11. E aí!?● Desenvolvimento ágil não garante necessariamente que o projeto terá mais ou menos sucesso :-(● Mas ajuda!!! Como?
  12. 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. 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. 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. 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. 16. Manifesto Ágil● Customer collaboration over contract negotiation ● Cliente deve estar infiltrado na equipe de desenvolvimento.
  17. 17. Manifesto Ágil● Responding to change over following a plan
  18. 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. 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. 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. 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. 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. 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. 24. Scrum – Visão Geral
  25. 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. 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. 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. 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. 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. 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. 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. 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. 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. 34. Scrum - Artefatos● Burndown Chart – quanto mais VERTICAL, melhor● Acima da linha significa atraso
  35. 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. 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. 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. 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. 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. 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. 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. 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. 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. 44. Scrum● Envolvimento x Comprometimento ● História do empreendimento de um porco e uma galinha.
  45. 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. 46. XP Define um conjunto de valores, práticas erecomendações que se seguidos em conjunto levarão aodesenvolvimento 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. 47. XP Premissa compartilhada com outros métodos Ágeis O cliente deve estar integrado a equipe dedesenvolvimento e aprenderá sobre suas necessidades amedida em que puder manipular versões intermediárias durante o desenvolvimento. 47
  48. 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. 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. 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. 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. 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. 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. 54. XP● Práticas :: Planning Game – Jogo do Planejamento 54
  55. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 78. XP – Estudos de Caso 78
  79. 79. XP – Estudos de Caso 79
  80. 80. XP – Estudos de Caso 80
  81. 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. 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. 83. XP - DocumentaçãoXP tem documentação, SIM SENHORES! Mas só o suficiente! 83
  84. 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. 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. 86. XP - DocumentaçãoExemplos 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. 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. 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. 89. Bibliografia Manhaes Teles, Vinicius. Um estudo de caso da adoção das práticas e valores do ExtremeProgramming. 2005. 180 f. Dissertação (Mestrado em Informática) - Universidade Federal do Rio deJaneiro, Rio de Janeiro. 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.129 Lucas 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 29thEUROMICRO Conference. Belek, Turkey: IEEE, 2003. D. J. Reifer, "How to Get the Most out of Extreme Programming/Agile Methods," in 2nd XP and 1stAgile 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 ExtremeProgramming," presented at Proceedings of the Eighth International Conference on EmpiricalAssessment in Software Engineering (EASE 04), 2004, in press. 89

×