minicurso scrum

ScrumGestão ágil de projetos

Autores:Fábio Abrantes Diniz

Íthalo Bruno de Moura

Thiago Reis da Silva

Diego Grosmanniz

ScrumGestão ágil de projetos

Apresentadores:

Fábio Abrantes Diniz

Íthalo Bruno de Moura

31% são cancelados 53% custam o dobro do estimado

Apenas 16% são completados no

prazo e custo estimados

* dados do CHAOS report

Mas por que?

Falta de envolvimento do usuário

Requisitos e especificações incompletas

Falta de suporte da direção

Falta de Pessoas e Recursos

Falta de ESTIMATIVAS!!!

Falhar é uma maneira muito

forte de aprendizado, mas é

preciso parar de apontar culpados

Olá, Scrum!Por que o nome Scrum?

O nome é proveninente de uma jogada do Rugby, onde é demostrada a força de trabalho em equipe.

O Scrum do Rugby é formado por até 8 pessoas de cada equipe.

O objetivo do Scrum no Rugby é avançar a bola oval no campo adversário o máximo possível. Para isso é necessário um ótimo trabalho em equipe.

Scrum é também um meio de

evidenciar os problemas

Mas Scrum não é bala de prata*

* Não mata vampiros & afins* Exige trabalho duro e comprometimento

P D C APlan, Do, Check, Act

Planejamento

Execução

Checagem

Exatamente o que Scrum faz!

Quem usa o Scrum

• Microsoft• Yahoo• Google• Lockheed Martin• Philips• Siemens• Nokia• BBC

Scrum tem sido usado para

• Software comercial• Desenvolvimento interno (empresa)• Desenvolvimento contratado (terceirização)• Aplicações financeiras• Sistemas embarcados• Jogos• Sistemas para controle de satélites• Websites• Telefones celulares

Características do Scrum

• As equipes se auto-organizam

• O produto evolui em uma série de “Sprints” mensais

• Os requerimentos são listados em um “Product Backlog”

• Não há prática de engenharia prescrita (o Scrum adequa-se a todas)

• É uma das “metodologias ágeis”

Papeis no scrum

Product Owner

• O representante do cliente

Scrum Master

• O Scrum Master lidera o time de desenvolvimento

Scrum Team

• Scrum Team São os membros que formam o time de desenvolvedores, designers, consiste de 5 a 9 pessoas.

© 2006 BenQ Mobile 26

►Define as funcionalidades do produto assim como conteúdo e data das liberações;

►Responsável pela rentabilidade do produto;►Prioriza as funcionalidades de acordo com o valor do mercado;►Pode mudar as funcionalidades e priorizar a cada 30 dias;►Aceita ou rejeita os resultados do trabalho.

►Estimar itens do backlog►Tem o direito de realizar quaisquer atividades para alcançar

o objetivo da iteração desde que respeite os guidelines do projeto;

►Auto organizados para entregar o que o PO quer.

►Garante que a equipe está completamente funcional e produtiva;►Facilita comunicação entre papéis e remove impedimentos;►Protege a equipe contra interferências externas;►Assegura que o processo é seguido;►Coordena os encontros diários, revisão e planejamento da

iteração.

Product Owner

Scrum Master

Team

Papéis e Responsabilidades

Ciclo de Vida

Ciclo de vida do ScrumFonte: Adaptado de Improve It (2008)

Ciclo de Vida

Ciclo de vida do ScrumFonte: Adaptado de Improve It (2008)

Ciclo de Vida

Ciclo de vida do ScrumFonte: Adaptado de Improve It (2008)

O Product Backlog é uma lista de todas as funcionalidades desejadas no

produto, estimadas pelo time e priorizadas pelo

Product Owner.

Exemplo de Product Backlog

O Product Backlog

EmergentePriorizado e estimado

Maior prioridade, mais detalhesPriorização é tarefa do PO

Alinhado ao plano de negócios

O Product BacklogEmergente

Priorizado e estimadoMaior prioridade, mais detalhes

Priorização é tarefa do POAlinhado ao plano de negócios

O Product BacklogEmergente

Priorizado e estimado

Maior prioridade, mais detalhesPriorização é tarefa do PO

Alinhado ao plano de negócios

O Product BacklogEmergente

Priorizado e estimadoMaior prioridade, mais detalhes

Priorização é tarefa do POAlinhado ao plano de negócios

O Product BacklogEmergente

Priorizado e estimadoMaior prioridade, mais detalhes

Qualquer um pode contribuirPriorização é tarefa do PO

Alinhado ao plano de negócios

Sprints

• Representa um Time Box (uma iteração), dentro do qual um conjunto de atividades deve ser executado

• Ocorre em um período de duas a quatro semanas

• Baseia-se na idéia de que um período constante leva a um melhor “ritmo”

• O produto é projetado, codificado e testado durante o Sprint

• No início de cada Sprint, faz-se um Sprint Planning Meeting

Sprints - Sprint Planning Meeting -

• É uma reunião de planejamento na qual:o O Product Owner prioriza os itens do Product

Backlogo O Scrum Team determina que atividades será

capaz de implementar durante o novo Sprint e cria o Sprint Backlog

o O Scrum Team e o Product Owner definem um objetivo para o Sprint

• O sucesso do Sprint será avaliado mais adiante no Sprint Review Meeting em relação ao objetivo traçado para o Sprint

Sprints - Sprint Backlog -

• É uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint

• Seus itens são extraídos do Product Backlog com base nas prioridades definidas pelo Product Owner• Uma estimativa do tempo necessário para a

implementação das funcionalidades

• O Scrum Master mantém o Sprint Backlog atualizado

Sprints - Daily Scrum -

– É uma reúnião diária da equipe dentro do Sprint, que tem por objetivo:o Disseminar conhecimento sobre o que foi feito no

dia anterioro Identificar impedimentoso Priorizar o trabalho a ser realizado no dia que se

inicia – Os impedimentos identificados devem ser tratados

pelo Scrum Master o mais rapidamente possível

Obs: o Daily Scrum não deve ser usado como uma reunião para resolução de problemas

Sprints - Daily Scrum -

• Três Questões para todos:

• O que fizeste ontem?• O que vais fazer Hoje?• Há Algum obstáculo?

• Obs: As respostas não são um

relatório para o Scrum Master. Elas são comprimissos dentro do Scrum Team.

Sprints - Sprint Review Meeting -

O ScrumTeam e o SCRUM Master apresentam ao Product Owner os resultados alcançados durante o sprint.

Sprints - Sprint Retrospective -

O Sprint Retrospective ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar. Todos participam:

–Scrum Master–Product Owner–Scrum Team

Sprints - Sprint Retrospective -

Em uma das maneiras de se conduzir um Sprint Retrospective, a equipe discute o que gostaria de:

– Iniciar a fazer– Parar de fazer– Continuar fazendo

© 2006 BenQ Mobile 45

• Software desktop destinado a usuários finais de celulares BenQ-Siemens• Projeto complexo com 300,000 LOC possuindo um ciclo de vida médio

→ Interação complexa com o ambiente físico (celular)

→ Uma série de versões intermediárias (builds) precisam ser desenvolvidas e testadas.

→ O software deve suportar diferentes modelos de celulares e rodar em diferentes distribuições do Linux

Estudo de Caso: O Projeto XMPM (1)

Características do Projeto

→ Desenvolvido por três parceiros situados fisicamente em localidades diferentes.

→ Necessidade de boa comunicação entre as equipes de desenvolvimento.

→ Definição clara de papéis e responsabilidades.

© 2006 BenQ Mobile 46

Estudo de Caso: O Projeto XMPM (2)

XMPM

Características do Produto

→ Suporte a 9 (nove) diferentes idiomas;

→ Possui instalador gráfico para as seguintes distribuições (supporte oficial):

- Ubuntu 5.10

- Suse 10

- Mandriva 2006

→ Algumas das funcionalidades do XMPM incluem:

- Sincromização de contatos, tarefas, notas e calendário entre o telefone celular BenQ-Siemens e KDE-Kontact.- Acesso à internet através de uma conexão GPRS.

- Acessa ao sistema de arquivos e suporte a diferentes formatos de música.

© 2006 BenQ Mobile 47

Estudo de Caso: O Projeto XMPM (3)Práticas adaptadas para o contexto do projeto

Sprint:- No projeto XMPM foram usados 5 sprints e cada sprint com duração de aproximadamente 30 dias.

- Sprints de 30 dias fornecem uma melhor visibilidade dos objetivos do projeto e comprometimento da equipe.

- Iterações mais curtas podem melhorar a visibilidade do projeto e permitir que riscos e incertezas sejam eliminados o mais rápido possível.

© 2006 BenQ Mobile 48

Estudo de Caso: O Projeto XMPM (4)

Práticas adaptadas para o contexto do projeto

Planejamento do Sprint:

- Duas reuniões são conduzidas no ínicio de cada iteração.

- A primeira é realizada internamente com o product owner e visa refinar e priorizar o backlog do produto.

- A segunda é realizada com os parceiros e visa criar o backlog do sprint de modo a atender os objetivos da iteração.

© 2006 BenQ Mobile 49

Estudo de Caso: O Projeto XMPM (5)

Práticas adaptadas para o contexto do projeto

Revisão do Sprint:

- A equipe apresenta no final de cada iteração os resultadosobtidos (software funcionando) para o product owner e parceiros.

- Esta prática impõe que a equipe trabalhe arduamente para alcançar os objetivos prometidos para a iteração.

© 2006 BenQ Mobile 50

Estudo de Caso: O Projeto XMPM (6)

Reunião de Retrospectiva:

- O Scrum master e a equipe participam desta reunião.

- O que deu certo durante o sprint e o que poderia ser melhorado.

© 2006 BenQ Mobile 51

Estudo de Caso: O Projeto XMPM (7)

Práticas adaptadas para o contexto do projeto

Reuniões Diárias do Scrum:

- O quê você fez desde o último report?- O quê você irá fazer até a próxima reunião?-Existe algum bloqueio para alcançar os objetivos da iteração?- Alguma lição aprendida ou decisão tomada?

- As reuniões diárias ajudam a saber o quê cada membro da equipe está fazendo, compartilhar conhecimento e fornece uma boa visão para o Scrum Master.

© 2006 BenQ Mobile 52

Estudo de Caso: O Projeto XMPM (8)Práticas adaptadas para o contexto do projeto

Builds Diários:

- Builds diários no branch de cada parceiro e um build semanal no ramo principal do projeto (uso de padrões de gerência de configuração).

© 2006 BenQ Mobile 53

Estudo de Caso: O Projeto XMPM (9)

Práticas sendo adaptadas para o contexto do projeto

Teste antes do desenvolvimento:

- Esta prática é simples em conceito, mas requer intensa preparação técnica.

- Esta prática força o desenvolvedor pensar sobre o que o código deveria fazer antes de realmente implementá-lo.

- Caso o desenvolvedor não seja capaz de escrever o caso de teste para o código então provavelmente existem problemas de projeto.

- Depois de criar e executar o teste unitário, o mesmo torna-se apenas uma instância de testes de regressão.

© 2006 BenQ Mobile 54

Resumo e PerspectivaResumo

Perspectiva

• A prática “revisão do sprint” exige que a equipe se esforce para cumprir com os objetivos prometidos da iteração.

• A prática “teste antes do desenvolvimento” evita a criação de classes complexas e assegura a qualidade do código.

• As práticas melhoram a visibilidade do projeto e reduzem riscos e incertezas no início do ciclo de desenvolvimento.

• O fator terceirização adiciona mais complexidade ao uso do Scrum.

• Adaptação dos métodos ágeis para desenvolvimento de sistemas embarcados.

Conclusão

Scrum é uma metodologia de gerenciamento de projetos que está se tornando cada vez mais comum na industria de software. É bastante eficiente quando utilizado por equipes pequenas, mas pode tranquilamente ser usado em projetos com grandes equipes.

O Scrum tem como vantagens a velocidade, um bom controle do cronograma, diminuição dos riscos e incertezas e a visibilidade - graças às constantes reuniões.

Por outro lado, a grande desvantagem do Scrum é a sensação de informalidade, devida a falta de documentação formal do software.

?

• http://br.groups.yahoo.com/group/scrum-brasil/

• http://blogdoabu.blogspot.com/2008/11/planning-poker.html

• http://planningpoker.com/

• http://netfeijao.blogspot.com/2008/10/estimativas-geis-planning-poker.html

• Ken Schwaber. Agile Project Management with Scrum. Ed. Microsoft Press 2004

• Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi &Warsta, Juhani. Agile Software Development Method, Review and Analysis. Espoo 2002. VTT Publications 478. 107p

• Henrik Kniberg. Scrum and XP Direto das trincheiras. Ed. Enterprise Software Development Community, 2007.

Planning Poker An agile estimating

technique for agile and Scrum teamsGestão ágil de projetos

Apresentadores:Fábio Abrantes Diniz

Íthalo Bruno de Moura

31% são cancelados 53% custam o dobro do estimado

Apenas 16% são completados no

prazo e custo estimados

* dados do CHAOS report

Mas por que?

Falta de envolvimento do usuário

Requisitos e especificações incompletas

Falta de suporte da direção

Falta de Pessoas e Recursos

Falta de ESTIMATIVAS!!!

É difícil estimar tempos de execução

Time*

*Tudo eu! Tudo eu!

2±9

7

Responsabilidades:• Estimar itens do backlog

• Se comprometer a entregar um incremento funcional de software

• Gerenciar o próprio progresso

• Auto organizados para entregar o que o PO quer

As cerimônias do SCRUM

Reunião de Estimativa:• Preparação para o Sprint Planning

• Estimar baseado no tamanho, nunca em tempo

• Atualizar Product Backlog com as estimativas

• Importante para o PO criar o release plan

O Product BacklogEmergente

Priorizado e estimadoMaior prioridade, mais detalhes

Qualquer um pode contribuirPriorização é tarefa do PO

Sempre visívelAlinhado ao plano de negócios

Scrum foca em

tamanho e

não em duração

Estimar em tamanho relativo é mais simples

Planning Poker

• É um método eficiente que estima o tamanho dos requisitos em times que adotam métodos ágeis (SCRUM, XP).1

• O método foi primeiramente descrito por James Grenning em 2002 e, mais tarde popularizado por Mike Cohn no livro Agile Estimating and Planning.

1 – É uma variação do método de estimativa Wideband Delphi (1940)

Planning Poker

• As estimativas acontecem em reuniões:– Geralmente 4 ou 8 horas.– Paticipantes:

• Todos os membros do time do Scrum;• O PO somente esclarece os requisitos e não

estima junto a equipe;• O Scrum Master registra os resultados, não

interferindo nas estimativas do time;• A equipe não deve ser superior a dez pessoas.

O Processo

1. Cada membro do time recebe um deck de cartas: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? e

“pausa”.

http://en.wikipedia.org/wiki/Planning_poker

O Processo

2. Os itens a serem estimados são lidos pelo PO ou SM

A equipe decide qual o menor item de backlog disponível.

http://blogdoabu.blogspot.com/2008/11/planning-poker.html

O Processo

3. Após a estimativa inicial, esse item é marcado como “2” pontos

Serve para definir uma referência de tamanho e complexidade para ser usada nas demais estimativas.

E deve ficar registrado para uso nas futuras reuniões.

Em casos excepcionais o time pode decidir mudar esta estória de referência por uma outra.

O Processo

4. Para cada estória o SM ou PO lê a descrição e os critérios da aceitação da mesma. São respondidos questionamentos a

respeito da estória; Manter a discussão em alto nível, não entrar em

detalhes. Tempo prefixado (timebox) nesta etapa.

O Processo

5. Cada desenvolvedor escolhe em silêncio a carta que representa sua estimativa. O moderador pede para todos mostrarem

as cartas.

http://blogdoabu.blogspot.com/2008/11/planning-poker.html

O Processo

6. Se todas as estimativas convergirem, a estimativa está feita e o processo volta ao início, para um novo item. Se houver uma grande variação na

estimativa, aqueles que apresentaram o(s) maior(es) e o(s) menor(es) valor(es) se justificam.

O processo se repete até todas as estimativas convergirem.

Dinâmica

• Grupo

• São Paulo

• Rio Grande do Norte

• Paraíba

• Goiás

• Amazonas

• Sergipe

• Paraná

Conclusões

• O Planning Poker é uma prática eficiente de estimação de requisitos

• Por ser uma técnica bastante flexível, se enquadra

• É uma prática que envolve todo o time– Ajuda times novos a se conhecerem

• Realmente funciona!!!

?

• http://br.groups.yahoo.com/group/scrum-brasil/

• http://blogdoabu.blogspot.com/2008/11/planning-poker.html

• http://planningpoker.com/

• http://netfeijao.blogspot.com/2008/10/estimativas-geis-planning-poker.html

• Ken Schwaber. Agile Project Management with Scrum. Ed. Microsoft Press 2004

• Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi &Warsta, Juhani. Agile Software Development Method, Review and Analysis. Espoo 2002. VTT Publications 478. 107p

• Henrik Kniberg. Scrum and XP Direto das trincheiras. Ed. Enterprise Software Development Community, 2007.

Referências