UNIVERSIDADE FEDERAL DO MATO GROSSO

ENGENHARIA DE
SOFTWARE II
Modelagem gil com Scrum
AULA 3

Prof MSc. MICHELLE DE OLIVEIRA PARREIRA

parreira.michelle@gmail.com
O que agilidade?
Agilidade
Rapidez, desembarao
Qualidade de quem veloz

Capacidade de responder rapidamente a mudanas

Mudanas de tecnologias, de equipe, de requisitos...

Entregar valor ao cliente quando se lida com

imprevisibilidade e dinamismo dos projetos

Problema
Aparenta ser indisciplinado

2
Princpios da agilidade
1. A mais alta prioridade a satisfao do cliente, por meio
da liberao mais rpida e contnua de software de valor.
2. Receba bem as mudanas de requisitos, mesmo em
estgios tardios do desenvolvimento. Processos geis devem
admitir mudanas que trazem vantagens competitivas para o
cliente.
3. Libere software frequentemente (em intervalos de 2
semanas at meses), dando preferncia para uma escala de
tempo mais curta.
4. Mantenha pessoas ligadas ao negcio (clientes) e
desenvolvedores trabalhando juntos a maior parte do
tempo do projeto.

3
Princpios da agilidade
5. Construa projetos com indivduos motivados, d a eles o
ambiente e suporte que precisam e confie neles para ter o
trabalho realizado.
6. O mtodo mais eficiente e efetivo para repassar informao
entre uma equipe de desenvolvimento pela comunicao
face-a-face.
7. Software funcionando a principal medida de progresso
de um projeto de software
8. Processos geis promovem desenvolvimento sustentado.
Assim, patrocinadores, desenvolvedores e usurios
devem ser capazes de manter conversao pacfica
indefinidamente.

4
Gerenciamento gil de Projetos
Valores centrais
As respostas s mudanas so mais
importantes que o segmento de um plano
A entrega de produtos est acima da
entrega de documentao
Priorizao da colaborao do cliente
sobre a negociao de contratos
Os indivduos e suas interaes so mais
importantes que os processos e ferramentas

5
Gerenciamento gil de Projetos
Principais objetivos
Inovao contnua: a idia de inovao associada
a um ambiente cuja cultura estimule o auto-
gerenciamento e a autodisciplina
Adaptabilidade do produto: os produtos
adaptveis s novas necessidades do futuro
Tempos de entrega reduzidos: direcionamento
preciso e capacidade tcnica da equipe
Capacidade de adaptao do processo e das
pessoas: equipe confortvel com mudanas, processo
leve
Resultados confiveis: entrega de produtos que
garantam operao, crescimento e lucratividade da
empresa

6
Tcnicas de Gerenciamento gil de
Projetos
Foque nas pessoas
As pessoas e a maneira como interagem so
determinantes mais importantes para o
sucesso de um projeto
Organize seu projeto em iteraes
Curtos perodos de tempo onde ao seu final
chega-se a um objetivo especfico
Estabelea marco de entrega final
somente se for realmente necessrio

7
Tcnicas de Gerenciamento gil de
Projetos
Tenha um plano de projeto de alto nvel
Principais dependncias externas, iteraes
planejadas e uma estimativa de trmino (se
possvel)
Crie planos de iterao detalhados com base
no JIT (Just In Time)
Voc s pode planejar precisamente com algumas
semanas de antecedncia da realizao
Envolva todos da equipe no planejamento
Planejar as prprias atividades

8
Tcnicas de Gerenciamento gil de
Projetos
As pessoas deveriam escolher seu trabalho
ao invs de serem mandadas para faz-lo
Organizar o prprio trabalho
Faa estimativa de coisas pequenas
mais fcil fazer a estimativa de um trabalho que
levar apenas um dia do que estimar algo que
levar um ms.
As pessoas deveriam estimar seu prprio
trabalho
As melhores estimativas vm de baixo para cima
e no de cima para baixo

9
Gerenciamento gil de Projetos
Ambientes onde pode apresentar
problemas
Cultura da documentao
Dificuldade para aceitar mudanas
Demora para obteno da realimentao
Resistncia cultural

10
Gerenciamento gil de Projetos
Crticas
Dificuldade de manuteno pela falta de
documentao
Efetividade da programao em pares: custo x
benefcio
Dificuldade de se ter o cliente no local
Dificuldade de estabelecer contrato com
escopo varivel
Requer colaborao e confiana entre equipe
e cliente
11
 Abordagem Clssica vs. Abordagem gil

Clssica gil
Desenvolvedor hbil gil

Cliente pouco envolvido comprometido

Requisitos conhecidos, estveis emergentes, mutveis

Retrabalho caro barato

Planejamento direciona resultados resultados o direcionam

projetos de natureza exploratria

Foco grandes projetos
controlar, em busca de
Objetivo
alcanar o planejado
e inovadores
simplificar processo de
desenvolvimento

12
Abordagem Clssica vs. Abordagem gil
Ciclo de vida gil semelhante ao clssico

Define o que o cliente quer e inicia o projeto

Planeja o projeto, calculando o esforo
Executa o plano, construindo a soluo
Monitora resultados e entrega ao cliente

13
SCRUM

14
 SCRUM
Iterativo e
Incremental
Resposta s
mudanas
Maior valor para o
negcio
Prticas de engenharia
livres
Framework de
processo 15
Scrum

Definio informal:

Estratgia em um jogo de rugby onde

jogadores colocam uma bola quase perdida
novamente em jogo atravs de trabalho em
equipe.

16
Scrum
Uma alternativa de utilizar mtodos geis
na gerncia de projetos
Pode ser aplicvel a qualquer tipo de
projeto
simples
Processo, artefatos e regras so poucos e
fceis de entender
A simplicidade pode ser decepcionante aos
acostumados com metodologias clssicas

17
Scrum
No um mtodo prescritivo
No define previamente o que deve ser feito em
cada situao
Projetos complexos no permitem prever todos
os eventos
Define um framework e um conjunto de
prticas
Aplica o senso comum
Combinao de experincia, treinamento,
confiana e inteligncia de toda a equipe
Senso comum em vez do senso de uma nica
pessoa uma das razes do sucesso do Scrum

18
 nfases
Comunicao
Trabalho em equipe
Flexibilidade
Fornecer software funcionando
incrementalmente

19
Papis no Scrum
Todas as responsabilidades de gerenciamento so divididas entre
trs papis:
Product Owner
Scrum Master
Time

Para o bom funcionamento do Scrum as pessoas responsveis pelo

projeto devem ter autoridade para fazer o que for necessrio pelo
seu sucesso

Pessoas no responsveis no podem interferir no projeto

Gera aumento de produtividade
Evita situaes constrangedoras para os envolvidos

20
Papis no Scrum

21
Papis Product Owner
Responsvel por apresentar os interesses de
todos os stakeholders
Define fundamentos iniciais do projeto,
objetivos e planos de release
Responsvel pela lista de requisitos
(Product Backlog)
Certifica se as atividades com maior valor para
o negcio so desenvolvidas primeiro
Priorizao frequente das funcionalidades antes de
cada iterao

22
 Product Owner
Determina a Viso do
Projeto
Define as
funcionalidades
Determina o valor de
negcio
Prioriza
funcionalidades

Aceita ou rejeita o resultado do

trabalho
23
Papis Scrum Master
Responsvel pelo sucesso do Scrum
Ensina o Scrum para os envolvidos com o
projeto
Implementa o Scrum na empresa de forma
adaptada a sua cultura, para continuamente
gerar benefcios
Certifica se cada pessoa envolvida est
seguindo seus papis e as regras do Scrum
Certifica que pessoas no responsveis no
interfiram no processo

24
 Scrum Master
Valores e Prticas do
Scrum
Resolve os
impedimentos
Conduz as reunies dirias,
de planejamento e reviso
Escudo para interferncias
externas

25
Papis Time
Equipe de Desenvolvimento
Responsvel por escolher as funcionalidades a serem
desenvolvidas em cada interao e desenvolv-las
O time se auto-gerencia, se auto-organiza
Postura multifuncional
Todos os membros do time so coletivamente
responsveis pelo sucesso de cada iterao

26
 Time
Entre 5 e 10
pessoas
Multi-
funcional
Auto organizvel e Auto
gerencivel
Estima as
funcionalidades
Define as tarefas
Levanta impedimentos
(externos)
27
O que so os Stakeholders?
Alm dos trs papis j descritos,
certamente tambm existiro envolvidos
com o projeto, mas que no desempenham
um papel direto na sua execuo. Estes
elementos podem englobar usurios,
gerentes, diretores ou departamentos que
possuem interesses ou ainda, so afetados
pelos resultados do produto final.

28
Comprometido X Envolvido

29
 Local do Encontro
Sempre o mesmo local Todos devem
e hora participar
Pode ser o local de Pode ser em p
desenvolvimento
Sala bem equipada,
Pessoas sentadas ao
redor de uma mesa quadro branco, etc.
A sala j deve estar
arrumada antes
Punies
(atrasos/faltas)

30
 Fases
Planejamento
Sprints
Reunies Dirias
Reviso
Retrospectivas
Encerramento

31
Processo Scrum

32
Planejamento
Relativamente curto
Projeto da arquitetura do sistema
Estimativas de datas e custos
Criao do backlog Backlog

Participao de clientes e outros departamentos

Levantamento dos requisitos e atribuio de prioridades
Definio de equipes e seus lderes
Definio de pacotes a serem desenvolvidos

33
Product Backlog
Criado a partir da Viso do Produto
Contm todos os requisitos funcionais e
no funcionais
Geralmente escritos em User Stories
Idealmente representado por itens que
agregam valor aos usurios ou cliente
Priorizado pelo Product Owner

34
Product Backlog
O product backlog o corao do
Scrum. aqui que tudo comea. O
product backlog basicamente uma
lista de requisitos, estrias, Coisas que
o cliente deseja, descritas utilizando a
terminologia do cliente.

35
Product Backlog

36
37
Sprint Planning 1
Reunio de no mximo 4 horas
Revisar o product backlog
Determinar o objetivo da sprint
Selecionar parte do product backlog
Estimar e priorizar IBLs (itens de
backlog)

38
39
Sprint Planning 2
um planejamento ttico da equipe
Os itens selecionados do Product Backlog
so destrinchados em tarefas
O resultado final o Sprint Backlog

40
Sprint Backlog
As tarefas no so atribudas aos
membros do time
Cada membro escolhe sua tarefa
diariamente
Qualquer membro do time pode
adicionar ou remover itens do Sprint
Backlog (durante o daily meeting)

41
Sprint Backlog
Criado de acordo com os itens do
product backlog levantado pelo Product
Owner, ou seja, de acordo com os itens
de maior prioridade criado o Sprint
Backlog que a equipe ter a
responsabilidade de terminar at o
prximo Sprint.

42
 Plannings 1 e 2
Histrias

A
Alta
B O que est dentro do Sprint
No pode ser alterado.
C
D
Prioridade

E - O que est fora do Sprint pode

F Ser alterado de acordo com a
G necessidade do cliente.
H
- Ele pode alterar prioridades,
I inserir novas tarefas ou retirar
tarefas existentes.
Baixa - Algumas tarefas podem ser
inseridas pela equipe.
Ex: Montar ambiente para
Integrao contnua
43
44
Sprint
Um perodo de tempo entre 1 a 4
semanas
Todos os Sprints devem possuir uma
estrutura exatamente igual
Funcionalidades construdas a partir dos
IBLs selecionados
Time define a organizao necessria
para efetuar o trabalho
O time recebe uma parte do backlog para
desenvolvimento
O backlog no sofrer modificaes durante o
Sprint
45
 Estrutura de um Sprint

Planejamento Sprint X+1

Apresentao
Planejamento Sprint X

Sprint X
Retrospectiva
Reunio Reunio Reunio Reunio Reunio Reunio Reunio Reunio
diria diria diria diria diria diria diria diria

46
Sprint - Reunies Dirias
Objetivo
Cada membro deve responder as seguintes perguntas:
1. O que voc fez desde a ltima reunio diria?
2. O que voc pretende fazer at a prxima reunio
diria?
3. Existe algum problema que o impea de realizar suas
atividades?
Impedimentos reportados aqui

Durao
15 minutos (no mais que isso)
Qualquer pessoa pode participar, mas apenas o Scrum
Master e os Membros da Equipe podem falar

47
Sprint - Reunies Dirias
Benefcios:
Maior integrao entre os membros da
equipe
Rpida soluo de problemas
Promovem o compartilhamento de conhecimento
Progresso medido continuamente
Minimizao de riscos

48
 Quadro Kanban
IBLs Tasks To Do Work In Progress Done
[IBL001]

[IBL003]

[IBL002]

49
Quadro Kanban

50
Sprint Burndown

51
 Sprint - Reviso
Deve obedecer data de entrega
Permitida a diminuio de funcionalidades

Apresentao do produto ao cliente

Sugestes de mudanas so incorporadas
ao backlog

Benefcios:
Apresentar resultados concretos ao cliente
Integrar e testar uma boa parte do
software Nova
Motivao da equipe funcionalidade

52
Sprint - Retrospectiva
Objetivo
Enumerar o que funcionou e o que no
funcionou durante o Sprint
Participantes
Product Owner, Scrum Master e os membros
do time
Time deve encontrar solues para os
problemas mais crticos

53
Retrospectiva - Exemplo
O que Funcionou O que no funcionou
Comunicao entre
Testes os membros
Reunies
Usurio Faltou
Dirias
melhor
Distante
planejamento
do Sprint
Alguns
membros
chegam tarde

54
Encerramento
Finalizao do projeto
Atividades:
Testes de integrao
Testes de sistema
Documentao do usurio
Preparao de material de treinamento
Preparao de material de marketing

55
QUAL O CRITRIO PARA
DECIDIR A ESTRIA QUE
SER INCLUDA NO
SPRINT ?

56
Velocidade dos sprints

Base da conversa

Clculo de Velocidade

57
Base da conversa
Base da conversa, ideal quando a equipe
no possui histrico de sprints, ou seja,
para equipes que nunca trabalharam com
Scrum e no possuem dados esttiscos
para realizar o calculo de velocidade.

58
Base da conversa
A conversa gira em torno dos
desenvolvedores, onde o Scrum Master
pergunta para cada membro do time
quanto tempo uma atividade do Backlog
demora para ser desenvolvida (em horas),
e com base nisso as horas necessrias
para o projeto.

59
Velocidade dos sprints
A maneira mais simples de estimar a
velocidade verificar o histrico do time.
Qual foi a velocidade do time nos ltimos
Sprints ?
Ento assumir que a velocidade ser a
mesma para o ltimo Sprint, mas isso s
funciona se o time j tive feito alguns
Sprints antes.

60
Velocidade dos sprints
Outra maneira de calcular atravs de
clculo de recurso.

Por exemplo, vamos assumir que estamos

planejando um Sprint de 3 semanas (15
dias) com um time de 4 pessoas.

61
Velocidade dos sprints
Frmula para velocidade estimada do
Sprint:
(Dias de Recurso Disponvel) = membro
da equipe * diasdisponiveis

(Dias de Recurso Disponvel) * (Fator

Foco) = (Velocidade Estimada)

62
Velocidade dos sprints

63
REGRAS DO SCRUM

64
Regras no Scrum
O ScrumMaster deve se certificar de que
cada envolvido no projeto siga suas regras
As regras permitem a execuo correta do
Scrum
Mudanas das regras devem se originar do
time
O ScrumMaster deve ser convencido de que
todos envolvidos entenderam suficientemente as
regras do Scrum para o correto discernimento
Discusses desnecessrias so perda de tempo
de produo da equipe

65
Sprint Planning Meeting
A reunio 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 reunio
Seleo dos itens do Product Backlog que o time
se compromete em torn-los incrementos
potencialmente implementveis
Deciso final do Product Owner
Stakeholders no devem participar

66
Sprint Planning Meeting
Segundo seguimento:
Ocorre imediatamente aps o primeiro
Product Owner deve estar disponvel para o
que o time faa perguntas sobre o Product
Backlog
O time deve decidir sozinho como os itens
selecionados sero implementados
Nenhum outro participante pode fazer
perguntas ou observaes nesta parte
Resultado deste seguimento o Sprint Backlog
67
Scrum Daily Meeting
Reunio de no mximo 15 minutos, a
menos que o time seja grande o suficiente
para precisar de mais tempo
Deve ser feita no mesmo lugar onde o
time trabalha
Resulta em melhores resultados se
realizada no inicio do dia de trabalho
Todos os membros do time devem
participar desta reunio
68
Scrum Daily Meeting
ScrumMaster faz as seguintes perguntas para
cada membro do time:
O que voc fez desde a ltima reunio diria do
Scrum relacionada a este projeto?
O que voc ir fazer desde agora at a prxima
reunio diria do Scrum relacionada a este
projeto?
O que est impedindo voc de realizar o seu
trabalho o mais efetivamente possvel?

Os membros devem responder apenas a

estas perguntas para no estender a reunio

69
Sprint
No deve ser maior do que 30 dias
consecutivos

Sem considerar outros fatores, este o

tempo necessrio para produzir algo de
interesse para o Product Owner e os
stakeholders

O time se compromete com o Product

Backlog
No so permitidas modificaes nele durante o
Sprint

70
Sprint
Responsabilidades do time durante o
Sprint:
Participar das reunies dirias do Scrum
Manter o Sprint Backlog atualizado
Disponibilizar o Sprint Backlog publicamente

O time tem o compromisso de

implementar todos os itens selecionados

71
Reunio de Reviso do Sprint
Reunio de no mximo 4 horas sob responsabilidade do
ScrumMaster
O time no deve gastar mais de 1 hora na preparao desta
reunio
Objetivo:
Mostrar ao Product Owner e stakeholders as funcionalidades que
foram feitas
Artefatos no devem ser apresentados, pois no so
funcionalidades
No final da reunio
Cada stakeholder fala suas impresses e sugere mudanas com
suas respectivas prioridades
Possveis modificaes no Product Backlog so discutidas entre o
Product Owner e o time
ScrumMaster anuncia a data e o local da prxima reunio de
reviso do Sprint ao Product Owner e a todos stakeholders

72
Reunio de Retrospectiva do Sprint
No deve ser maior do que 3 horas

Participam desta reunio

Time, ScrumMaster e, opcionalmente, Product Owner

Os membros do time devem responder a duas questes:

O que aconteceu de bom durante o ltimo Sprint?
O que pode ser melhorado para o prximo Sprint?

ScrumMaster escreve as respostas e prioriza na ordem que deseja

discutir as potenciais melhorias

ScrumMaster nesta reunio tem o papel de fazer com que o time

encontre melhores formas de aplicar o Scrum

73
CONSIDERAES

74
Reflexo
Grandes projetos podem ser
gerenciados de forma gil?
Como possvel?
confivel?
Gerenciamento gil para qualquer tipo
de projeto
Construo de edifcios, avies,
robs
Como possvel?
75
Nem tudo so flores

Scrums so as fases mais perigosa no rugby,

uma vez que erros podem levar a um jogador
da linha de frente danificar ou at mesmo
quebrar o pescoo.

76
Principais Dificuldades
Independncia de equipes

Problemas de comunicao

Barreiras Culturais

Modo de Trabalho

Prticas de Scrum so para equipes reunidas

77
Consideraes Finais
Manifesto gil
Pares de alternativas se reforam
Processos e ferramentas podem melhor
capacitar os indivduos e interaes
Documentao ajuda as pessoas a entenderem
um software complexo
Negociao de contrato pode ser parte integrante
da colaborao do cliente
Seguir um plano pode ser o melhor modo para
responder a mudana, quando esta for previsvel

78
Consideraes Finais
Abordagens possuem pontos positivos e
negativos
Partem de pressupostos diferentes

Podem coexistir e conviver bem em um mesmo

ambiente
Considerar criteriosamente o ambiente correto

Necessrio buscar o ponto de equilbrio,

avaliando riscos
Planejamento aperfeioa a agilidade
Agilidade d eficincia ao planejamento

79
Consideraes Finais
Projetos complexos e com restries de tempo
necessitam de uma nova abordagem

Scrum uma boa soluo

eficiente quando as regras e os papis so bem
seguidos
Apesar da sua simplicidade, as pessoas costumam
no aceitar facilmente a nova abordagem
H diversos casos de sucesso

Deve-se considerar as condies da equipe e as

caractersticas dos projetos antes de uma migrao

80
 Mais Informaes
Agille Alliance - www.agilealliance.org
tima fonte sobre mtodos geis

Scrum Alliance - www.scrumalliance.org/

Mountain Goat Software

www.mountaingoatsoftware.com
Site de um treinador de Scrum Masters

Site do Ken Schwaber - www.controlchaos.com

81
Referncias
AMBLER, S. Gerenciamento gil de projetos: Colocando o desenvolvimento de
software em ordem. Mundo PM. out/nov 2006
ANDERSON, D. J. Agile management for software engineering: Applying the
theory of constraints for business results. New Jersey: Prentice Hall, 2003. 336p.
AUGUSTINE, S. Managing agile projects. Prentice Hall, 2005. 264p.
AUGUSTINE, S.; PAYNE, B.; SENCINDIVER, F.; WOODCOCK, S. Agile project
management: Steering from the edges. Communications of the ACM, v. 48, dez.
2005. p. 85-89.
BECK, K. 2001. AGILE ALLIANCE. Manifesto for agile software development.
Disponvel em <http://www.agilemanifesto.org/>. Acesso em 29 nov. 2006.
CHIN, G. Agile project management: how to succeed in the face of changing
project requirements. New York: Amacon, 2004. 229 p.
DECARLO, D. Extreme project management: Using leadership, principles, and
tools to deliver value in the face of volatility. California: Jossey-Bass, 2004. 560p.

82
Referncias
DECLARATION OF INTERDEPENDENCE. 2001. Declaration of
interdependence. Disponvel em <http://pmdoi.org/>. Acesso em 29 nov. 2006.
GRIFFITHS, M. Using agile alongside the PMBOK. PMI Global Congress
Proceedings, 2004.
HIGHSMITH, J. Agile project management: creating innovative products. Boston:
Addison-Wesley, 2004. 312 p .
KERZNER, H. Project Management: A Systems Approach to Planning, Scheduling,
and Controlling. New Jersey: John Wiley & Sons, 2003. 912p.
PROJECT MANAGEMENT INSTITUTE PMI. PMBOK Guide: Um guia do
conjunto de conhecimentos do gerenciamento de projetos. Pennsylvania: Project
Management Institute, 3. ed., 2004.
SCHWABER, K. Agile Project Management with Scrum. Microsoft Press, 2004.
MAGALHES, A. O gerenciamento de projetos desenvolvidos luz das
metodologias geis. PMI-MG jun/2006. Disponvel em
<http://www.pmimg.org.br/downloads/Palestra-GerenciamentoAgil.pdf>. Acesso em
29 nov. 2006

83