Scrum Introdução
Nós estamos perdendo a corrida de revezamento “A… abordagem ‘’corrida de revezamento” para o desenvolvimento de produtos…pode conflitar com os objetivos de máximas velocidade e flexibilidade. Por outro lado, uma abordagem holística ou ‘de rugby’ —onde um time tenta vencer a distância como uma unidade, passando a bola para frente e para trás — pode suprir melhor os requisitos atuais de competitividade.” would be nice to include a quote from Wicked Problems here Hirotaka Takeuchi e Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, Janeiro 1986.
Scrum em 100 palavras Scrum é um processo ágil que nos permite focar em entregar o maior valor de negócio no menos tempo possível. Ele nos permite inspecionar o produto funcionando de forma rápida e constante (a cada duas semanas ou um mês). O negócio determina as prioridades. Os times se auto gerenciam para determinar a melhor forma de entregar as funcionalidades mais prioritárias. A cada duas semanas ou um mês, todos podem ver um software que realmente funciona e decidir liberá-lo como está ou continuar a melhorá-lo por mais um sprint.
As origens do Scrum Jeff Sutherland Início do Scrum na Easel Corp em 1993 Mais de 500 pessoas utilizando Scrum Ken Schwaber Apresentou, em conjunto com Sutherland, Scrum na conferência OOPSLA 96 Autor de 3 livros sobre Scrum Mike Beedle Publicou padrões de Scrum na conferência PLOPD4 Ken Schwaber and Mike Cohn Fundaram a Scrum Alliance em 2002, inicialmente com parte da Agile Alliance
Scrum tem sido utilizado por: Intuit Nielsen Media First American Real Estate BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Oce Microsoft Yahoo Google Electronic Arts High Moon Studios Lockheed Martin Philips Siemens Nokia Capital One BBC
Scrum tem sido utilizado para: Softwares comerciais Desenvolvimentos internos Desenvolvimento sob contrato Projetos de preço fixo Aplicações financeiras Aplicações certificadas ISO 9001 Sistemas embarcados Sistemas 24x7 com disponibilidade de 99.999% Desenvolvimento de jogos Sistemas “life-critical” aprovados pela FDA Softwares de controle de satélites Websites Softwares para palms e celulares Aplicações de gerenciamento de rede Etc, etc, etc.
Características Times auto-gerenciáveis O progresso do produto acontece em uma série de “sprints” de um mês de duração Requisitos são capturados com itens de uma lista chamada “product backlog” Nenhuma prática de engenharia específica é prescrita Utiliza regras genéricas para criar um ambiente ágil para o desenvolvimento de projetos Um dos “processos ágeis”
Nível de “ruído” do projeto Instáveis Anarquia Complexo Requisitos Complicado Fonte: Strategic Management and Organizational Dynamics por Ralph Stacey em Agile Software Development with Scrum por Ken Schwaber e Mike Beedle. Simples Estáveis Tecnologia Bem conhecida Pouco conhecida
Scrum 24 horas Sprint 2-4 semanas Devolver Sprint goal Incremento do produto com potencial para implantação Sprint backlog Devolver Cancelar Empacotar Cupons Cancelar Empacotar Cupons Product backlog
Putting it all together Imagem disponível www.mountaingoatsoftware.com/scrum
Sprints Projetos Scrum projects progridem em uma sucessão de “sprints” Análogo às iterações de Extreme Programming Duração típica de 2 a 4 semanas ou 1 mês Uma duração constante proporciona um melhor ritmo O produto é projetado, codificado e testado durante o sprint
Desenvolvimento sequencial vs. paralelo Requisitos Projeto Codificação Teste Ao invés de fazer uma coisa de cada vez... ...equipes Scrum fazem um pouco de cada coisa todo tempo Fonte: “The New New Product Development Game” por Takeuchi e Nonaka. Harvard Business Review, Janeiro 1986.
Nenhuma mudança é permitida durante o sprint A duração dos sprints é planejada de acordo com o tempo em que é possível se comprometer a manter as mudanças fora do sprint
Papéis Product owner ScrumMaster Time Burocracias Sprint planning Scrum framework Product owner ScrumMaster Time Papéis Sprint planning Sprint review Sprint retrospective Daily scrum meeting Burocracias Product backlog Sprint backlog Gráfico de Burndown Artefatos
Papéis Product owner ScrumMaster Time Burocracias Sprint planning Scrum framework Product owner ScrumMaster Time Papéis Sprint planning Sprint review Sprint retrospective Daily scrum meeting Burocracias Artefatos Product backlog Sprint backlog Gráfico de Burndown
Papéis: Pigs x Chickens
Product owner Define as funcionalidades do produto Decide a data e o conteúdo da entrega É responsável pelo retorno do investimento (ROI) Prioriza funcionalidades de acordo com o valor de negócio Tira dúvidas da equipe durante os Sprints Ajusta funcionalidades e prioridades a cada iteração, quando necessário Aceita ou rejeita os resultados do trabalho
ScrumMaster Cuida da gestão do projeto Responsável por garantir o uso dos princípios e práticas do Scrum Remove impedimentos Garante a produtividade do time Garante a cooperação entre todos os papéis e funções Protege o time de interferências externas
Time Tipicamente de 5 a 9 pessoas Multi-disciplinar: Programadores, testadores, designers, etc. Membros devem ter dedicação full-time Pode haver exceçõe (ex: DBA) Times são auto-gerenciáveis Idealmente sem hierarquias, mas nem sempre é possível Membros só podem mudar entre sprints
Papéis Product owner ScrumMaster Time Burocracias Sprint planning Scrum framework Sprint planning Sprint review Sprint retrospective Daily scrum meeting Burocracias Product backlog Sprint backlog Gráfico de Burndown Artefatos
Sprint planning meeting Capacidade do time Priorização Analisar e avaliar o product backlog Escolher o objetivo do sprint Objetivo do Sprint Product backlog Condições de negócio Planejamento Decidir como alcançar o objetivo do sprint (design) Criar o sprint backlog (tarefas) a partir dos itens do product backlog (funcionalidades) Estimar o sprint backlog em horas Produto atual Sprint backlog Tecnologia
Planejamento do Sprint O time seleciona os itens do Product Backlog que eles podem se comprometer a completar no tempo do Sprint O Sprint Backlog é criado Tarefas são identificadas e cada uma delas é estimada (1-16 horas) Feito de forma colaborativa e não apenas pelo ScrumMaster Projeto de alto-nível é considerado Como turista, eu quero ver fotos dos hotéis. Codificar a camada do meio (8 horas) Codificar a interface com o usuário (4) Escrever classes de teste (4) Codificar a classe X (6) Atualizar testes de performance (4)
Daily Scrum Meeting Diária 15 minutos Em pé (Stand-up Meeting) Parâmetros Diária 15 minutos Em pé (Stand-up Meeting) Não objetiva a resolução de problemas Todo mundo é convidado Apenas os membros do Time, o ScrumMaster e o Product Owner podem falar Ajuda a evitar reuniões desnecessárias
Cada pessoa responde três perguntas O que você fez ontem? 1 O que você vai fazer hoje? 2 Algo está te impedindo? 3 Não é comunicação de status para o ScrumMaster É um compromisso assumido perante a equipe
Sprint Review Regra das 2 horas de preparação Sem slides O Time apresenta o que foi realizado ao longo do Sprint Normalmente na forma de uma demonstração das novas funcionalidades e da arquitetura relacionada Informal Regra das 2 horas de preparação Sem slides Todos participam Convide o mundo todo
Sprint retrospective ScrumMaster Product owner Time Verificar periodicamente o que está e o que não está funcionando Normalmente de 15 a 30 minutos Realizado após cada sprint Todo a equipe participa ScrumMaster Product owner Time Possivelmente clientes e outras pessoas
Começar / Parar / Continuar Todo o time lista e discute o que eles gostariam de: Começar a fazer Parar de fazer Esta é apenas uma das muitas formas de fazer uma Sprint Retrospective. Continuar fazendo
Papéis Product owner ScrumMaster Time Burocracias Sprint planning Scrum framework Product owner ScrumMaster Time Papéis Sprint planning Sprint review Sprint retrospective Daily scrum meeting Burocracias Product backlog Sprint backlog Gráfico de Burndown Artefatos
Esse é o Product Backlog Os requisitos Uma lista de todo trabalho desejado no projeto Idealmente expressado de forma que os itens tenham valor para os usuários e clientes do produto Priorizado pelo Product Owner Repriorizado no início de cada sprint Estimado pela equipe com base em pontos (Story Points) Esse é o Product Backlog
Exemplo de Product Backlog Item de Backlog Estimativa Permitir a um hóspede fazer uma reserva. 3 Como hóspede, eu quero cancelar uma reserva. 5 Como hóspede, eu quero mudar as datas de uma reserva. Como funcionário do hotel, eu quero gerar relatórios de bônus por quartos vagos 8 Melhorar tratamento de exceções ... 30
Estimando itens do Product backlog – Planning Poker Estimativa pela equipe – Com Planning Poker ScrumMaster: Qual o tamanho desta funcionalidade?
O Objetivo do Sprint Ciências naturais Uma frase curta que determina o foco do trabalho durante o Sprint Ciências naturais Dar suporte a funcionalidades necessárias para estudos genéticos da população. Aplicação de BD Fazer a aplicação rodar também em SQL Server, além de Oracle. Serviços financeiros Dar suporte ao indicador ABC da empresa com dados em tempo real.
Gerenciando o Sprint Backlog Os membros do Time se voluntariam para o trabalho escolhido por eles mesmos O trabalho nunca é atribuído O trabalho restante estimado é atualizado diariamente Qualquer membro do time pode adicionar, remover ou alterar itens do Sprint Backlog O trabalho para o Sprint surge naturalmente Se o trabalho a fazer não está claro, defina um item no Sprint Backlog com um tempo maior e quebre-o em vários itens mais tarde Atualize o trabalho restante à medida Update work remaining as more becomes known
Exemplo de Sprint Backlog Tarefas Seg Ter Qua Qui Sex Codificar GUI Adicionar log de erro 8 10 16 8 16 12 4 12 16 8 4 11 8 8 Codificar camada central Testar camada central Escrever help online Escrever classe X
Gráfico de Burndown de um Sprint Hours
Tarefas Seg Ter Qua Qui Sex 8 4 12 16 8 10 16 7 11 8 16 8 12 Codificar GUI 8 4 12 16 8 10 16 7 11 8 Codificar camada central 16 Testar camada central 8 Escrever help online 12 50 40 30 Horas 20 10 Seg Ter Qua Qui Sex
Escalabilidade A escalabilidade é realizada com times de times Cada time, individualmente, tem 7 ± 2 pessoas A escalabilidade é realizada com times de times Fatores que definem a necessidade de escalar Tipo de aplicação Tamanho do time Dispersão geográfica do time Duração do projeto Scrum já foi utilizado em projetos com mais de 500 pessoas
Escalando através de Scrum de scrums
Scrum de scrums de scrums
Exercício Projeto: Webmail Objetivo: Construir um webmail corporativo parecido com o GMail 1 pessoa atua como Product Owner 1 pessoa atua como ScrumMaster Definir lista priorizada de funcionalidades (Product Backlog) Estimar itens do Product Backlog utilizando o Planning Poker Determinar o objetivo do Sprint 1 e escolher itens que entrarão no Sprint Backlog do Sprint 1 (assumindo produtividade de 20 Story Points por Sprint e Sprint de 2 semanas) Criar lista de tarefas para Sprint, estimá-las e distribuir entre o Time “Inventar” o status das tarefas no final de cada dia e criar o Gráfico de Burndown do Sprint 1
Onde encontrar mais sobre Scrum Agile and Iterative Development: A Manager’s Guide por Craig Larman Agile Estimating and Planning por Mike Cohn Agile Project Management with Scrum por Ken Schwaber Agile Retrospectives por Esther Derby e Diana Larsen Agile Software Development Ecosystems or Jim Highsmith Agile Software Development with Scrum por Ken Schwaber e Mike Beedle Scrum and The Enterprise por Ken Schwaber User Stories Applied for Agile Software Development por Mike Cohn www.mountaingoatsoftware.com/scrum www.scrumalliance.org www.controlchaos.com scrumdevelopment@yahoogroups.com
Nota de Copyright Presentation by: Mike Cohn Apresentação parcialmente baseada em: Presentation by: Mike Cohn mike@mountaingoatsoftware.co m www.mountaingoatsoftware.com (720) 890-6110 (office)