Desenvolvimento ágil deSoftwareMotivaçãoManifesto Ágil e ConceitosSCRUMExtreme Programming (XP)
Motivação Interna –“Dor”    http://www.youtube.com/watch?            v=1lqxORnQARw
Motivação Interna -Chaos ReportProjetos de                Projetos de Pontes                      Software  Prazo – OK ...
Motivação Interna -Chaos Report               Aspectos críticos  Projetos de ponte são engessados e ninguém dá   “pitaco”...
Motivação Interna -Chaos ReportProjetos queterminam               31%                     Termina                     m   ...
Motivação Interna -Chaos Report   Requisitos presentes   ao final           42%                  Sim                      ...
Motivação do MercadoRAD – Rapid Application Development – anos 90.  Métodos iterativos (ciclos) e evolucionários   (bott...
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?Aj...
Manifesto ÁgilEncontro de 17 agilistas – Utah – Fevereiro – 2001Kent Beck – XP (Extreme Programming)Ken Schwaber – SCRU...
Manifesto ÁgilIndividuals     and    interactions     over processes and tools  Uma     descrição mínima de processo    ...
Manifesto ÁgilWorking software over comprehensive documentation Software bem organizado e documentado Alguma      docum...
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 (ou meto...
SCRUMO nome vem do rugby. Reinício da partida.Baseado na teoria de controle de processo industrial  Auto-organização e ...
SCRUMAjuda a controlar projetos de desenvolvimento de softwareNão garante sucesso completo do projetoGarante que o trab...
SCRUM        Obtém-se do backlog o         que é de mais valor        Planeja-se a iteração        Faz-se acompanhametn...
SCRUM - PapéisProduct Owner (CLIENTE) Lista de requisitos (product backlog) Objetivos de ROI Planejamento de Releases ...
SCRUM - PapéisScrumMaster Ensinar Scrum aos outros envolvidos Manter o método nos trilhos Respeitar cultura da organiz...
SCRUM – Visão Geral
SCRUM - ArtefatosProduct backlog Sempre evoluiSprint backlog  Derivado a partir do product backlog  Detalha os itens ...
SCRUM - ArtefatosBurndown Chart – quanto mais horizontal, melhor
SCRUM - ArtefatosIncremento de funcionalidade de produto potencialmente empacotável  Esse incremento deve ser levantado ...
SCRUM - RegrasSprint Planning Meeting – parte inicial – 4 horas 4 horas definindo itens mais importantes e   empacotávei...
SCRUM - RegrasDaily Scrum Meeting 15 minutos independente do número de  membros Muita rigidez com presença e pontualida...
SCRUM - RegrasSprint – duração sugerida: 30 dias Itens de Backlog de sprint CONGELADOS durante a   execução do sprint A...
SCRUM - RegrasSprint Review Meeting 4 horas Apresentar funcionalidades ao Cliente e   stakeholders Artefatos não podem...
SCRUM - RegrasSprint Retrospective Meeting 3 horas SM, TM e PO (opcional) Perguntas ao TM    O que foi bom no último ...
Gostaram do SCRUM?Falamos de Gestão de ProjetoAgora tá na hora de práticas de desenvolvimentoVamos falar de XP
:.: ÍNDICE  1.1   Motivação  1.2   Muito Prazer, eu sou XP                                  33
:.: 1.1 - MotivaçãoProgramadores estão Sofrendo ao Redor do MundoVersão Original( http://www.youtube.com/watch?v=SE7gzecA4...
:.: 1.1 - MotivaçãoRelatório do Caos – Chaos Report                                   35
:.: 1.2 – Muito Prazer, Eu sou XP“Jeito leve, eficiente, de baixo risco, flexível,previsível, científico e divertido de de...
:.: 1.2 – Muito Prazer, Eu sou XPDefine um conjunto de valores, práticas erecomendações que se seguidos em conjuntolevarão...
:.: 1.2 – Muito Prazer, Eu sou XPPremissa compartilhada com outrosmétodos ÁgeisO cliente deve estar integrado a equipe ded...
:.: 1.2 – Muito Prazer, Eu sou XPXP não é:Um software ou ferramenta de gestão deprojetosUm processo de desenvolvimento de ...
Metodologias Ágeis: Extreme       Programming 2 – Elementos de Extreme       Programming.   Professor: Joaquim Lopes Júnio...
:.: ÍNDICE  2.1   Valores  2.2   Práticas                   41
:.: 2.1 - ValoresComunicaçãoAlguém no time saberá a solução para seu problema. Mas      você precisa avisar!Ao se deparar ...
:.: 2.1 - ValoresSimplicidadePosicione-se: onde está e para onde quer ir?Qual é o jeito mais simples(barato, legal) de se ...
:.: 2.1 - ValoresCoragemVocê não precisa ser um bombeiro ou policial para sercorajosoCoragem não é inconsequência – seja e...
:.: 2.2 - PráticasPlanning Game – Jogo do PlanejamentoTécnicas de planejamento para manter o foco no que émais importante ...
:.: 2.2 - PráticasPlanning Game – Jogo do PlanejamentoNo JP, o cliente é responsável por definir quais são asfuncionalidad...
:.: 2.2 - PráticasPlanning Game – Jogo do Planejamento                                       47
:.: 2.2 - PráticasStandup Meeting – Reunião em péReunião diária para acompanhamento das tarefas. Eladeve ser rápida e obje...
:.: 2.2 - PráticasPair Programming – Programação em ParesDois desenvolvedores compartilhando uma estação.Análise, Desenho,...
:.: 2.2 - PráticasTest Driven Development – Desenvolvimento Dirigidopor TestesXP e outros métodos ágeis tem foco em alta q...
:.: 2.2 - PráticasRefactoring – RefatoraçãoModificações contínuas no código-fonte sem alterar afuncionalidade implementada...
:.: 2.2 - PráticasShared Code – Código Compartilhado/ColetivoNão existe segmentação de partes do sistema entre osdesenvolv...
:.: 2.2 - PráticasCoding Standards – Código padronizado           Já que todo mundo pode mexer, “né” ?Agilidade na refator...
:.: 2.2 - PráticasSimple Design – Design(Desenho) Simples       Faça hoje o que você precisa para hoje.Motivação: feedback...
:.: 2.2 - PráticasMetaphor – Metáfora do ProdutoRelacionar o desenvolvimento do produto com abstraçõesdo cotidiano.Importa...
:.: 2.2 - Práticas40-hour week – 40h semanais / Ritmo SustentávelXP depende de pessoas praticarem XPToda a qualidade do pr...
:.: 2.2 - PráticasContinuos Integration – Integração ContínuaOs pares integram seus códigos ao sistema todo várias vezesao...
:.: 2.2 - PráticasShort Releases – Releases CurtosO principal objetivo desta prática é fazer com que o clientetenha acesso...
:.: 2.2 – PráticasFrequência de Utilização das PráticaslEntendimento em 4 cicloshttp://blogs.msdn.com/b/jmeier/archive/201...
Metodologias Ágeis: Extreme       Programming 3 – Implantação de XP nas       Organizações   Professor: Joaquim Lopes Júni...
:.: Í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...
:.: 3.1 – Desafios GerenciaisConflitos de Processo de DesenvolvimentoMesclar agilidade com processos tradicionais: ou se p...
:.: 3.1 – Desafios GerenciaisConflitos de Processo de DesenvolvimentoSistemas Legados: Difícil de refatorar.Requisitos: Hi...
:.: 3.1 – Desafios GerenciaisConflitos de Processo de NegócioRecursos Humanos: Traz desafios para gerir pessoas     que nã...
:.: 3.1 – Desafios GerenciaisConflitos de PessoasAtitudes: Processos evolutivos muito     formalizados      dificultam ati...
:.: 3.2 – Adoção de XPUtilizar XP não vai mudar seus problemas    –       Atitudes do cliente   –       Prazos mal negocia...
:.: 3.2 – Adoção de XPMude e em seguida provoque a mudançaAprenda TDD, depois ensine a toda equipeSua equipe aprende a est...
:.: 3.2 – Adoção de XPEscolha um coachPessoa com experiência em XP → Mais fácil aprender      com o erro alheioNormalmente...
:.: 3.2 – Adoção de XPQuando não adotar XPEscute os valores → Se os valores da organização não      forem alinhados não va...
:.: 3.3 – Estudo de CasoConsiderações importantes sobre estudos de casos:Um caso de estudo não é um experimento formal, ma...
:.: 3.3 – Estudo de CasoSabre Airline Solutions → Resultados apontam     aumento de produtividade e qualidade.Empresa que ...
:.: 3.3 – Estudo de CasoSabre Airlines Solutions → Resultados apontam     aumento de produtividade e qualidade.Desenvolver...
:.: 3.3 – Estudo de Caso                           73
:.: 3.3 – Estudo de CasoHipóteses:Qualidade do pré-release → defeitos detectados antes      de liberar o softwareQualidade...
:.: 3.3 – Estudo de Caso                           75
:.: 3.3 – Estudo de Caso                           76
:.: 3.3 – Estudo de CasoOutros Estudos de Casos:  –          NASA testou XP para validá-lo para           projetos de miss...
:.: 3.3 – Estudo de CasoOutros Estudos de Casos:  –        Williams et. al. [2004] fez uma aplicação do           framewor...
:.: 3.4 – Documentação em XPXP tem documentação, SIM SENHORES!        Mas só o suficiente!                                ...
:.: 3.4 – Documentação em XPDocumentações, testes de unidade e aceitação dão     suporte ao código gerado (principal entre...
:.: 3.4 – Documentação em XPVisão tradicional → custo de alterar o software cresce      exponencialmente ao longo do ciclo...
:.: 3.4 – Documentação em XPExemplos de documentos:Histórias - Testes de Aceitação - Testes de Unidade -      Documentação...
:.: 3.5 – Escalando XPNúmero de pessoas → divida o problema em vários     times pequenos e trate a integraçãoRelação com a...
:.: 3.6 – DebateComo é a cultura da sua organização?Você consegue identificar um primeiro projeto para     utilizar XP?Voc...
:.: BIBLIOGRAFIAManhaes Teles, Vinicius. Um estudo de caso da adoção das práticas e valores do Extreme Programming.2005. 1...
Upcoming SlideShare
Loading in...5
×

Aula03 04 agile_scrum_xp

599

Published on

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

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

  • Be the first to like this

No Downloads
Views
Total Views
599
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Aula03 04 agile_scrum_xp

  1. 1. Desenvolvimento ágil deSoftware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 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. 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 Report Requisitos presentes ao 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Necessidade de atendimento a modelos de maturidade – CMMI, MPS.BRAlternativas à época com baixa tolerância a mudanças de requisitos
  8. 8. E aí!?
  9. 9. E aí!?Desenvolvimento ágil não garante necessariamente que o projeto terá mais ou menos sucesso :-(
  10. 10. E aí!?Desenvolvimento ágil não garante necessariamente que o projeto terá mais ou menos sucesso :-(Mas ajuda!!! Como?
  11. 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. 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. 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. 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. 15. Manifesto ÁgilCustomer collaboration over contract negotiation Cliente deve estar infiltrado na equipe de desenvolvimento.
  16. 16. Manifesto ÁgilResponding to change over following a plan
  17. 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. 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. 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. 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. 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. 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. 23. SCRUM – Visão Geral
  24. 24. SCRUM - ArtefatosProduct backlog Sempre evoluiSprint backlog Derivado a partir do product backlog Detalha os itens do product backlog em tarefas
  25. 25. SCRUM - ArtefatosBurndown Chart – quanto mais horizontal, melhor
  26. 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. 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. 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. 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. 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. 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. 32. Gostaram do SCRUM?Falamos de Gestão de ProjetoAgora tá na hora de práticas de desenvolvimentoVamos falar de XP
  33. 33. :.: ÍNDICE 1.1 Motivação 1.2 Muito Prazer, eu sou XP 33
  34. 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. 35. :.: 1.1 - MotivaçãoRelatório do Caos – Chaos Report 35
  36. 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. 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. 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. 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. 40. Metodologias Ágeis: Extreme Programming 2 – Elementos de Extreme Programming. Professor: Joaquim Lopes Júnior (joaquimlopesjr@gmail.com) 40
  41. 41. :.: ÍNDICE 2.1 Valores 2.2 Práticas 41
  42. 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. 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. 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. 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. 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. 47. :.: 2.2 - PráticasPlanning Game – Jogo do Planejamento 47
  48. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 60. Metodologias Ágeis: Extreme Programming 3 – Implantação de XP nas Organizações Professor: Joaquim Lopes Júnior (joaquimlopesjr@gmail.com) 60
  61. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 73. :.: 3.3 – Estudo de Caso 73
  74. 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. 75. :.: 3.3 – Estudo de Caso 75
  76. 76. :.: 3.3 – Estudo de Caso 76
  77. 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. 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. 79. :.: 3.4 – Documentação em XPXP tem documentação, SIM SENHORES! Mas só o suficiente! 79
  80. 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. 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. 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. 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. 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. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×