Este documento discute as motivações para a busca de um modelo híbrido que combine metodologias ágeis e o modelo MPS.BR de qualidade de software. As principais motivações incluem a teoria das restrições, a teoria do caos, e a necessidade de planejamento constante devido à incerteza em projetos de desenvolvimento de software.

1. Metodologias
ágeis
e
MPS.BR
–
Aplicação
Prá9ca
Isabella
Fonseca
isabella.afonseca@gmail.com

2. Apresentação
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
2
Isabella
Fonseca
É
Certified
Scrum
Master
(CSM)
com
9
anos
de
prática
de
Scrum,
tendo
sido
líder
no
SEPG
que
conduziu
a
Powerlogic
à
certificação
MPS.BR
Nível
F
em
junho/2007
e
MPS.BR
Nível
C
em
março/2010
incorporando
grande
nível
de
abrangência
do
Scrum,
XP
e
Lean
Principles.
É
também
PMP-­‐ACP.
Atuou
como
Scrum
Master
e
Product
Owner
participando
de
mais
de
150
Sprints
(iterações
de
desenvolvimento
ágeis)
rodados
e
aperfeiçoados
ao
longo
dos
últimos
anos.
Formada
em
Ciência
da
Computação
pela
PUC-­‐MG
com
especialização
em
Redes
de
Telecomunicações
pela
UFMG.
É
consultora
de
processos
de
desenvolvimento
de
Software
e
Serviços
na
área
de
Qualidade
da
FUMSOFT.

3. • Processo
de
Desenvolvimento
de
Software
da
Powerlogic
(PDS_P&D_v19)
• Craig
Larman:
Agile
and
Iterative
Development:
A
Manager’s
Guide,
Addison-­‐Wesley
2003
• Artigo:
“Por
que
SCRUM?”,
ESM,
4ª.
ed.
(Agosto
2008)
escrito
por
Fonseca,
I.
e
Campos,
A.
• Artigo:
“Ideal
Day
e
Priorização?”,
ESM,
6ª.
ed.
(Outubro
2008)
escrito
por
Fonseca,
I.,
Alves,
M.
e
Alves,
F.
• Mary
and
Tom
Poppendieck:
Lean
Software
development,
Addison
Wesley
2003
• Ken
Schwaber
and
Mike
Beedle:
Agile
Software
Development
with
SCRUM,
Prentice
Hall
2001
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
3
Bibliografia

4. Bibliografia
• Ken
Schwaber:
Agile
Project
Management
with
SCRUM,
Microsoft
Press
2004
• Takeuchi
&
Nonaka,
“The
New
New
Product
Development
Game”,
Harvard
Business
Review,
Jan/Feb
1986
• Cohn,
“Agile
Estimating
and
Planning”,
Prentice
Hall,
2006
• Alistair
Cockburn:
Agile
Software
Development,
Cockburn
Highsmith
Series
Editors,
2000
• http://www.rallydev.com/sites/default/files/5%20levels%20of
%20agile%20planning-­‐Portuguese-­‐Final.pdf
• http://scrumex.com.br/blog/?p=907
• http://www.cesar.edu.br/docs/paulocaju.pdf
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
4

5. Mo#vações
para
busca
de
um
modelo
híbrido
Isabella
Fonseca

6. TEORIA
DAS
RESTRIÇÕES
“Usando
esse
processo
podemos
enfocar
nossos
esforços
nos
poucos
pontos
de
um
sistema
que
determinam
seu
desempenho
(nas
suas
restrições),
e
assim
podemos
melhorar
significativamente
no
curto
prazo.”
Eliyahu
Goldratt
–
A
Meta
Escopo
Prazo
Preço
Projeto
Urgente
Escopo
Prazo
Preço
Projeto
Crí9co
Escopo
Prazo
Preço
Sem
Orçamento
Motivações
para
busca
de
um
modelo
híbrido
Fonte:
Processo
de
Desenvolvimento
de
Software
da
Powerlogic
(PDS_P&D_v19)

7. Motivações
para
busca
de
um
modelo
híbrido
Fonte:
Craig
Larman
–
Agile
&
Iterative
Development
CONE
DA
INCERTEZA
-­‐
Planos
evolucionários
trazem
maior
possibilidade
de
acerto.

8. TEORIA
DO
CAOS
–
Trata
do
funcionamento
de
sistemas
complexos
e
dinâmicos.
Processos
Preditivos
não
são
adequados
para
este
tipo
de
desenvolvimento
de
produtos.
Não
garantem
sua
previsibilidade!!
Ser
ágil
é
ser
capaz
de
responder
ou
impor
mudanças
estratégicas.
Motivações
para
busca
de
um
modelo
híbrido

9. PLANNING
CONSTANTE!
Múl9plos
PDCAs:
Plan
-­‐
Do
–
Check
–
Act
O
ciclo
de
Deming
tem
por
princípio
tornar
mais
claros
e
ágeis
os
processos
envolvidos
na
execução
-­‐>
Melhoria
ConVnua
Motivações
para
busca
de
um
modelo
híbrido

10. Motivações
para
busca
de
um
modelo
híbrido
As
atividades
de
planejamento
para
projetos
de
desenvolvimento
devem
se
basear
em
cinco
níveis:
– Visão
do
Produto
– Roadmap
do
Produto
– Planejamento
do
Release
– Planejamento
da
Iteração
– Planejamento
Diário
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
10
Fonte:
http://www.rallydev.com/sites/default/files/5%20levels%20of
%20agile%20planning-­‐Portuguese-­‐Final.pdf

11. 02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
11
Fonte:
http://www.rallydev.com/sites/default/files/5%20levels%20of%20agile
%20planning-­‐Portuguese-­‐Final.pdf
Motivações
para
busca
de
um
modelo
híbrido

12. Motivações
para
busca
de
um
modelo
híbrido
Fonte:
Alistar
Cockburn
-­‐
Agile
Software
Development

13. Através
da
evolução,
entedimento
e
aplicação
de
modelos
de
qualidade,
a
fundamentação
básica
do
CMMI
já
vem
sendo
interpretada
de
forma
mais
“ágil”
por
consultores
e
certificadores,
conscientes
das
burocracias
desnecessárias
advindas
de
aplicação
de
“fórmulas”
não
contextualizadas.
Motivações
para
busca
de
um
modelo
híbrido

14. Motivações
para
busca
de
um
modelo
híbrido
Fonte:
The
Ra9onal
Unified
Process
Made
Easy:
A
Prac99oner's
Guide
to
the
RUP

15. Motivações
para
busca
de
um
modelo
híbrido
Fonte:
The
Ra9onal
Unified
Process
Made
Easy:
A
Prac99oner's
Guide
to
the
RUP

16. “O
caráter
sensato
“de
ênfase”
(e
não
ruptura)
do
Manifesto
da
Agilidade
tem
sido
ignorado
em
algumas
posturas
radicais
que,
precipitadas,
chegam
a
confundir
agilidade
com
mera
informalidade.”
Paulo
Alvim
Motivações
para
busca
de
um
modelo
híbrido
hZp://www.agilemanifesto.org

17. Práticas
de
métodos
ágeis
podem
ser
mapeadas
às
áreas-­‐chaves
de
processos
do
MPS.BR
ou
CMMI
levando
às
organizações
a
implementarem
as
atividades
necessárias
a
implantação
do
modelo
e
ainda
continuar
com
as
vantagens
e
leveza
dos
métodos
ágeis.
Estes
modelos
dizem
o
que
fazer,
mas
não
dizem
como
fazer.
Metodologias
ágeis
são
um
conjunto
de
melhores
práticas
que
contém
informações
específicas
de
“como
fazer”.
Motivações
para
busca
de
um
modelo
híbrido

18. Em Otimização
Gerenciado Quantitativamente
Definido
Largamente Definido
Parcialmente Definido
Gerenciado
Parcialmente Gerenciado
A
B
C
D
E
F
G
2
3
4
5
PROGRAMA
DE
MELHORIA
DE
PROCESSO
DE
SW-­‐BRASILEIRO
INICIATIVA
SOFTEX/
APOIO
BID
•
Avaliações
realizadas:
596
Software
e
7
Serviços
=
TOTAL
603
•
Instituições
Implementadoras
(II):
19
•
Instituições
Organizadoras
de
Grupos
de
Empresas
(IOGES):
São
17
instituições
e
72
projetos.
•
Instituições
Avaliadoras:
13
•
Cursos
realizados:
277
•
Provas
realizadas:
60
•
Participantes
de
cursos
oficiais
MPS
presenciais:
5974
•
Participantes
de
cursos
oficiais
MPS
EAD:
117
•
Aprovados
em
provas
oficiais
MPS:
1416
Dados
de
Outubro/2014

19. Exemplo
de
um
modelo
híbrido
Fonte:
hZp://www.powerlogic.com.br

20. Visão
Prá#ca
Isabella
Fonseca

21. PreGame
Game
PostGame
Monitoramento
Produto
Release
1
Release
N-­‐1
Release
N
Product
Backlog
Release
Backlog
Alta
Gestão
Clientes
Suporte,
Comercial,
etc
Priorização
GPR
GCO
VA
L
GRI
GRE
DRE
PCP
GRU
GPP
MED
Release
Planning
1
Release
Review
Release
Retrospective
GPR
GRU
GRH
GRI
GRE
VAL
GRE
GRI
MED
ITP
GQ
A
AMP
Scrum
Team
GRH
GRH
Release
Backlog
PreSprint
(N-­‐1))
Sprint
(N)
PostSpri
nt
(N+1)
GRE
DRE
VAL
ITP
MED
GQA
GCO
VER
Sprint
Planning
1
Sprint
Planning
2
Sprint
Review
Sprint
Retrospec9ve
Daily
Scrum
Rees9mate
Mee9ng
Follow
Up
Mee9ng
Abnormal
Termina9on
Sprint
Mee9ng
Sprint
Scrum
Team
1
2
3
4
VAL
VER
Selected
Backlog
Sprint
Backlog

22. Produto
Release
1
Release
N-­‐1
Release
N
Product
Backlog
Release
Backlog
Alta
Gestão
Clientes
Suporte,
Comercial,
etc
Priorização
GPR
GCO
VAL
GRI
GRE
DRE
PCP
GRU
GPP
MED
1

23. PreGame
Game
PostGame
Release
Monitoramento
Release
Planning
2
GCO
Release
Planning
1
Release
Review
Release
Retrospec#ve
GPR
GRU
GRH
GRI
GRE
VAL
GRE
GRI
MED
ITP
GQA
AMP
Scrum
Team
GRH
GRH
Release
Backlog
2
VAL
VER

24. Game
PreSprint
(N-­‐1))
Sprint
(N)
PostSprint
(N+1)
GRE
DRE
Scrum
Team
Auditor
(GQA)
e
GCO
QC
Externo
VAL
ITP
MED
GQA
GCO
VER
3

25. Sprint
Sprint
Planning
1
Sprint
Planning
2
Sprint
Review
Sprint
Retrospec9ve
Daily
Scrum
Rees9mate
Mee9ng
Follow
Up
Mee9ng
Abnormal
Termina9on
Sprint
Mee9ng
ITP
PCP
GCO
GQA
DRE
GRU
DFP
DRU
GRI
AMP
MED
VER
VAL
GRE
Selected
Backlog
Sprint
Backlog
4

26. DESAFIO
1:
GPR
(Gerência
de
Projetos):
Como
gerenciar
com
base
em
“planejamento
conYnuo”
(planning)
em
lugar
de
um
grande
plano
inicial?

27. Fonte:
hZp://www.powerlogic.com.br
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
27
Planning
constante!
GPR1
GPR3
GPR5
GPR10
GPR,
GRI,
AMP
GPR,
GRI
GPR1
-­‐
O
escopo
do
projeto
é
definido.
GPR3
-­‐
O
ciclo
de
vida
do
projeto
é
definido.
GPR5
–
O
cronograma
do
projeto,
incluindo
marcos
e
pontos
de
controle,
é
man9do.
GPR10
-­‐
Um
plano
geral
é
estabelecido.
GPR2
-­‐
.o
tamanho.
é
dimensionado.
GPR4
-­‐O
esforço
para
a
execução
são
es9mados
.
GPR11
-­‐
A
viabilidade
de
a9ngir
as
metas
é
avaliada.
GPR12
-­‐
O
Plano
do
Projeto
é
revisado
com
todos.
GPR17
-­‐
Revisões
são
realizadas
em
marcos
do
projeto.
AMP
–
Avaliação
e
Melhoria
de
Processo
GPR
7
e
GRH
GPR7
-­‐
Os
recursos
humanos
para
o
projeto
são
planejados
considerando
o
perfil
e
o
conhecimento
necessários
para
executá-­‐lo
.
GRH
–
Gerência
de
Recursos
Humanos
GPR13
-­‐
O
escopo,
as
es9ma9vas,
o
cronograma
do
projeto
são
monitorados
.
GPR14
-­‐
Os
recursos
materiais
e
humanos
são
monitorados.
GPR15
-­‐
Os
riscos
são
monitorados
em
relação
ao
planejado
.
GPR18
-­‐
Registros
de
problemas.
GPR19
-­‐
Ações
para
corrigir
desvios
em
relação
ao
planejado
são
estabelecidas,
implementadas
e
acompanhadas
até
a
sua
conclusão
GPR13,
14,15,
18
e
19.
GPR,
GRI,
AMP

28. Boas
Práticas
–
Uso
do
Release
Goal
▫ Breve
declaração
que
informa
o
foco
do
trabalho
durante
uma
Release
dado
pelo
Product
Owner
▫ Orienta
o
time
no
monitoramento
e
andamento
dos
trabalhos
e
entrega
de
maior
retorno
de
valor
▫ Deve
estar
coerente
aos
itens
de
backlog
da
release
–
Release
Backlog
▫ Cria
alinhamento
entre
PO,
SM
e
Time
e
comunica
aos
envolvidos
em
que
o
time
está
trabalhando.
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
28

29. Boas
Práticas
–
Plano
de
Capacitação
Fonte:
hZp://www.powerlogic.com.br

30. Boas
Práticas:
Real
Sprint
Review
▫ Realizada
após
cada
Sprint,
com
duração
de
entre
2
a
4
horas
e
participação
do
PO.
▫ Equipe
apresenta
os
resultados
obtidos
durante
o
Sprint.
▫ O
Sprint
Goal
é
verificado!
▫
Informal
-­‐>
sem
slides!!!
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
30

31. Boas
Práticas:
Real
Retrospective
Meeting
▫ Reunião
com
duração
de
1-­‐2
horas.
Levantamento
das
lições
aprendidas.
▫ Timeline
pode
ser
relembrado
em
grupo.
▫ 2
perguntas:
▫ "O
que
foi
bem?"
(WWW-­‐What
Went
Well?)
e
▫ "O
que
pode
ser
melhorado?
(WCBI
-­‐
What
Can
Be
Improved?).
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
31

32. Boas
Práticas:
Daily
Scrum
–
viabilidade
diária
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
32
Para
manter
o
controle
sobre
o
andamento
do
projeto,
sugere-­‐se
fortemente
inves9r
15
minutos
diários
para
atualizar
o
status
do
“o
que
foi
feito
ontem“
e
reafirmar
o
compromisso
com
o
trabalho
de
hoje
e
da
iteração.
Problemas
devem
ser
levantados
e
suas
soluções
devem
ser
definidas.
A
viabilidade
é
con9nuamente
avaliada.
Nome%do%Release:%
Nome%da%Iteração:%
O%que%foi%feito%hoje%(tarefas)?%
O%que%será%feito%amanhã%(tarefas)?%
Que%impedimentos%ocorreram?%
Riscos:%
Viabilidade%comprometida?%
!

33. Boas
Práticas:
Estado
'pronto'
(ready)
• Acordo
sobre
entregáveis
quando
uma
funcionalidade
está
“pronta”.
• Diz
respeito
ao
estado
estável
e
conhecido
necessário
para
que
o
time
possa
iniciar
seus
trabalhos.
• É
a
partir
desse
estado
que
o
time
pode
se
auto-­‐organizar
e
exercitar
sua
multidisciplinaridade.

34. Boas
práticas:
Acompanhamento
via
Kanban
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
34
Fonte:
Livro
Scrum
e
XP
direto
das
trincheiras

35. Boas
práticas:
Uso
do
BurnDown
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
35
Fonte:
hZp://www.powerlogic.com.br
Fonte:
hZp://www.powerlogic.com.br
Fonte:
hZp://www.powerlogic.com.br
Fonte:
hZp://www.powerlogic.com.br

36. Boas
Práticas:
Levantamento
e
atuação
diante
dos
impedimentos
▫ Entendimento
de
impedimentos:
eventos
que
impeçam
o
progresso
do
9me
dentro
do
Sprint.
▫ Problemas
pessoais
▫ Interrupções
externas
–
a9vidades
de
outro
projeto,
reuniões,
atendimento,
etc.
▫ Devem
ser
tratados
até
sua
conclusão.
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
36

37. Desafio
2:
GRE
(Gerência
de
Requisitos):
Como
es#mar
requisitos
que
são
parcialmente
conhecidos
no
início
do
projeto?

38. GRE
–
Gerência
de
Requisitos
• Priorização
dos
itens
do
backlog
• Quebra
de
itens
do
Product
Backlog
em
Atividades
• Refinamento
de
itens
do
de
Product
Backlog,
com
refinamento
em
três
fases
(Release
Backlog
-­‐>
Select
Backlog
-­‐>
Sprint
Backlog)
• Uso
de
Ideal
Day,
Story
Point,
EmpresaPoint,
etc.
• Uso
de
Planning
Poker

39. Boas
Práticas:
Priorização
itens
do
Product
Backlog
Pontos
a
serem
levados
em
consideração:
-­‐
80%
do
valor
de
um
sorware
vem
de
20%
das
funcionalidades
-­‐
Cerca
de
60%
das
funcionalidades
entregues
em
projetos
de
sucesso
são
raramente
ou
nunca
u9lizadas.
Fonte:
hZp://www.sorhouse.se/
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
39

40. • Um
gráfico
de
quatro
quadrantes
de
itens
do
escopo
que
foram
classificados
em
função
seu
BV
e
sua
facilidade
de
implementação.
Itens
que
se
concentram
no
quadrante
superior
direito
são
os
que
devem
ser
priorizados
e,
seguramente,
são
os
que
mais
representam
a
maximização
do
resultado.
Fonte:
hZp://www.powerlogic.com.br
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
40
Boas
Práticas:
Priorização
itens
do
Product
Backlog

41. Plano
Ágil
Sprint
1
48
SP
-­‐
400
BV
Sprint
2
52
SP
-­‐
250
BV
Sprint
3
55
SP
-­‐
150
BV
Sprint
4
40
SP
-­‐
100
BV
Sprint
5
50
SP
-­‐
100
BV
Plano
de
Projeto
(Release
Plan):
Total
de
245
SP
e
1.000
BV
Gaste
60%
do
tempo
elicitando
os
20%
de
itens
no
"topo
da
pilha"
Gaste
outros
30%
estimando
os
20%
próximos
Gaste
10%
para
o
restante
20%
20%
60%
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
41
Boas
Práticas:
Priorização
itens
do
Product
Backlog

42. Boas
Práticas:
Refinamento
e
Quebra

43. Boas
práticas
–
Quebra
e
Agrupamento
Fonte:
hZp://www.powerlogic.com.br

44. Estimativas
Ágeis
• A
estimativa
empírica
é
uma
maneira
sensata
de
se
prever
o
tamanho
de
requisitos
acompanhada
por:
– Realimentação
iterativa
da
"velocidade",
a
partir
de
dados
históricos
coletados
para
a
mesma
equipe.
– Realização
de
consenso
entre
especialistas,
com
técnicas
de
comunicação
e
convergência
como
a
do
Planning
Poker.
– Utilização
da
técnica
de
PERT
(Program
Evaluation
and
Review
Technique).
– Utilização
de
balanceamento
como
a
técnica
Cocomo
(COnstructive
COst
MOdel).
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
44

45. Boas
práticas
–
Uso
do
Planning
Poker
• Planning
Poker
– Envolvimento
de
todo
o
Time
– Evita
influência
nas
opiniões
– Aprendizado
nos
requisitos
até
que
haja
consenso
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
45

46. Estimativas
Ágeis
–
Velocidade
da
equipe
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
46

47. Desafio
3:
GPR
e
GCO
(Gerência
de
Projetos
e
Configuração):
Como
aceitar
mudanças
estratégicas
e
controlá-­‐las?

48. SM
–
Solicitação
de
Mudança
• Solicitação
de
Mudança
“leve”:
Mudanças
ao
final
do
Sprint
ou
dentro
de
um
Sprint
que
não
afetem
o
“Sprint
Goal”
não
requerem
“Solicitação
de
Mudança”.
Somente
são
requeridas
em
situações
críticas
(Ex.:
“não
vamos
cumprir
o
Goal”)
ou
para
mudanças
de
configuração
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
48

49. Desafio
5:
MED
(Medição):
O
que
são
bons
indicadores
em
um
processo
ágil?

50. Boas
práticas:
Sistema
de
Avaliação
e
Controle
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
50
A
avaliação
e
o
controle
de
um
Plano
de
Tecnologia
permite
reduzir
a
diferença
entre
o
desempenho
esperado
e
o
desempenho
real,
garan9ndo
sua
eficácia.
Por
isso,
devem
ser
realizados
antes,
durante
e
após
a
implementação
do
Plano.
!
Desvio'de'esforço'ou'custo'no'projeto'
!
Gráfico'de'BurnDown'!
!
!
!

51. Indicador
que
mede
o
progresso
do
trabalho
refle9ndo
diariamente
seu
trabalho.
Sua
curva
indica
se
o
Scrum
Team
está
se
adaptando
para
o
plano
definido
e
comprome9do
por
todos
-­‐
Sprint
Goal
e
conseguindo
trabalhar
de
forma
realmente
itera9va
ou
sofrendo
impedimentos
em
excesso.
Boas
práticas:
Sistema
de
Avaliação
e
Controle

52. Também
é
interessante
armazenar
o
histórico
de
sucesso
de
alcance
de
goals
a
cada
Sprint.
Para
isso,
sugere-­‐se
criar
um
indicador
simples
de
resultado
por
iteração
a
fim
de
manter
a
equipe
focada
em
melhorar
seu
desempenho.
Além
disso,
de
forma
lúdica,
pode-­‐se
criar
mecanismos
de
premiação
em
caso
de
alcances
sucessivos.
Fonte:
hZp://www.powerlogic.com.br/
Boas
práticas:
Sistema
de
Avaliação
e
Controle

53. É
de
extrema
importância
medir
a
efe9vidade
em
relação
à
liberação
de
máximo
valor
de
negócio
a
cada
entrega
efetuada.
Dessa
forma,
deve-­‐se
medir
se
o
PO
está
priorizando
corretamente
as
demandas
de
trabalho
nas
liberações
ao
longo
do
tempo.
Fonte:
hZp://www.powerlogic.com.br/
Boas
práticas:
Sistema
de
Avaliação
e
Controle

54. Outro
indicador
também
importante
é
se
obter
o
quão
eficaz
está
sendo
o
dimensionamento
em
tamanho
dos
requisitos.
Dado
os
itens
de
selected
backlog
do
sprint,
comparar
tamanhos
previstos
x
realizados
após
a
reunião
de
Release
Review.
Fonte:
hZp://www.powerlogic.com.br/
Boas
práticas:
Sistema
de
Avaliação
e
Controle

55. Dashboard
que
acompanha
diariamente
a
evolução
de
entregas
de
BV
e
de
esforço
restante.
Fonte:
Revista
Visão
Ágil
–
Gestão
Ágil
de
Projetos
com
Scrum
e
FDD
–
Manoel
Pimentel
Medeiros
Exemplo
de
Medição
–
Sprint
Dashboard

56. Desafio
6:
VER,
VAL
(Verificação,
Validação)
e
GQA
(Qualidade):
Como
averiguar
a
qualidade
de
produto
e
processo?

57. VER
–
Verificação
e
ITP
–
Integração
de
Produto
Fonte:
hZp://www.powerlogic.com.br/
-­‐
SONAR

58. GQA
(Garantia
da
Qualidade)
e
VAL
(Validação)
• GQA:
Atividades
de
auditoria
de
produtos
e
sub-­‐produtos
via
checklists
• VAL:
Atividades
de
aceitações
finais
de
um
produto
já
verificado,
normalmente
realizadas
pelo
cliente
(PO)
e
usuários
finais
(programas
de
validação).
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
58

59. Fonte:
hZp://www.powerlogic.com.br

60. E
por
fim...
q Por
tudo
isso,
o
Scrum
(e
outros
modelos
e
metodologias
ágeis)
não
é
milagreiro.
Quem
contribui,
em
muito,
para
o
sucesso
de
um
projeto,
são
as
pessoas
envolvidas:
sejam
desenvolvedores,
gerentes,
o
corpo
diretor
ou
clientes.
Todos
devem
estar
cientes
do
porquê
utilizar
as
técnicas
citadas
neste
curso:
pair
programming,
peer
review,
comunicação
tácita,
compartilhamento
de
código,
entrega
de
maior
valor
de
negócio,
planejamento
contínuo,
etc.
q Estas
são
somente
algumas
práticas
que
você
pode
aplicar
para
complementar
seu
dia-­‐a-­‐dia
no
gerenciamento
de
projetos.
02/12/14
TOTUM
Consultoria
-­‐
isabella.afonseca@gmail.com
60

61. Metodologias
ágeis
e
MPS.BR
–
Aplicação
Prá9ca
Isabella
Fonseca
isabella.afonseca@gmail.com