minicurso scrum
TRANSCRIPT
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