O documento aborda a gestão ágil de projetos, destacando o Manifesto Ágil e seus princípios fundamentais, como a prioridade na satisfação do cliente e a adaptação a mudanças. É apresentada a metodologia Scrum, que enfatiza a transparência, a comunicação constante e a melhoria contínua dentro das equipes. Práticas ágeis, como o desenvolvimento ágil e a colaboração com clientes, são discutidas como meios para aumentar a eficácia e a produtividade dos projetos.

1. Gestão Ágil de Projetos Adriano de Pinho Tavares Fevereiro 2009 – Circuito IGTI de Palestras Corporativas

2. Gestão Ágil de Projetos

3. Agenda

4. “ O movimento ágil não é anti-metodologia” Jim Highsmith http://agilemanifesto.org/history.html

5. Fonte: The Standish Group International, Inc. 2004 THIRD QUARTER RESEARCH REPORT

6. Fonte: The Standish Group International, Inc. 2004 THIRD QUARTER RESEARCH REPORT

7. “ Buscar uma metodologia formal que aplicada corretamente possa: envolver o usuário, melhorar a comunicação, melhorar as relações do time e melhorar a produtividade.”

8. Agenda

9. Publicado em fevereiro de 2001 por 17 profissionais renomados http://www.agilemanifesto.org/

10. “ Uma boa forma de pensar sobre o manifesto é que ele define preferências , não alternativas.” Scott W. Ambler http://agilemodeling.com

11. Indivíduos e interação mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociar contratos Responder às mudanças mais que seguir um plano

12. “ Estamos evidenciando maneiras melhores de desenvolver software, fazendo e ajudando os outros a fazê-lo.”

13. “ Nós seguimos estes princípios.”

14. 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.

15. Receba bem as mudanças de requisitos , mesmo em estágios tardios do desenvolvimento. Processos ágeis devem admitir mudanças que tragam vantagens competitivas para o cliente .

16. Libere software freqüentemente (em intervalos de 2 semanas até 2 meses), dando preferência para uma escala de tempo mais curta.

17. Mantenha as pessoas ligadas ao negócio (cliente) e desenvolvedores trabalhando juntos sempre que possível para facilitar a comunicação.

18. Construa projetos com indivíduos motivados , dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado.

19. O método mais eficiente e efetivo para repassar informação entre uma equipe de desenvolvimento é pela comunicação face-a-face .

20. Software funcionando é a principal medida de progresso de um projeto de software.

21. Processos ágeis promovem desenvolvimento sustentado. Assim, patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica indefinidamente .

22. 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.

23. Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial, devendo ser assumida em todos os aspectos do projeto. Fuja de soluções “legais” (cool) e do “excesso de engenharia” (overengineering).

24. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas .

25. 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.

26. “ É mais fácil alguém lutar por seus princípios do que cumpri-los.” Alfred Adler (Psiquiatra: Criador da psicologia individual) “ No contexto da psicologia individual, um indivíduo é "indivisível", ou seja, as pessoas devem ser tratadas holisticamente.“

27. Agenda

28. Você adota algum método ágil? Quais métodos? Você tem usado alguma prática ágil? Quais práticas? 4232 pessoas, Março 2006 Maillist das revistas Dr. Dobb’s Journal e Software Development Resultados de Scott Ambler’s Março 2006 “Agile Adoption Rate Survey” publicado em www.agilemodeling.com/surveys/

30. TDD - Test-Driven Development XP - eXtreme Programming DSDM - Dynamic Systems Development Method AUP - Agile Unified Process Agile MSF - Agile Microsoft Solution Framework

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

34. Desenvolvedores estão incorporando práticas ágeis independentes de usarem uma metodologia ágil completa Abordagens ágeis tem aumentado a satisfação dos clientes

35. Agenda

36. “ Scrum é baseado em verdade, transparência e comprometimento.” Jeff Sutherland

37. Jeff Sutherland Uso inicial do scrum na Easel em 1993 Mais de 500 pessoas usando scrum Ken Schwaber Apresentação na OOPSLA 95 com Sutherland Três livros sobre Scrum Mike Beedle Padrões para o Scrum na PLOPD4 Ken Schwaber and Mike Cohn Fundaram a Scrum Alliance em 2002, inicialmente junto com a Agile Alliance

39. Sprint (1w – 4w) Papéis Product Owner ScrumMaster Team Members Cerimônias (reuniões) Sprint Planning (4 h) Daily Meeting (15 m) Sprint Review (2 h) Sprint Retrospective (2 h) Artefatos Product Backlog Sprint Backlog Impediments Backlog Burndown Chart

40. Produtos complexos em ambientes de incerteza e mudanças. Alto nível de clareza e transparência para todos os envolvidos – time, cliente, gerencia e outros. Inspeção, adaptação e criatividade. Melhoria contínua da eficácia.

41. Representante dos usuários. Seu foco é no produto do lado do negócio. Ele se preocupa em passar a visão do produto para o time. Ele formaliza junto com o time uma especificação, mensurável e razoável chamada Product Backlog

42. O Product Backlog lista os entregáveis do produto. Seu conteúdo é ordenado pelo valor para o negócio. A prioridade dos itens do Backlog pode mudar. Requisitos podem ser adicionados e removidos O Product Backlog é planejado continuamente.

43. O tamanho ideal do time é 7 +ou- 2 O time é multi-funcional: desenvolvedores, testadores, arquitetos, DBAs, desenhistas, escritores de documentação, etc ... O time trabalha para atingir as metas do Sprint definidas junto com Product Owner. Membros do time devem ter dedicação full-time.

44. O time trabalha por um período de tempo fixo, chamado Sprint, tipicamente de 1 e 4 semanas Sprints ocorrem um após outro sem interrupção. Trabalho pacífico e sustentável é importante para que o time se mantenha. O time e o Product Owner decidem o tamanho do Sprint.

45. 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. O time cria um plano a executar no nível de tarefas, de acordo com a estimativa em horas. Cada um do time, colabora com sua experiência.

46. É muito importante que o Product Owner não pressione o time a se comprometer com mais do que o time pensa que é possível. 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.

47. Muitos gerentes inicialmente pensam que o time se compromete com menos do que consegue executar. 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.

48. Durante o Sprint, o que o time se comprometeu a entregar e a data final do Sprint não mudam. 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.

49. Se alguma coisa maior acontecer o Product Owner pode terminar o Sprint prematuramente, e iniciar um novo. Product Owner pode adicionar, remover, reordenar ou mudar itens antes do próximo Sprint. Ele pode pedir ao time para re-implementar um trabalho já concluído.

50. Todo dia, o time faz uma reunião de 15 minutos para atualizar os outros sobre o progresso. 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. ScrumMaster mantém o Impediment Backlog e depois ajuda o time a resolve-los.

51. Outros podem participar se convidados, mas eles não falam. Esta reunião não é para monitorar o time e sim sincronizar o time O Daily Meeting ajuda o time a se organizar.

52. Todo dia, o time atualiza um gráfico simples que torna visível o que está sendo feito para atingir a meta do Sprint. O gráfico Burndown mostra o total de horas que faltam para completar as tarefas. Este gráfico permite que o time se auto-gerencie e entregue o que se comprometeu.

53. Todo dia, o time atualiza um gráfico simples que torna visível o que está sendo feito para atingir a meta do Sprint. O gráfico Burndown mostra o total de horas que faltam para completar as tarefas. Este gráfico permite que o time se auto-gerencie e entregue o que se comprometeu.

54. O Scrum Master é o técnico, o facilitador do time. O Scrum Master protege o time. Controla os ciclos de “inspeção e adaptação” do Scrum. Ele deve garantir que as práticas ágeis sejam entendidas e respeitadas, por todos os envolvidos.

55. Trabalha com o Product Owner para maximizar o ROI. Sem o ScrumMaster, o time tem um alto risco de falhar.

56. A intenção do time é completar 100% do que foi acordado, idealmente uma parte entregável de um produto no final a cada Sprint. Isso significa, projetar, implementar e testar e corrigir defeitos críticos ou blocantes. Poucos times liberam produtos entregáveis no Sprint 1.

57. No fim do Sprint, Product Owner, time, ScrumMaster e outros envolvidos veem uma demo do que o time produziu. O Product Owner dá um feedback para todos do que pode melhorar o que foi produzido. Este feedback é incorporado ao Product Backlog.

58. 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. Este é o mecanismo de melhoria contínua e onde os problemas críticos são identificados.

60. Melhora a comunicação Melhora as relações do time Promove a transparência Promove a mitigação de riscos Melhora a produtividade

61. Metodologias ágeis - Scrum, XP e tudo mais! Discutir metodologias, seu impacto sobre a condução dos projetos e sobre o trabalho do arquiteto. http://pangeanet.org

62. http://www.institutogti.com.br

63. Obrigado!