Apresentacao gerenciamento projetos_mpsbr_scrum

MPS.BR
e
Metodologias

Ágeis

Carlos
Barbieri

Isabella
Fonseca

GERENCIAMENTO DE PROJETOS DE
SOFTWARE

Apresentação

Carlos
Barbieri
é
Gerente
de
Qualidade
da

FUMSOFT,
Coordenador
do
Programa
MPS.BR

em
Minas
Gerais,
Coordenador
Nacional
do

Curso
de
Pós-‐Graduação
Engenharia
e
Qualidade

de
SoFware
do
Modelo
MPS.

Foi
também
Gerente
de
Tecnologia
da
CEMIG
onde

trabalhou
por
30
anos.

Mestrado
no
INPE
na
área
de
Engenharia
de

Sensoriamento
Remoto
e
em
InformáOca.

Professor
de
Pós
Graduação
do
UNI-‐BH,
FUMEC
e

IETEC.

Dois
livros
publicados
e
o
terceiro
que
será
lançado

em
Julho/2011.

Apresentação

Isabella
Fonseca
é
CerOfied
Scrum
Master
(CSM)
com
6

anos
de
práOca
de
Scrum
e
14
anos
de
experiência

em
TI,
tendo
sido
líder
no
SEPG
que
conduziu
a

Powerlogic
à
cerOficação
MPS.BR
Nível
F
com
Scrum,

em
junho/2007.

Atuou
como
Scrum
Master
por
2,5
anos
e
pelos
4,5

anos
restantes
exerceu
o
papel
de
Product
Owner

para
a
família
de
produtos
eCompany
da
Powerlogic,

conOnuando
como
líder
do
SEPG
para
cerOficação

MPS.BR
Nível
C,
finalizada

em
março/2010.

Atualmente
é
Analista
de
Qualidade
da
FUMSOFT.

Formada
em
Ciência
da
Computação
pela
PUC-‐MG
com

especialização
em
Redes
de
Telecomunicações
pela

UFMG,
lecionou
ainda
disciplinas
de
Engenharia
de

SoFware
e
Análise
de
Sistemas
na
UNA.

Agenda

¨  GERAL

¤  MPS.BR
–
Conceitos

n  SoFex

¤  FUMSOFT

E
CCOMP.MG

n  Resultados
2010

n  PerspecOvas
2011

n  PerspecOvas
2012

¨  PROJETO
MPS.BR/2011-‐08
(Grupo
8)
-‐
VISÃO
GERAL

¤  Plano
de
Implementação
Padrão

¤  Cronograma

¨  Conceitos
dos
Processos
nível
F-‐REPS

¨  Conceito
de
Resultados
de
Atributos
de
Processos-‐RAPS

¨  MPS.BR
com
Metodologias
Ágeis

MPS.BR
-‐
Conceitos

SOFTEX:
Associação
para
Promoção
da

Excelência
do
SoSware
Brasileiro

•  Organização
da
Sociedade
Civil
de
Interesse
Público
que

visa
aumentar
a
compeOOvidade
da
indústria
de
soFware

brasileira,
por
meio
de
ações
em
três
áreas-‐ﬁm:

–  Capacitação
e
Inovação

–  Mercado

–  Qualidade
e
CompeOOvidade

•  Coordena
as
ações
de
22
Agentes
SOFTEX,
em

20
cidades
de
12
UF,
com
mais
de
1.600
empresas

associadas
(cerca
de
70%
são
micro
e
pequenas

empresas)

Maturidade
do
Processo
de
SoSware

no
Brasil
em
2003

Estudos
no
início
dos
anos
2000
mostraram
que:

Ø  era
necessário
um
esforço
signiﬁcaOvo
para
aumentar
a

maturidade
dos
processos
de
soFware
nas
empresas

brasileiras
[MCT
2001]

Ø  as
empresas
de
soFware
no
Brasil
favoreceram
a
ISO
9000
em

detrimento
de
outras
normas
e
modelos
especiﬁcamente

voltadas
para
a
melhoria
de
processos
de
soFware
como
o

CMM
(antecessor
do
CMMI)
[MIT
2003]

Referências:

[MCT
2001]
Qualidade
e
Produ;vidade
no
Setor
de
So?ware

Brasileiro

[MIT
2003]
Slicing
the
Knowledge-‐based
Economy
in
Brazil,
China

and
India:

a
tale
of
3
so?ware
industries

Programa
MPS.BR:
Melhoria
de
Processo
do

SoSware
Brasileiro

¨  Para
ajudar
na
solução
deste
problema,
a
SOFTEX
–
Associação
para
Promoção
da

Excelência
do
SoFware
Brasileiro
lançou
o
programa
MPS.BR
em
11DEZ2003
(há

quase
sete
anos),
numa
reunião
realizada
no
MCT
–
Ministério
da
Ciência
e

Tecnologia
em
Brasília-‐DF

¨  O
propósito
do
programa
mobilizador
MPS.BR
é
a
Melhoria
de
Processo
do

SoSware
Brasileiro,
compreendendo
duas
metas
(desaﬁos):

¤  Meta
técnica:
criação
e
aprimoramento
do
modelo
MPS

n  em
conformidade
com
as
normas
ISO/IEC
12207
–
So?ware
Life
Cycle
Processes
e
ISO/IEC

15504
–
Process
Assessment

n  compasvel
com
o
CMMI

n  baseado
nas
melhores
práOcas
da
Engenharia
de
SoFware

n  adequado
à
realidade
das
empresas
brasileiras

¤  Meta
de
mercado:
disseminação
e
adoção
do
modelo
MPS
(em

todas
as
regiões
do
país,
num
intervalo
de
tempo
justo,
a
um
custo

razoável)

n  tanto
em
PME
-‐
Pequenas
e
Médias
Empresas
(foco
principal)

n  quanto
em
Grandes
Organizações
(públicas
e
privadas)

Modelo
MPS:
MR-‐MPS,
MA-‐MPS
e
MN-‐MPS

Modelo
MPS

ISO/IEC CMMI-DEV ISO/IEC
12207 15504

Modelo de Referência Modelo de Avaliação Modelo de Negócio
MR-MPS MA-MPS MN-MPS

Guia Geral Guia de Aquisição Guia de Avaliação Documento do MPS.BR

Guia de Implementação

5 A Em Otimização
4 B Gerenciado Quantitativamente

C Definido
3
D Largamente Definido

E Parcialmente Definido
2
F Gerenciado

• PROGRAMA DE MELHORIA
DE PROCESSO DE SW-BRASILEIRO G
• INICIATIVA SOFTEX/ APOIO BID Parcialmente Gerenciado
• BRASIL->CONE SUL-MÉXICO
• > 250 CERTIFICAÇÕES
• FUMSOFT- CCOMP.MG-II-IA-IOGE

Modelo
de
Referência
MR-‐MPS
(Guia
Geral:2009)

7 Níveis Processos Atributos de Processo (AP)

A – 1.1, 2.1, 2.2, 3.1, 3.2, 4.1*, 4.2*, 5.1* - o processo é objeto
de melhorias e inovações, 5.2* - o processo é
otimizado continuamente

Gerência de Projetos – GPR (evolução)
B 1.1, 2.1, 2.2, 3.1, 3.2, 4.1* - o processo é medido, 4.2* - o
processo é controlado

Gerência de Riscos – GRI, Desenvolvimento para
C Reutilização – DRU, Gerência de Decisões – 1.1, 2.1, 2.2, 3.1, 3.2
GDE
Verificação – VER, Validação – VAL, Projeto e
D Construção do Produto – PCP, Integração do
Produto – ITP, Desenvolvimento de Requisitos 1.1, 2.1, 2.2, 3.1, 3.2
- DRE
Gerência de Projetos – GPR (evolução), Gerência
E de Reutilização – GRU, Gerência de Recursos
Humanos – GRH, Definição do Processo 1.1, 2.1, 2.2, 3.1 – o processo é definido, 3.2 – o processo
Organizacional – DFP, Avaliação e Melhoria do está implementado
Processo Organizacional – AMP

Medição – MED, Garantia da Qualidade – GQA,
F Gerência de Portfólio de Projetos – GPP, 1.1, 2.1, 2.2 – os produtos de trabalho do processo são
Gerência de Configuração – GCO, Aquisição - gerenciados
AQU
Gerência de Requisitos – GRE, Gerência de
G Projetos - GPR
1.1 – o processo é executado, 2.1 – o processo é
gerenciado

* Estes AP somente devem ser implementados para os processos críticos da organização/unidade organizacional. Os demais AP devem ser
implementados para todos os processos.

PROCESSO ISO/IEC-12207

DESENVOL-
OPERAÇÃO MANUTENÇÃO AQUISIÇÃO FORNECIMENTO
VIMENTO

SDP
2
CAPACIDADE-ISO/IEC-15504

PROJETO (AQU)GERÊNCIA DE
AQUISIÇÃO

(GCO)-GERÊNCIA DE (GQA)-GARANTIA
CONFIGURAÇÃO DE QUALIDADE
P.PROJETO
(MED) MEDIÇÃO

F
GERENCIADO
(GPP)-GERÊNCIA DE PORTFÓLIO DE
PROJETOS

2
(PMC)MONITORAÇÃO E
(GRE) GERÊNCIA DE CONTROLE
REQUISITOS (PP) PLANEJAMENTO
DE PROJETO

G PARCIALMENTE GERENCIADO
GERÊNCIA DE
PROJETOS(GPR)

DESENVOL-
VIMENTO

3

(ADR)ANÁLISE E
DECISÃO E RESOLUÇÃO

C
(DRU) DESENVOLVIMENTO PARA
REUTILIZAÇÃO
DEFINIDO (GRI)GERÊNCIA DE RISCOS

UML
(ITP)INTEGRAÇÃO DO
PRODUTOS
(VAL)VALIDAÇÃO
PROCESSO
USADO
3
(DRE)DESENVOLVIMENTO DE(CONSTRUIU O QUE FOI PEDIDO?)
(PCP)-PROJETO E CONSTRUÇÃO REQUISITOS
DO PRODUTO

D
LARGAMENTE DEFINIDO
(VER)VERIFICAÇÃO
(CONSTRUIU CORRETAMENTE?)

SEPG
3
(AMP)AVALIAÇÃO E MELHORIA DO
(DFP)-DEFINIÇÃO DO PROCESSO
PROCESSO ORGANIZACIONAL ORGANIZACIONAL (GRH)GERÊNCIA DE (GRU) GERÊNCIA DE

E
RH REUTILIZAÇÃO

PARCIALMENTE DEFINIDO

DESENVOL-
VIMENTO

5

A EM OTIMIZAÇÃO

NÍVEL COMPOSTO PELOS PROCESSOS DOS NÍVEIS
ANTERIORES(G ao C), SENDO QUE AO
4
GPR SÃO ACRESCENTADOS NOVOS RESULTADOS.
TODOS OS PROCESSOS DEVEM SATISFAZER OS ATRIBUTOS DESIGN
CODE
AP 1.1, AP2.1, AP3.1,AP 3.2 E AS RAPS RAP 16 E RAP 17 TEST
DO AP 4.1. OS PROCESSOS SELECIONADOS PARA ANÁLISE
DE DESEMPENHO DEVEM SATISFAZER INTEGRALMENTE AP 4.1
E AP4.2 ANÁLISE DE
B GERENCIADO QUANTITATIVAMENTE
DESEMPENHO

Implementação
MPS.BR

por
estado
(MNC)
–
Publicadas-‐Setembro-‐2009

Programa
MPS.BR

=>
Programa
de
longo
prazo(*)

(
*)
como
o
CMMI
que
começou
com
o
CMM
em
1991,
com
antecedentes
desde
1988

SP
2012-2015

INTERNACIONALIZAÇÃO
DO MPS.BR

2008-2011
CONSOLIDAÇÃO
DO MPS.BR

2004-2007
IMPLANTAÇÃO
DO MPS.BR

FONTE: SOFTEX – set 2009

250
Avaliações
MPS
Publicadas
(validade
3
anos),
por
níveis
MPS
e
regiões

brasileiras.

Em
20-‐MAI-‐2010:
179
organizações
na
base
de
clientes
MPS
(grande

porte=28%
e
PME=72%,
sendo
microempresas=6%,
pequenas=45%
e

médias=21%)

120 120

100 100
2005-2007: 72
80 2005-2007: 72 80 organizações
organizações
60 60

40 40
2008-2011: 178 2008-2011:
organizações 178
20 até 30NOV2010 20 organizações
até
0 30NOV2010
0
G F E D C B A SE CO NE SU NO

iMPS2010:
Desempenho
das
empresas
que
adotaram
o

modelo
MPS
de
2008
a
2010
(Travassos,
G.
H.
e

Kalinowski,
M.
-‐
SOFTEX
2010)

¨  Esta
publicação
apresenta
os
resultados
da
pesquisa
iMPS2010,
realizada
pelo
Grupo
de

Engenharia
de
SoFware
Experimental
da
COPPE/UFRJ,
dando
conOnuidade
às
pesquisas

iMPS2008
e
iMPS2009

¨  No
total,
para
o
ano
de
2010,
foram
recebidos
quesOonários
eletrônicos
de
156
empresas

diferentes
que
adotaram
o
modelo
MPS:

¤  A
saOsfação
das
empresas
foi
notória
em
2010,
com
mais
de
92%
se
dizendo
parcialmente
ou

totalmente
saOsfeitas
com
o
modelo
MPS

¤  A
caracterização
permiOu
observar
que
as
empresas
que
adotaram
o
MPS,
quando
comparadas
às

empresas
que
estão
iniciando
a
implementação
MPS:

n  Apresentam
maior
saOsfação
dos
seus
clientes

n  Lidam
com
projetos
maiores

n  Apresentam
mais
precisão
em
suas
esOmaOvas
de
prazos

n  Mostram-‐se
mais
produOvas

¤  Na
análise
de
variação
de
desempenho,
idenOﬁcou-‐se
que
as
empresas
tendem
a
apresentar
os

benexcios
esperados
pela
Engenharia
de
SoFware
em
relação
a
custo,
prazo,
produOvidade
e

qualidade

Programa
MPS.BR

-‐
Avanços

PG-MPS: Pós-graduação em Engenharia e Qualidade de Software com
Modelo MPS, latu sensu 342h

Projeto RELAIS – Rede Latino Americana
da Indústria de Software, com apoio do
BID (participação do Brasil - MPS.BR,
México - MoProSoft, Colômbia - ITMark e
Peru – coordenador regional)

Comunidade de Prática do MPS.BR/RELAIS, que deverá
estar disponível em 2011 para seus usuários

Programa
MPS.BR

-‐
Fatores
Crílcos
de
Sucesso

-‐

A
forte
interação
universidade-‐empresa-‐governo,
sob
coordenação
da

SOFTEX

-‐

O
apoio
efeOvo
do
Governo
Federal
através
do
MCT
-‐
Ministério
das
Ciência

e
Tecnologia
e
da
FINEP
-‐
Financiadora
de
Estudos
e
Projetos,
desde
o
início
do

Programa

-‐ Dentre
outros
apoios
ao
Programa
MPS.BR
(MCT/SEPIN,
FINEP
e
SEBRAE),

destacam-‐se
os
dois
apoios
do
BID
(Banco
Interamericano
de

Desenvolvimento):

-‐ 
num
1º
projeto
que
permiOu
a
implantação
do
MPS
em
77
empresas

(onde
71
foram
avaliadas
=
92%
de
sucesso)

-‐ 
e
agora
através
do
Projeto
RELAIS,
que
está
no
início
mas
é
visto
como
o

embrião
da
próxima
etapa
de
Internacionalização
do
Programa
MPS.BR

(2012-‐2015)

FUMSOFT

¨  Sociedade
Mineira
de
SoSware

¨  CCOMP.MG

¤  Centro
de
Competência
FumsoS
em
MPS.BR
e
CMMI

¤  Formado
com
o
apoio
da
FAPEMIG
E
SECTES

¨  IOGE-‐Insltuição
Organizadora
de
Grupos
de
Empresas-‐2005

¨  II-‐Insltuição
Implementadora

credenciada
pela
SoSex-‐2005

¨  IA-‐Insltuição
Avaliadora
oﬁcial-‐2007

FUMSOFT

¨  IMPLEMENTAÇÃO
MPS.BR

¤  Modelo
Cooperado

Apoio
do
Governo
do
Estado
(SOFTEX
e
SECTES/
FAPEMIG)

¤  MODELO
ESPECÍFICO

¨  AQUISIÇÃO
DE
SOFTWARE
E

SERVIÇOS
CORRELATOS

Resultados 2010/11 – Minas Gerais

¨  Minas
Gerais
tem
1
II-‐InsOtuição
Implementadora
(FUMSOFT-‐
CCOMP.MG)

¨  Número
de
cerOﬁcações
até
maio/2011
=
45

¨  Cidades
fora
da
RMBH
alcançadas
pelo
Programa
MPS.BR=
Juiz
de

Fora,Itauna,
Viçosa,Divinópolis,Santa
Rita,Itajubá,Lavras,Ouro

Branco,Barbacena)

¤  Plano
para
Triângulo,
Vale
do
Aço
e
Norte
de
Minas

¤  Cooperação
com
Universidades
do
interior-‐Curso
para
Professores
se

transformarem
em
Implementadores

¨  Número
de
consultores
do
CCOMP.MG=16

Perspeclvas
2011

¨  Número
de
empresas
cerOﬁcadas
até
ﬁnal
de
2011
=
55-‐56

¨  Número
de
cidades
fora
da
RMBH
alcançadas
pelo
Programa
MPS.BR=
+
(Divinópolis,

Lavras,
Barbacena,
Ouro
Branco)

¤ Foco
no
Triângulo(Uberlândia)
e
Vale
do
Aço

¨  Número
de
consultores
do
CCOMP.MG=17-‐18

¨  Finalização
do
G7
com
11
empresas-‐avaliação
entre
Junho-‐Julho

¨  Início
do
G8-‐
17
empresas

¨  Programa
de
parceria
de
treinamento
com
a
IBM

¨  PerspecOvas
de
consultoria
em
empresas,
fora
do
padrão
cliente
MPS.BR
(Sebrae,UFV,Inatel,Cemig,
etc)

¨  Pós-‐graduação
em
Engenharia
de
SoFware
com
modelo
MPS,
acordo
SoFex-‐FumsoF

e
PUC-‐MG,
para
setembro/2011

Projeto
MPS.BR/2011

G8
–
Grupo
8
–
Visão

Geral

Plano
de
Implementação
Padrão

CARGA HORÁRIA POR NÍVEL
ID ATIVIDADE PÚBLICO ALVO
G G>F F F>C
1 DIAGNÓSTICO INICIAL
1.1 Levantamento e Análise de dados 8 8 8 8 a 12 Alta Direção/ SEPG/
1.2 Apresentação de Relatório 4 4 4 4 Equipe SW
2 TREINAMENTO / CAPACITAÇÃO
2.1 Workshop Executivo 4 4 4 4 Alta Direção/ SEPG
2.2 Gestão de Requisitos 8 8(*) 8 - SEPG
2.3 Gerência de Projetos 12 a 16 12 a 16(*) 12 a 16 - SEPG
2.4 Gerência de Portfólio - 4a8 4a8 4a8 SEPG
2.5 Garantia de Qualidade - 8 8 - SEPG
2.6 Aquisição 8(*) 8(*) SEPG
2.7 Medição - 8 8 - SEPG
2.8 Gerência de Configuração - 8 8 - SEPG
2.9 Engenharia de Software - - - 8 SEPG
2.10 Verificação e Validação - - - 8 SEPG
2.11 Processos Organiz. de Gestão - - - 8 SEPG
2.12 Workshop Técnico 8 8 8 8 SEPG
3 CONSULTORIAS
3.1 Consultoria Executiva 64 48 100 100 SEPG
4 ANÁLISE CRÍTICA
4.1 Levantamento e Análise de dados 4 4 4 4 Alta Direção/ SEPG
5 DIAGNÓSTICO PRE-ASSESSMENT
5.1 Levantamento do Andamento do Proj. 8 8 16 16 Alta Direção/ SEPG/
5.2 Apresentação dos Resultados 4 4 4 4 Equipe SW
6 AVALIAÇÃO
6.1 Avaliação Inicial 8 16 16 24 SEPG

Pós
Graduação
em
Engenharia
e

Qualidade
de
SoSware
com
o

modelo
MPS.
PUC-‐MG/FUMSOFT/
SOFTEX

(1ª
Edição
no
Brasil)

http://tinyurl.com/6cl3ouq

PG
Pós-‐Graduação
MPS.BR

BH

Potenciais
edições
do
PG-‐MPS.BR/2012

1ª
EDIÇÃO-‐
BH-‐
SETEMBRO/2011-‐
COORDENAÇÃO
NACIONAL

PG MODELO
DO
CURSO
DE
PG-‐MPS.BR

SOFTEX

CONVÊNIO
CONVÊNIO

CONVÊNIO

UNIVERSI
AGENTE

DADE

29

PLANO
DO
CURSO
DE
PG-‐MPS.BR

PG Curso
de
Pós-‐graduação
Latu-‐Sensu
-‐
ENGENHARIA
E
QUALIDADE
DE
SOFTWARE
COM
O

MODELO
MPS

Duraçã
Planejamento
-‐
Modelo
de
Negócios
o:
meses

11

Planejamento
Professores_PG-‐MPS_v09
Início:

Fevereiro/
2011

Carga
432

Tempo

Responsável
pela
Professor

Código
Cursos
Processos
OBS
sugerid Titulação

ementa
responsável

o

CESW
Conceitos
de
Engenharia
de
Geral
1s
20
Ana
Liddy

Humberto

SoFware
Magalhães
Torres(PUC)
Dsc

ERE
Engenharia
de
Requisitos
GRE
e
DRE
1s
20
Carlos
Barbieri

Carlos

Msc,

Barbieri

implementado
r
e
avaliador

líder

MPS.BR

GPR
Gerência
de
Projetos
e
Por•ólios
GPR
e
GPR-‐II
1s
28
Sheila
Reinehr
Andriele
Msc,

e
GPP
Ribeiro
implementado
r
e
avaliador

líder
MPS.BR

GCO
Gerência
de
Conﬁguração
GCO
1s
20
Leonardo
Murta

Marcelo
Msc,Dsc,Imple
Werneck
e

mentadores

Carlos
CMMI
e

Pietrobom-‐ MPS.BR

PUC

GQA
GaranOa
da
Qualidade
GQA
1s
20
Ana
Liddy
Cesar
Ávila
Msc,Implemen
Magalhães
tador
MPS.BR

e
CMMI

MED
Medições

MED
1s
20
CrisOna
Filipak
Ana
Liddy
Dsc,Implemen
Magalhães
tadora
e

Avaliadora

líder
MPS.BR

CEPC
Controle
EstassOco
de
Processo
Nível
B
SoFware 28
Gleison
Souza
Ana
Liddy

-‐sala
aula
Magalhães

Dsc

PLANO
DO
CURSO
DE
PG-‐MPS.BR

PG
Curso
de
Pós-‐graduação
Latu-‐Sensu
-‐
ENGENHARIA
E
QUALIDADE
DE
SOFTWARE
COM
O

MODELO
MPS

Planejamento
-‐
Modelo
de
Negócios
Duração:
meses

11

Planejamento
Início:

Fevereiro/
2011

Carga

432

Tempo
Responsável
pela
Professor

Código
Cursos
Processos
OBS
Titulação

sugerido
ementa
responsável

GRH
Gerência
de
Recursos
Humanos
e
de
GRH
+KM
1s
20
Mariano
Montoni
Rodrigo

Conhecimentos

Baroni(PUC)
Dsc

GDE
Gerência
de
Decisões
GDE
1s/2s
20
CrhisOan
Souza
Crhislan
Curso
de

Gamaliel
Especialização

e
experiência

implementaçã
o
N3-‐CMMI
e

C-‐MPS.BR

VER/
Veriﬁcação
e
Validação
de
SoFware-‐I
VER
e
VAL
28
Marcus
Juliano
Msc,especializ
VAL
Kalinowsky,Tayana
Santos/
ados
em

Conte,Juliano Base2
Testes,
em

+Robert
Pasteur
fase
de

Oyoni(PUC)
preparação

para

implementado
res

CISW
Construção
e
Integração
de
SW
PCP
e
ITP
laborat 20
Leonardo
Araujo/
Walter
dos

Msc-‐Prof.

(arquitetura)
ório
Isabella
Fonseca
Santos
Filho

UFMG

ERU
Engenharia
de
ReuOlização
GRU
e
DRU

20
Claúdia
Werner
Rogério
Curso
de

Baldini(PUC)
especialização

e
experiência

implementaçã
o
C-‐MPS.BR

PG PLANO
DO
CURSO
DE
PG-‐MPS.BR

Curso
de
Pós-‐graduação
Latu-‐Sensu
-‐
ENGENHARIA
E
QUALIDADE
DE
SOFTWARE
COM
O

MODELO
MPS

Duraçã

Planejamento
-‐
Modelo
de
Negócios
o:
meses

11

Planejamento
Início:

Fevereiro/
2011

Carga
432

Tempo

Responsável
pela
Professor

Código
Cursos
Processos
OBS
sugerid Titulação

ementa
responsável

o

AQU
Aquisições
AQU

20
Rosângela
Fabiana
Msc,Implemen
Mendonça
Bigão
tadora
e

avaliadora

adjunta

MPS.BR,

especialista

em
AQU

ADS
Abordagem
para
Desenvolvimento
OO,UP,Scru

24
Isabela
Fonseca
e
Isabella
Curso
de

de
SoFware
m,XP
Leonardo
Araujo
Fonseca
e
especialização

Dhanyel
e
experiência

Nunes
implementaçã
o
C/F-‐MPS.BR

MTC
Metodologia
de
Trabalho
Ciensﬁco
Geral-‐
20
Oswaldo
Correa
George
Jamil
Msc,Implemen
MCiensﬁca
tadora
MPS.BR

MPS
Melhoria
de
Processos
Melhoria
do

20
CrisOna
Cerdeiral
e
Laudecy

Curso
de

3
e
do
5
Reinaldo
Cabral
Alves
Especialização

e
responsável

por

implantação

em
CMMI
N5

PG PLANO
DO
CURSO
DE
PG-‐MPS.BR

Curso
de
Pós-‐graduação
Latu-‐Sensu
-‐
ENGENHARIA
E
QUALIDADE
DE
SOFTWARE
COM

O
MODELO
MPS

Planejamento
-‐
Modelo
de
Negócios
Duração:
meses

11

Planejamento
Início:
Fevereiro/
2011

Carga
432

Professor

Tempo
Responsável

Código
Cursos
Processos
OBS
responsáve Titulação

sugerido
pela
ementa

l

GQPR
Gerência
QuanOtaOva
de
Nível
B

24
Ana
Regina

Laudecy
Curso
de

Projetos
+MED
Rocha
e
Gleison
Alves
Especializaçã
Souza
o
e

responsável

por

implantação

em
CMMI
N5

EDRE
Estruturas
de
Dados
para
Estruturas
laborató 20
Carlos
Barbieri
Carlos
Msc,

Repositórios
de
rio
Barbieri
implementad
repositório
or
e
avaliador

(BI,BD)
em
líder

MPS.BR

Eng
de
SW

PAL
Seminários:
(ex.:
Experiências
nas
Palestras
(4

16
diversos
Vários

Empresas)
x
4)

CARGA
HORÁRIA
TOTAL
432

5 A Em Otimização
4 B Gerenciado Quantitativamente

C Definido
3
D Largamente Definido

E Parcialmente Definido
2
F Gerenciado

• PROGRAMA DE MELHORIA
DE PROCESSO DE SW-BRASILEIRO G
• INICIATIVA SOFTEX/ APOIO BID Parcialmente Gerenciado
• BRASIL->CONE SUL-MÉXICO
• > 200 CERTIFICAÇÕES
• FUMSOFT- CCOMP.MG-II-IA-IOGE

GRE-‐Gerência
de
Requisitos

¨  Entendimento
dos
Requisitos

¤  Reqtos
Negócios-‐Reqtos
de
Cliente-‐
Reqtos
Funcionais
e
Não
Funcionais

¨  CompromeOmento
das
partes

¤  Entendi
o
que
você
me
pediu
!

¤  Você
entendeu
o
que
eu
propus
como
solução?

¨  Fornecedores
de
requisitos

¤  Com
quem
dialogamos
formalmente
a
respeito
de
Reqtos

¨  Rastreabilidade
de
requisitos

¤  Se
eu
mexer
um
CSU,
onde
mais
terei
que
mexer(Dclasses,DaOvidades,Dsequência,

Modelo
de
Arquitetura,
Plano
de
Testes,
Código(Classe,
Método)

¨  Alteração
de
requisitos

¤  O
que
quase
nunca
acontece!

GPR-‐Gerência
de
Projetos

¨  Escopo
(Limite,
Recorte
do
que
será
feito)

¨  Planejamentos
das
Tarefas
e
produtos
de
trabalhos
(
O
quê,Como,Quando)

¨  Ciclo
de
vida
do
projeto

¨  Esforço
e
custo
para
as
tarefas
e
produtos
de
trabalho,
baseado
em
dados
históricos
(Quanto
e

Quanto
custa)

¨  Orçamento
e
Cronograma
(O
Quanto
e
o
Quando
mais
detalhado).
Tempo
é
dinheiro

¨  Riscos
(possíveis
problemas,
impedimentos,
o
que
fazer?)

¨  Recursos
humanos
(Recurso
+
importante
em
qualquer
projeto)

¨  Recursos
outros(hdw,sw,etc)

¨  Recursos
de
dados

¨  Plano
de
projeto
integrando
outros
planos

¨  Viabilidade
(Ainda
conOnua
válido,
devemos
prosseguir?)

¨  Gerenciamento
do
Projeto(status
report,reuniões
de
análise
críOca)

¨  Gerenciar
o
envolvimento
das
partes

¨  Revisões
em
marcos

¨  Registros
dos
problemas
e
acompanhamento

¨  Ações
para
correção

GQA-‐Garanla
da
Qualidade

¨  Auditoria
de
produtos
ao
processo,
feitas
em
pontos
certos(antes
da
entrega

ao
cliente)

¤  Verificando

se
os
ingredientes
da
RECEITA

foram
os
especificados

¨  Auditoria
de
processos
às
descrições
(de
processos)

¤  Verificando
se
a
RECEITA
foi
seguida
de
acordo

¨  Problemas
e
NC
são
idenOficados
,
registrados
e
comunicados

¤  Registrar,
acompanhar,
EDUCAR

¨  Ações
correOvas
acompanhadas
até
o
seu
término.
Pode
escalar

GPP-‐Gerência
de
Porzólio

¨  As
oportunidades
de
negócios,
necessidades
e
invesOmentos
são
idenOficados,

qualificados,
priorizados
e
selecionados

¤  Oportunidade
deve
virar
projeto?
Vale
a
pena,
do
ponto
de
vista:
$$,estratégia,
tecnologia,
recursos,
etc

¨  Recursos
e
orçamentos
para
cada
projeto
são
idenOficados
e
alocados

¤  $$
e
outros
que
serão
alocados
no
projeto(visto
da
óOca
do
conjunto
de
projetos)

¨  Responsabilidades
e
autoridade
pelo
gerenciamento
dos
projetos
são

estabelecidas

¤  Quem
vai
tocar
o
projeto?
Com
que
autoridade?

¨ 
Conflitos
sobre
recursos
entre
projetos
são
tratados
e
resolvidos

¤  Falta
recurso,
conflito
de
disponibilidade,
prioridades
revistas,
mudança
de
rumos

¨  Projetos
que
atendem
aos
acordos
e
requisitos
que
levaram
à
sua
aprovação
são

manOdos
e
outros
que
não
atendem
são
redirecionados
ou
cancelados

¤  Decisão
recorrente
sobre
a
viabilidade
dos
projetos

AQU-‐Aquisição

¨  Necessidades
de
aquisição,
metas,critérios
de
aceitação,
Opos
e
estratégias
de
compra

¤  O
que
preciso
comprar,
como
vou
comprar,como
devo
aceitar
?

¨  Critérios
para
seleção
de
Fornecedores

¤  De
quem
eu
vou
comprar?

Conjunto
de
Fornecedores

¨  Seleção
do(s)
Fornecedor(es)

¤  Vou
comprar
desse
aqui!

¨  Acordo
formal
estabelecido

¤  A
compra
será
regulada
por
esse
contrato,
convênio,
acordo
formal

¨  Produto
que
saOsfaça
é
adquirido

¤  Instanciação
da
Compra,
Aquisição.
Comprei

¨  Processos
críOcos
do
Fornecedor
são
idenOﬁcados
e
monitorados,
gerando
ações
correOvas,
se

necessário

¤  Fico
de
olho
nos
processos
críOcos
do
FN.
Como
ele
faz?,
usa
métodos,
processos,
aplica
qualidade

¨  Aquisição
é
monitorada(custo,cronograma,
qualidade,etc)

¤  O
processo
da
aquisição(que
pode
ser
longo)
é
acompanhado,
monitorado
no
(tempo,
custo,
etc)

¨  O
Produto
é
entregue
e
avaliado
em
relação
ao
acordado

¤  Está
tudo
OK,
conforme
previsto
no
contrato,
Teste
de
Aceitação,
Homologação

¨  As
condições
para
a

internalização
do
produto
estão
todas
OK?

GCO-‐Gerência
de
Configurações

¨  Sistema
de
GCO
é
estabelecido
e
manOdo(issue,fonte,
executável)

¤  SVN,ManOs,Libs
de
executáveis
Jars,etc

¨  Itens
de
Configuração
são
definidos

¤  O
que
será
controlado
como
IC?:
Tudo(esquece),
Documentos
e
Planos(Alguns
mais
estratégicos),
Diagramas,
projetos(depende),

Entregáveis
externos

(lógico:
Código,
documentação,
etc)

¨  Itens
de
Configuração
sujeitos
a
controle
formal
são
colocados
sob
Base
Line

¤  Controle
formal
para
mexer
naquilo:
Alguém
tem
que
pedir
,
sujeitar
o
pedido
à
uma
análise
e
mexer
depois
de
aprovado

¨  Situação
dos
IC
e
das
BaseLines
é
registrada
e
disponibilizada

¤  Controlo
todas
as
fotografias
dos
itens
ao
longo
da
vida
da

solução

¨  Modificações
de
IC
são
controladas

¤  Controle
formal
para
mexer
naquilo:
Alguém
tem
que
pedir
,
sujeitar
o
pedido
à
uma
análise
e
mexer
depois
de
aprovado.
Alguém

analisa
impactos,
etc

¨  Armazenamento,
manuseio
e
a
liberação
dos
IC
e
BaseLines
são
controlados

¤  Os
IC
e
as
Blines
são
controladas
por
alguém:analista
de
configuração
do
projeto

¨  Auditoria
de
Configuração(Física-‐completude
e
Funcional-‐corretude/correção)

¤  Alguém
audita
a
fotografia
do
ponto
de
vista
xsico(completude)
e
funcional(correção)
–
½
que
estende
o
papel
de
QA/QA

MED-‐Medições

¨  ObjeOvos
estratégicos
para
balizar
as
métricas

¤  Somente
medir
por
necessidade
explícita

¨  Conjunto
de
medidas,
associadas
aos
objeOvos
é
definido,priorizado,
documentado,
revisado
e

atualizado

¤  Medidas
definidas
com
um
conjunto
de
atributos,
priorizado,
revisado(as
estratégias
mudam)
e
atualizado

¨  Procedimentos
para
coleta
e
armazenamento

¤  Como
e
de
onde
busco
as
medidas
elementares,
para
compor
a
métrica

IMC=peso/altura**2

¨  Procedimentos
para

análise

¤  Avaliar
os
idenOficadores.
O
IMC,
por
exemplo
tem
faixas
que
sugerem
ginásOca,
dietas,
etc

¨  Os
dados
requeridos
são
coletados
e
analisados

¤  Instanciação
do
processo
de
coleta
e
análise

¨  Os
dados
e
os
resultados
das
análises
são
armazenados

¤  Formalizar
estruturas
(planilhas,
repositórios
mais
evoluídos),
para
facilitar
análises(BD
Relacional,
ou
Um
DW
de
medidas)

¨  Os
dados
e
os
resultados
das
análises
são
comunicados
aos
interessados
e
usados
para
apoiar

tomada
de
decisão

¤  Medidas
,
métricas
e
indicadores
devem
ser
divulgados,
consumidos,
trabalhados
e
apoiando
decisões

RAPS

Engenharia de Requisitos
MPS.BR
Resultados de
Atributos de Processo

Processo
de
Gerência

de
Requisitos
-‐

RAPs

¤  AP
1.1
–
O
PROCESSO
É
EXECUTADO

n  RAP1-‐
O
PROCESSO
ATINGE
OS
RESULTADOS
DEFINIDOS

¤  AP
2.1
–O
PROCESSO
É
GERENCIADO

n  RAP2-‐POLÍTICAS

n  RAP3-‐EXECUÇÃO
PLANEJADA

n  RAP4-‐EXECUÇÃO
MONITORADA(GS.
MED)

n  RAP5-‐RECURSOS
DE
INFORMAÇÕES
E
PESSOAS

n  RAP6-‐RESPONSABILIDADES
E
AUTORIDADES

P/EXECUÇÃO
(*)NOVA

n  RAP7-‐PESSOAS
E
COMPETÊNCIAS

n  RAP8-‐COMUNICAÇÃO

n  RAP9-‐RESULTADOS

DO
PROCESSO
REVISTOS
C/
GS

n  RAP10-‐(G)
-‐PROCESSO
PLANEJADO
PARA
O
PROJETO

É
EXECUTADO
(*)
NOVA-‐PLANEJA
NA
RAP3
E

EXECUTA
NA
RAP
10

¤  AP
2.2-‐
OS

PRODUTOS
DE
TRABALHOS
DO
PROJETO
SÃO
GERENCIADOS

n  RAP
10-‐(F)-‐A
ADERÊNCIA
AOS
PROCESSOS
É
AVALIADA(QA
DO
PROCESSO)

n  RAP
11-‐REQUISITOS

DOS
P.TRABALHOS(GCO)
-‐
o
que
devem
ter?

n  RAP
12-‐OS
REQUISITOS
PARA
DOCUMENTAÇÃO
E
CONTROLE
DOS
PT(GCO)
(como
documentar
e

controlar?)

n  RAP
13-‐OS
PRODUTOS
DE
TRABALHO
SÃO
DOCUMENTADOS
E
CONTROLADOS
(GCO)

n  RAP
14-‐A
ADERÊNCIA
DOS
PRODUTOS
(QA
DO
PRODUTO)

Processo
de
Gerência

de
Requisitos
-‐

RAPs
AP 2.1

n  RAP2
–
Existe
uma
polílca
organizacional
estabelecida
e
manlda
para
o

processo

n  deﬁnição
das
expectaOvas
organizacionais
para
a
execução
do
processo,

disponibilizada
e
divulgada
a
todos
os
interessados
em
sua
execução.

n  RAP3
–
A
execução
do
processo
é
planejada

n  realização
de
um
plano
para
execução
do
processo
que
inclui
recursos,

responsabilidades,
tempo,
aOvidades
de
controle
e
monitoramente
da
execução
do

processo,
e
a
própria
descrição
do
processo.

n  o
plano
deve
ser
revisto
sempre
que
necessário
(ex.
quando
forem
aprovadas

mudanças
signiﬁcaOvas
no
projeto)

n  RAP4
(G)
–

A
execução
do
processo
é
monitorada
e
ajustes
são
realizados

n  Acompanhamento
juntamente
com
a
monitoração
do
projeto

n  RAP4
(F)
–
Medidas
são
planejadas
e
coletadas
para
monitoração
da
execução

do
processo

n  aplicação
do
processo
de
Medição
para
o
processo
(e
não
apenas
para
os
projetos)
–

devem
haver
medidas,
alinhadas
aos
objeOvos
da
organização,

que
são
usadas
para

apoiar
a
gestão
do
processo

Processo
de
Gerência

de
Requisitos
-‐

RAPs

n  RAP5
–
informações
e
os
recursos
necessários
p/

execução
do
processo
são
idenlficados
e
disponibilizados

n  assegurar
que
os
recursos
para
executar
o
processo
(ex.
financeiros,

condições
xsicas,
pessoal,
ferramentas,
processos,
modelos
de

documentos)
são
idenOficados
previamente
e
disponibilizados
quando

forem
necessários

n  RAP6
–
As
responsabilidades
e
autoridades
para
executar

o
processo
são

definidas,
atribuídas
e
comunicadas

n  Os
responsáveis
definidos
e
as
responsabilidades
bem
compreendidas.

Processo
de
Gerência

de
Requisitos
-‐

RAPs

n  RAP7
–
As
pessoas
que
executam
o
processo
são

competentes
em
termos
de
formação,
treinamento
e

experiência

n  assegurar
que
as
pessoas
tenham
habilidades
e
conhecimentos,
nos

devidos
níveis
de
envolvimento
como
processo,
para
executá-‐lo
ou

apoiá-‐lo.

n  registrar
status
atual
da
equipe,
as
competências
necessárias
para

cada
papel
envolvido
no
processo
e
planejar
treinamentos
necessários.

Processo
de
Gerência

de
Requisitos
-‐

RAPs

n  RAP8
–
A
comunicação
entre
as
partes
interessadas
no

processo
é
gerenciada
de
forma
a
garanlr
seu

envolvimento
no
projeto

n  idenOﬁcar
as
partes
interessadas
no
processo
(pessoas
envolvidas
no

planejamento,
coordenação,
revisão,
deﬁnições),
planejar
e
manter

seu
envolvimento

n  gerenciar
a
interface
entre
as
partes
interessadas
de
forma
a
assegurar

a
comunicação

n  RAP9
–
(F)-‐Os
resultados
do
processo
são
revistos
com
a

GS
para
fornecer
visibilidade
sobre
a
situação

n  fornecer
visibilidade
com
relação
ao
estado
da
execução
dos
processos

(adequação
ao
projeto,
operação
com
recursos
apropriados,
alcance

dos
resultados
esperados)

n  ex.
de
monitoração:
revisões
periódicas
ou
moOvadas
por
algum

evento,
junto
à
gerência
de
alto
nível,
do
estado,
aOvidades
realizadas,

resultados
alcançados
pelo
processo/
relatório
do
status
e
problemas/

acompanhamento
das
correções
até
o
fechamento.

Processo
de
Gerência

de
Requisitos
-‐

RAPs

n  RAP10
–
O
processo
planejado
para
o
projeto
é
executado

n  GaranOr
que
o
processo
planejado
seja
conduzido
como
foi
planejado

na
RAP3.
Deve-‐se
ter
registros
de
execução
das
aOvidades
do

processo,
com
base
no
seu
planejamento

Processo
de
Gerência

de
Requisitos
-‐

RAPs

¨  AP2.2
–
Os
produtos
de
trabalho
do
processo
são

gerenciados

¤  medida
do
quanto
os
produtos
de
trabalho
produzidos

pelo
processo
são
gerenciados
apropriadamente

n  RAP10
(F)
–
A
aderência
dos
processos
executados
às

descrições
de
processo,
padrões
e
procedimentos
é
avaliada

objelvamente
e
são
tratadas
as
não-‐conformidades

n  garanOr
uma
avaliação
objeOva
de
que
o
processo
aplicado
ao
projeto
foi

implementado
como
planejado
e
segue
as
descrições
de
processo,
padrões

e
procedimentos
aplicáveis

n  executada
por
grupo
isento
(ex.
área
de
GaranOa
da
Qualidade),
uOlizando

critérios
deﬁnidos
como
checklists

Processo
de
Gerência

de
Requisitos
-‐

RAPs

n  RAP
11-‐
Os
requisitos
dos
produtos
de
trabalho

produzidos
pelo
processo
são
gerenciados

apropriadamente

n  GaranOr
que
os
PT(produtos
de
trabalho)
tenham
seus
requisitos

especificados:
templates
dos
documentos

n  RAP12
–
Os
requisitos
para
a
documentação
e
controle

dos
produtos
de
trabalhos
são
estabelecidos

n  Assegurar
que
foram
definidas
a
descrição
e
o
nível
apropriado
de

controle
para
os
produtos
de
trabalhos
do
processo.
Incluem

idenOficação(de
requisitos)
,
idenOficação
de
mudanças,
e
revisão
de

estado,
de
aprovação
e
reaprovação.

n  Diferentes
níveis
de
controle
são:
armazenamento
com

versionamento,controle
de
baselines,
controle
de
mudanças

acontecidas
no
PT,etc.

Processo
de
Gerência

de
Requisitos
-‐

RAPs

n  RAP13
–
Os

produtos
de
trabalho
são

colocados
em
níveis
apropriados
de

controle.

n  Assegurar
que
os
controles
deﬁnidos

anteriormente
são
aplicados

Processo
de
Gerência

de
Requisitos
-‐

RAPs

n  RAP14
–
Os
produtos
de
trabalho
são
avaliados

objelvamente
com
relação
aos
padrões,
procedimentos
e

requisitos
aplicáveis
e
são
tratadas
as
não-‐conformidades

n  os
produtos
de
trabalho
gerados
pela
execução
do
processo
devem
ser

previamente
selecionados
e
submeOdos
à
garanOa
da
qualidade,

uOlizando
critérios
previamente
estabelecidos,
por
pessoa
isenta,
por

meio,
p.
ex.,
de
auditoria

n  não-‐conformidades
e
melhorias
dos
produtos
de
trabalho
dos

processos
devem
ser
registradas
e
encaminhadas
aos
responsáveis
aos

responsáveis
para
seu
tratamento
e
gerenciadas
até
sua
conclusão.

MPS.BR
e
Metodologias

Ágeis
–
Projetos
de
TI

SOFTWARE

O
problema
que
ainda
enfrentamos…

Por
que
projetos
de
TI
conOnuam

fracassando
em
preços,
prazos
e

resultados?

A
Gestão
Clássica
de
Projetos
de

Tecnologia
da
Informação
nunca
foi

trivial!
E
ainda
enfrentamos
outras

variáveis
que
constantemente
se

modiﬁcam.

Novos
Desaﬁos
-‐
Web

Novos
Clientes

e
Mercados

Economia

em
Rede

Forncedores

Parceiros

Cliente

Corporação

Estendida

Funcionários

Automação

CorporaOva

Cliente/Servidor
Intranet/Extranet
Internet

Fonte:
Apresentação
Powerlogic
–
www.powerlogic.com.br

MPS.BR
e
Metodologias

Ágeis
–

Discussão
Principais

Problemas

SOFTWARE

Principais
problemas

Segundo
PMI
Brasil,
os
problemas
mais
freqüentes

em
gerenciamento
de
projetos
levantados
são:

¨  Não
cumprimento
de
prazos
(72%)

¨  Problemas
de
comunicação
(71%)

¨  Mudança
de
escopo
(69%)

¨  EsOmaOva
errada
de
prazo
(66%)

Fonte:
Benchmarking
em
Gerenciamento
de
Projetos,
2006,
chapters
do

PMI
no
Brasil

Principais
problemas
-‐
Comunicação

Principais
problemas
-‐
Comunicação

Fonte:
Alistar
Cockburn
-‐
Agile
SoFware
Development

Principais
problemas
-‐
Comunicação

Todo
Ome
de
projeto
deve
quesOonar
sobre
como
reduzir
o

custo
de
energia
total
para
detectar
ou
transferir
idéias

necessárias.

Alistair
Cockburn

Fonte:
Alistar
Cockburn
-‐
Agile
SoFware
Development

MPS.BR
e
Metodologias

Ágeis
–

Gerenciamento
Ágil

SOFTWARE

Agile?
Responder
à
mudança

¨  Em
desenvolvimento
de
soFware,
ser
ágil
signiﬁca
a

habilidade
em
responder
rápido
às
mudanças.

¨  Que
Opo
de
mudanças?

¤  De
Requisitos

¤  Prioridades

¤  Tecnologias
e
Ferramentas

¤  Pessoas

¤  Complexidade
do
desenvolvimento
de
soFware

¨  UOliza
conceitos
como:

¤  IteraOvidade,
Técnicas
incrementais,
Times
mulO-‐
funcionais,
Auto-‐gerenciamento
e
Auto-‐organização.

Gerenciamento
em
projetos
ágeis

•  Tem
mais
foco
em
•  Encoraja
a
mudança

"planejamento"
do
que

em
"plano".
Constante

planejamento

•  Resulta
em
planos
que
•  É
distribuído
ao
longo
do

são
facilmente
projeto

modiﬁcáveis

Mike
Cohn
–
Agile
EsVmaVng
&
Planning

Gerenciamento
em
projetos
ágeis

• São
iteraOvos
e
• Possuem
aOvidades

incrementais
paralelas
e

concorrentes

• Escopo
aberto
• Ênfase
em

colaboração

Mike
Cohn
–
Agile
EsVmaVng
&
Planning

Gerenciamento
em
projetos
ágeis

Gerenciamento
em
projetos
ágeis

¨  FOCO
no
OUTPUT
e
não
no
INPUT

¨  Planejamento
prediOvos:

¤  Criação
de
um
plano
com
aOvidades
deﬁnidas

¤  O
gerenciamento/acompanhamento
de
aOvidades

conforme
o
plano

ágil:

¤  Criação
de
entregas
com
conjunto
de
itens
priorizados

¤  Gerencimanto
via
feedback
e
constante
adaptação

Teoria
das
Restrições
-‐
TOC

Uma
das
grandes
contribuições
da
TOC
é
o
seu
processo
de
oOmização

consnua.
Esse
processo
de
oOmização
consnua
contém
5
etapas:

1.
IdenOﬁcar
a(s)
restrição(ões)
do
sistema.

2.
Decidir
como
explorar
a(s)
restrição(ões)
do
sistema.

3.
Subordinar
tudo
o
mais
à
decisão
acima.

4.
Elevar
a(s)
restrição(ões)
do
sistema.

5.
Se
num
passo
anterior
uma
restrição
for
quebrada,
volte
ao
passo
1.

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
signiﬁcaOvamente
no
curto
prazo

Eliyahu
GoldraŒ
–
A
Meta

Gerenciando
projetos
ágeis
-‐
TOC

¨  Quatro
variáveis
de
controle
requerem
cuidado
em

qualquer
projeto:

¤  Recursos

n  Pessoas

n  Infra-‐estrutura

¤  Tempo

¤  Escopo

¤  Qualidade

¨  Não
é
“inteligente”estabelecer
todos
estas
variáveis

como
prioritárias
em
um
projeto
simultaneamente.

TOC
em
SoSware
-‐
Restrições

Escopo

(Inventário)

Escalona-‐
Orçamento

mento

Pessoas
Recursos

Agile
Management
for
SoFware
Enginnering

David
J.
Anderson

TOC
em
SoSware
-‐
Soluções

Enﬁleiramento
priorizado:

"deve
ter",

Margem
no
Prazo

"deveria
ter",

Certeza
-‐>
Margem

"seria
bom
ter"
100%

-‐>
15%

Escopo
90%

-‐>
25-‐30%

(Inventário)
80%

-‐>
50%

50-‐70%
-‐>
100%

<50%

-‐>
200%

Reserva
de
Dinheiro

Escalona-‐
Orçamento

mento

Reservas
de

Reserva
de
equipamento,
lugares
de

Produlvidade

trabalho,
sistemas
de

(Ex.:
5,5
horas/dia)
backup,

suporte
a
infra-‐
Reserva
de
Pessoas
estrutura

Aptas*

Pessoas
Recursos

(Brook's
Law)

Agile Management for Software Enginnering
David J. Anderson

TOC
Comercial
-‐
Realíslco

Projeto
Urgente
Projeto
CríOco

Escopo
Escopo

Preço
Prazo
Preço
Prazo

Sem
Orçamento

Escopo

Preço
Prazo

David J. Anderson

TOC
Comercial
-‐
Arriscados

Urgente
e
CríOco
CríOco
Sem
Orçamento

Escopo
Escopo

Preço
Prazo
Preço
Prazo

"Marcha
para
a
Morte"

Escopo

Preço
Prazo

David J. Anderson

TOC
-‐
Variável
Recursos

¨  Recursos
são
geralmente
a
variável
menos

efeOva
para
se
ajustar:

¤  The
Mythical
Man
Month
by
Frederick
Brooks,
1975.

n  “Quando
um
projeto
está
atrasado,
adicionar
pessoas
ao
projeto
servirá
apenas
para

atrasá-‐lo
ainda
mais.

n  Devemos
considerar
o
tempo
que
perdemos
em
gestão
e
comunicação
quando
temos

pessoas
demais
trabalhando
em
um
projeto.

n  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.”

¨  Ênfase
nas
pessoas!

¨  Treinamentos,
disseminação
de

conhecimento,
boas
condições
de
trabalho

TOC - Variável Recursos - Scrum

¨  Desenvolvimento
heróico
enfaOza
indivíduos.

¤  As
aOvidades
são
designadas
individualmente

¤  Projeto
ﬁca
altamente
dependente
da
performance
dos

indivíduos
envolvidos

¨  Desenvolvimento
colaboraOvo
enfaOza
o
Ome
-‐>

Scrum

¤  Um
Ome
alto-‐organizado
deﬁne
as
aOvidades
para
se

aOngir
as
metas
estabelecidas

¤  O
Ome
possui
habilidades
diversas
(generalizing
specialist

–
ScoŒ
Ambler)


Modo
Tradicional

-‐ 
Comunicação
ﬁca
um
pouco
deteriorada

-‐ 
Pouca
visão
do
todo

-‐ 
Pouca
interação,
compromeOmento
baixo,
etc...


Generalista/especialista
–
Agile
–
ScoŒ
Ambler

-‐ 
Melhoria
na
comunicação
e
colaboração

-‐ 
Melhoria
na
ﬂexibilidade

-‐ 
Visão
holísOca
do
projeto

-‐ 
MulOdisciplinaridade

-‐ 
Menor
risco

TOC - Variável Escopo

¨  Pode
ser
a
variável
mais
efeOva
em
se

ajustar

¤ 
Entregas
parciais
podem
gerar

retornos
imediatos
–
PRINCÍPIO
AGILE!

¤ “É
preferível
se
aOngir
uma
data
com

um
escopo
parcial
implementado
do

que
com
o
escopo
completo

parcialmente
terminado”

TOC - Processos ágeis

¨  Com
relação
à
recursos:

¤  Times
estáveis
e
trabalhando
em
equipe

¨  À
Tempo:

¤  Ciclos
de
desenvolvimento
tempo-‐fechado
(Ome-‐
boxed)

¨  À
Escopo:

¤  Ajustes
de
escopo
feitos
através
de
feedback
e

planejamento
constante

Gerenciamento
ágil
–
mudanças

Scrum
-‐
Business
Value

¨  Itens
que
se
concentram
no
quadrante
superior

direito
são
os
que
devem
ser
priorizados
e
são
os
que

mais
representam
a
maximização
do
resultado.

¤  Exemplo
de
fórmula
que
enfaOza
a
visão
do
PO
e
Scrum
Team:

n  Priorização
ﬁnal
da
pilha
=
BV/
Tamanho
do
requisito

Fonte:
hŒp://www.powerlogic.com.br

Priorização
do
Product
Backlog

Fonte:
hŒp://www.soFhouse.se/

Exemplo
de
Priorização
do
Backlog

Plano
Ágil

Gaste

60%
do
tempo
Sprint
1

20%
elicitando
os
20%
de
48
SP
-‐
400
BV

itens
no
"topo
da

pilha"

Sprint
2

52
SP
-‐
250
BV

20%

Gaste
outros
30%

Sprint
3

esOmando
os
20%
próximos

55
SP
-‐
150
BV

Sprint
4

60%

40
SP
-‐
100
BV

Gaste
10%
para
o
restante

Sprint
5

50
SP
-‐
100
BV

Plano
de
Projeto
(Release
Plan):
Total
de
245
SP
e
1.000
BV

Exemplo
de
Priorização
do
Backlog

Gerenciamento
ágil
-‐
resumo

é
feito
conOnuamente
durante
todo
o

projeto,
e
baseado
em
um
goal
(objeOvo),
onde
são

deﬁnidas
as
tarefas
necessárias
para
se
iniciar
o
mesmo.

¨  Bom
senso
é
indispensável
ao
gerenciamento
efeOvo
de

projetos

¨  O
Ome
conhece
o
objeOvo
ﬁnal,
todos
ajudam
a
manter

a
direção
certa.

¨  Não
se
tem
a
procura
por
um
culpado.
Todos
estão

imbuídos
na
busca
da
melhor
solução
para
a

organização,
seja
o
analista,
desenvolvedor,
gerente
de

projeto
ou
o
cliente.

MPS.BR
e
Metodologias
Ágeis
–

O
que
é
o
Scrum?

O
que
é
o
Scrum?

Em
Rugby,
Scrum
é
um
Ome
de
oito

integrantes
que
trabalham
em

conjunto
para
levar
a
bola
adiante

no
campo.
Ou
seja:
Omes

trabalhando
como
uma
unidade

altamente
integrada
com
cada

membro
desempenhando
um
papel

bem
deﬁnido
e
o
Ome
inteiro

focando
num
único
objeOvo.

Fonte:
news.bbc.co.uk/sport1/hi/rugby_union/7048733.stm

“Na
abordagem
em
forma
de
rugby
(jogo
britânico
parecido
com
o
futebol

americano),
o
processo
de
desenvolvimento
do
produto
surge
a
parOr
de
constante

interação,
como
que
de
mãos
dadas,
onde
um
grupo
extremamente
disciplinado

trabalha
junto
do
início
ao
ﬁm.
”

Nonaka
e
Takeuchi
-‐
The
New
New
Product
Development
Game

O
Manifesto
da
Agilidade

Os
Quatro
Valores

Nós
estamos
descobrindo
novas
maneiras
de
desenvolver
soSware
fazendo
e

ajudando
outros
a
fazê-‐lo.
Através
deste
trabalho
nós
valorizamos:

•  Indivíduos
e
interações
mais
que
processos
e
ferramentas

•  So]ware
funcionando
mais
que
documentação
compreensiva

•  Colaboração
do
cliente
mais
que
negociação
de
contrato

•  Responder
à
mudança
mais
que
seguir
um
plano

Isto
é,
muito
embora
valorizemos
os
itens
da
direita,
valorizamos
mais
os
da

esquerda!

1o Semestre de 2001.

O
MANIFESTO
DA
AGILIDADE:
OS
12

PRINCÍPIOS

Diretrizes
Gerais
Para
um

Projeto
de
Sucesso!

Princípio 1

A
mais
alta
prioridade
é
a

saOsfação
do
cliente
através
da

liberação
mais
rápida
e
consnua

de
soFware
de
valor!

Princípio 2

Receba
bem
as
mudanças
de

requerimentos,
mesmo
em

estágios
tardios
do

desenvolvimento.
Processos
ágeis

devem
admiOr
mudanças
que

trazem
vantagens
compeOOvas

para
o
cliente.

Princípio 3

Libere
soFware
com
a
frequência

de
um
par
de
semanas
até
um

par
de
meses,
com
preferência

para
a
escala
de
tempo
mais

curta.

Princípio 4

Mantenha
as
pessoas
dos
negócios

e
os
desenvolvedores

trabalhando
juntos
a
maior
parte

do
tempo
do
projeto.

Princípio 5

Construa
projetos
com
indivíduos

moOvados,
dê
a
eles
o
ambiente

e
suporte
que
precisam
e
conﬁe

neles
para
ter
o
trabalho

realizado.

Princípio 6

O
método
mais
eﬁciente
e
efeOvo

de
repassar
informação
entre

uma
equipe
de
desenvolvimento

é
através
de
conversação
cara-‐a-‐
cara.

Princípio 7

SoFware
funcionando
é
a

principal
medida
de
progresso.

Princípio 8

Processos
ágeis
promovem

desenvolvimento
sustentado.
Os

patrocinadores,
desenvolvedores

e
usuários
devem
ser
capazes
de

manter
conversação
pacíﬁca

indeﬁnidamente.

Princípio 9

A
atenção
consnua
para
a

excelência
técnica
e
um
bom

projeto
aprimora
a
agilidade.

Princípio 10

Simplicidade
–
a
arte
de
maximizar

a
quanOdade
de
trabalho
não

feito
–
é
essencial.

Princípio 11

As
melhores
arquiteturas,

requerimentos
e
projetos

emergem
de
equipes
auto-‐
organizadas.

Princípio 12

Em
intervalos
regulares,
as
equipes

devem
reﬂeOr
sobre
como
se

tornarem
mais
efeOvas,
e
então

reﬁnarem
e
ajustarem
seu

comportamento
de
acordo.

Scrum
–
Papéis
e
principais
responsabilidades

¨  Product
Owner
(representante
do
cliente)

¤  Gerenciar
a
visão
(goal)

¤  Gerenciar
o
ROI
–
Retorno
de
InvesOmento

¨  Scrum
Master

¤  GaranOr
o
andamento
do
projeto
de
acordo
com
o
processo

¤  Gerenciar
a
Release
e
Sprints

¤  Remover
impedimentos

¨  Scrum
Team

¤  GaranOr
o
desenvolvimento
da
iteração

¤  EsOmar
tamanho
das
aOvidades
e
se
comprometer
com
os

goals
estabelecidos.

Scrum
–
Ciclo
de
Vida

Fonte:
Apresentação
Powerlogic
–

Scrum
-‐
Reuniões

Scrum
-‐
Sprint
Goal

" O
Sprint
Goal
é
um
objeOvo
no
escopo
do
Sprint,
para

orientar
a
adaptação
do
Ome
e
promover
a
visão
holísOca

necessária
para
o
real
compromeOmento
da
equipe;

" É
um
parágrafo
estabelecido
pelo
Product
Owner
ao
ﬁnal

do
Sprint
Planning
1
e
acordado
entre
os
envolvidos;

" É
sempre
veriﬁcado
durante
a
reunião
de
Sprint
Review
e

confrontado
com
a
demonstração
das
funcionalidades

implementadas
durante
o
sprint
pelo
Scrum
Team.

Scrum
–
Artefatos
–
Product
Backlog

Scrum
–
Outros
Artefatos

" Impediment
Backlog:
pilha
de
impedimentos
que
atrapalham

o
progresso
do
Scrum
Team
em
seu
trabalho.
É
manOdo
pelo

Scrum
Master
que
deve
resolvê-‐los
em
24
horas.

" WWW
e
WCBI
–
RetrospecOve
MeeOng:
são
as
lições

aprendidas
levantadas
durante
a
reunião
de
retrospecOva
e

servem
de
acompanhamento
de
“aOtudes
posiOvas”
(WWW

–
What
went
well
-‐
que
devem
ser
reforçadas
sempre
e

processos
que
devem
ser
melhorados/resolvidos
(WCBI
–

What
could
be
improved).

" Sprint
BurnDown:
gráﬁco
que
demonstra
a
quanOdade
de

trabalho
restante
dentro
de
um
sprint.
É
atualizado

diariamente
pelo
Scrum
Team.

Sprint
Burndown

HH Restantes

Dias

Scrum
–
Outros
Artefatos

" Release
BurnDown:
gráﬁco
que
demonstra
a
quanOdade
de

trabalho
restante
dentro
de
uma
Release.
É
atualizado
ao

ﬁnal
de
cada
Sprint
pelo
Product
Owner/Scrum
Master
e

Scrum
Team.

" Agile
Radiator
ou
Kanban:
quadro
de
acompanhamento
de

aOvidades
Opicamente
dentro
de
um
sprint
–
com
aOvidades

não
iniciadas
(previstas),
aOvidades
em
andamento
e

aOvidades
concluídas.
É
atualizado
diariamente
durante
as

reuniões
de
Daily
Scrum.
É
neste
quadro
também
onde
os

impedimentos
devem
ser
anexados,
além
dos
itens
de
lições

aprendidas
como
WWW
e
WCBI.

Scrum
–
Agile
Radiator
x
Kanban

¨  Controle
visual
para
acompanhar
o
trabalho
à
medida
que
ele

flui
através
das
várias
etapas
do
fluxo
de
valor.

¨  O
Kanban,
ou
cartão
de
sinalização,
é
um
sinal
visual

produzido
indicando
que
novo
trabalho
pode
ser
iniciado
e

que
a
aOvidade
atual
não
coincide
com
o
limite
acordado.

Limita
as
AOvidades
em
andamento
(do
inglês
WIP)
para
cada

estágio.
Parte
de
uma
iniciaOva
Lean
(enxuta)
que
expõe

gargalos,
filas,
variabilidade
e
desperdício.

¨  A
abordagem
de
"parar
a
linha
de
produção"
para
superar
os

obstáculos
e
os
erros
encontrados,
também
parece
encorajar

níveis
mais
elevados
de
qualidade
e
uma
queda
rápida
de

retrabalho.

Release
Burndown

Fonte:
hŒp://www.mountaingoatsoFware.com/

Scrum
–
Agile
Radiator
–
Itens
de
maior
prioridade

Scrum
–
Agile
Radiator
–
Primeiras
alvidades

Scrum
–
Agile
Radiator
-‐
Acompanhamento

Scrum
–
Agile
Radiator
–
Atenção
às
prioridades

Scrum
–
Agile
Radiator
–
Exemplo

Fonte:
Apresentação
Powerlogic
–

Scrum
–
Agile
Radiator
-‐
Exemplo

Fonte:
Apresentação
Powerlogic
–

MPS.BR
e
Metodologias

ágeis

SOFTWARE

MPS.BR
e
Metodologias
Ágeis

A
combinação
entre
a
agilidade
conseguida
através
de
métodos
ágeis
e

a
maturidade
adquirida
por
meio
do
MPS.BR,
formam
uma
abordagem

interessante
na
busca
de
resultados
posiOvos
para
processos
de

informáOca.
Agilidade
como
sendo
a
habilidade
de
reagir
a
mudanças
e

se
manter
na
direção
planejada
inicialmente.

PráOcas
de
métodos
ágeis
como
SCRUM
e
XP
podem
ser
mapeadas
aos

processos
do
MPS.BR
levando
às
organizações
a
implementarem
as

aOvidades
necessárias
a
implantação
do
modelo
e
ainda
conOnuar
com

as
vantagens
e
leveza
dos
métodos
ágeis.

MPS.BR
diz
o
que
fazer,
mas
não
diz
como
fazer.
Metodologias
ágeis
são

um
conjunto
de
melhores
práOcas
que
contém
informações
especíﬁcas

de
como
fazer .

MPS.BR
e
Metodologias
Ágeis

Product
Scrum

Scrum
Team

Owner
Master

Agile
Radiator
-‐
BurnDown

GPR
Daily
Scrum

Impediment
Backlog

Sprint
Planning
1

Sprint
Planning
2

Sprint
Review

RetrospecOve
MeeOng

Ideal
Day
/
Story
Points
–
Business
Value

Product
e
Sprint
Backlog

Planning
Poker

Equipes
mulOdisciplinares
e
auto-‐organizadas

Velocidade
de
equipe

WWW
e
WCBI

MPS.BR
e
Metodologias
Ágeis

Product
Scrum

Scrum
Team

Owner
Master

Épicos

GRE/DRE/PCP
Temas

IDEA

Product
e
Sprint
Backlog

Sprint
Planning
1

Sprint
Planning
2

LightWeight
Change
Request

Aceitação
de

requisitos

Propriedade
coleOva
de

código

MPS.BR
e
Metodologias
Ágeis

Product
Scrum

Scrum
Team

Owner
Master

Equipes
mulOdisciplinares
e
auto-‐organizadas

GCO/ITP

Integração
Consnua

LightWeight
Change
Request

GQA/
VER/
VAL
Product
e
Sprint
Backlog

TDD

Testes
Funcionais,
etc

Teste
de
Aceitação

Sprint
Review

MPS.BR
e
Metodologias
Ágeis

Product
Scrum

Scrum
Team

Owner
Master

Equipes
mulOdisciplinares
e
auto-‐organizadas

GRH
Sprint
Planning
1

Pair
Programming

Propriedade
coleOva
de

código

RetrospecOve
MeeOng

MED
Agile
Radiator
-‐
BurnDown

Velocidade
de
equipe

RetrospecOve
MeeOng

Ideal
Day
/
Story
Points
–
Business
Value

MPS.BR
e
Metodologias
Ágeis

Product
Scrum

Scrum
Team

Owner
Master

GRU/DRU
Equipes
mulOdisciplinares
e
auto-‐organizadas

Pair
Programming

Propriedade
coleOva
de

código

AMP/DFP
Product
e
Sprint
Backlog

RetrospecOve
MeeOng

WWW
e
WCBI

Scrum
–
Conclusão

¨  Por
tudo
isso,
o
Scrum
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ê

uOlizar
as
técnicas
citadas
neste
curso:
pair
programming,

peer
review,
comunicação
tácita,
comparOlhamento
de

código,
entrega
de
maior
valor
de
negócio,
planejamento

consnuo,
etc.

¨  Estas
são
somente
algumas
práOcas
que
você
pode
aplicar

para
complementar
seu
dia-‐a-‐dia
no
gerenciamento
de

projetos.

FIM

carlos.barbieri@fumsoS.soSex.br

isabella@fumsoS.soSex.br

SOFTWARE

Apresentacao gerenciamento projetos_mpsbr_scrum

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Apresentacao gerenciamento projetos_mpsbr_scrum

Apresentacao gerenciamento projetos_mpsbr_scrum