1. MPS.BR
e
Metodologias
Ágeis
Carlos
Barbieri
Isabella
Fonseca
GERENCIAMENTO DE PROJETOS DE
SOFTWARE

2. 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.

3. 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.

4. 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

5. MPS.BR
-­‐
Conceitos

6. 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-­‐fim:
– 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)

7. Maturidade
do
Processo
de
SoSware
no
Brasil
em
2003
Estudos
no
início
dos
anos
2000
mostraram
que:
Ø era
necessário
um
esforço
significaOvo
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
especificamente
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

8. 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
(desafios):
¤ 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)

9. 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

10. 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

11.
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.

12. 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)

13. PROCESSO ISO/IEC-12207
DESENVOL-
OPERAÇÃO MANUTENÇÃO AQUISIÇÃO FORNECIMENTO
VIMENTO
3
CAPACIDADE-ISO/IEC-15504
(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

14. PROCESSO ISO/IEC-12207
DESENVOL-
OPERAÇÃO MANUTENÇÃO AQUISIÇÃO FORNECIMENTO
VIMENTO
CAPACIDADE-ISO/IEC-15504
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

15. 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

16. 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

17. 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,
idenOficou-­‐se
que
as
empresas
tendem
a
apresentar
os
benexcios
esperados
pela
Engenharia
de
SoFware
em
relação
a
custo,
prazo,
produOvidade
e
qualidade

18. 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

19. 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)

20. FUMSOFT
–
CCOMP.MG

21. 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
oficial-­‐2007

22. 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

23. Resultados 2010/11 – Minas Gerais
¨ Minas
Gerais
tem
1
II-­‐InsOtuição
Implementadora
(FUMSOFT-­‐
CCOMP.MG)
¨ Número
de
cerOficaçõ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

24. Perspeclvas
2011
¨ Número
de
empresas
cerOficadas
até
final
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

25. Projeto
MPS.BR/2011
G8
–
Grupo
8
–
Visão
Geral

26. 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

27. 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

28. 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

29. PG MODELO
DO
CURSO
DE
PG-­‐MPS.BR
SOFTEX
CONVÊNIO
CONVÊNIO
CONVÊNIO
UNIVERSI
AGENTE
DADE
29

30. 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
Configuraçã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

31. 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
Professores_PG-­‐MPS_v09
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/
Verificaçã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

32. 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
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
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
Ciensfico
Geral-­‐
20
Oswaldo
Correa
George
Jamil
Msc,Implemen
MCiensfica
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

33. 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
Professores_PG-­‐MPS_v09
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

34. 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

35. 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!

36. 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

37. 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

38. 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

39. 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
idenOficados
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?

40. 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

41. 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

42. RAPS
Engenharia de Requisitos
MPS.BR
Resultados de
Atributos de Processo

43. 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)

44. Processo
de
Gerência
de
Requisitos
-­‐
RAPs
AP 2.1
n RAP2
–
Existe
uma
polílca
organizacional
estabelecida
e
manlda
para
o
processo
n definiçã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
significaOvas
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

45. 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.

46. 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.

47. 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 idenOficar
as
partes
interessadas
no
processo
(pessoas
envolvidas
no
planejamento,
coordenação,
revisão,
definiçõ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.

48. 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

49. 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
definidos
como
checklists

50. 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.

51. 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
definidos
anteriormente
são
aplicados

52. 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.

53. MPS.BR
e
Metodologias
Ágeis
–
Projetos
de
TI
GERENCIAMENTO DE PROJETOS DE
SOFTWARE

54. 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
modificam.

55. Novos
Desafios
-­‐
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

56. MPS.BR
e
Metodologias
Ágeis
–
Discussão
Principais
Problemas
GERENCIAMENTO DE PROJETOS DE
SOFTWARE

57. 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

58. Principais
problemas
-­‐
Comunicação

59. Principais
problemas
-­‐
Comunicação
Fonte:
Alistar
Cockburn
-­‐
Agile
SoFware
Development

60. 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

61. MPS.BR
e
Metodologias
Ágeis
–
Gerenciamento
Ágil
GERENCIAMENTO DE PROJETOS DE
SOFTWARE

62. Agile?
Responder
à
mudança
¨ Em
desenvolvimento
de
soFware,
ser
ágil
significa
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.

63. 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
modificáveis
Mike
Cohn
–
Agile
EsVmaVng
&
Planning

64. 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

65. Gerenciamento
em
projetos
ágeis

66. Gerenciamento
em
projetos
ágeis
¨ FOCO
no
OUTPUT
e
não
no
INPUT
¨ Planejamento
prediOvos:
¤ Criação
de
um
plano
com
aOvidades
definidas
¤ O
gerenciamento/acompanhamento
de
aOvidades
conforme
o
plano
¨ Planejamento
ágil:
¤ Criação
de
entregas
com
conjunto
de
itens
priorizados
¤ Gerencimanto
via
feedback
e
constante
adaptação

67. 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.
IdenOficar
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
significaOvamente
no
curto
prazo
Eliyahu
GoldraŒ
–
A
Meta

68. 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.

69. TOC
em
SoSware
-­‐
Restrições
Escopo
(Inventário)
Escalona-­‐
Orçamento
mento
Pessoas
Recursos
Agile
Management
for
SoFware
Enginnering
David
J.
Anderson

70. TOC
em
SoSware
-­‐
Soluções
Enfileiramento
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

71. TOC
Comercial
-­‐
Realíslco
Projeto
Urgente
Projeto
CríOco
Escopo
Escopo
Preço
Prazo
Preço
Prazo
Sem
Orçamento
Escopo
Preço
Prazo
Agile Management for Software Enginnering
David J. Anderson

72. 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
Agile Management for Software Enginnering
David J. Anderson

73. 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

74. TOC - Variável Recursos - Scrum
¨ Desenvolvimento
heróico
enfaOza
indivíduos.
¤ As
aOvidades
são
designadas
individualmente
¤ Projeto
fica
altamente
dependente
da
performance
dos
indivíduos
envolvidos
¨ Desenvolvimento
colaboraOvo
enfaOza
o
Ome
-­‐>
Scrum
¤ Um
Ome
alto-­‐organizado
define
as
aOvidades
para
se
aOngir
as
metas
estabelecidas
¤ O
Ome
possui
habilidades
diversas
(generalizing
specialist
–
ScoŒ
Ambler)

75. TOC - Variável Recursos - Scrum
Modo
Tradicional
-­‐
Comunicação
fica
um
pouco
deteriorada
-­‐
Pouca
visão
do
todo
-­‐
Pouca
interação,
compromeOmento
baixo,
etc...

76. TOC - Variável Recursos - Scrum
Generalista/especialista
–
Agile
–
ScoŒ
Ambler
-­‐
Melhoria
na
comunicação
e
colaboração
-­‐
Melhoria
na
flexibilidade
-­‐
Visão
holísOca
do
projeto
-­‐
MulOdisciplinaridade
-­‐
Menor
risco

77. 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”

78. 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

79. Gerenciamento
ágil
–
mudanças

80. 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
final
da
pilha
=
BV/
Tamanho
do
requisito
Fonte:
hŒp://www.powerlogic.com.br

81. Priorização
do
Product
Backlog
Fonte:
hŒp://www.soFhouse.se/