Gestao agil de projetos

1.546 visualizações

Publicada em

Esta palestra apresenta os valores e princípios do manifesto ágil, os resultados de uma pesquisa sobre a adoção de metodologias e práticas ágeis, uma visão geral do processo ágil para construção de software SCRUM e práticas ágeis de desenvolvimento mais usadas da XP. O objetivo é apresentar os conceitos do manifesto ágil e promover uma discussão sobre como eles podem influenciar as equipes positivamente, visando obter sucesso nos projetos.

Publicada em: Negócios
0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.546
No SlideShare
0
A partir de incorporações
0
Número de incorporações
11
Ações
Compartilhamentos
0
Downloads
168
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Gestao agil de projetos

  1. 1. Gestão Ágil de Projetos Adriano de Pinho Tavares Fevereiro 2009 – Circuito IGTI de Palestras Corporativas
  2. 2. Gestão Ágil de Projetos
  3. 3. Agenda
  4. 4. <ul><li>“ O movimento ágil não é anti-metodologia” </li></ul><ul><li>Jim Highsmith </li></ul><ul><li>http://agilemanifesto.org/history.html </li></ul>
  5. 5. Fonte: The Standish Group International, Inc. 2004 THIRD QUARTER RESEARCH REPORT
  6. 6. Fonte: The Standish Group International, Inc. 2004 THIRD QUARTER RESEARCH REPORT
  7. 7. <ul><li>“ Buscar uma metodologia formal que aplicada corretamente possa: </li></ul><ul><li>envolver o usuário, melhorar a comunicação, melhorar as relações do time e melhorar a produtividade.” </li></ul>
  8. 8. Agenda
  9. 9. <ul><li>Publicado em fevereiro de 2001 por 17 profissionais renomados </li></ul><ul><li>http://www.agilemanifesto.org/ </li></ul>
  10. 10. <ul><li>“ Uma boa forma de pensar sobre o manifesto é que ele define preferências , não alternativas.” </li></ul><ul><li>Scott W. Ambler </li></ul><ul><li>http://agilemodeling.com </li></ul>
  11. 11. <ul><li>Indivíduos e interação mais que processos e ferramentas </li></ul><ul><li>Software em funcionamento mais que documentação abrangente </li></ul><ul><li>Colaboração com o cliente mais que negociar contratos </li></ul><ul><li>Responder às mudanças mais que seguir um plano </li></ul>
  12. 12. <ul><li>“ Estamos evidenciando maneiras melhores de desenvolver software, fazendo e ajudando os outros a fazê-lo.” </li></ul>
  13. 13. “ Nós seguimos estes princípios.”
  14. 14. <ul><li>A mais alta prioridade é a satisfação do cliente , por meio da liberação mais rápida e contínua de software que agregue valor. </li></ul>
  15. 15. <ul><li>Receba bem as mudanças de requisitos , mesmo em estágios tardios do desenvolvimento. </li></ul><ul><li>Processos ágeis devem admitir mudanças que tragam vantagens competitivas para o cliente . </li></ul>
  16. 16. <ul><li>Libere software freqüentemente (em intervalos de 2 semanas até 2 meses), dando preferência para uma escala de tempo mais curta. </li></ul>
  17. 17. <ul><li>Mantenha as pessoas ligadas ao negócio (cliente) e desenvolvedores trabalhando juntos sempre que possível para facilitar a comunicação. </li></ul>
  18. 18. <ul><li>Construa projetos com indivíduos motivados , dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado. </li></ul>
  19. 19. <ul><li>O método mais eficiente e efetivo para repassar informação entre uma equipe de desenvolvimento é pela comunicação face-a-face . </li></ul>
  20. 20. <ul><li>Software funcionando é a principal medida de progresso de um projeto de software. </li></ul>
  21. 21. <ul><li>Processos ágeis promovem desenvolvimento sustentado. </li></ul><ul><li>Assim, patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica indefinidamente . </li></ul>
  22. 22. <ul><li>A atenção contínua para a excelência técnica , um bom projeto (design) aliado a uma arquitetura sólida (framework) favorecem a agilidade. </li></ul>
  23. 23. <ul><li>Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial, devendo ser assumida em todos os aspectos do projeto. </li></ul><ul><li>Fuja de soluções “legais” (cool) e do “excesso de engenharia” (overengineering). </li></ul>
  24. 24. <ul><li>As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas . </li></ul>
  25. 25. <ul><li>Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais eficases , capturar lições aprendidas, boas práticas, criar templates, checklists, glossários, catalogar padrões e então refinarem e ajustarem seu comportamento de acordo. </li></ul>
  26. 26. <ul><li>“ É mais fácil alguém lutar por seus princípios do que cumpri-los.” </li></ul><ul><li>Alfred Adler </li></ul><ul><li>(Psiquiatra: Criador da psicologia individual) </li></ul><ul><li>“ No contexto da psicologia individual, um indivíduo é &quot;indivisível&quot;, </li></ul><ul><li>ou seja, as pessoas devem ser tratadas holisticamente.“ </li></ul>
  27. 27. Agenda
  28. 28. <ul><ul><li>Você adota algum método ágil? </li></ul></ul><ul><ul><li>Quais métodos? </li></ul></ul><ul><ul><li>Você tem usado alguma prática ágil? </li></ul></ul><ul><ul><li>Quais práticas? </li></ul></ul><ul><li>4232 pessoas, Março 2006 </li></ul><ul><li>Maillist das revistas Dr. Dobb’s Journal e Software Development </li></ul><ul><li>Resultados de Scott Ambler’s Março 2006 “Agile Adoption Rate Survey” publicado em www.agilemodeling.com/surveys/ </li></ul>
  29. 29.
  30. 30. TDD - Test-Driven Development XP - eXtreme Programming DSDM - Dynamic Systems Development Method AUP - Agile Unified Process Agile MSF - Agile Microsoft Solution Framework
  31. 31.
  32. 32. Padrão comum de codificação 1595 Refatoração de código 1467 Testes de regressão de código 1383 Integração contínua 1113 Desenvolvimento dirigido por testes 959 Participação ativa dos clientes 938 Programação em pares 587 Refatoração de banco de dados 416 Testes de regressão de banco de dados 407
  33. 33.
  34. 34. <ul><li>Desenvolvedores estão incorporando práticas ágeis independentes de usarem uma metodologia ágil completa </li></ul><ul><li>Abordagens ágeis tem aumentado a satisfação dos clientes </li></ul>
  35. 35. Agenda
  36. 36. <ul><li>“ Scrum é baseado em verdade, transparência e comprometimento.” </li></ul><ul><li>Jeff Sutherland </li></ul>
  37. 37. <ul><li>Jeff Sutherland </li></ul><ul><ul><ul><li>Uso inicial do scrum na Easel em 1993 </li></ul></ul></ul><ul><ul><ul><li>Mais de 500 pessoas usando scrum </li></ul></ul></ul><ul><li>Ken Schwaber </li></ul><ul><ul><ul><li>Apresentação na OOPSLA 95 com Sutherland </li></ul></ul></ul><ul><ul><ul><li>Três livros sobre Scrum </li></ul></ul></ul><ul><li>Mike Beedle </li></ul><ul><ul><ul><li>Padrões para o Scrum na PLOPD4 </li></ul></ul></ul><ul><li>Ken Schwaber and Mike Cohn </li></ul><ul><ul><ul><li>Fundaram a Scrum Alliance em 2002, inicialmente junto com a Agile Alliance </li></ul></ul></ul>
  38. 38.
  39. 39. <ul><li>Sprint (1w – 4w) </li></ul><ul><ul><li>Papéis </li></ul></ul><ul><ul><ul><li>Product Owner </li></ul></ul></ul><ul><ul><ul><li>ScrumMaster </li></ul></ul></ul><ul><ul><ul><li>Team Members </li></ul></ul></ul><ul><ul><li>Cerimônias (reuniões) </li></ul></ul><ul><ul><ul><li>Sprint Planning (4 h) </li></ul></ul></ul><ul><ul><ul><li>Daily Meeting (15 m) </li></ul></ul></ul><ul><ul><ul><li>Sprint Review (2 h) </li></ul></ul></ul><ul><ul><ul><li>Sprint Retrospective (2 h) </li></ul></ul></ul><ul><ul><li>Artefatos </li></ul></ul><ul><ul><ul><li>Product Backlog </li></ul></ul></ul><ul><ul><ul><li>Sprint Backlog </li></ul></ul></ul><ul><ul><ul><li>Impediments Backlog </li></ul></ul></ul><ul><ul><ul><li>Burndown Chart </li></ul></ul></ul>
  40. 40. <ul><li>Produtos complexos em ambientes de incerteza e mudanças. </li></ul><ul><li>Alto nível de clareza e transparência para todos os envolvidos – time, cliente, gerencia e outros. </li></ul><ul><li>Inspeção, adaptação e criatividade. </li></ul><ul><li>Melhoria contínua da eficácia. </li></ul>
  41. 41. <ul><li>Representante dos usuários. </li></ul><ul><li>Seu foco é no produto do lado do negócio. </li></ul><ul><li>Ele se preocupa em passar a visão do produto para o time. </li></ul><ul><li>Ele formaliza junto com o time uma especificação, mensurável e razoável chamada Product Backlog </li></ul>
  42. 42. <ul><li>O Product Backlog lista os entregáveis do produto. </li></ul><ul><li>Seu conteúdo é ordenado pelo valor para o negócio. </li></ul><ul><li>A prioridade dos itens do Backlog pode mudar. </li></ul><ul><li>Requisitos podem ser adicionados e removidos </li></ul><ul><li>O Product Backlog é planejado continuamente. </li></ul>
  43. 43. <ul><li>O tamanho ideal do time é 7 +ou- 2 </li></ul><ul><li>O time é multi-funcional: desenvolvedores, testadores, arquitetos, DBAs, desenhistas, escritores de documentação, etc ... </li></ul><ul><li>O time trabalha para atingir as metas do Sprint definidas junto com Product Owner. </li></ul><ul><li>Membros do time devem ter dedicação full-time. </li></ul>
  44. 44. <ul><li>O time trabalha por um período de tempo fixo, chamado Sprint, tipicamente de 1 e 4 semanas </li></ul><ul><li>Sprints ocorrem um após outro sem interrupção. </li></ul><ul><li>Trabalho pacífico e sustentável é importante para que o time se mantenha. </li></ul><ul><li>O time e o Product Owner decidem o tamanho do Sprint. </li></ul>
  45. 45. <ul><li>Antes de cada Sprint, o time seleciona o Sprint Backlog, que ele vai se comprometer a entregar no final do Sprint, iniciando do topo do Product Backlog. </li></ul><ul><li>O time cria um plano a executar no nível de tarefas, de acordo com a estimativa em horas. </li></ul><ul><li>Cada um do time, colabora com sua experiência. </li></ul>
  46. 46. <ul><li>É muito importante que o Product Owner não pressione o time a se comprometer com mais do que o time pensa que é possível. </li></ul><ul><li>Se existe pressão, o time irá se comprometer com o que não consegue entregar e não vai terminar, ou terá que fazer outro Sprint. </li></ul>
  47. 47. <ul><li>Muitos gerentes inicialmente pensam que o time se compromete com menos do que consegue executar. </li></ul><ul><li>Na realidade,muitos times tem o problema oposto: eles podem ter que fazer diversos Sprints para aprender a não se comprometer com mais do que consegue cumprir. </li></ul>
  48. 48. <ul><li>Durante o Sprint, o que o time se comprometeu a entregar e a data final do Sprint não mudam. </li></ul><ul><li>Isso permite ao time fazer e cumprir compromissos, mantém o foco e a estabilidade do time durante o Sprint e treina o Product Owner a pensar claramente no que está no Product Backlog. </li></ul>
  49. 49. <ul><li>Se alguma coisa maior acontecer o Product Owner pode terminar o Sprint prematuramente, e iniciar um novo. </li></ul><ul><li>Product Owner pode adicionar, remover, reordenar ou mudar itens antes do próximo Sprint. </li></ul><ul><li>Ele pode pedir ao time para re-implementar um trabalho já concluído. </li></ul>
  50. 50. <ul><li>Todo dia, o time faz uma reunião de 15 minutos para atualizar os outros sobre o progresso. </li></ul><ul><li>Eles ficam de pé, para que seja rápido: Cada um responde a 3 perguntas: o que fez, o que vai fazer e o que está impedindo o trabalho. </li></ul><ul><li>ScrumMaster mantém o Impediment Backlog e depois ajuda o time a resolve-los. </li></ul>
  51. 51. <ul><li>Outros podem participar se convidados, mas eles não falam. </li></ul><ul><li>Esta reunião não é para monitorar o time e sim sincronizar o time </li></ul><ul><li>O Daily Meeting ajuda o time a se organizar. </li></ul>
  52. 52. <ul><li>Todo dia, o time atualiza um gráfico simples que torna visível o que está sendo feito para atingir a meta do Sprint. </li></ul><ul><li>O gráfico Burndown mostra o total de horas que faltam para completar as tarefas. </li></ul><ul><li>Este gráfico permite que o time se auto-gerencie e entregue o que se comprometeu. </li></ul>
  53. 53. <ul><li>Todo dia, o time atualiza um gráfico simples que torna visível o que está sendo feito para atingir a meta do Sprint. </li></ul><ul><li>O gráfico Burndown mostra o total de horas que faltam para completar as tarefas. </li></ul><ul><li>Este gráfico permite que o time se auto-gerencie e entregue o que se comprometeu. </li></ul>
  54. 54. <ul><li>O Scrum Master é o técnico, o facilitador do time. </li></ul><ul><li>O Scrum Master protege o time. </li></ul><ul><li>Controla os ciclos de “inspeção e adaptação” do Scrum. </li></ul><ul><li>Ele deve garantir que as práticas ágeis sejam entendidas e respeitadas, por todos os envolvidos. </li></ul>
  55. 55. <ul><li>Trabalha com o Product Owner para maximizar o ROI. </li></ul><ul><li>Sem o ScrumMaster, o time tem um alto risco de falhar. </li></ul>
  56. 56. <ul><li>A intenção do time é completar 100% do que foi acordado, idealmente uma parte entregável de um produto no final a cada Sprint. </li></ul><ul><li>Isso significa, projetar, implementar e testar e corrigir defeitos críticos ou blocantes. </li></ul><ul><li>Poucos times liberam produtos entregáveis no Sprint 1. </li></ul>
  57. 57. <ul><li>No fim do Sprint, Product Owner, time, ScrumMaster e outros envolvidos veem uma demo do que o time produziu. </li></ul><ul><li>O Product Owner dá um feedback para todos do que pode melhorar o que foi produzido. </li></ul><ul><li>Este feedback é incorporado ao Product Backlog. </li></ul>
  58. 58. <ul><li>O time, Product Owner e ScrumMaster se reunem no final de cada Sprint para rever a forma de trabalho e visualizar formas de se tornarem mais eficazes. </li></ul><ul><li>Este é o mecanismo de melhoria contínua e onde os problemas críticos são identificados. </li></ul>
  59. 59.
  60. 60. <ul><li>Melhora a comunicação </li></ul><ul><li>Melhora as relações do time </li></ul><ul><li>Promove a transparência </li></ul><ul><li>Promove a mitigação de riscos </li></ul><ul><li>Melhora a produtividade </li></ul>
  61. 61. <ul><li>Metodologias ágeis - Scrum, XP e tudo mais! </li></ul><ul><ul><li>Discutir metodologias, seu impacto sobre a condução dos projetos e sobre o trabalho do arquiteto. </li></ul></ul><ul><ul><li>http://pangeanet.org </li></ul></ul>
  62. 62. <ul><ul><li>http://www.institutogti.com.br </li></ul></ul>
  63. 63. <ul><li>Obrigado! </li></ul>

×