Aula 10 - Scrum

(1)

SCRUM – Um Framework Ágil para

Gestão e Planejamento de Projetos

de Software

Marcelo Marinho

(2)

Roteiro



Contextualização



Manifesto Ágil



Scrum – Definição



Scrum – Por Que?



Ambiente Scrum



Papéis no Scrum



Fluxo do Scrum



Leituras Recomendadas



Referências

(3)

Contextualização

A Engenharia de software vêm recorrentemente

enfrentando o cenário onde ...



As aplicações são cada vez mais complexas...



O tempo de desenvolvimento é cada vez menor...



Há necessidade de diminuição de custos ...

(4)

Contextualização

Processos tradicionais tornaram-se “pesados” para a

engenharia de software



Muita burocracia



Muita documentação



Pouca flexibilidade a mudanças no projeto



Não contemplam o cenário atual

(5)

• Em 2001 um grupo de profissionais da área de software resolveu se reunir numa estação de esqui nos EUA , estava nascendo o manifesto Ágil.

• Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de software ter sucesso, cada qual com as suas particularidades, todos concordavam que, em suas experiências prévias, um pequeno conjunto de princípios sempre parecia ter sido respeitado quando os projetos davam certo.

• O grupo era composto de grandes nomes do mundo do software : Kent Beck , Jim Highsmith , Martin Fowler , Ken Shwaber e Jeff Sutherland.

(6)

Manifesto Ágil



Estamos

descobrindo

melhores

formas

de

desenvolver software através da nossa própria

prática e auxiliando outros.

Indivíduos e Iterações Software funcionando Colaboração com cliente Responder a mudanças Processos e Ferramentas Documentação detalhada Negociação de contratos Seguir um plano

Valores

(7)

(8)

Scrum



Uma alternativa de utilizar métodos ágeis na

gerência de projetos



Pode ser aplicável a qualquer tipo de projeto



É simples

– Processo, artefatos e regras são poucos e fáceis de entender

– A simplicidade pode ser decepcionante aos acostumados com metodologias clássicas

(9)

Scrum



Não é um método prescritivo

– Não define previamente o que deve ser feito em cada situação

– Projetos complexos não permitem prever todos os eventos



Define um framework e um conjunto de práticas



Aplica o senso comum

– Combinação de experiência, treinamento, confiança e inteligência de toda a equipe

– Senso comum em vez do senso de uma única pessoa é uma das razões do sucesso do Scrum

(10)

Fases



Planejamento



Sprints

– Reuniões Diárias – Revisão – Retrospectivas



Encerramento

(11)

Quem usa Scrum

• Electronic Arts

• High Moon Studios • Lockheed Martin • Philips • Capital One • BBC • Intuit

Nielsen Media

First American

Real Estate

BMC Software

Ipswitch

John Deere

Lexis Nexis

Sabre

Salesforce.com

Time Warner

Turner

Broadcasting

Oce

(12)

Scrum – Por que?

• Aumentar a freqüência de entrega

• Reduzir atrasos

• Alinhar expectativa durante o desenvolvimento

• Todos acompanham o projeto

• Validação completa de cada etapa

• Redução de retrabalho

(13)

(14)

(15)

(16)

Papéis no Scrum



Product Owner

 Determina a Visão do Produto  Define as funcionalidades do

produto (Product Backlog)

 Determina o valor de negócio

de cada funcionalidade

 Apresenta e explica o Product

Backlog para o time

 Prioriza funcionalidades

 Aceita ou rejeita o resultado do

(17)

Papéis no Scrum



Scrum Master

 Responsável pela aplicação dos valores e práticas do Scrum

 Resolve os impedimentos

levantados pelo Time

 Conduz as reuniões diárias, de

planejamento e de revisão

 Escudo para interferências

externas

 Organiza as reuniões de

planejamento da sprint, diárias, revisão e retrospectiva

(18)

Papéis no Scrum



Time

 Entre 5 e 10 pessoas  Sem nível hierárquico

 Desenvolve as funcionalidades

do Produto

 Multifuncional : Programadores,

testadores, desenvolvedores de interfaces, etc.

 Auto organizável e Auto

gerenciável

 Estima as funcionalidades do

(19)

(20)

Product Backlog

O Product Backlog é a lista mestre de todas as

funcionalidades desejadas no Produto.



Contém todos os requisitos funcionais e não-funcionais



Geralmente escritos em User Stories



Os itens devem ter um valor de negócio reconhecido

pelo Product Owner



Os itens são priorizados pelo Product Owner



Contém itens solicitados pelo time, desde que seja

possível ter um valor de negócio

(21)

Product Backlog

Backlog item (BLI) Business Value

(BV)

[BLI001] As a standard user, search for a movie 1000 [BLI002] As a standard user, search for movie

reviews

1000

[BLI003] As a standard user, view the top movies 1000 [BLI004] As a standard user, search for theaters 700 [BLI005] As a standard user, search for movie

trailers

700

[BLI006] As a standard user, create the user profile

500

[BLI007] As a standard user, edit the user profile 300 [BLI008] Integration with LDAP 100

(22)

(23)

Sprint Planning 1



A reunião de planejamento do Sprint deve ocorrer

dentro de 8 horas com duas partes de 4 horas



Primeiro seguimento:

– Product Owner deve preparar o Product Backlog antes da reunião

– Seleção dos itens do Product Backlog que o time se compromete em torná-los incrementos potencialmente implementáveis

– Decisão final é do Product Owner – Stakeholders não devem participar

(24)

(25)

Sprint Planning 2

Item do Backlog

Estimativa

Permitir que o usuário faça uma reserva

3 Permitir que o usuário cancele a reserva

5 Permitir a troca de datas da reserva

3 Permitir que empregadod do hotel gerem

relatórios de lucratividade

8 Melhorar manipulação de erros

8

(26)

Planning Poker



Baseado em Fibonacci

(1,2,3,5,8,13,...) +

20, 40, 100

(27)

Planning Poker

Pessoal, qual a estimativa

para essa história?

(28)

(29)

(30)

Sprint



Duração de 1 a 4 semanas.



Time constrói funcionalidades

selecionadas do Product Backlog

e atende os objetivos da Sprint.



Time se auto organiza para

realizar o trabalho



O time se compromete com o

Product Backlog

– Não são permitidas modificações nele durante o Sprint

(31)

Sprint



Responsabilidades do time durante o Sprint:

– Participar das reuniões diárias do Scrum – Manter o Sprint Backlog atualizado

– Disponibilizar o Sprint Backlog publicamente



O time tem o compromisso de implementar todos

(32)

Daily Scrum

(33)

Scrum Daily Meeting



Todos respondem às perguntas:

– O que você realizou desde a última reunião? – Quais problemas você enfrentou?

(34)

(35)

(36)

Sprint Review

(37)

Sprint Review

 O time apresenta os

resultados obtidos ao

Product Onwer que então valida se os objetivos da Sprint foram alcançados.

 Todos os stakeholders

podem participar

 Deve ser uma apresentação

informal

 Proibido o uso de slides  Realizada a demonstração

das novas funcionalidades ou arquitetura.

Nova

(38)

Timeboxed – 3 horas

(39)

Reunião de Retrospectiva do Sprint

 Não deve ser maior do que 3 horas

 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 a última Sprint? – O que pode ser melhorado para a próxima 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

(40)

• Software comercial

• Desenvolvimento interno • Desenvolvimento contratado

(terceirização)‏

• Projetos de preço fixo • Aplicações Financeiras

• Aplicações certificadas pela isso 9001

• Sistemas embarcados

• Sistemas disponíveis 24x7 • Desenvolvimento por hackers

solitários

• Video games

• Sistemas para suporte à vida • Sistemas para controle de

satélites • Websites

• Software para handhelds • Telefones celulares

• Aplicações para redes

• Aplicações de ISV (Independent Software Vendors)‏

• Algumas das maiores aplicações em produção

(41)

(42)

Referências

 Schwaber, K., Agile Project Management With Scrum, Microsoft,

2004.

 Schwaber, K. and Beedle, M., Agile Software Development With

Scrum. NJ: Prentence Hall, 2002.

• www.mountaingoatsoftware.com/scrum

• www.scrumalliance.org