SCRUM aplicado na Gerência de Projetos

Transcrição

1 SCRUM aplicado na Gerência de Projetos

2 Processo Conjunto de atividades ordenadas, restrições e recursos que produzem um resultado de algum tipo. (Pfleeger) Em software: Processo de desenvolvimento Define quem faz o quê, quando e como O processo guia o desenvolvimento do software

3 Por que precisamos de um processo? Desenvolver software envolve pessoas Precisamos definir suas atividades, artefatos, prazos, prioridades Precisamos planejar, estimar, executar E controlar a evolução do desenvolvimento O processo estrutura o planejamento, execução e controle das atividades e artefatos gerados

4 Processos Tradicionais Processos pesados ou focados em planejamento Contexto: Requisitos não mudam (ou mudam pouco) com o tempo. Grande esforço no planejamento e projeto do software. Gerência focada nos papéis desempenhados pelas pessoas: programador, arquiteto, analista, testador,...

5 Comparando metodologias atuais

6 Manifesto Ágil Resposta à insatisfação com os processos tradicionais de desenvolvimento de software Estabelece os valores: Indivíduos e Interações mais que Processos e Ferramentas Software Funcionando mais que Documentação Colaboração com o cliente mais que Contrato Resposta a mudanças mais que Seguir planejamento Embora tenham valor os itens da direita, nós valorizamos mais os itens da esquerda

7 Agilidade de Dilbert

8 Processo Ágeis Muito mais do que simples definições de processos Afetam várias dimensões das empresas e dos projetos Relação profissional Atribuição de responsabilidades e confiança Relação com clientes Parceria ao invés da relação de prestação de serviço Formato contratual Contratos têm que ser adaptáveis

9 Requisitos para uso de processos ágeis Cliente sempre presente Requisitos mudam com muita freqüência Requisitos imprevisíveis Equipe forte, bons profissionais Profissionais devem ser capazes de tomar decisões Não adotar contrato com valor fixo Contrato fixo -> requisitos fixos -> não usar processos ágeis

10 Quando não usar processos ágeis Cliente ausente Reuniões a cada dois meses. Requisitos fixos, com pouca mudança no tempo Equipe volátil e despreparada Contratos com valor e escopo fixos Submissão a programas de certificação de qualidade, como CMMI É necessário incorporar muitas atividades nos processos ágeis para atenderem aos requisitos dos programas de qualidade.?

11 Processos ágeis são uma boa idéia Quando aplicados no contexto adequado Não são tão leves assim Standup meeting, testes constantes, iterações curtas, releases pequenas, Exigem disciplina e competência da equipe

12 SCRUM em poucas palavras

13 SCRUM Criado por Ken Schwaber e Jeff Sutherland em 1996; Surgiu para recuperar um projeto problemático; Ciclo PDCA; Foco em valor e nas interações; Mudanças são incentivadas; Time boxed ; Processo empírico. Não sabemos ao certo onde queremos chegar Desenvolvemos baseados nas experiências

14 SCRUM em resumo

15 SCRUM no taskboard

16 Envolvimento versus comprometimento

17 SCRUM atores São três atores principais e mais um grupo de secundários: PRODUCT OWNER SCRUM MASTER TEAM E os secundários: CHICKENS

18 Introdução ao SCRUM

19 Scrum em 100 palavras Scrum é um processo ágil que permite manter o foco na entrega do maior valor de negócio, no menor tempo possível. Isto permite a rápida e contínua inspeção das entregas (em intervalos de duas a quatro semanas). As necessidades do negócio é que determinam as prioridades. As equipes se auto-organizam para definir a melhor maneira de entregar em conformidade com a prioridade. Entre cada duas a quatro semanas todos podem ver a real entrega, decidindo se as mesmas devem ser liberadas ou continuar a serem aprimoradas por mais um Sprint.

20 Características Equipes que se auto-organizam O produto evolui em uma série de Sprints Os requisitos são listados em um Product Backlog Não há prática de engenharia prescrita (o Scrum adequa-se a todas) Usa regras culturais na criação de um ambiente ágil para a entrega de projetos É uma das metodologias ágeis

21 Manifesto Ágil Resposta à insatisfação com os processos tradicionais de desenvolvimento de software Estabelece os valores: Indivíduos e Interações mais que Processos e Ferramentas Software Funcionando mais que Documentação Colaboração com o cliente mais que Contrato Resposta a mudanças mais que Seguir planejamento Embora tenham valor os itens da direita, nós valorizamos mais os itens da esquerda

22 SCRUM em resumo

23 Sprints Projetos Scrum progridem em uma série de sprints Similar às iterações do XP Ocorre em um período de duas a quatro semanas Um período constante leva a um melhor ritmo O produto passa por todas as fases necessárias durante o sprint

24 Nenhuma mudança durante o Sprint Planeje a duração dos sprints de acordo com o máximo tempo com o qual você pode se comprometer a deixar as mudanças fora deles (um mês ou menos) Change

25 SCRUM Framework - Papéis Papéis Dono do produto ScrumMaster Equipe Cerimônia Planejamento Revisão Retrospectiva Reunião diária Artefatos Product backlog Sprint backlog Burndown charts

26 Dono do produto Responsável pela rentabilidade (ROI) Define as funcionalidades do produto Decide datas de lançamento e conteúdo Prioriza funcionalidades de acordo com o valor de mercado Ajusta funcionalidades e prioridades Aceita ou rejeita o resultado dos trabalhos

27 Scrum Master Representa a gerência para o projeto Responsável pela aplicação dos valores e práticas do Scrum Remove impedimentos Garante a plena funcionalidade e produtividade da equipe Garante a colaboração entre os diversos papéis e funções Escudo para interferências externas

28 Equipe Entre 5 e 9 pessoas Multi-funcional Tempo integral na equipe Auto-organizável Idealmente, sem títulos, ainda que possível Trocas só na mudança de Sprints

29 SCRUM Framework - Cerimônia Papéis Dono do produto ScrumMaster Equipe Cerimônia Planejamento Revisão Retrospectiva Reunião diária Artefatos Product backlog Sprint backlog Burndown charts

30 Planejamento do Sprint Capacidades da equipe Product backlog Planejamento Priorização Análise e avaliação do product backlog Objetivo do sprint Objetivo Condições de negócio Produto atual Tecnologia Plano Decidir como chegar ao objetivo (projeto) Cria tarefas do sprint backlog a partir dos itens do product backlog (user stories / funcionalidades) Horas no sprint backlog Sprint backlog

31 Planejamento do Sprint A equipe seleciona itens do Product Backlog com os quais compromete-se a concluir O Sprint Backlog é criado Tarefas identificadas e estimadas (1 a 16 horas) De forma colaborativa, não apenas feito pelo ScrumMaster Planejamento de alto nível é considerado

32 Scrum diário Parâmetros Diário 15 minutos Todos em pé! Não é para a solução de problemas Todo mundo é convidado Apenas os membros da equipe, ScrumMaster, dono do produto podem falar Ajuda a evitar reuniões adicionais desnecessárias

33 Três questões, para todos O que foi feito ontem? O que será feito hoje? 1 2 Há algum impedimento? 3

34 Três questões, para todos As respostas não são um relatório para o ScrumMaster Elas são COMPROMISSOS perante todos os participantes

35 Revisão do Sprint Equipe apresenta os resultados obtidos durante o Sprint Tipicamente, demonstração de novas funcionalidades ou sua arquitetura Informal 2 horas de preparação Sem slides Todo o time participa O mundo é convidado

36 Retrospectiva do Sprint Feita após o término de cada Sprint Periodicamente, observe o que funciona e o que não funciona Tipicamente de 15 a 30 minutos Toda a equipe participa ScrumMaster Dono do produto Membros da equipe Clientes e outros

37 Inicia, Pára, Continua A equipe discute o que gostaria de: Iniciar a fazer Parar de fazer Esta é uma das várias maneiras de se conduzir uma retrospectiva do Sprint Continuar fazendo

38 SCRUM Framework - Artefatos Papéis Dono do produto ScrumMaster Equipe Cerimônia Planejamento Revisão Retrospectiva Reunião diária Artefatos Product backlog Sprint backlog Burndown charts

39 Product Backlog Este é o Product Backlog Os requisitos Uma lista de todo o trabalho desejado no projeto Idealmente, na forma em que cada item tenha seu peso de acordo com a vontade do cliente ou usuários Priorizado pelo dono do produto Repriorizado no início de cada Sprint

40 O objetivo do Sprint Breve declaração que ilustre o foco do trabalho durante o Sprint Base de Dados Fazer com que a aplicação rode no SAL Server além do PostgreSQL Serviços financeiros Criar suporte para indicadores de desempenho em tempo real

41 Gerenciamento o Sprint Backlog Cada indivíduo escolhe o trabalho que fará Trabalhos nunca são atribuídos Atualização diária da estimativa do trabalho restante Qualquer membro da equipe pode adicionar, apagar ou mudar tarefas O trabalho aparece a partir do Sprint Se uma tarefa não é clara, defina-a como um item com uma quantidade maior de tempo e subdivida-a depois Atualize as coisas a serem feitas na medida em que se tornam mais conhecidas

42 Sprint Backlog Tarefas Seg Ter Qua Qui Sex Codificar interface de usuário Codificar regra de negócio Testar Escrever help online 12 Escrever a classe foo Adicionar log de erros 8 4

43 Burndown Chart

44 Horas Seg Ter Qua Qui Sex

45 SCRUM no taskboard

46 Referências 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

47 Referências Artigos de Cesar Brod, sobre Scrum, no Dicas-L Procure por Scrum Links para exemplos online de Sprint e Product Backlog

48 Referências Agile and Iterative Development: A Manager s Guide by Craig Larman Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Software Development Ecosystems by Jim Highsmith Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Scrum and The Enterprise by Ken Schwaber User Stories Applied for Agile Software Development by Mike Cohn Artigos semanais em

49 Contato Criação: Mike Cohn +1 (720) (escritório) Tradução e adaptação: Cesar Brod [email protected]