Upload
giuliana-lagos-sanches
View
251
Download
7
Embed Size (px)
Citation preview
SCRUM
Agenda
• Manifesto Ágil
• Origens do Scrum
• Componentes do Scrum
Dinâmicas
Manifesto Ágil
Os 12 Princípios Ágeis1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e
adiantada de software com valor agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
Os 12 Princípios Ágeis
7. Software funcionando é a medida primária de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
9. Contínua atenção à excelência técnica e bom design aumenta a agilidade.
10. Simplicidade --a arte de maximizar a quantidade de trabalho não realizado --é essencial.
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto organizáveis.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.
Abordagem Clássica vs. Abordagem Ágil
Clássica Ágil
Desenvolvedor hábil ágil
Cliente pouco envolvido comprometido
Requisitos conhecidos, estáveis emergentes, mutáveis
Retrabalho caro barato
Planejamento direciona resultados resultados o direcionam
Foco grandes projetos projetos de natureza exploratória e inovadores
Objetivo controlar, em busca de alcançar o planejado
simplificar processo de desenvolvimento
Nível de ruído em um projeto
Simples
Complicado
Anarquia
Complexo
Perto da certeza
Longe da certeza
Tecnologia
Perto deAcordo
Longe deacordo
Requerimentos
Origens do Scrum
The Mythical Man Month by Frederick Brooks, 1975.(O mítico homem mês)
Quando um projeto está atrasado, adicionar pessoas ao projeto servirá apenas para atrasá-lo ainda mais.
Devemos considerar o tempo que perdemos em gestão e comunicação quando temos pessoas demais trabalhando em um projeto.
Ao calcular o tempo de desenvolvimento de qualquer coisa, temos que dobrá-lo. O programador precisa de "tempo para pensar" além do "tempo para programar“.
Scrum é...
Scrum: valores...
Scrum: benefícios...
Comunicação
Trabalho em equipe
Flexibilidade
Fornecimento de software funcionando(Incremental)
Scrum: componentes...
Scrum: componentes...
Scrum: componentes...
Scrum: Product Owner
Gerencia Product Backlog
Representa Stakeholders
Aceita/Rejeita resultados
Define/Prioriza funcionalidades
Garante e maximiza o ROI do cliente a partir do trabalho do Time de Desenvolvimento
Scrum: Scrum Master
Facilitador
Remove obstáculos
Evita Interferências
Mantém Foco na Meta do Sprint
Garante colaboração
Guardião das práticas do Scrum
Scrum: Team Developer Auto gerenciável
Composto por 3 a 9 pessoas
Multifuncional
Sem nível hierárquico
Scrum: Product Backlog
• Os requerimentos• 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
Este é o Product Backlog
Scrum: Sprint Planning PO Apresenta as Estórias (necessidades, tarefas, eventos, etc.) de maior
prioridade
Time seleciona Estórias para compor Sprint e as quebra em Tarefas
PO + Time definem o Sprint Backlog
Este é o Sprint Backlog
Este é o Sprint Planning
Scrum: Sprint Não deve ser maior do que 30 dias consecutivos
O time se compromete com o Sprint BacklogNão são permitidas modificações nele durante o Sprint
O que está fora do Sprint pode ser alterado de acordo com a necessidade do cliente
Somente o Product Owner pode interromper um Sprint
Kanban =>
Este é o Sprint
Scrum: Daily Meeting
Reuniões diárias de 15 min. no máximo com a equipe de pé
Questões que devem ser respondidas:1) O quê você fez ontem ?2) O quê você vai fazer hoje ?3) Tem algum obstáculo ?
• A reunião todo dia ajuda a manter as promessas, evita atraso no projeto, qualquer problema pode ser corrigido de imediato.
Este é o Daily Meeting
Scrum: Burn Down Chart
Scrum: Sprint Review Apresentação dos Resultados do Sprint
Demo de novas funcionalidades
No final da reunião• Cada stakeholder fala suas impressões e sugere mudanças com suas
respectivas prioridades• Possíveis modificações no Product Backlog são discutidas entre o Product
Owner e o Time• ScrumMaster anuncia a data e o local da próxima reunião de revisão do
Sprint ao Product Owner e a todos stakeholders
Este é o Sprint Review
Scrum: Sprint Retrospective Participam desta reunião
• Time, ScrumMaster e, opcionalmente, Product Owner
Os membros do time devem responder a duas questões:• O que aconteceu de bom durante o último Sprint?• O que pode ser melhorado para o próximo Sprint?
ScrumMaster escreve as respostas e prioriza na ordem que deseja discutir as potenciais melhorias
ScrumMaster nesta reunião tem o papel de fazer com que o time encontre melhores formas de aplicar o Scrum
Este é o Sprint Retrospective
Simulado (prova)
http://www.knowledge21.com.br/simulado-de-scrum-para-a-prova-de-certificacao-da-scrum-alliance-certified-scrummaster/
Certo ou Errado ???
Revisão