Gestão Ágil de Projetos Adriano de Pinho Tavares Fevereiro 2009 – Circuito IGTI de Palestras Corporativas
Gestão Ágil de Projetos
Agenda
<ul><li>“ O movimento ágil não é anti-metodologia” </li></ul><ul><li>Jim Highsmith  </li></ul><ul><li>http://agilemanifest...
Fonte: The Standish Group International, Inc. 2004 THIRD QUARTER RESEARCH REPORT
Fonte: The Standish Group International, Inc. 2004 THIRD QUARTER RESEARCH REPORT
<ul><li>“ Buscar uma metodologia formal que aplicada corretamente possa: </li></ul><ul><li>envolver o usuário,  melhorar a...
Agenda
<ul><li>Publicado em fevereiro de 2001 por 17 profissionais renomados </li></ul><ul><li>http://www.agilemanifesto.org/ </l...
<ul><li>“ Uma boa forma de pensar sobre o manifesto é que ele define  preferências , não alternativas.” </li></ul><ul><li>...
<ul><li>Indivíduos e interação  mais que processos e ferramentas </li></ul><ul><li>Software em funcionamento  mais que doc...
<ul><li>“ Estamos evidenciando maneiras melhores de desenvolver software, fazendo e ajudando os outros a fazê-lo.” </li></ul>
“ Nós seguimos estes princípios.”
<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 a...
<ul><li>Receba bem as mudanças de requisitos , mesmo em estágios tardios do desenvolvimento.  </li></ul><ul><li>Processos ...
<ul><li>Libere software freqüentemente  (em intervalos de 2 semanas até 2 meses), dando preferência para uma escala de tem...
<ul><li>Mantenha as  pessoas ligadas ao negócio (cliente) e desenvolvedores trabalhando juntos  sempre que possível para f...
<ul><li>Construa projetos com  indivíduos motivados , dê a eles o ambiente e suporte que precisam e confie neles para ter ...
<ul><li>O método mais eficiente e efetivo para repassar informação entre uma equipe de desenvolvimento é pela  comunicação...
<ul><li>Software funcionando  é a principal medida de progresso de um projeto de software. </li></ul>
<ul><li>Processos ágeis promovem desenvolvimento sustentado.  </li></ul><ul><li>Assim, patrocinadores, desenvolvedores e u...
<ul><li>A atenção contínua para a  excelência técnica , um bom projeto (design) aliado a uma arquitetura sólida (framework...
<ul><li>Simplicidade –  a arte de maximizar a quantidade de trabalho não realizado  – é essencial, devendo ser assumida em...
<ul><li>As melhores arquiteturas, requisitos e projetos emergem de  equipes auto-organizadas .  </li></ul>
<ul><li>Em intervalos regulares,  as equipes devem refletir sobre como se tornarem mais eficases , capturar lições aprendi...
<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><...
Agenda
<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 u...
TDD - Test-Driven Development XP - eXtreme Programming  DSDM - Dynamic Systems Development Method AUP - Agile Unified Proc...
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 De...
<ul><li>Desenvolvedores estão incorporando práticas ágeis independentes de usarem uma metodologia ágil completa  </li></ul...
Agenda
<ul><li>“ Scrum é baseado em verdade, transparência e comprometimento.” </li></ul><ul><li>Jeff Sutherland </li></ul>
<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><l...
<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><u...
<ul><li>Produtos  complexos em ambientes de incerteza e mudanças. </li></ul><ul><li>Alto nível de clareza e transparência ...
<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 ...
<ul><li>O Product Backlog lista os entregáveis do produto.  </li></ul><ul><li>Seu conteúdo é ordenado pelo valor para o ne...
<ul><li>O tamanho ideal do time é 7 +ou- 2 </li></ul><ul><li>O time é multi-funcional: desenvolvedores, testadores, arquit...
<ul><li>O time trabalha por um período de tempo fixo, chamado Sprint, tipicamente de 1 e 4 semanas </li></ul><ul><li>Sprin...
<ul><li>Antes de cada Sprint, o time seleciona o Sprint Backlog, que ele vai se comprometer a entregar no final do Sprint,...
<ul><li>É muito importante que o Product Owner não pressione o time a se comprometer com mais do que o time pensa que é po...
<ul><li>Muitos gerentes inicialmente pensam que o time se compromete com menos do que consegue executar.  </li></ul><ul><l...
<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>Iss...
<ul><li>Se alguma coisa maior acontecer o Product Owner pode terminar o Sprint prematuramente, e iniciar  um novo. </li></...
<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...
<ul><li>Outros podem participar se convidados, mas eles não falam.  </li></ul><ul><li>Esta reunião não é para monitorar o ...
<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 Sprin...
<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 Sprin...
<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...
<ul><li>Trabalha com o Product Owner para maximizar o  ROI.  </li></ul><ul><li>Sem o ScrumMaster, o time tem um alto risco...
<ul><li>A intenção do time é completar 100% do que foi acordado, idealmente uma parte entregável de um produto no final a ...
<ul><li>No fim do Sprint, Product Owner, time, ScrumMaster e outros envolvidos veem uma demo do que o time produziu. </li>...
<ul><li>O time, Product Owner e ScrumMaster se reunem no final de cada Sprint para rever a forma de trabalho e visualizar ...
<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><li>Metodologias ágeis - Scrum, XP e tudo mais! </li></ul><ul><ul><li>Discutir metodologias, seu impacto sobre a condu...
<ul><ul><li>http://www.institutogti.com.br </li></ul></ul>
<ul><li>Obrigado! </li></ul>
Próximos SlideShares
Carregando em…5
×

Gestao agil de projetos

1.508 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.508
No SlideShare
0
A partir de incorporações
0
Número de incorporações
11
Ações
Compartilhamentos
0
Downloads
167
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>

×