Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions.

Transcrição

1 Scrum Guia Prático Os papéis, eventos, artefatos e as regras do Scrum Solutions Raphael Rayro Louback Saliba Certified Scrum Master 1

2 Gráfico de Utilização de Funcionalidades Utilização das funcionalidades entregues em Sistemas de Software atuais NUNCA 45% Das funcionalidades entregues, 45% NUNCA são utilizadas 19% RARAMENTE Das funcionalidades entregues, 19% raramente são utilizadas 16% ALGUMAS VEZES Das funcionalidades entregues, 16% são utilizadas algumas vezes Fonte: Standish Group Chaos Report 13% 7% FREQUENTEMENTE Das funcionalidades entregues, 13% são utilizadas frequentemente SEMPRE Das funcionalidades entregues, 7% são sempre utilizadas

3 Índice de Sucesso nos Projetos de Software Pesquisa: Chaos Report 2006 / 2008 / Standish Group 50% 45% 40% 44% 37% 42% 39% 43% SUCESSO Projeto finalizado no prazo, no orçamento e totalmente funcional 35% 30% 25% 20% 15% 32% 24% 21% 18% DESAFIO Projeto finalizado com atraso, com estouro de orçamento e/ou não totalmente funcional 10% 5% 0% FALHA Projeto cancelado ou nunca utilizado

4 Definição de Scrum O que é Scrum? Um framework com a qual as pessoas podem resolver problemas complexos e adaptáveis, enquanto entregam produtos de forma produtiva e criativa e com o maior valor possível. O que é Framework? Conjunto de: Processos Técnicas Boas práticas Conceitos

5 Os 3 Pilares do Scrum Transparência: Aspectos significativos do processo devem estar visíveis a todos responsáveis pelos resultados de forma clara e objetiva. Adaptação: Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção a detectar variações. Inspeção: Se um processo desviou para fora dos limites aceitáveis, e que o produto resultado será inaceitável, o processo ou o material sendo produzido deve ser ajustado.

6 Modelo em Cascata ou Waterfall Método tradicional de desenvolvimento de software Necessidade Necessidade do sistema Design Design do Programa Requisitos Requisitos de sistema Codificação Codificação do Software Requisitos Requisitos Do software Testes Testes do software Análise Análise do sistema Operações Software Pronto

7 Planeja Desenvolve Testa Revisa Revisa Entrega Entrega Representação Waterfall x Scrum Waterfall Planeja Planeja Planeja Desenvolve Desenvolve Desenvolve Ágil Testa Revisa Testa Revisa Testa Revisa

8 Waterfall x Scrum Analogia do bolo Waterfall Ágil

9 Modelo em Cascata (Waterfall) x Scrum Entrega de Valor entre Cascata x Scrum Figuras extraídas de: A Guide to the SCRUM BODY OF KNOWLEDGE (SBOK Guide)

10 Modelo em Cascata (Waterfall) x Scrum Principais diferenças entre os dois modelos Figura extraída de: A Guide to the SCRUM BODY OF KNOWLEDGE (SBOK Guide)

11 4 principais diferenças Ágil x Tradicional As 4 principais diferenças entre Processos Ágeis e Processos Tradicionais de Desenvolvimento 1. Participação do Cliente 2. Retorno do Investimento 3. Adaptabilidade 4. Risco Solutions Figuras extraídas de: 11

12 Índice de Sucesso Waterfall x Ágil Pesquisa: Chaos Report Standish Group SUCESSO Projeto finalizado no prazo, no orçamento e totalmente funcional Waterfall Ágil 14% 42% 49% DESAFIO Projeto finalizado com atraso, com estouro de orçamento e/ou não totalmente funcional 29% 57% 9% FALHA Projeto cancelado ou nunca utilizado

13 Princípios do Scrum Diretrizes fundamentais para a aplicação do Scrum e devem obrigatoriamente serem usados em todos os projetos Priorização baseada em valor Esse princípio destaca o foco do Scrum em entregar o máximo de valor de negócio possível, durante todo o projeto. Controle de Processo Empírico Esse princípio enfatiza a filosofia central do Scrum com base em três ideias principais: transparência, inspeção e adaptação. Time-boxing O tempo é considerado uma restrição limitada em Scrum. É usado para ajudar a gerenciar o planejamento e execução do projeto com eficácia. Princípios Scrum Colaboração Criação de valor compartilhado, com times trabalhando e interagindo em conjunto para atingirem melhores resultados Desenvolvimento Iterativo O Produto é desenvolvido em ciclos e o resultado se soma e modifica o que já se tem pronto do produto até o momento Auto-organização Equipes comprometidas e com responsabilidade compartilhada com um ambiente inovador e criativo

14 Manifesto Ágil Disponível em:

15 Comprometimento da Equipe Scrum Não basta estar envolvido, o comprometimento é essencial para entrega de valor

16 Comunicação da Equipe Scrum Comunicação é um ponto-chave dentro de metodologias ágeis

17 Solutions Figura extraída de:

18 Papéis x Projeto Visão Geral dos papéis dos integrantes do Time Scrum dentro do Projeto Projeto Time de Desenvolvimento Responsável pelo andamento do Projeto. Desenvolvedores devem preocupar-se com o Micro. Product Owner Responsável pela Visão do Produto e de repassar ao Time o problema do cliente. Deve preocupar-se com o Macro. Scrum Master Responsável por fazer o ambiente Scrum Funcionar. Deve preocupar-se com o Processo.

19 Papéis Scrum Fluxo de comunicação do Time Scrum (PO, SM e DevTeam) Figura extraída de: A Guide to the SCRUM BODY OF KNOWLEDGE (SBOK Guide)

20 Papéis e Responsabilidades Principais responsabilidades dos integrantes do Time Scrum Product Owner Scrum Master Time de Desenvolvimento É o Dono do Produto. Deve expressar claramente os itens do Backlog do Produto. Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões. Garantir o valor do trabalho e o ROI* realizado pelo Time de Desenvolvimento. Garantir que o Backlog do Produto seja visível e claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir. Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário. É um facilitador, um servo-líder que garante que o Scrum seja entendido e aplicado seguindo às regras e práticas. Remover impedimentos para o progresso do Time de Desenvolvimento. Facilitar os eventos Scrum conforme exigidos ou necessários. Ensinar e liderar o Time de Desenvolvimento na criação de produtos de alto valor. Treinar o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade. São os desenvolvedores. Eles são auto-organizados. Times de Desenvolvimento são multifuncionais. O Scrum não reconhece títulos para os integrantes que não seja o de Desenvolvedor. Integrantes podem ter habilidades especializadas mas a responsabilidade pertence ao Time como um todo. Times de Desenvolvimento não contém sub-times dedicados a domínios específicos. *Return On Investiment: Retorno Sobre Investimento - relação entre a quantidade de dinheiro ganho (ou perdido) como resultado de um investimento e a quantidade de dinheiro investido

21 Eventos Scrum Fluxo de atividades obrigatório dentro de um Sprint - Dividir para Conquistar Figura extraída de:

22 Eventos Scrum Fluxo de atividades obrigatório dentro de um Sprint Reunião de Planejamento O trabalho a ser realizado na Sprint é planejado na reunião de planejamento. Este plano é criado com o trabalho colaborativo de todo o Time Scrum. Máx.: 8 horas/sprint 1 mês Reunião Diária A Reunião Diária do Scrum é um evento timeboxed de 15 minutos, para que o Time possa sincronizar as atividades e criar um plano para as próximas 24 horas. Responde à 3 perguntas. Reunião de Revisão A Revisão da Sprint é executada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário. Não tem como objetivo receber aprovação, mas sim feedback. Reunião de Retrospectiva A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint Sprint Coração do Scrum; Time-boxed: 1-4 semanas; Resultado: Versão incremental potencialmente utilizável; Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior. A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto; Sprints permitem previsibilidade que garante a inspeção e adaptação do progresso em direção à meta; Sprints também limitam o risco ao custo de um mês corrido.

23 Artefatos Scrum Backlog do Produto: O Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O PO é responsável por ele Backlog da Sprint: Conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint. Definition of Done: Os integrantes devem ter um entendimento compartilhado do que significa o trabalho estar completo ( Pronto ) assegurando a transparência.

24 Planning Poker Técnica baseada no consenso para estimar esforço ou tamanho relativo de itens do Product Backlog Procedimento Planning Poker: Na figura acima é usada a sequência de Fibonacci adaptada Sugestão para jogar on-line: 1. A equipe em conjunto lê a descrição de todas as histórias do Product Backlog para ter uma visão geral do que deverá ser estimado. 2. Das histórias do Product Backlog, a equipe seleciona a que julga ser a mais simples de todas, isto é, a que demandará menos esforço para implementação. Para essa história a estimativa será de 2 pontos, que é o menor ponto do baralho selecionado para esse primeiro planning poker. 3. Pronto! Essa história será a história guia do processo de estimativas. Ela servirá como referência para as estimativas das demais. 4. Agora, seguindo a ordem apresentada no Product Backlog, cada história é relida e pontuada, tomando-se a história guia como referência.

25 Product Backlog

26 Sprint Backlog

27 Benefícios Metodologia Ágil Principais benefícios da utilização do Scrum Vantagem Competitiva Capacidade de responder às mudanças acolhidas como oportunidade de melhoria Produtividade Aumento da produtividade através de uma equipe autoorganizada e motivada Qualidade maior qualidade no produto gerado, pois o feedback do cliente é constante Entregas Frequentes Entregas frequentes de valor e mais rápido retorno ao investimento dos clientes Redução dos Riscos Redução dos riscos e desperdícios com o planejamento por Sprint Visibilidade Baseado na transparência, através das reuniões temos maior visibilidade do progresso do projeto

28 Gráficos de desempenho Medição de desempenho do Time Gráfico Burndown Gráfico Burnup

29 Empresas usando Scrum Algumas grandes empresas que apostaram no uso dessa metodologia ágil

30 Conclusão Devo utilizar Scrum? A Sua empresa concorda em mudar o ciclo de vida dos projetos para timeboxes de 1-4 semanas? B Sua organização concorda em juntar divisões funcionais clássicas como analistas, programadores, testers em um único time? C Sua empresa concorda em abrir mão de hierarquias rígidas tradicionais para uma estrutura mais horizontal? D A liderança concorda em permitir que a equipe multi-disciplinar se auto-organize e auto-gerencie seu trabalho? E Escolher um líder-servidor para atuar como ScrumMaster é algo fácil na sua organização ou vai gerar muita discussão? F O papel de Product Owner é facilmente identificável na sua organização? O cliente está próximo? G Sua empresa está disposta a cumprir com as reuniões obrigatórias (reunião de planejamento, diária, revisão e retrospectiva)? H Ela está disposta a abrir mão dos atuais mecanismos de controle (custos, prazo, escopo) para adotar a forma ágil de controle?

31 Obrigado pela atenção! Dúvidas, sugestões ou críticas, entre em contato conosco! Facebook.com/Fantastsoft Solutions 31