Gerenciamento e Desenvolvimento Ágil de Projetos de Software com Scrum

1. Luciano Soares de Souza Gerenciamento e Desenvolvimento Ágil de Projetos de Software com Scrum

2. Agenda • Problemas no Desenvolvimento de Software • Metodologias Tradicionais "Old School" • Metodologias Ágeis • Scrum • Considerações Finais

3. Problemas No Desenvolvimento de Software

4. A história se repete

5. Estatísticas ChaosReport Fonte: The Standish Group http://www.infoq.com/articles/chaos-1998-failure-stats

6. Uso de Funcionalidades não serve para 20% 80% NADA!! Standish Group, 2002

7. Mas por que?

8. Problemas • A experiência de décadas seguindo pesadas práticas prescritivas tornou evidente que: • Os detalhes são complexos para as pessoas. • Os clientes ou usuários não tem certeza do que eles querem. • Eles tem dificuldade de expressar tudo o que querem e pensam. • Muitos detalhes do que eles querem só serão revelados durante o desenvolvimento. • Na medida em que elas vêem o produto sendo construído, elas mudam de idéia. • Forças externas (como um produto ou serviço da concorrência) trazem mudanças ou melhorias nos requisitos

9. Metodologias Tradicionais“OldSchool”

10. Modelos Tradicionais Qualidade do Processo Qualidade ==

11. Gestão “OldSchool” Reproduzir e Controlar

12. Problemas - Reproduzir Inibe aprendizado & criativiade

13. Problemas - Controlar Gerenciamento excessivo

14. Modelo Herdado

15. Modelo Cascata Meses!!!

16. Modelo Rup 2 semanas 2 semanas 2 semanas Bom resultado Não ataca o problema principal

17. Problema processo circular separação das atividades facilidade de controle

18. Problema - Continuação problema na comunicação!

19. Problema de comunicação • Demora-se muito tempo • Interface de comunicação limitada e pouco expressiva • Modelo linear e unidirecional

20. existe um mundo existe um mundo MELHOR !!!

21. Metodologias Ágeis

22. Manifesto Ágil Indivíduos e interações sobre processos e ferramentas Software funcionando sobre documentação extensa Colaboração com o cliente sobre negociação de contratos Responder a mudança sobre seguir um plano www.agilemanifesto.org

23. Modelo centralizado Todos os papéis presentes quando necessário

24. Sem ordem Atividades realizadas quando necessário

25. Planejamento Ágil

26. SCRUM

27. SCRUM Iterativo e Incremental Resposta às mudanças Maior valor para o negócio Práticas de engenharia livres Framework de processo

28. Visão Geral do Scrum

29. Papéis no Scrum • ProductOwner • ScrumMaster • Equipe

30. ProductOwner Determina a Visão do Projeto Define as funcionalidades Determina o valor de negócio Responsável pelo ROI Prioriza funcionalidades Aceita ou rejeita o resultado do trabalho

31. ScrumMaster Valores e Práticas do Scrum Resolve os impedimentos Conduz as reuniões diárias, de planejamento e revisão Escudo para interferências externas

32. Time Entre 5 e 10 pessoas Multi-funcional Auto organizável e Auto gerenciável Estima as funcionalidades Define as tarefas Levanta impedimentos (externos)

33. Processo Scrum

34. ProductBacklog • Criado a partir da Visão do Produto • Contém todos os requisitos funcionais e não funcionais • Geralmente escritos em User Stories • Idealmente representado por itens que agregam valor aos usuários ou cliente • Priorizadopelo Product Owner

35. ProductBacklog - Exemplo

37. SprintPlanning 1 • Reunião de no máximo 4 horas • Revisar o product backlog • Determinar o objetivo da sprint • Selecionar parte do product backlog • Estimar e priorizar IBLs (itens de backlog)

38. Estimando o ProductBacklog 2 1 3

39. Estimando com PlanningPoker 2 1 3

40. 3 5 2 5 8 8 20 13

42. SprintPlanning 2 • É um planejamento tático da equipe • Os itens selecionados do Product Backlog são destrinchados em tarefas • O resultado final é o Sprint Backlog

43. SprintBacklog • As tarefas não são atribuídas aos membros do time • Cada membro escolhe sua tarefa diariamente • Qualquer membro do time pode adicionar ou remover itens do Sprint Backlog (durante o daily meeting)

44. SprintBacklog – TaskBoard Requirements Analysis and Design Coding Test Code Review Deployment Requirements Analysis and Design Coding Test Code Review Deployment Requirements Analysis and Design Coding Test Code Review Deployment

45. Lista de Tarefas Itens para entrega Entendimento daequipe

46. Plannings 1 e 2 Histórias Alta A O que está dentro do Sprint Não pode ser alterado. B Sprint 1 C D E - O que está fora do Sprint pode Ser alterado de acordo com a necessidade do cliente. - Ele pode alterar prioridades, inserir novas tarefas ou retirar tarefas existentes. - Algumas tarefas podem ser inseridas pela equipe. Ex: Montar ambiente para Integração contínua F ProductBacklog Prioridade G H I Baixa

48. Sprint • Um período de tempo entre 2 a 4 semanas • Todos os Sprints devem possuir uma estrutura exatamente igual • Funcionalidades construídas a partir dos IBLs selecionados • Time define a organização necessária para efetuar o trabalho

49. Estrutura de um Sprint dias 1º 2º 3º 4º 5º 6º 7º 8º 9º 10º Apresentação SprintX Planejamento – Sprint X Planejamento – Sprint X+1 Retrospectiva Reunião diária Reunião diária Reunião diária Reunião diária Reunião diária Reunião diária Reunião diária Reunião diária Sprint X

50. Reunião Diária • Objetivo • Cada membro deve responder as seguintes perguntas: • O que você fez desde a última reunião diária? • O que você pretende fazer até a próxima reunião diária? • Existe algum problema que o impeça de realizar suas atividades? • Impedimentos reportados aqui • Duração • 15 minutos (não mais que isso) • Sugestão: Todos em Pé • Qualquer pessoa pode participar, mas apenas o ScrumMaster e os Membros da Equipe pedem falar