Agile Tour 2010
•
1 j'aime•340 vues
1) O documento discute a adoção de métodos ágeis em outsourcing de desenvolvimento de software. 2) É possível aplicar métodos ágeis em outsourcing definindo claramente as responsabilidades e realizando reuniões como planning e retrospectivas. 3) Contratos ágeis com escopo definido em pontos em vez de horas permitem maior flexibilidade para mudanças durante o projeto.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Agile Tour 2010
Similaire à Agile Tour 2010 (20)
Dernier
Dernier (8)
Agile Tour 2010
- 1. Adoção dos Métodos Ágeis em Outsourcing Paulo Rebelo phrebelo@yahoo.com 25 de Outubro 2010 São Paulo
- 2. Biografia • Mestre em Engenharia de Computação pelo IPTComputação pelo IPT • Formado em Licenciatura e Bacharelado em Matemática • Gerente de Projetos Ágil – Abril www.agiletour.com25/10/10
- 3. Meta #1 É possível aplicarmos Agile em Outsourcing?
- 4. Meta #2 Como podemos adotar Agile em Outsourcing?
- 6. A sua empresa já está preparada em desenvolvimento de software e www.agiletour.com25/10/10 desenvolvimento de software e gestão de projetos ágeis?
- 7. Se não está, os desafios são grandes! www.agiletour.com25/10/10
- 9. PARCERIA e não ADVERSÁRIOS! www.agiletour.com25/10/10
- 10. Parceria Ágil? • Nem todos estão dispostos, assim como na adoção de Agile em equipes internas www.agiletour.com25/10/10
- 11. Contratos Tradicionais • Inflexíveis e não permitem mudança de escopo www.agiletour.com25/10/10
- 14. Ao invés de escopo fixo… www.agiletour.com25/10/10
- 16. -Time-boxing é uma prática ágil comum. - Limitar o custo faz com que o time- boxing trabalhe até melhor! www.agiletour.com25/10/10
- 17. Portanto: • User stories, ao invés de uma Especificação de Requisitos detalhada (elas são orientadas a features, podem ser criadas e destruídasfeatures, podem ser criadas e destruídas facilmente, provém uma boa visão do escopo e podem ser comparadas pelo tamanho ou esforço). • Pontos, ao invés de horas, pois são relativos e não expressam necessariamente o esforço. • DONE: confiança e entendimento comum. www.agiletour.com25/10/10
- 18. Desta forma, fixando o escopo em termos de pontos, conseguimos, no decorrer do projeto, abraçar mudanças, pois conseguimos trocar histórias por outras de mesmo valor. www.agiletour.com25/10/10 de mesmo valor. Assim, temos a tríplice: custo, prazo e escopo fixos, da forma ágil!
- 20. Business Value “Uma abordagem de melhoria de aprendizado e incremental, com a finalidade de oferecer aos www.agiletour.com25/10/10 finalidade de oferecer aos clientes mais do que eles realmente querem, observando o processo como um todo.”
- 24. Velocidade do Time Total de Pontos 100 Velocidade Baixa 5Velocidade Baixa 5 VelocidadeAlta 15 www.agiletour.com25/10/10 100 ÷ 5 = 100 ÷ 15 =
- 25. TEMPO f = (total de pontos ÷ velocidade) ×f = (total de pontos ÷ velocidade) × tamanho do sprint (100 ÷ 10) × 2 semanas = 20 semanas www.agiletour.com25/10/10
- 26. CUSTO f = horas sprint × qtde. sprints × qtde.f = horas sprint × qtde. sprints × qtde. pessoas × valor/hora 80h × 10 sprints × 4 pessoas × R$ 100,00 = R$ 320.000,00 www.agiletour.com25/10/10
- 27. Flexibilidade • Número de pontos a serem entregues já sabemos! • Abrace mudanças, levando em consideração a• Abrace mudanças, levando em consideração a quantidade de pontos! • Se cliente quiser mais 1 sprint, sem problema! Faça um aditivo ao contrato com esse sprint adicional. www.agiletour.com25/10/10
- 29. Acompanhe a cada sprint!!! www.agiletour.com25/10/10
- 35. Definir as responsabilidades com clareza • Product Owner • ScrumMaster • QA• QA • Time • Arquiteto de Software • Sysadmin www.agiletour.com25/10/10
- 36. Definir as responsabilidades com clareza • Product Owner • ScrumMaster • QA • Define uma visão clara do produto • Define as características• QA • Time • Arquiteto de Software • Sysadmin www.agiletour.com25/10/10 • Define as características do produto • Planeja e organiza o backlog • Pontua o valor de negócio das histórias • Responsável pelo ROI
- 37. Definir as responsabilidades com clareza • Product Owner • ScrumMaster • QA • Remove os impedimentos • Responsável pelo processo• QA • Time • Arquiteto de Software • Sysadmin www.agiletour.com25/10/10 processo • Facilita a colaboração entre todos • Garante que o time esteja sempre funcionando e produzindo
- 38. Definir as responsabilidades com clareza • Product Owner • ScrumMaster • QA • Planeja e executa os testes de aceitação do usuário• QA • Time • Arquiteto de Software • Sysadmin www.agiletour.com25/10/10 usuário • Apóia time • Trabalha com todos para garantir a qualidade do software a ser lançado
- 39. Definir as responsabilidades com clareza • Product Owner • ScrumMaster • QA • Desenvolve as features planejadas pelo PO • Define como será• QA • Time • Arquiteto de Software • Sysadmin www.agiletour.com25/10/10 • Define como será realizado o trabalho • Auto-gerenciado e auto- organizado • Apresenta o que foi feito ao PO
- 40. Definir as responsabilidades com clareza • Product Owner • ScrumMaster • QA • Programa em par remotamente • Revisa o código• QA • Time • Arquiteto de Software www.agiletour.com25/10/10 • Revisa o código • Integra continuamente • Realiza provas de conceito • Alinhamento conceitual e arquitetural entre os principais projetos da área
- 41. Sessão de Levantamento de Features www.agiletour.com25/10/10
- 42. Coaching do PO • Como escrever histórias, aplicando o conceito de INVESTconceito de INVEST (Independent, Negotiable, Valuable, Estimable, Sized right and Testable) • Responsabilidades www.agiletour.com25/10/10
- 51. Reuniões • Daily • Planning• Planning • Review • Retrospective www.agiletour.com25/10/10
- 52. Reuniões • Daily • Planning Perguntas: • O que foi feito? • O que será feito?• Planning • Review • Retrospective • O que será feito? • Algum impedimento? Regras: • 15’ • PO liga para todos www.agiletour.com25/10/10
- 53. Reuniões • Daily • Planning • Meta do Sprint • Apresentação das histórias• Planning • Review • Retrospective histórias • Estimativa (user stories < 13) • Definição do Sprint www.agiletour.com25/10/10
- 54. Reuniões • Daily • Planning • Apresentação das histórias DONE para stakeholders • Planning • Review • Retrospective stakeholders • Aceitação ++ Reviews constantes, quase diários www.agiletour.com25/10/10
- 55. Reuniões • Daily • Planning • O que foi bom e devemos continuar? • O que precisa ser• Planning • Review • Retrospective • O que precisa ser melhorado? ++ Retrospectiva geral presencial no final do Release www.agiletour.com25/10/10
- 56. Acompanhe a Evolução www.agiletour.com25/10/10 Acompanhe a Evolução
- 58. Boas Práticas de Desenvolvimento de Software • Pair programming (Team Viewer, Pair Eclipse Programming, etc.) • Code review• Code review • Desenvolvimento orientado a testes • Padronização de código • Integração regular do código • Incentivo à refatoração www.agiletour.com25/10/10
- 60. “Quem não se comunica, se estrumbica” (Velho Guerreiro) www.agiletour.com25/10/10