8. Os três “Quem” - Quem já participou de algum projeto de software do Início ao Fim... ... que tenha terminado no prazo? - Quem participa de algum projeto de software hoje? Se sim, esse projeto já têm algo em produção? - Quem já participou de algum projeto de software onde os requisitos não mudaram? Se sim, então NÃO era um projeto de Software!
11. Problemas ... Doenças do Gerenciamento de Projetos Muita gente envolvida e pouca gente comprometida Muitas barreiras de comunicação entre cliente e desenvolvedor
12. Doenças do Gerenciamento de Projetos Multi-tarefa nociva Equipes enfrentam constantemente prioridades que mudam, fazendo com que interrompam uma tarefa e trabalhem em outra Lei de Parkinson Mais tempo de segurança, mais tempo de projeto Síndrome do Estudante O trabalho quase sempre é adiado Dependência entre tarefas O atraso é passado adiante, mas o adiantamento não
15. Então, o que fazer? Em 2001, um grupo de profissionais veteranos na área de software decidiu se reunir em uma estação de esqui, nos EUA. O objetivo seria discutir formas de melhorar o desempenho de seus projetos. Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de software ter sucesso, cada qual com as suas particularidades, todos concordavam que, em suas experiências prévias, um pequeno conjunto de princípios sempre parecia ter sido respeitado quando os projetos davam certo; O grupo era composto de grandes nomes do mundo do software, tais como: Kent Beck, Jim Highsmith, Alistair Cockburn, Martin Fowler, Ken Schwaber e Jeff Sutherland; O encontro deu origem ao MANIFESTO ÁGIL
16. O Manifesto Ágil “Estamos descobrindo melhores maneiras de desenvolver software, fazendo software e ajudando outros a fazê-lo. Através deste trabalho passamos a valorizar: Processos e ferramentas Indivíduos e interações Maisque Documentação abrangente Software quefunciona Maisque Negociação de contrato Colaboração do cliente Maisque Seguir um plano Resposta à mudanças Maisque Isto é, embora haja valor nos itens do lado direito, nós valorizamos mais os do lado esquerdo.” http://www.agilemanifesto.org
18. Desenvolvimento Incremental e IterativoPensando um pouco... Planejamento Por Fase Requisitos Especific. Desenvolv Testes Produção Isso não é do jeito que eu queria !!! Iteração 1 Iteração 2 Iteração N Por que não... Iterações? ... Entrega 1 Entrega 2
21. O que é Scrum?Algumas definições Scrum é um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer trabalho. Scrum é um processo ágil para o gerenciamento e controle de projetos; Scrum é uma abordagem para desenvolvimento de sistemas e produtos onde os requisitos sofrem constantes mudanças; Scrum é um processo que controla o caos dos conflitos de interesses;
24. ProductBacklog Criado a partir de uma Visão do Projeto Lista de funcionalidades priorizadas Maior prioridade Menor Prioridade
25. SprintBacklog Parte do ProductBacklog que vai ser feita numa iteração (Sprint) Montado a partir das funcionalidade que estão no topo do ProductBacklog Maior prioridade Sprint Backlog Menor Prioridade
26. Mas o que é um Sprint? Um período de Tempo entre 2 a 4 semanas Sempre deve ter um objetivo a ser atingidao pela equipe É normal que o tempo de duração dos Sprints possam variar no início do projeto, mas o ideal é que se chegue num tempo único para todos os sprints Todos os Sprints devem pessuir uma estrutura exatamente igual
27. 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
28. Dinâmica do ProductBacklog 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
30. ProductOwner Define as funcionalidades do produto Decide datas de lançamento e conteúdo Responsávelpelarentabilidade (Return Of Investiment - ROI) Priorizafuncionalidades de acordo com seuvalorpara o negócio Gerencia a entrada de novosrequisitos e suasprioridades Aceitaourejeita o resultado dos trabalhos $$$$$$$$$$
31. Interação do PO com os Usuários Usuários Product Owner Isso não impede Equipe de desenvolvimento
32. ScrumMaster Representa a gerênciapara o projeto Responsávelpelaaplicação dos valores e práticas do Scrum Remove obstáculos Garante a plenafuncionalidade e produtividadedaequipe Garante a colaboração entre osdiversospapéis e funções Escudoparainterferênciasexternas
33. Equipe Tamanhovariável , é aconcelhávelnãomaisque 9 pessoas e nãomenosque 4 Multi-funcional Programadores, testadores, desenvolvedores... Aconcelháveltrocassónamudança de Sprints Faz o que for precisoparaalcançar a Meta do Sprint, umavezque se compromete com o quevai ser entregue Apresentaaosinteressados o resultado do Sprint
35. Planejamento do Sprint(SprintPlanning Meeting) Reunião que define O objetivo (meta) do Sprint Uma lista dos membros da equipe que estarão comprometidos com a meta Um SprintBacklog (lista com todas as funcionalidades incluídas no sprint) Uma Data para demonstrar que foi produzido durante o sprint Hora e lugar definido para acontecerem as reuniões diárias Dependendo do projeto, esta reunião pode durar de 4 a 16 horas
36. Planejamento do SprintESTIMATIVAS Como estimar? StoryPoints Um “peso” dado para cada história Indica quanto uma história é maior ou mais complexa que outra Horas Tempo estimado por cada tarefa
44. Retrospectiva(SprintRetrospective) Objetivo Enumerar o que funcionou e o que não funcionou durante o Sprint Duração 30 a 60 minutos Participantes Product Owner, Scrum Master e os membros do time Esta reunião pode ser feita à frente de um quadro branco onde membro cola post its dizendo o que funcionou e o que não funcionou Feita após cada Sprint
49. Paradigmas a serem quebrados Equipes auto-gerenciáveis Equipes multi-disciplinares Até onde a documentação é último Comunicação Referência Desenvolvimento por iterações Zonas de conforto
50. Referências www.mountaingoatsoftware.com/scrum www.scrumalliance.org www.controlchaos.com scrumdevelopment@yahoogroups.com Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Agile Project Management with Scrum by Ken Schwaber Scrum and the Enterprise by Ken Schwaber Scrum and XP from the trenches