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