O documento descreve os princípios e práticas da metodologia Scrum para gestão ágil de projetos. Scrum é um framework que permite entregar valor ao cliente de forma incremental através de sprints curtas e feedback constante. O documento explica os papéis de Product Owner, Scrum Master e time, assim como artefatos como backlog do produto e burn down.
1. Gestão Ágil de Projetos com Scrum
Noaldo Sales Santos Filho
noaldo@gmail.com
Noaldo Sales Santos Filho
2. Motivação
• 1986 um paper foi publicado comparando a
construção de pontes e a construção de
softwares. Como premissa foi utilizado:
– Pontes normalmente são entregues no prazo, dentro
do orçamento e “não caem”
– Softwares raramente são entregues no prazo ou dentro
do orçamento. E normalmente eles tem bugs.
• Razões para o sucesso na construção de
pontes:
– Alto nível de detalhe em momento de design;
– O design é congelado e o contratante tem pouquíssima
flexibilidade de mudanças.
Noaldo Sales Santos Filho
3. Motivação
• The Standish Group fez uma pesquisa e em
2009 publicou:
• 24% dos projetos fracassam;
• 44% dos projetos são entregues com sucesso
parcial;
• E apenas 32% dos projetos obtêm sucesso.
Noaldo Sales Santos Filho
4. Motivação
• Os principais fatores que ajudaram no sucesso dos
projetos foram:
– Envolvimento do usuário: 15.9%
– Apoio executivo: 13.9%
– Declaração de requisitos clara e limpa: 13%
– Planejamento apropriado: 9.6%
– Expectativas realistas: 8.2%
– Milestones pequenos: 7.7%
– Equipe competente: 7.2%
– Propriedade: 5.3%
– Visão e objetivos claros: 2.9%
– Trabalho duro e equipe focada: 2.4%
– Outros: 13.9%
Noaldo Sales Santos Filho
5. Motivação
• Os fatores que influenciaram os projetos de sucesso
parcial foram:
– Falta de insumos do usuário: 12.8%
– Requisitos & Especificações incompletas: 12.3%
– Mudanças nos requisitos & especificações: 11.8%
– Falta de apoio executivo: 7.5%
– Ambiente tecnológico incompleto: 7.0%
– Falta de recursos: 6.4%
– Expectativas irrealistas: 5.9%
– Objetivos nebulosos: 5.3%
– Ciclos (tempo) irrealistas: 4.3%
– Novas tecnologias: 3.7%
– Outras: 23%
Noaldo Sales Santos Filho
6. Motivação
• As principais causas de fracasso são:
– Requisitos Incompletos: 13.1%
– Falta de envolvimento do usuário: 12.4%
– Falta de recursos: 10.6%
– Expectativas não realistas 9.9%
– Falta de apoio executivo: 9.3%
– Mudanças de requisitos: 8.7%
– Falta de planejamento: 8.1%
– Não precisa mais daquilo: 7.5%
– Falta de gestão da TI: 6.2%
– Analfabetismo tecnológico: 4.3%
– Outros: 9.9%
Noaldo Sales Santos Filho
7. Motodologias Ágeis
• Agile Alliance
– Em 2001, Kent Beck e outros dezesseis renomados
desenvolvedores, autores e consultores assinaram o manifesto para
o desenvolvimento ágil de software.
– Indivíduos e interações mais que processos e ferramentas
– Software que funciona mais que documentação completa
– Colaboração com o cliente mais que negociação contratual
– Respostas as mudanças mais que seguir o plano
Noaldo Sales Santos Filho
12. Scrum Framework
• Scrum não é uma metodologia que irá te ajudar a
desenvolver melhores produtos;
• Scrum não lhe dá a resposta de como desenvolver
software de qualidade mais rapidamente;
• Scrum é uma ferramenta, um framework, que você pode
usar para identificar o que você precisa fazer para
desenvolver software de qualidade rapidamente;
• Scrum não necessita que as equipes estejam co-
localizadas. Porém, lhe permite medir a produtividade de
equipes co-localizadas;
• Eficaz para projetos com prazos de entrega apertados,
requisitos mutáveis e críticos de negócio.
Noaldo Sales Santos Filho
13. O que é Scrum?
• É um Framework Agile que permite entregar um “valor de
negócio” mais elevado num período de tempo mais curto;
• Concebido em 1990 por Jeff Sutherland e sua equipe;
• Permite entregar rapidamente software funcionando e de
qualidade a cada duas a quatro semanas (Sprints);
• O cliente define as prioridades. O time se auto-organiza e
determina a melhor forma de entregar as funcionalidades
de maior priorização;
• No fim de cada Sprint o Time apresenta para o cliente as
funcionalidades funcionando.
• Seus princípios são usados para orientar as atividades de
desenvolvimento dentro de um processo que incorpora as
atividades de requisitos, análise, projeto, evolução e
entrega.
Noaldo Sales Santos Filho
14. Por que Scrum?
• Aumento do ROI
– Métodos tradicionais demoram para satisfazer as necessidades do
cliente;
– Entregar mais cedo permite um ROI mais cedo.
• Flexibilidade
– Responder a mudanças de requisitos;
– Responder a evolução da tecnologia.
• Produto de Qualidade
– Entregar produto certo na primeira entrega;
– Entregar com menos erros, testando mais cedo e com mais
frequência.
• Visibilidade
– Medida do progresso = produto concluído;
• Rápido Feedback
– Feedback constante do cliente, stakeholders e membros do time.
Noaldo Sales Santos Filho
15. O que é Scrum?
• Transparência
• Inspeção
• Adaptação
Noaldo Sales Santos Filho
16. Scrum é composto por
• Times Scrum – e seus papéis associados;
• Time-Boxes – Eventos com duração fixa;
• Artefatos;
• Regras;
Noaldo Sales Santos Filho
17. Time-Boxes
• Assegurar o foco do time nas tarefas que
precisam ser executadas.
– Reunião de Release Planning;
– Reunião de Sprint Planning;
– Sprint;
– O Daily Stand up;
– Sprint Review;
– Retrospectiva;
Noaldo Sales Santos Filho
20. Galinhas
• Não fazem parte do time;
• Não podem mandar no time;
• Não podem alterar o caminho do time;
• Suas idéias só farão parte do Product Backlog
se o PO assim decidir;
• Quer fazer alguma coisa? Quer decidir? Quer
participar? Então, seja porco.
Noaldo Sales Santos Filho
22. Product Owner (PO)
• Define as funcionalidades do produto;
• Decide a data de entrega e o conteúdo;
• Responsável pelo ROI;
• Prioriza as funcionalidades conforme o valor de
negócio;
• Ajusta as funcionalidades e suas prioridades a
cada Sprint;
• Aceita ou rejeita os resultados.
Noaldo Sales Santos Filho
23. Scrum Master (SM)
“The sheepdog for the team” – Ken Schwaber
Noaldo Sales Santos Filho
24. Scrum Master (SM)
• Responsável pela aplicação dos valores e
práticas do Scrum;
• Remove impedimentos;
• Assegura que a equipe está totalmente funcional
e produtiva;
• Permite a cooperação entre os diversos papéis e
funções;
• Proteje o time das interferências externas.
Noaldo Sales Santos Filho
25. Scrum Master (SM)
• Quem pode ser o ScrumMaster?
• O ScrumMaster pode ter outros papéis?
• Quais as qualidades que ele precisa ter?
• Qual a autoridade que o ScrumMaster tem?
• O ScrumMaster é responsável por datas,
orçamento, benefícios, etc.?
• Quais as obrigações do ScrumMaster?
Noaldo Sales Santos Filho
27. O Time (Team)
• 7 pessoas (+ ou - 2);
• Multifuncional;
• Dedicados ao projeto;
• Auto-organizado e auto-gerenciável;
• Responsável por escolher o trabalho que será
executado durante o Sprint;
• Responsável por quebrar as funcionalidades e
estimar a sua complexidade;
Noaldo Sales Santos Filho
31. Product Backlog Example
User Story Priority Estimate
Como usuário eu gostaria de criar uma conta H 4
Como usuário eu gostaria de enviar um documento H 8
Como usuário eu gostaria de visualizar um H 5
documento
Como usuário eu gostaria de buscar documentos H 10
pelo texto deles
Como usuário eu gostaria de criar pastas para os M 3
documentos
Como usuário eu gostaria de poder mover um M 3
documento para uma pasta
Como usuário eu gostaria de taggear um documento L 4
Noaldo Sales Santos Filho
32. User Stories
• Atributos:
– Tamanho (pontos, dias ideiais), Valor de negócio;
– Condições de satisfação.
Noaldo Sales Santos Filho
33. User Stories
• Quando necessário, a equipe também pode
definir estórias para o produto;
• Estórias muito grandes devem ser divididas.
Noaldo Sales Santos Filho
34. User Stories
• Teste escrever:
– What? (O quê?)
– Why? (Por que?), Who? (Quem?)
Noaldo Sales Santos Filho
35. User Stories no Backlog
• 3 “C”s
– Card – Escritas em index cards de tamanho 9 x 15cm
– Podem conter estimativas, alguns detalhes, etc.
– Conversation – Um lembrete para ter uma conversa
– Exponha os requerimentos, não os documente
– Os detalhes aparecem durante as conversas
– Confirmation – Teste de aceitação para confirmar que
a estória foi desenvolvida corretamente
– Documente os detalhes das conversas
Noaldo Sales Santos Filho
36. Story Points
• Tamanho de uma estória;
• Influenciado por:
– O quanto difícil é a estória;
– Qual o tamanho do trabalho.
• Valor relativo;
• Pontos não possuem unidades:
– Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, ...)
Noaldo Sales Santos Filho
37. Tempo
• Quanto tempo algo iria demorar se:
– Você trabalhasse apenas nisso;
– Sem interrupção de tempo;
– Tudo que você precisa estará disponível;
• O tempo ideal de uma partida de futebol seria de
90 minutos:
– Dois tempos de 45 minutos.
• O tempo total, porém, leva + ou - 2 horas.
Noaldo Sales Santos Filho
38. Prática – Product Backlog
Dividam-se em equipes;
Escolham um Product Owner;
O produto será um software para uma loja de roupas;
Definam de 10 a 12 User Stories;
Priorizem com o Product Owner;
30 minutos;
Noaldo Sales Santos Filho
39. ROI – Return Of Investment
Noaldo Sales Santos Filho
44. Prática – Sprint Planning
• Com o product backlog produzido
anteriormente:
– Quebrar as User Stories em tasks;
– Definir o tempo em horas ideais que cada task deve
demorar pra ser feito;
– Priorizar conforme as necessidades do product owner;
– #PARADO AQUI#
Noaldo Sales Santos Filho
46. Velocity
• Para fazer um release plan, precisamos saber
ou ter uma idéia de Velocity;
• 3 formas de termos a Velocity:
– Média das anteriores;
– Aprendizado das Sprints anteriores;
– Faça uma previsão.
• Deve ser expressa como um intervalo
Noaldo Sales Santos Filho
47. Re-estimar
• Velocity normalmente corrige as falhas de
estimativas;
• Só deve acontecer quando o tamanho relativo
de uma user story se altera;
• Alterar os tamanhos relativos de todas as user
stories não leva você a lugar nenhum;
Noaldo Sales Santos Filho
48. Definindo Pronto
• O que significa “pronto” em seu projeto atual?
• Quais os problemas que você tem com a
definição atual?
• Como resolver esses problemas?
• Quais problemas de engenharia você percebe?
Noaldo Sales Santos Filho
49. Definição de Done
• Code produced (all ‘to do’ items in code completed)
• Code commented, checked in and run against current version in source
control
• Peer reviewed (or produced with pair programming) and meeting
development standards
• Builds without errors
• Unit tests written and passing
• Deployed to system test environment and passed system tests
• Passed UAT (User Acceptance Testing) and signed off as meeting
requirements
• Any build/deployment/configuration changes
implemented/documented/communicated
• Relevant documentation/diagrams produced and/or updated
• Remaining hours for task set to zero and task closed
Fonte: http://www.allaboutagile.com/definition-of-done-10-point-checklist/
Noaldo Sales Santos Filho
51. Interrupção Anormal
• Uma ferramenta a ser evitada;
• Para circunstâncias extremas;
• Um novo Sprint Planning Meeting deve ser feito.
Noaldo Sales Santos Filho
54. Referências
• Material do curso CSM do CST Michel Goldenberg;
• http://www.scrumalliance.org
• http://www.allaboutagile.com/
• http://blog.agilegamedevelopment.com/2008/08/should-
scrum-master-also-be-member-of.html
• http://www.planningpoker.com/
Noaldo Sales Santos Filho