Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do

RODRIGO LOPES DE SANTANA
ANLISE DE COMPATIBILIDADE DA METODOLOGIA

GIL SCRUM COM O MODELO DE PROCESSO DE
GERNCIA DE PROJETOS DO MPS.BR
Trabalho apresentado ao curso MBA em
Gerenciamento de Projetos, ps-graduao lato
sensu, nvel de especializao, do Programa
FGV Management da Fundao Getlio Vargas,
como pr-requisito para a obteno do ttulo de
especialista.
Carlos A. C. Salles Jr. (In memoriam)

Coordenador Acadmico Executivo
Edmarson B. Mota
Sonia Lopes da Silva
Orientadora
Fortaleza CE
2013
FUNDAO GETULIO VARGAS
PROGRAMA FGV MANAGEMENT
MBA EM GERNCIAMENTO DE PROJETOS
O Trabalho de Concluso de Curso

Anlise de Compatibilidade da Metodologia gil SCRUM com o Modelo de Processo de
Gerncia de Projetos do MPS.BR
elaborado por Rodrigo Lopes de Santana e aprovado pela Coordenao Acadmica, foi aceito
como pr-requisito para a obteno do certificado do Curso de Ps-Graduao lato sensu
MBA em Gerenciamento de Projetos, nvel de especializao, do programa FGV
Management.
Fortaleza, 13 de Outubro de 2013
Carlos A. C. Salles Jr. (In memoriam)

Edmarson B. Mota
Sonia Lopes da Silva

Orientadora
TERMO DE COMPROMISSO
O aluno Rodrigo Lopes de Santana, abaixo assinado, do curso de MBA em Gerenciamento

de Projetos, Turma GP07-Fortaleza, do Programa FGV Management, realizado nas
dependncias da instituio conveniada MRH, no perodo de 06/05/2010 a 10/11/2011,
declara que o contedo do Trabalho de Concluso de Curso intitulado Anlise de
Compatibilidade da Metodologia gil SCRUM com o Modelo de Processo de Gerncia
de Projetos do MPS.BR autntico e original.
Fortaleza, 13 de Outubro de 2013
Rodrigo Lopes de Santana
Dedico esse trabalho especialmente minha famlia, que forma os meus pilares, como pessoa
e como profissional e, ao mesmo tempo, so o objetivo fim de todo o meu esforo nessa vida.
Dedico tambm aos meus mestres, no somente os professores, mas tambm queles que
conseguiram mudar algo em mim, que me fizeram evoluir a forma de enxergar o mundo.
Resumo
Durante muito tempo o foco principal das organizaes esteve nos produtos. No entanto, com
o passar do tempo e a globalizao do mercado, a competio se tornou mais acirrada e os
clientes passaram a ser o foco, que exigem cada vez mais um tratamento individualizado e
satisfatrio. Nessa corrida por satisfazer o cliente e consequentemente maior competitividade,
as organizaes precisam adaptar-se constante e rapidamente para responder s mudanas e
demandas do mercado e, portanto, esto cada vez mais preocupadas em oferecer e prover
servios com qualidade. Neste contexto, as organizaes que proveem servios de TI
comearam a adotar formalmente conceitos, metodologias e ferramentas de gesto de
projetos. Quando essas organizaes so micro e pequenas empresas de software, a gesto de
projetos possui algumas limitaes em virtude de problemas relacionados prpria natureza
de tais empresas, como: quadro reduzido de funcionrios, limitaes financeiras, baixa
intensidade de capital, imaturidade na definio de suas metodologias, crescimento por
demanda, acmulo de papis entre os funcionrios e utilizao de mo de obra pouco
qualificada. Para auxili-las, surgiram, ao longo dos anos, metodologias e iniciativas de
melhoria do processo de desenvolvimento de software, como o SCRUM e o MPS.BR,
respectivamente. Este trabalho tem como objetivo analisar a compatibilidade da metodologia
gil de gesto de projetos SCRUM com o processo de Gerncia de Projetos do MPS.BR. A
anlise de compatibilidade ser realizada utilizando-se do mtodo formal de avaliao do
MPS.BR chamado de MA-MPS.
Palavras Chave: Gerenciamento de Projetos; MPS.BR; SCRUM; Metodologia gil.
Abstract
For a long time the main focus of the organizations was on the products. However, over time
and with the globalization of the market, the competition has become fiercer and customers
have come to be the focus, which increasingly require an individualized and satisfactory
treatment. In this race to satisfy the customer and, therefore, more competitive, the
organizations must constantly adapt and quickly respond to changes and demands of the
market and, therefore, they are increasingly concerned to offer and provide high quality
services. In this context, the organizations that provide IT services started, formally, to adopt
concepts, methodologies and tools of project management. When these organizations are
micro and small business of software development, the project management has some
limitations due to problems related to the nature of such companies as: the reduced number of
employees, financial constraints, low capital intensity, immaturity in defining their
methodologies, growth by demand, accumulation of roles between the staff and the use of
unskilled team. To assist these organizations, methodologies and initiatives to improve the
process of software development have emerged over the years, such as SCRUM and MPS.BR
respectively. This paper aims to examine the compatibility of agile methodology to project
management SCRUM with the Project Management process of the MPS.BR initiative. The
compatibility analysis will be performed using the formal method for assessment of MPS.BR,
called MPS-MA.
Key Words: Project Management; MPS.BR; SCRUM; Agile Methodology
AGRADECIMENTOS
Antes de tudo e todos, agradeo em especial a Deus por abenoar a minha vida com a minha
famlia que, apesar das dificuldades, propiciou um ambiente favorvel para a construo e o
sucesso desse trabalho. Voltando aos meros mortais, mas to amados como amo a Deus,
agradeo imensamente minha esposa Tarciane pela ajuda, no s nos momentos de grande
produtividade, mas principalmente nos momentos mais difceis desse trabalho. Agradeo
profundamente aos meus pais, Raul e Ftima, por dedicarem uma vida inteira a tentar educar
os filhos e possibilitar-lhes oportunidades de vencer na vida, de me permitirem estar onde
estou neste momento. Agradeo tambm ao Banco do Nordeste do Brasil pelo patrocnio
financeiro e o pelo valoroso incentivo profissional. Por fim, agradeo a todos os meus
professores que participaram dessa construo, parentes prximos, amigos e colegas de
trabalho que de alguma forma ajudaram ou torceram pelo meu sucesso acadmico e
profissional.
LISTA DE FIGURAS
Figura 1 - Componentes do MPS (SOFTEX, 2012a)......................................................................15
Figura 2 - Subprocesso Preparar a Realizao da Avaliao (FALBO, 2008) ....................................27
Figura 3 - Subprocesso Realizar a Avaliao Final (FALBO, 2008).................................................31
Figura 4 - Ciclo de Execuo do Scrum.........................................................................................42
Figura 5 - Grfico Burndown (MAGNO, 2009).............................................................................44
Figura 6 - Caracterizao do grau de implementao do Scrum.......................................................71
LISTA DE TABELAS
Tabela 1 - Nveis de Maturidade e Atributos de Processos do MR-MPS-SW (SOFTEX, 2012a) ........18
Tabela 2 Detalhe do Processo de Avaliao (SOFTEX, 2012c).....................................................26
Tabela 3 - Escala para caracterizao do grau de implementao de um resultado esperado do processo
e de um resultado esperado de atributo do processo nos projetos (SOFTEX, 2012c) .........................32
Tabela 4 - Regras para agregar a caracterizao dos resultados esperados dos processos e dos
resultados esperados de atributos do processo nos projetos e chegar caracterizao da unidade
organizacional (SOFTEX, 2012c).................................................................................................33
Tabela 5 - Regras para caracterizar o grau de implantao dos atributos do processos na unidade
organizacional (SOFTEX, 2012c).................................................................................................34
Tabela 6 - Caracterizao de atributos de processos para satisfazer aos nveis MR-MPS (SOFTEX,
2012c)........................................................................................................................................35
Tabela 7 - Atributos de Processos para a Capacidade do Processos do Nvel G de maturidade ...........46
Tabela 8 - Exemplo de Indicadores de Implementao...................................................................49
Tabela 9 - Exemplo de Escala de Caracterizao para cada Resultado Esperado ...............................49
Tabela 10 - GPR 1. Indicadores de Implementao........................................................................50
Tabela 11 - GPR 1. Classificao de acordo com os Indicadores de Implementao .........................50
Tabela 28 - GPR 10. Indicadores de Implementao.......................................................................60
Tabela 29 - GPR 10. Classificao de acordo com os Indicadores de Implementao .......................60
Tabela 31 - GPR 11. Classificao de acordo com os Indicadores de Implementao ........................61

SUMRIO
RESUMO...................................................................................................................................5
ABSTRACT...............................................................................................................................6
AGRADECIMENTOS.....................................................................................................................7
1 INTRODUO.................................................................................................................10
1.1 OBJETIVOS GERAIS.........................................................................................................12
1.2 OBJETIVOS ESPECFICOS................................................................................................12
1.3 ORGANIZAO DO TRABALHO.......................................................................................13
2 MPS.BR..............................................................................................................................14
2.1 DESCRIO DO MR-MPS-SW.......................................................................................15
2.2 NIVEL G: PROCESSO DE GERNCIA DE PROJETOS........................................18
2.2.1 RESULTADOS ESPERADOS...............................................................................................19
2.3 MODELO DE AVALIAO: MA-MPS......................................................................25
2.3.1 SUBPROCESSO PREPARAR A REALIZAO DA AVALIAO...........................................27
2.3.1.1 Atividade Viabilizar a Avaliao................................................................................28
2.3.1.2 Atividade Planejar a Avaliao...................................................................................28
2.3.1.3 Atividade Preparar a Avaliao..................................................................................29
2.3.1.4 Atividade Conduzir a Avaliao Inicial......................................................................29
2.3.1.5 Atividade Completar a preparao da avaliao........................................................30
2.3.2 SUBPROCESSO REALIZAR A AVALIAO FINAL............................................................31
2.3.2.1 Atividade Conduzir a Avaliao Final........................................................................31
2.3.2.2 Atividade Avaliar a execuo do processo de avaliao............................................35
2.4 CONSIDERAES FINAIS........................................................................................36
3 METODOLOGIA GIL SCRUM....................................................................................37
3.1 PAPIS............................................................................................................................38
3.2 GERNCIA DE PROJETOS NO SCRUM..................................................................40

3.2.1 ARTEFATOS.....................................................................................................................40
3.2.2 CICLO DE EXECUO DO PROJETO NO SCRUM..............................................................42
3.3 CONSIDERAES FINAIS................................................................................................45
4 ANLISE DE COMPATIBILIDADE DO SCRUM COM O PROCESSO
GERNCIA DE PROJETOS DO MPS.BR..........................................................................46
4.1 PREPARAO PARA A AVALIAO UTILIZANDO O MTODO MA-MPS...48
4.2 ANLISE DE COMPATIBILIDADE DO SCRUM COM O MPS.BR.........................50
4.2.1 GPR 1. O ESCOPO DO TRABALHO PARA O PROJETO DEFINIDO....................................50
4.2.2 GPR 2. AS TAREFAS E OS PRODUTOS DE TRABALHO DO PROJETO SO DIMENSIONADOS
UTILIZANDO MTODOS APROPRIADO.........................................................................................51
4.2.3 GPR 3. O MODELO E AS FASES DO CICLO DE VIDA DO PROJETO SO DEFINIDOS..........52

4.2.4 GPR 4. O ESFORO E O CUSTO PARA A EXECUO DAS TAREFAS E DOS PRODUTOS DE
TRABALHO SO ESTIMADOS COM BASE EM DADOS HISTRICOS OU REFERNCIAS TCNICAS.
.53
4.2.5 GPR 5. O ORAMENTO E O CRONOGRAMA DO PROJETO, INCLUINDO A DEFINIO DE

MARCOS E PONTOS DE CONTROLE, SO ESTABELECIDOS E MANTIDOS;.....................................54
4.2.6 GPR 6. OS RISCOS DO PROJETO SO IDENTIFICADOS E O SEU IMPACTO, PROBABILIDADE

DE OCORRNCIA E PRIORIDADE DE TRATAMENTO SO DETERMINADOS E DOCUMENTADOS;....55
4.2.7 GPR 7. OS RECURSOS HUMANOS PARA O PROJETO SO PLANEJADOS CONSIDERANDO O

PERFIL E O CONHECIMENTO NECESSRIOS PARA EXECUT-LO;.................................................57
4.2.8 GPR 8. OS RECURSOS E O AMBIENTE DE TRABALHO NECESSRIOS PARA EXECUTAR O

PROJETO SO PLANEJADOS;.......................................................................................................58
4.2.9 GPR 9. OS DADOS RELEVANTES DO PROJETO SO IDENTIFICADOS E PLANEJADOS

QUANTO FORMA DE COLETA, ARMAZENAMENTO E DISTRIBUIO.
UM MECANISMO
ESTABELECIDO PARA ACESS-LOS, INCLUINDO, SE PERTINENTE, QUESTES DE PRIVACIDADE E

SEGURANA;..............................................................................................................................59
4.2.10 GPR 10. UM PLANO GERAL PARA A EXECUO DO PROJETO ESTABELECIDO COM A
INTEGRAO DE PLANOS ESPECFICOS;.....................................................................................60
4.2.11 GPR 11. A VIABILIDADE DE ATINGIR AS METAS DO PROJETO EXPLICITAMENTE

AVALIADA CONSIDERANDO RESTRIES E RECURSOS DISPONVEIS.
SE NECESSRIO, AJUSTES
SO REALIZADOS;......................................................................................................................61
4.2.12 GPR 12. O PLANO DO PROJETO REVISADO COM TODOS OS INTERESSADOS E O

COMPROMISSO COM ELE OBTIDO E MANTIDO;........................................................................62
4.2.13 GPR 13. O ESCOPO, AS TAREFAS, AS ESTIMATIVAS, O ORAMENTO E O CRONOGRAMA

DO PROJETO SO MONITORADOS EM RELAO AO PLANEJADO;...............................................63
4.2.14 GPR 14. OS RECURSOS MATERIAIS E HUMANOS BEM COMO OS DADOS RELEVANTES
DO PROJETO SO MONITORADOS EM RELAO AO PLANEJADO;...............................................64
4.2.15 GPR 15. OS RISCOS SO MONITORADOS EM RELAO AO PLANEJADO;.....................65

4.2.16 GPR 16. O ENVOLVIMENTO DAS PARTES INTERESSADAS NO PROJETO PLANEJADO,
MONITORADO E MANTIDO;.........................................................................................................66
4.2.17 GPR 17. REVISES SO REALIZADAS EM MARCOS DO PROJETO E CONFORME

ESTABELECIDO NO PLANEJAMENTO;..........................................................................................67
4.2.18 GPR 18. REGISTROS DE PROBLEMAS IDENTIFICADOS E O RESULTADO DA ANLISE DE

QUESTES PERTINENTES, INCLUINDO DEPENDNCIAS CRTICAS, SO ESTABELECIDOS E
TRATADOS COM AS PARTES INTERESSADAS;..............................................................................68
4.2.19 GPR 19. AES PARA CORRIGIR DESVIOS EM RELAO AO PLANEJADO E PARA
PREVENIR A REPETIO DOS PROBLEMAS IDENTIFICADOS SO ESTABELECIDAS,
IMPLEMENTADAS E ACOMPANHADAS AT A SUA CONCLUSO;.................................................69
4.3 CLASSIFICAO DO NVEL DE MATURIDADE DO SCRUM NO PROCESSO

DE GERNCIA DE PROJETOS..........................................................................................71
4.4 CONSIDERAES FINAIS................................................................................................72
5 CONCLUSO E TRABALHOS FUTUROS.................................................................74
6 REFERNCIAS BIBLIOGRFICAS............................................................................76
10
INTRODUO
Eficincia, termo que resume o objetivo de qualquer organizao interessada em se manter no

mercado de forma competitiva, ou seja, maximizao da produo com o menor esforo e
menor custo possvel. No entanto, para isso, e no menos importante, essas organizaes
precisam tambm se preocupar com a eficcia do que produzido ou servido, atendendo
satisfatoriamente seu mercado. Sandroni (2008) resume bem essa ideia ao enfatizar que fazer
a coisa certa de forma certa a melhor definio de trabalho eficiente e eficaz. Para isso,
necessrio conhecer profundamente os melhores mtodos de produo, as melhores prticas
de gesto, o mercado onde se deseja atuar, suas condies e necessidades e, acima de tudo, ter
um planejamento estratgico bem definido para conhecer bem onde se deseja chegar.
Durante muito tempo o foco principal das organizaes esteve nos produtos. O
mais importante era produzir um grande nmero de produtos padronizados, tratando todos os
clientes da mesma forma. No entanto, com o passar do tempo, com a globalizao do
mercado, a competio se tornou mais acirrada e, somando ainda as evolues tecnolgicas,
as organizaes se viram obrigadas a mudarem o foco principal. Os clientes passaram a ser o
foco, que exigem cada vez mais um tratamento individualizado (ARAUJO, CAPPELLI, et al.,
2004). As organizaes em geral procuram utilizar novas tcnicas, tecnologias, padres e
paradigmas que ajudem a alcanar eficincia e eficcia em seus processos, produtos e servios
e, assim, atender as necessidades individuais dos seus clientes.
Dentro das organizaes de software existe um nicho de empresas caracterizadas
como Micro e Pequenas Empresas de Software (MPES) que, segundo (MCT, 2005), so
empresas com at 50 empregados e representam uma parcela significativa no percentual de
empresas brasileiras desse ramo, alm de possurem caractersticas tpicas, como por
exemplo: baixa intensidade de capital, imaturidade nas metodologias, crescimento por
demanda, acmulo de papis entre os funcionrios e utilizao de mo de obra no
qualificada. Outro problema crtico enfrentado pelas MPES est relacionado prpria cultura
organizacional, onde os funcionrios esto acostumados informalidade ou at mesmo
ausncia de processos. Em alguns casos, a implantao de processo vista como aumento da
burocracia e restrio liberdade individual. Esta ausncia de processos bem definidos
caracteriza um dos fatores para a grande quantidade de falncias entre as MPES. No Brasil,
cerca de 50% das MPES fecham aps os trs primeiros anos de vida (MCT, 2005). Este
cenrio tambm se repete em vrios outros pases em todo o mundo. Dessa forma, um
11
caminho que contribui para que essas empresas se tornem competitivas investir na melhoria
dos processos.
Nessa corrida por maior competitividade, que requer uma adaptao constante s
mudanas do mundo externo, as MPES precisam ajustar-se constante e rapidamente para
responder s mudanas (ARAUJO, CAPPELLI, et al., 2004). Foi a partir desta necessidade
que surgiram as Metodologias geis para desenvolvimento de Software. Elas tem como
objetivo propor uma nova abordagem de desenvolvimento que elimina gastos com
documentao excessiva e burocrtica, enfatizando a interao entre as pessoas e as atividades
que efetivamente trazem valor e produzem software com qualidade (BECK, 2001). As MPES
esto cada vez mais interessadas na possibilidade de adoo de uma metodologia gil para a
melhoria de seus processos, devido diminuio de documentao, um maior controle no
ritmo acelerado de mudanas e a participao do cliente durante o processo de
desenvolvimento, alem da possibilidade de propiciar um melhor gerenciamento de seus
projetos.
Com a introduo de princpios e prticas advindas das metodologias geis, o
desenvolvimento de software ganhou um novo impulso. Influenciando no s a forma de se
desenvolver software, mas tambm a forma de se contratar o desenvolvimento de um
software. Tais metodologias quebram paradigmas e trazem enormes vantagens, tanto para o
cliente quanto para a equipe de desenvolvimento envolvida no projeto. Dentre os vrios
mtodos de desenvolvimento gil existentes, o Scrum (SCHWABER e SUTHERLAND,
2010) o nico que se preocupa exclusivamente com os aspectos gerenciais de um projeto.
Paralelo a isso, o governo brasileiro juntamente com a empresa Softex investiu na
construo de um modelo de Melhoria de Processos de Software (MPS.BR) (SOFTEX,
2012a) voltado para atender as MPES brasileiras. Com o incentivo, diversas MPES se
certificaram no modelo garantindo maior qualidade nos seus processos, servios e
consequentemente nos seus produtos.
As empresas de TI , em geral, se esforam para manter altos nveis de satisfao
dos clientes. Segundo Softex (2012b, p.6):
"Trabalhando de forma reativa, eles passam pouco tempo planejando,
treinando, analisando criticamente, investigando e trabalhando com seus
clientes. O resultado a falha em adotar prticas proativas e estruturadas
de trabalho. O desenvolvimento e a melhoria das prticas de servios so
chaves para um melhor desempenho, aumento da satisfao do cliente e a
12
lucratividade do setor. Desta forma, assim como para outros setores,
qualidade fator crtico de sucesso. Para que se tenha um setor
competitivo, nacional e internacionalmente, essencial que as empresas
de TI coloquem a eficincia e a eficcia dos seus processos em foco nas
empresas, visando oferta de servios conforme padres internacionais
de qualidade."
Uma soluo prtica que atenda s necessidades destas empresas a unio das
prticas do MPS.BR com o Scrum, porm, para que isto ocorra, necessrio um estudo que
conclua se as prticas do Scrum so aderentes s prticas do MPS.BR, visto que o Scrum foi
projetado para atender o desenvolvimento de software. Visando esta unio, este trabalho
prope-se a analisar, atravs do Modelo de Avaliao MPS.BR (MA-MPS) (SOFTEX,
2012c), a compatibilidade entre as prticas do Scrum e as prticas do processo de Gerncia de
Projetos que se encontra no nvel G de maturidade do MPS.BR, e fornecer as informaes
necessrias para que as dvidas a respeito desta compatibilidade sejam esclarecidas.
1
OBJETIVOS GERAIS
O objetivo principal deste trabalho realizar uma anlise, atravs da utilizao do
mtodo de avaliao MA-MPS (SOFTEX, 2012c), da compatibilidade do uso da metodologia

gil Scrum atendendo aos resultados esperados dos atributos de processo relativos ao processo
de Gerncia de Projetos do Nvel G de maturidade do MPS.BR, e, de acordo com o resultado
desta anlise, concluir se a prtica do Scrum compatvel com o MPS.BR no que diz respeito
ao processo citado. A escolha do Scrum para a realizao desta avaliao justifica-se por se
tratar de uma metodologia gil especfica para o gerenciamento de projetos.
2
OBJETIVOS ESPECFICOS
Analisar a aplicabilidade da metodologia Scrum dentro da rea de gesto de
projetos de TI, considerando os atributos de processo do MPS.BR, para tanto, os seguintes

objetivos especficos sero detalhados:
Detalhar o MPS.BR, explicar o modelo, descrever suas representaes e seus

nveis, apresentar seu mtodo de avaliao MA-MPS e detalhar os atributos e
resultados de atributos do processo de Gerncia de Projetos do Nvel G;
Detalhar o Scrum, explicar seus papis, artefatos e sua estrutura de processo;
13
Avaliar a compatibilidade do processo Gerncia de Projetos do MPS.BR com

a metodologia Scrum, atravs do uso do mtodo formal de avaliao MAMPS no que diz respeito anlise dos resultados esperados do processo;
ORGANIZAO DO TRABALHO
Este trabalho se baseia, principalmente, na anlise de compatibilidade da
metodologia gil Scrum com o processo de Gerncia de Projetos do MPS.BR. Para tanto, este
trabalho est organizado em 5 captulos, sendo o presente captulo introdutrio enquanto os
demais captulos esto organizados da seguinte forma:
O captulo , MPS.BR, abordar os principais conceitos relacionados ao modelo de
melhoria de processos MPS.BR e a importncia do processo de Gerncia de Projetos. Ser
apresentado como o MPS.BR est organizado, os diversos nveis de maturidade e com mais
detalhes o processo que ser objeto de estudo deste trabalho que o processo de Gerncia de
Projetos, pertencente ao nvel G de maturidade. Tambm neste captulo ser apresentado o
modelo de avaliao formal do MPS.BR chamado de MA-MPS.BR.
O captulo Error: Reference source not found, SCRUM, descrever os princpios e
caractersticas do Scrum, seus papis, artefatos, a dinmica do planejamento de projetos e sua
estrutura de processo.
No
captulo
Error:
Reference
source
not
found,
ANLISE
DE
COMPATIBILIDADE DO SCRUM COM O PROCESSO GERNCIA DE PROJETOS DO

MPS.BR, feita a anlise, propriamente dita, da compatibilidade do Scrum com processo de
Gerncia de Projetos do MPS.BR do nvel G utilizando o mtodo de avaliao MA-MPS.
O captulo Error: Reference source not found, Error: Reference source not found,
pretende fechar este trabalho com uma viso geral dos conceitos no que diz respeito sua
contribuio s MPES, no que diz respeito compatibilidade entre o modelo de processo
MPS.BR e a metodologia gil Scrum, dentro do escopo do trabalho, alm disso, esboar
futuros passos no desenvolvimento de trabalhos que exploraro a potencialidade desse tema.
14
MPS.BR
O Modelo de Processo de Software Brasileiro (MPS.BR) (SOFTEX, 2012a) um programa

mobilizador, de longo prazo, criado em dezembro de 2003, coordenado pela Associao para
Promoo da Excelncia do Software Brasileiro (SOFTEX), que conta com apoio do
Ministrio da Cincia, Tecnologia e Inovao (MCT) (MCT, 2005), Financiadora de Estudos e
Projetos (FINEP), Servio Brasileiro de Apoio s Micro e Pequenas Empresas (SEBRAE) e
Banco Interamericano de Desenvolvimento (BID/FUMIN). O objetivo do programa MPS.BR
a melhoria de processo de software e servios, com duas metas a alcanar a mdio e longo
prazos respectivamente: a) meta tcnica, visando criao e aprimoramento do Modelo MPS;
b) meta de negcio, visando disseminao e adoo do Modelo MPS, em todas as regies do
pas, em um intervalo de tempo justo, a um custo razovel, tanto em micro, pequenas e
mdias empresas (foco principal) quanto em grandes organizaes privadas e governamentais,
com resultados esperados tais como: (i) criao e aprimoramento do modelo de negcio MNMPS; (ii) cursos, provas e workshops MPS; (iii) organizaes que implementaram o Modelo
MPS; (iv) organizaes com avaliao MPS publicada (prazo de validade de trs anos) MAMPS (SOFTEX, 2012c).
O MPS est descrito por meio de documentos em formato de guias, a Figura 1 ilustra
todos os componentes do modelo:
Guia Geral MPS de Software: contm a descrio geral do modelo MPS e detalha o
Modelo de Referncia MPS para Software (MR-MPS-SW), seus componentes e as
definies comuns necessrias para seu entendimento e aplicao;
Guia Geral MPS de Servios: contm a descrio geral do modelo MPS e detalha o
Modelo de Referncia MPS para Servios (MR-MPS-SV), seus componentes e as
definies comuns necessrias para seu entendimento e aplicao;
Guia de Aquisio: descreve um processo de aquisio de software e servios

correlatos. descrito como forma de apoiar as instituies que queiram adquirir
produtos de software e servios correlatos apoiando-se no MR-MPS-SW;
Guia de Avaliao: descreve o processo e o mtodo de avaliao MA-MPS, os

requisitos para avaliadores lderes, avaliadores adjuntos e Instituies Avaliadoras (IA)
(SOFTEX, 2012c);
15
Guia de Implementao: srie de documentos que fornecem orientaes para

implementar nas organizaes os nveis de maturidade descritos no Modelo de
Referncia MR-MPS-SW (SOFTEX, 2011d).
Figura 1 - Componentes do MPS (SOFTEX, 2012a, p. 14)
Este trabalho est focado na descrio resumida do Guia Geral MPS de Software (MRMPS-SW), o Guia de Avaliao de Software (MA-MPS) e o Guia de Implementao que
detalha a implementao de cada um dos processos descritos no Guia Geral MPS de Software.
1.1
DESCRIO DO MR-MPS-SW
O Modelo de Referncia MPS para Software (MR-MPS-SW) (SOFTEX, 2012a)
define nveis de maturidade que so uma combinao entre processos e sua capacidade. A
capacidade do processo a caracterizao da habilidade do processo para alcanar os
objetivos de negcio, atuais e futuros; estando relacionada com o atendimento aos atributos de
processo associados aos processos de cada nvel de maturidade.
Os nveis de maturidade estabelecem patamares de evoluo de processos,
caracterizando estgios de melhoria da implementao de processos na organizao. O nvel
de maturidade em que se encontra uma organizao permite prever o seu desempenho futuro
ao executar um ou mais processos. O MR-MPS- SW define sete nveis de maturidade: A (Em
16
Otimizao), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E
(Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A escala de
maturidade se inicia no nvel G e progride at o nvel A. Para cada um destes sete nveis de
maturidade atribudo um perfil de processos que indicam onde a organizao deve colocar o
esforo de melhoria. O progresso e o alcance de um determinado nvel de maturidade do MRMPS-SW se obtm quando so atendidos os propsitos e todos os resultados esperados dos
respectivos processos e os resultados esperados dos atributos de processo estabelecidos para
aquele nvel. A diviso em 7 estgios tem o objetivo de possibilitar uma implementao e
avaliao adequada s micros, pequenas e mdias empresas. A possibilidade de se realizar
avaliaes considerando mais nveis tambm permite uma visibilidade dos resultados de
melhoria de processos em prazos mais curtos.
A capacidade do processo representada por um conjunto de atributos de processo
descrito em termos de resultados esperados, que expressa o grau de refinamento e
institucionalizao com que o processo executado na organizao ou unidade
organizacional. No MR-MPS-SW, na medida em que a organizao ou a unidade
organizacional evolui nos nveis de maturidade, um maior nvel de capacidade para
desempenhar o processo deve ser atingido.
Os diferentes nveis de capacidade dos processos so descritos por nove atributos de
processo (AP). O alcance de cada atributo de processo avaliado utilizando os respectivos
resultados esperados de atributo de processo (RAP). Neste trabalho iremos detalhar apenas os
dois atributos (AP 1.1 e AP 2.1) que so utilizados no nvel G de maturidade do MPS.BR e
que compe a base de estudo deste trabalho. Os demais atributos sero apenas citados como
forma de compor todos os nveis de maturidade.
A seguir o detalhe dos atributos de processos com a mesma nomenclatura utilizada no
Guia Geral do MPS (SOFTEX, 2012a):
AP 1.1 O processo executado: este atributo evidencia o quanto o processo atinge o

seu propsito.
o Resultado esperado: RAP 1. O processo atinge seus resultados definidos.
AP 2.1 O processo gerenciado: Este atributo evidencia o quanto a execuo do

processo gerenciada.
17
o Resultados esperados: RAP 2. Existe uma poltica organizacional
estabelecida e mantida para o processo;
o RAP 3. A execuo do processo planejada;
o RAP 4. A execuo do processo monitorada e ajustes so realizados;
o RAP 5. As informaes e os recursos necessrios para a execuo do processo
so identificados e disponibilizados;
o RAP 6. As responsabilidades e a autoridade para executar o processo so
definidas, atribudas e comunicadas;
o RAP 7. As pessoas que executam o processo so competentes em termos de
formao, treinamento e experincia;
o RAP 8. A comunicao entre as partes interessadas no processo planejada e
executada de forma a garantir o seu envolvimento;
o RAP 9. Os resultados do processo so revistos com a gerncia de alto nvel
para fornecer visibilidade sobre a sua situao na organizao;
AP 2.2 Os produtos de trabalho do processo so gerenciados;
AP 3.1. O processo definido;
AP 3.2 O processo est implementado;
AP 4.1 O processo medido;
AP 4.2 O processo controlado;
AP 5.1 O processo objeto de melhorias incrementais e inovaes;
AP 5.2 O processo otimizado continuamente.

A Tabela 1 ilustra os nveis de maturidade e os atributos de processos exigidos para
cada nvel. Como os atributos de processos so compostos de resultados esperados, para que
18
uma empresa alcance determinado nvel de maturidade a mesma deve prover a
implementao dos atributos de processos e obter os resultados esperados conforme detalhado
na tabela.
Na seo seguinte ser descrito detalhamento o Processo de Gerncia de Projetos que
pertence ao nvel G de maturidade.
Tabela 1 - Nveis de Maturidade e Atributos de Processos do MR-MPS-SW
(SOFTEX, 2012a, p. 23)
1.2
NIVEL G: PROCESSO DE GERNCIA DE PROJETOS

O propsito do processo Gerncia de Projetos (SOFTEX, 2011d) estabelecer e
manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como
prover informaes sobre o andamento do projeto que permitam a realizao de correes
19
quando houver desvios significativos no desempenho do projeto. O propsito deste processo
evolui medida que a organizao cresce em maturidade. O processo Gerncia de Projetos
(GPR) envolve vrias atividades, como: desenvolver um plano geral de controle do projeto;
obter o comprometimento e mant-lo ao longo de toda a execuo do projeto; e conhecer o
progresso do projeto, de maneira que aes corretivas possam ser tomadas quando a execuo
do projeto desviar do planejado.
O desenvolvimento do plano do projeto inclui: identificar e estimar o escopo, os
produtos de trabalho e as tarefas do projeto; estabelecer recursos necessrios; identificar e
analisar riscos do projeto; estabelecer compromissos; e definir cronograma de execuo
baseado no ciclo de vida definido para o projeto.
O acompanhamento do projeto realizado atravs da comparao dos atributos reais
de produtos de trabalho e tarefas, esforo, custo e cronograma com o que foi planejado, nos
marcos (pontos de reviso) predefinidos no planejamento do projeto. A reviso de incio de
fase de projeto tem por objetivo verificar se as condies para que uma fase seja iniciada
esto atendidas. Pode ser que, mesmo que a fase anterior no esteja encerrada, seja possvel
iniciar a nova fase, nas condies atendidas e com prazos para o cumprimento de algumas
outras condies. A reviso de fim de fase de projeto tem por objetivo verificar se todos os
critrios de encerramento de fase foram cumpridos. As revises em marcos podem ter um
carter formal, com participao de gerncias superiores, representantes do cliente e outras
partes interessadas no projeto. Sempre que necessrio, deve-se realizar um replanejamento e
uma nova anlise de sua viabilidade.
Os pontos de controle representam pontos entre um marco e outro nos quais revises
so realizadas para avaliar o andamento do projeto, porm, no fazem parte do caminho
crtico do projeto. O projeto pode prosseguir mesmo que a reviso de um ponto de controle
no tenha sido concluda. A visibilidade apropriada do estado do projeto, atravs dos pontos
de controle, possibilita a tomada de aes corretivas quando o estado do projeto se desvia
significativamente do esperado. Tais aes podem exigir o replanejamento, o estabelecimento
de novos acordos ou atividades adicionais de mitigao de riscos no plano.
1.2.1
Resultados esperados
O Processo de Gerncia de Projetos, nvel G, para ser implementado necessita alcanar
os seguintes resultados esperados (SOFTEX, 2011d) (SOFTEX, 2012a):
20
GPR 1. O escopo do trabalho para o projeto definido: o escopo do projeto define

todo o trabalho necessrio, e somente ele, para entregar um produto que satisfaa as
necessidades, caractersticas e funes especificadas para o projeto, de forma a
conclu-lo com sucesso. O escopo o ponto de partida para o planejamento do projeto.
A definio do escopo deve estabelecer o que est e o que no est includo no projeto.
Para isso, o escopo contm a definio do objetivo e da motivao, os limites e
restries, todos os produtos que sero entregues e os outros produtos gerados pelo
projeto, entre outras informaes. Este resultado tambm pode ser descrito por meio
de um Documento de Viso ou outro documento que defina, claramente, o escopo do
trabalho;
GPR 2. As tarefas e os produtos de trabalho do projeto so dimensionados

utilizando mtodos apropriados: o tamanho a principal entrada de muitos modelos
utilizados para estimar o esforo, custo e cronograma. O tamanho a dimenso das
funcionalidades sob o ponto de vista do usurio. So contadas tabelas internas e
externas ao sistema, classes, objetos, relatrios, telas, consultas a banco de dados,
clculos, transaes e atores dos casos de uso, linhas de cdigo, etc;
GPR 3. O modelo e as fases do ciclo de vida do projeto so definidos: o ciclo de

vida de um projeto consiste de fases e atividades que so definidas de acordo com o
escopo, as estimativas para os recursos e a natureza do projeto, visando oferecer maior
controle gerencial. As fases geram produtos de trabalho necessrios para o
desenvolvimento de fases posteriores. Essa organizao em fases permite planejar o
projeto, incluindo marcos importante para o controle e revises;
GPR 4. O esforo e o custo para a execuo das tarefas e dos produtos de

trabalho so estimados com base em dados histricos ou referncias tcnicas: as
estimativas de esforo e custo so, normalmente, baseadas nos resultados de anlises
utilizando modelos e/ou dados histricos aplicados ao tamanho, atividades e outros
parmetros de planejamento. importante destacar que dados histricos incluem os
dados de custo, esforo e tempo de projetos executados anteriormente, alm de dados
apropriados de escala para equilibrar as diferenas de tamanho e complexidade. As
estimativas de esforo e custo tipicamente consideram o escopo do projeto e os riscos;
21
GPR 5. O oramento e o cronograma do projeto, incluindo a definio de marcos

e pontos de controle, so estabelecidos e mantidos: as dependncias entre tarefas
so estabelecidas e potenciais gargalos so identificados e resolvidos quando possvel
utilizando mtodos apropriados (por exemplo, anlise de caminho crtico). O
cronograma das atividades com incio, durao e trmino estabelecido e os recursos
requeridos so refletidos nos custos estimados. O oramento do projeto estabelecido
com base no cronograma e na estimativa de custos;
GPR 6. Os riscos do projeto so identificados e o seu impacto, probabilidade de

ocorrncia e prioridade de tratamento so determinados e documentados:
projetos tm riscos e estes precisam ser identificados, analisados e priorizados atravs
de uma lista de riscos priorizada com anlise da probabilidade de ocorrncia e da
gravidade dos problemas decorrentes de sua ocorrncia. A monitorao dos riscos, os
problemas gerados devido materializao dos riscos e o acompanhamento podem ser
garantidos atravs do GPR15, GPR 18 e GPR19, respectivamente. No nvel G, os
riscos so acompanhados para verificar como afetam o projeto e para se tomar aes,
mesmo que ainda sem um gerenciamento completo;
GPR 7. Os recursos humanos para o projeto so planejados considerando o perfil

e o conhecimento necessrios para execut-lo: o planejamento de recursos humanos
inclui informaes de como e quando o recurso ser envolvido no projeto, critrios
para sua liberao, competncia necessria para a execuo das atividades, mapa de
competncias da equipe e identificao de necessidades de treinamento. A existncia
de registros das necessidades e disponibilidade evita a alocao com base em critrios
subjetivos. Este resultado esperado possui dois pontos principais: (a) planejamento
prvio das necessidades de pessoal em relao a competncias (conhecimento,
habilidades, atitudes e experincias); (b) a alocao dos recursos humanos ao projeto
de acordo com o planejamento realizado;
GPR 8. Os recursos e o ambiente de trabalho necessrio para executar o projeto

so planejados: Este resultado faz referncia necessidade de se planejar, com base
na EAP (ou estrutura equivalente), as tarefas previstas, os recursos e o ambiente
necessrios,
incluindo,
por
exemplo,
equipamentos,
ferramentas,
servios,
componentes, viagens e requisitos de processo (processos especiais para o projeto).
22
GPR 9. Os dados relevantes do projeto so identificados e planejados quanto

forma de coleta, armazenamento e distribuio. Um mecanismo estabelecido
para acess-los, incluindo, se pertinente, questes de privacidade e segurana: os
dados do projeto so as vrias formas de documentao exigidas para sua execuo,
por exemplo: relatrios; dados informais; estudos e anlises; atas de reunies;
documentao; lies aprendidas; artefatos gerados; itens de ao; e indicadores. Os
dados podem estar em qualquer formato e existir em qualquer meio, como: impressos
ou desenhados em diversos materiais; fotografias; meio eletrnico; e multimdia.
importante identificar os dados relevantes do projeto, para depois colet-los,
armazen-los e distribu-los de forma controlada, mesmo que isso gere custos;
GPR 10. Um plano geral para a execuo do projeto estabelecido com a

integrao de planos especficos: o objetivo deste resultado esperado garantir que
todos os planos que afetam o projeto estejam integrados e que a dependncia entre
estes planos tenha sido identificada e levada em considerao durante o planejamento.
A reunio dos documentos (cronograma de atividades, o planejamento de recursos
humanos, custos, riscos, dados etc) entendida como sendo o Plano de Projeto. O
monitoramento efetivo do projeto depender de uma organizao adequada destas
informaes de planejamento. Ao longo do projeto, elas devero ser comparadas aos
dados obtidos durante sua execuo, em busca de uma maior visibilidade do
andamento do projeto;
GPR 11. A viabilidade de atingir as metas do projeto explicitamente avaliada

considerando restries e recursos disponveis. Se necessrio, ajustes so
realizados: o estudo de viabilidade considera o escopo do projeto e examina aspectos
tcnicos (requisitos e recursos), financeiros (capacidade da organizao) e humanos
(disponibilidade de pessoas com a capacitao necessria). No incio do projeto, uma
avaliao preliminar pode ser conduzida, a partir da viso geral dos objetivos e
caractersticas dos resultados pretendidos, dos recursos financeiros, tcnicos e
humanos. medida que o projeto evolui, as mudanas de requisitos so eventos que
podem levar necessidade de reavaliar a viabilidade do projeto;
GPR 12. O Plano do Projeto revisado com todos os interessados e o

compromisso com ele obtido e mantido: para obter compromissos dos interessados
23
relevantes, importante revisar o planejamento com eles e conciliar as diferenas
existentes entre os recursos estimados e disponveis. A integrao dos planos e o
planejamento global dos recursos da organizao contribuem para a resoluo prvia
de conflitos envolvendo, por exemplo, a alocao de profissionais compartilhados em
diferentes projetos ou a conciliao de datas de profissionais das reas de apoio (por
exemplo, Garantia da Qualidade e Gerncia de Configurao). A soluo dos conflitos
e estabelecimento de compromissos fundamental para que o projeto possa
efetivamente contar com os recursos planejados, para atingir as metas definidas;
GPR 13. O escopo, as tarefas, as estimativas, o oramento e o cronograma do

projeto so monitorados em relao ao planejado: os resultados e os critrios de
concluso de cada tarefa so analisados, as entregas so avaliadas em relao s suas
caractersticas (por meio de revises e auditorias, por exemplo), a aderncia ao
cronograma e o dispndio de esforos so examinados, bem como o uso dos recursos.
Esta uma atividade essencial de gerenciamento: acompanhar o que foi planejado,
detectar problemas e corrigi-los. O objetivo deste resultado esperado assegurar que
haja monitorao do projeto em relao a aspectos relacionados s tarefas, estimativas,
oramento e cronograma (vide GPR2, GPR3, GPR4, GPR5). Em geral, durante um
monitoramento, faz-se uma anlise do que foi planejado anteriormente com os valores
atuais das variveis consideradas;
GPR 14. Os recursos materiais e humanos bem como os dados relevantes do

projeto so monitorados em relao ao planejado: o objetivo deste resultado
esperado garantir que o projeto seja monitorado em relao aos itens planejados
referentes a recursos materiais e recursos humanos (ver GPR7 e GPR8). Por exemplo,
a sada de um membro da equipe pode disparar a alocao de uma nova pessoa. Da
mesma forma, pode ser necessria a compra de novos equipamentos ou softwares ao
longo da execuo do projeto. Outro ponto a ser considerado identificar se novos
documentos devem ser includos no repositrio do projeto ou se os produtos de
trabalho intermedirios do projeto esto de fato sendo produzidos e armazenados
adequadamente. Em todo o caso, o planejamento do projeto deve ser revisto para
adequao dos itens pertinentes. Caso seja necessrio, planos de ao devem ser
gerados (ver GPR18 e GPR19) para corrigir problemas ou evitar que outros problemas
aconteam posteriormente;
24
GPR 15. Os riscos so monitorados em relao ao planejado: no decorrer do

projeto novos riscos podem ser identificados e os parmetros dos riscos j
identificados podem ser alterados (vide GPR6). Alm disso, pode ser necessrio
executar aes de mitigao para evitar que os riscos aconteam ou, no caso de riscos
terem se concretizado, pode ser preciso executar aes de contingncia para minimizar
seus efeitos. A lista de riscos deve ser reavaliada periodicamente em conjunto com
uma avaliao dos seus parmetros de anlise (probabilidade e impacto) e prioridade;
GPR 16. O envolvimento das partes interessadas no projeto planejado,

monitorado e mantido: devem ser identificados os interessados relevantes no projeto,
em que fases eles so importantes e como eles sero envolvidos (comunicaes,
revises em marcos de projeto, comprometimentos, entre outros). Uma vez
identificado e planejado o envolvimento, este dever ser seguido, monitorado e
mantido ao longo de todo o projeto. A comunicao envolve, por exemplo, questes
relativas a prazos, custos, recursos, comprometimentos e tambm requisitos, pois estes
afetam as outras variveis. Um plano de gerenciamento das comunicaes pode cobrir
este resultado esperado;
GPR 17. Revises so realizadas em marcos do projeto e conforme estabelecido

no planejamento: revises em marcos do projeto no devem ser confundidas com o
acompanhamento descrito em GPR13, GPR14 e GPR15, que derivado do
acompanhamento do dia-a-dia do projeto. Os marcos do projeto precisam, portanto,
ser previamente definidos ao se realizar o planejamento do projeto. Este resultado
importante porque as revises em marcos so oportunidades para verificar, de forma
ampla, o andamento de todo o projeto, independente do acompanhamento do dia-a-dia.
Em projetos grandes essas revises so fundamentais, questionando, inclusive, a
viabilidade de continuidade do projeto. Alm das revises em marcos, outras revises
podero ser estabelecidas no planejamento do projeto;
GPR 18. Registros de problemas identificados e o resultado da anlise de questes

pertinentes, incluindo dependncias crticas, so estabelecidos e tratados com as
partes interessadas: as atividades de reviso em marcos (GPR17) e de
monitoramento (GPR13, GPR14 e GPR15) do projeto possibilitam a identificao de
problemas que estejam ocorrendo nos projetos. Estes problemas e desvios devem ser
25
analisados e registrados, por exemplo, por meio de ferramentas especficas, planilhas
ou outros tipos de mecanismos de gerenciamento de problemas. Para completar o
trabalho de monitoramento do projeto, os problemas precisam ser corrigidos e
gerenciados at a sua resoluo, com base em planos de aes, estabelecidos
especificamente para resolver os problemas levantados e registrados (GPR19). Caso
no se consiga resolver os problemas neste nvel, deve-se escalonar a resoluo das
aes a nveis superiores de gerncia;
GPR 19. Aes para corrigir desvios em relao ao planejado e para prevenir a
repetio dos problemas identificados so estabelecidas, implementadas e
acompanhadas at a sua concluso: como resultado do acompanhamento do projeto
(GPR13, GPR14 e GPR15) e das revises em marcos (GPR17), problemas so
identificados, analisados e registrados (GPR18). Aes corretivas devem ser
estabelecidas para resolver problemas que possam impedir o projeto de atingir seus
objetivos se no forem resolvidos de forma adequada. As aes corretivas definidas
devem ser gerenciadas at serem concludas. Acompanhar o andamento de uma ao
corretiva at sua concluso inclui verificar, com uma certa frequncia, se ela j foi
resolvida e atuar em possveis pendncias. Caso no se consiga resolver neste nvel,
deve-se escalonar a resoluo das aes a nveis superiores de gerncia. As aes
corretivas estabelecidas podem ser reportadas para a gerncia de alto nvel da
organizao e para os interessados no projeto, como clientes e usurios.
1.3
MODELO DE AVALIAO: MA-MPS
O propsito do Processo e Mtodo de Avaliao MA-MPS verificar a maturidade da

unidade organizacional na execuo de seus processos de software. O processo de avaliao
descreve o conjunto de atividades e tarefas a serem realizadas para atingir este propsito. Ele
tem incio com a seleo de uma Instituio Avaliadora (IA) e encerra com o registro dessa
avaliao na base de dados confidencial da SOFTEX (SOFTEX, 2012c). O patrocinador pode
ser um representante da alta gerncia da unidade organizacional a ser avaliada, ou de outra
organizao que solicita a avaliao da unidade organizacional por uma terceira parte para
fins de contrato.
O Processo e o Mtodo de Avaliao MA-MPS foram definidos de forma a (SOFTEX,
2012c):
26
Permitir a avaliao objetiva dos processos de software de uma organizao/unidade

organizacional;
Permitir a atribuio de um nvel de maturidade do MR-MPS com base no resultado

da avaliao;
Ser aplicvel a qualquer domnio na indstria de software;
Ser aplicvel a organizaes/unidades organizacionais de qualquer tamanho.
O processo de avaliao composto de 4 subprocessos:
Subprocesso 1: Contratar a avaliao;
Subprocesso 2: Preparar a realizao da avaliao;
Subprocesso 3: Realizar a avaliao final;
Subprocesso 4: Documentar os resultados da avaliao.
Como resultado da execuo deste processo:
So obtidos dados e informaes que caracterizam os processos de software da

organizao/unidade organizacional;
determinado o grau em que os resultados esperados so alcanados e os processos

atingem o seu propsito;
atribudo um nvel de maturidade do MR-MPS organizao/unidade

organizacional.
Para alcanar os resultados previstos para a execuo do processo de avaliao de uma

organizao com domnio de software necessrio executar um conjunto de tarefas que esto
agrupadas dentro de cada subprocesso. A Tabela 2 mostra as atividades que compem o
processo de avaliao do MPS.BR. Por se tratar de um processo longo que envolve desde a
busca de instituies que executam as avaliaes, passando pela contratao e preparao da
avaliao, este trabalho ir detalhar apenas a parte da avaliao que trata da anlise dos
27
artefatos e responsabilidades de um projeto que est sendo avaliado, no caso ser considerado
a avaliao do Framework Scrum (Captulo 3) na sua essncia.
Tabela 2 Detalhe do Processo de Avaliao. Elaborada pelo autor com base em
Softex (2012c)
SUBPROCESSO
Contratar
avaliao
Preparar
realizao
avaliao(*)
Processo de Avaliao
ATIVIDADE
a Pesquisar Instituies Avaliadoras
Estabelecer contrato
a Viabilizar a avaliao
da Planejar a avaliao
Preparar a avaliao
Conduzir a avaliao inicial
Completar a preparao da avaliao
Realizar
a Conduzir a avaliao final
avaliao final (*)
Avaliar a execuo do processo de avaliao
Documentar
os Relatar os resultados
resultados
da Registrar resultados
avaliao
(*) Apenas estes subprocessos sero detalhados neste trabalho
1.3.1
Subprocesso Preparar a Realizao da Avaliao
O propsito deste subprocesso planejar a avaliao, preparar a documentao necessria e

fazer uma avaliao inicial que permita verificar se a Unidade Organizacional (UO) est
pronta para a avaliao no nvel de maturidade pretendido. A Figura 2 ilustra o detalhe do
subprocesso e os artefatos de entrada de sada.
28
Figura 2 - Subprocesso Preparar a Realizao da Avaliao (FALBO, 2008, p. 60)

1.3.1.1 Atividade Viabilizar a Avaliao
Esta atividade possui como objetivo participar SOFTEX a contratao da Instituio
Avaliadora (IA) para uma avaliao MPS.BR e obter aprovao para a sua realizao.
A atividade possui as seguintes tarefas:
Comunicar SOFTEX a contratao da avaliao;
Analisar a composio da equipe de avaliao e indicar o auditor da avaliao:

o No mnimo 3 pessoas: 1 Avaliador Lder; 1 ou mais Avaliadores Adjuntos; 1 ou mais
Representante da Unidade Organizacional;
o Deve ter assistido ao Curso Oficial de Introduo ao MPS.BR.
o Deve ter experincia em desenvolvimento de software, preferencialmente em

gerncia de projetos;
o No pode ser superior hierrquico dos participantes da avaliao;
o No pode ter tido participao significativa em nenhum dos projetos que sero
avaliados;
29
Solicitar unidade organizacional participao de avaliador em formao;
Pagar contribuio SOFTEX;
Autorizao a realizao da avaliao;
1.3.1.2 Atividade Planejar a Avaliao

Esta atividade tem como objetivo elaborar o plano de avaliao a ser seguido para se realizar
a avaliao na unidade organizacional.
Enviar modelo do Plano de Avaliao e modelo da Planilha para Seleo de Projetos

unidade organizacional:
o Projetos devem ser representativos tanto em termos de processos quanto em termos
de negcio da unidade organizacional:
Uma avaliao MPS considera uma amostra composta, normalmente, de dois (2) a
quatro (4) projetos. Nvel G: pelo menos 1 projeto concludo e 1 em andamento a
partir da implementao do MR-MPS na UO definida no escopo da avaliao. Para
os nveis F e superiores: pelo menos 2 projetos concludos e 2 em andamento a
partir da implementao do MR-MPS na UO definida no escopo da avaliao.
Caso necessrio, podem ser includos mais um ou dois projetos para evidenciar
algum resultado ou para ter uma amostragem mais adequada da UO avaliada.
Planejar a avaliao inicial, o que inclui: preencher os dados da unidade organizacional e

dos projetos selecionados para avaliao, confirmar a data da avaliao, definir quais
sero as tarefas da avaliao inicial e seu cronograma. A avaliao inicial presencial
obrigatria para todos os nveis de maturidade.
1.3.1.3 Atividade Preparar a Avaliao

O principal objetivo desta atividade preencher a planilha com os indicadores (evidncias)
que comprovem a implementao dos processos e que ser utilizada na avaliao.
30
Esta atividade possui as seguintes tarefas:
Enviar modelo da Planilha de Indicadores e Acordo de Confidencialidade Unidade

Organizacional;
Preencher Planilha de Indicadores;

o Indicadores de implementao evidenciam que os resultados foram alcanados e que
as atividades foram realizadas. Podem ser de trs tipos:
Indicadores Diretos: So o objetivo de uma atividade. Tipicamente artefatos

produzidos no processo;
Indicadores Indiretos: So utilizados para confirmar que a organizao tem

condies de implementar um resultado. Tipicamente so documentos que indicam
que a atividade pode ser realizada. Ex.: Um modelo de documento.
Afirmaes: So obtidas de entrevistas ou apresentaes e confirmam a

implementao do processo, seus resultados e atributos.
Para cada resultado esperado de um processo ou atributo de processo a ser avaliado,

em cada projeto, deve existir pelo menos um indicador direto e um indireto (ou
afirmao) que comprovem que o resultado foi alcanado.
1.3.1.4 Atividade Conduzir a Avaliao Inicial

Esta atividade tem como objetivo realizar a avaliao inicial dos indicadores e verificar se a
unidade organizacional est pronta para a avaliao MR-MPS.
A atividade possui as seguinte tarefas:
Assinar comprometimento com o Plano de Avaliao de Avaliao;
Assinar o Acordo de Confidencialidade;
Treinar Equipe de Avaliao para a Avaliao Inicial;
31
o Mini-equipes: verificam os indicadores. As mini-equipes formadas, cada uma por 2
membros da equipe, devem ser definidas de acordo com a sua experincia e perfil.
o O avaliador lder pode fazer parte de uma das mini-equipes de avaliao ou verificar
um ou mais processos sozinho. Pode, tambm, no avaliar nenhum processo,
dedicando o seu tempo a apoiar as mini-equipes.
Apresentar os processos da Unidade Organizacional;
Verificar os Indicadores de Implementao;
Analisar os dados da avaliao inicial;
Enviar ao auditor a documentao da avaliao inicial;
Auditar a Avaliao Inicial;
Realizar ajustes na documentao da avaliao inicial:

o Um Relatrio de Avaliao Inicial produzido, indicando os ajustes requeridos;
o Com o relatrio, o avaliador lder completa o Plano de Avaliao que ser assinado
pelo patrocinador e pelo coordenador local, formalizando o comprometimento.
o A data da avaliao poder ser at 6 meses aps a avaliao inicial. Durante esse
perodo, a UO deve realizar os ajustes obrigatrios indicados.
1.3.1.5 Atividade Completar a preparao da avaliao

Esta atividade tem como objetivo completar o planejamento da avaliao final e realizar os
ajustes indicados no Relatrio de Avaliao Inicial dos indicadores.
Completar Plano de Avaliao;
32
Realizar Ajustes.
1.3.2
Subprocesso Realizar a Avaliao Final
O propsito deste subprocesso treinar a equipe para a avaliao final, conduzir a avaliao
final, comunicar seus resultados UO avaliada e avaliar a execuo do processo de avaliao
na UO. A Figura 3 ilustra as atividades que compem este subprocesso.
Figura 3 - Subprocesso Realizar a Avaliao Final (FALBO, 2008, p. 63)
1.3.2.1 Atividade Conduzir a Avaliao Final

O propsito do subprocesso Realizar a avaliao final treinar a equipe para a realizao da
avaliao final, conduzir a avaliao final, comunicar seus resultados unidade organizacional
avaliada e avaliar a execuo do processo de avaliao na unidade organizacional. A atividade
"Conduzir Avaliao Final" composta por vrias tarefas a saber:
Realizar Reunio de Abertura;
Assinar Comprometimento com o Plano de Avaliao;
Completar assinaturas do Acordo de Confidencialidade;
Treinar equipe para avaliao fina;
33
Verificar Evidncias: a avaliao feita com base nos indicadores (diretos, indiretos e
afirmaes). A equipe de avaliao pode solicitar mais documentos quando um
entrevistado menciona um documento no disponvel para a equipe de avaliao ou
quando a equipe nota a falta de uma evidncia direta necessria avaliao.
Realizar Entrevistas: um dos mais importantes componentes de uma avaliao MPS.

Mostram o grau em que os colaboradores da organizao entendem e usam os processos.
Podem ser individuais ou em grupo. Se guarda rigorosa confidencialidade das entrevistas:
Nenhuma informao atribuda a uma pessoa individualmente.
Registrar afirmaes na Planilha de Indicadores;
Caracterizar o grau de implementao de cada resultado esperado do processo e de cada

resultado do atributo do processo em cada projeto. Deciso para cada projeto e processo,
vide Tabela 3:
Tabela 3 - Escala para caracterizao do grau de implementao de um resultado
esperado do processo e de um resultado esperado de atributo do processo nos
projetos (SOFTEX, 2012c, p. 60)
34
Caracterizar o grau de implementao de cada resultado esperado do processo e de cada

resultado do atributo do processo na unidade organizacional, vide Tabela 4.
Tabela 4 - Regras para agregar a caracterizao dos resultados esperados dos
processos e dos resultados esperados de atributos do processo nos projetos e chegar
caracterizao da unidade organizacional (SOFTEX, 2012c, p. 62)
Caracterizar, inicialmente, o grau de implementao de cada atributo do processo na

unidade organizacional, vide Tabela 5.
35
Tabela 5 - Regras para caracterizar o grau de implantao dos atributos do processos
na unidade organizacional (SOFTEX, 2012c, p. 64)
Caracterizar o grau de implementao, na unidade organizacional, de cada resultado

esperado do processo, de cada resultado esperado de atributo do processo e de cada
atributo do processo em reunio de consenso;
Caracterizar o grau de implementao dos processo na unidade organizacional. A equipe

de avaliao por meio de consenso, caracteriza o grau de implementao de cada
processo na unidade organizacional como SATISFEITO ou NO SATISFEITO. Um
processo est SATISFEITO quando:
o Todos os resultados esperados para o processo foram caracterizados como T
(Totalmente Implementado) ou L (Largamente Implementado);
o A caracterizao dos atributos de processo satisfaz s exigncias de acordo com a

Tabela 6;
o Em qualquer outra situao o processo caracterizado como NO SATISFEITO.
36
Tabela 6 - Caracterizao de atributos de processos para satisfazer aos nveis MRMPS (SOFTEX, 2012c, p. 67)
Apresentar pontos fortes, pontos fracos e oportunidades de melhoria;
Rever a caracterizao e finalizar a redao dos pontos fortes, pontos fracos e

oportunidades de melhoria;
Atribuir nvel MR-MPS: A atribuio do nvel de maturidade feita a uma UO se cada

processo pertencente quele nvel e includo no escopo da avaliao tiver sido
caracterizado como SATISFEITO. A UO pode ter solicitado um Nvel MR-MPS e lhe ser
atribudo um nvel inferior.
Organizar ambiente de trabalho da avaliao;
Comunicar o resultado da avaliao ao patrocinador;
Comunicar o resultado da avaliao aos colaboradores da unidade organizacional.
1.3.2.2 Atividade Avaliar a execuo do processo de avaliao

Esta atividade tem como objetivo avaliar a execuo da avaliao na unidade organizacional de
forma a fornecer feedback SOFTEX acerca do Processo e Mtodo de Avaliao MA-MPS. Esta
atividade composta pelas seguintes tarefas:
37
Avaliar a execuo da avaliao pela equipe de avaliao;
Avaliar a execuo da avaliao pelo patrocinador;
Avaliar a execuo da avaliao pelo coordenador da IA (opcional);
Avaliar a execuo da avaliao pelo coordenador da Instituio Organizadora do Grupo

de Empresas (se pertinente e opcional);
Avaliar a execuo da avaliao pela Instituio Implementadora (se pertinente e

opcional).
1.4
CONSIDERAES FINAIS
O MPS.BR tem como objetivo padronizar e disciplinar um conjunto de boas de prticas de

desenvolvimento de software. Para isto, o modelo organizado e detalha a implementao de
vrios processos, desde processo de Gerncia de Projetos, at processo de Gerncia de
Configurao e Aquisio. Para que uma unidade organizacional de desenvolvimento de
software de qualquer porte se adeque ao modelo MPS.BR necessrio que a mesma atinja os
resultados esperados exigidos dentro de cada um dos processos. Para se tornar, oficialmente,
uma unidade organizacional que trabalha e executa seus processos dentro do padro exigido
pelo MPS.BR preciso ser avaliada por uma instituio avaliadora utilizando o guia de
avaliao MA-MPS.
O MA-MPS detalha o passo a passo para avaliar uma unidade
organizacional e mostra quais resultados esperados devem ser alcanados para atingir o
objetivo e se tornar certificada em um nvel de maturidade do MPS.BR.
38
METODOLOGIA GIL SCRUM
O Scrum uma metodologia gil de Gerenciamento de Projetos. As metodologias geis

permitem responder rapidamente s mudanas, pois focado nas pessoas e indicado para
ambientes em que os requisitos surgem e mudam rapidamente, reduzindo o impacto das
mudanas nos projetos, permitindo inclusive mudanas tardias nos requisitos ou mesmo no
escopo do projeto. O cliente fica mais satisfeito, pois constantemente h entrega de
funcionalidades 100% desenvolvidas, e ele participa ativamente no projeto, trazendo seu
conhecimento sobre o prprio negcio.
O papel do Scrum fazer transparecer a eficcia relativa das suas prticas de
desenvolvimento para que voc possa melhor-las, enquanto prov um framework, dentro do
qual, produtos complexos podem ser desenvolvidos (SCHWABER e SUTHERLAND, 2010).
O nome Scrum vem do jogo de rugby, esporte semelhante ao futebol, com bola
oval e jogado tambm com as mos. No rugby, o scrum utilizado para reposio da bola,
aps faltas ou penalidades. Oito jogadores de cada equipe posicionam-se frente frente,
formando um crculo. Um jogador da equipe que no cometeu a infrao lana a bola no
espao entre os jogadores alinhados que tentam, com os ps, ganhar a bola para isso, a
grupo deve trabalhar em conjunto, como se fosse uma unidade. A utilizao da palavra Scrum
associada ao desenvolvimento de produtos foi feita primeira vez por Takeuchi e Nonaka, no
livro
The New Product Development Game (TAKEUCHI e NONAKA, 1986), onde os
autores defendem a idia de que no desenvolvimento toda a equipe deve trabalhar como uma
unidade para atingir um objetivo comum, como no scrum do rugby (SCHWABER e
SUTHERLAND, 2010).
Apesar de muito utilizado no desenvolvimento de software, o scrum foi criado
para gerenciamento de projetos de fabricao de automveis e produtos de consumo. Sua
popularizao no desenvolvimento de software ocorreu em 1995, aps a formalizao de sua
definio, feita por Ken Schwaber (SCHWABER e SUTHERLAND, 2010). O scrum pode ser
utilizado sempre que um grupo de pessoas precise trabalhar em conjunto para atingir um
objetivo comum, desde o gerenciamento de projetos de software at tarefas do cotidiano,
como organizar uma festa.
39
O Scrum como uma metodologia gil, aceita que o desenvolvimento de software
seja imprevisvel e formaliza a abstrao, sendo aplicvel a ambientes volteis. uma
abordagem emprica baseada na flexibilidade, adaptabilidade e produtividade em que a
escolha das tcnicas de desenvolvimento fica a cargo do time (MARAL, 2009). O Scrum
destaca-se dos demais pela maior nfase dada ao gerenciamento do projeto e rene atividades
de monitoramento e feedback, em geral, reunies rpidas e dirias com toda a equipe, visando
a identificao e correo de quaisquer deficincias e/ou impedimentos no processo de
desenvolvimento.
O Scrum assume a premissa de que o desenvolvimento de software muito
complexo e imprevisvel para ser planejado totalmente no seu incio e que ao invs de
realizarmos um planejamento detalhado prescritivo do projeto, deve-se usar o modelo
emprico de controle de processos para garantir a visibilidade, inspeo e adaptao do
planejamento do projeto. O mtodo baseia-se ainda, em princpios como: equipes pequenas de
no mximo 7 pessoas; requisitos que so pouco estveis ou desconhecidos; com ciclos curtos
em que divide o desenvolvimento em intervalos de tempos de no mximo 30 dias, tambm
chamados de Sprints.
1
PAPIS
O Scrum implementa um esqueleto iterativo e incremental atravs de trs papis
principais (SCHWABER e SUTHERLAND, 2010):
Scrum Master: responsvel por garantir que Scrum seja entendido e aplicado por todos
os outros papis e verifica se eles esto aderindo aos valores do Scrum, s prticas e s
regras; ajuda o Time e a organizao a adotarem o Scrum; educa o Time treinando-o e
levando-o a ser mais produtivo e a desenvolver produtos de maior qualidade; ajuda o Time
a entender e usar auto-organizao e multidisciplinaridade. O Scrum Master tambm ajuda
o Time a fazer o seu melhor em um ambiente organizacional que pode ainda no ser
otimizado para o desenvolvimento de produtos complexos. Quando o Scrum Master ajuda
a realizar essas mudanas, isso chamado de remoo de impedimentos. O papel de
Scrum Master o de lder-servidor para o Time do Scrum. Quando o Scrum Master
trabalha para o Product Owner, o Scrum Master serve o Product Owner de vrias maneiras,
por exemplo: a) Encontra tcnicas para o gerenciamento efetivo do Backlog do Produto; b)
Claramente comunica a viso, objetivo e itens do Backlog do Produto para o Time; c)
40
Ensina o Time a criar itens de Backlog do Produto de forma clara e concisa; d)
Compreende a longo-prazo o planejamento do Produto no ambiente emprico e etc.
Quando o Scrum Master trabalha para o Time, o Scrum Master serve o Time de vrias
maneiras, incluindo: a) Treinar Time em auto-gerenciamento e interdisciplinaridade; b)
Ensinar e liderar o Time na criao de produtos de alto valor; c) Remover impedimentos
para o progresso do Time;
Product Owner: ou dono do produto, a pessoa responsvel pelo gerenciamento do

Product Backlog (do ingls Backlog do Produto ou lista dos requisitos do sistema) e por
garantir o valor do trabalho realizado pelo Time. Essa pessoa mantm o Backlog do
Produto e garante que ele est visvel para todos. O gerenciamento do Backlog do Produto
inclui: a) Expressar claramente os itens do Backlog do Produto; b) Ordenar os itens do
Backlog do Produto para alcanar melhor as metas e misses; c) Garantir o valor do
trabalho realizado pelo Time; d) Garantir que o Backlog do Produto seja visvel,
transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e, e)
Garantir que a Time entenda os itens do Backlog do Produto no nvel necessrio
(SCHWABER e SUTHERLAND, 2010). Todos sabem quais itens tm a maior prioridade,
de forma que todos sabem em que se ir trabalhar. O Product Owner uma pessoa, e no
um comit. Podem existir comits que aconselhem ou influenciem essa pessoa, mas quem
quiser mudar a prioridade de um item, ter que convencer o Product Owner. As empresas
que adotam Scrum podem perceber que isso influencia seus mtodos para definir
prioridades e requisitos ao longo do tempo. Para que o Product Owner obtenha sucesso,
todos na organizao precisam respeitar suas decises. Ningum tem a permisso de dizer
ao Time para trabalhar em um ou outro conjunto de prioridades, e os Times no podem dar
ouvidos a ningum que diga o contrrio. As decises do Product Owner so visveis no
contedo e na priorizao do Backlog do Produto. Essa visibilidade requer que o Product
Owner faa seu melhor, o que faz o papel de Product Owner exigente e recompensador ao
mesmo tempo;
Team (em portugus, Time, Equipe de Desenvolvimento): transforma o Product Backlog

em incrementos de funcionalidades potencialmente entregveis (do ingls, releases) em
cada Sprint (iterao do ciclo de execuo). Apenas integrantes do Time geram
incrementos de funcionalidades e so multidisciplinares, ou seja, devem possuir todo o
conhecimento necessrio para criar um incremento no trabalho. Os Times tambm no
41
contm subtimes dedicados a reas particulares como testes ou anlise de negcios, so
auto-organizveis; ningum nem mesmo o Scrum Master diz ao time como transformar
o Product Backlog em incrementos de funcionalidades entregveis. O Time descobre por si
s. Cada membro do Time aplica sua especialidade a todos os problemas. A sinergia que
resulta disso melhora a eficincia e eficcia geral do Time como um todo (SCHWABER e
SUTHERLAND, 2010). O tamanho ideal para um Time de sete pessoas. Quando h
menos do que cinco membros em um Time, h menor interao e, como resultado, h
menor ganho de produtividade. Mais do que isso, o time poder encontrar limitaes de
conhecimento durante partes da Sprint e no ser capaz de entregar uma parte pronta do
produto. Se h mais do que nove membros, h simplesmente a necessidade de muita
coordenao. Os times grandes geram muita complexidade para gerenciar um processo
emprico. O Product Owner e o Scrum Master no esto includos nessa conta, a menos
que tambm estejam trabalhando em tarefas do Sprint Backlog. A composio do Time
pode mudar ao final da Sprint. Toda vez que o Time muda, a produtividade ganha atravs
da auto-organizao reduzida.
2
GERNCIA DE PROJETOS NO SCRUM

O Scrum define conceitos importantes referentes aplicao do processo no
perodo do projeto. Esses conceitos fundamentam prticas importantes para definir a

estratgia de inspeo e adaptao do projeto, fornecendo uma excelente visibilidade do
andamento dos trabalhos, juntamente com uma importante previsibilidade do que acontecer
no futuro.
1
Artefatos
Conforme Schwaber (SCHWABER e SUTHERLAND, 2010), o Scrum introduz
alguns importantes artefatos utilizados ao longo do ciclo de execuo do projeto:
Product Backlog (do portugus, Backlog do Produto): o Backlog do Produto uma

lista ordenada de tudo que deve ser necessrio no produto, e uma origem nica
dos requisitos para qualquer mudana a ser feita no produto. O Product Owner
responsvel pelo Backlog do Produto, incluindo seu contedo, disponibilidade e
ordenao. Deve estar priorizado por ordem de importncia para o negcio. O
Backlog do Produto dinmico; mudando constantemente para identificar o que o
42
produto necessita para ser mais apropriado, competitivo e til e existir enquanto o
produto tambm existir. Este o artefato mais importante utilizado dentro da
metodologia (MAGNO, 2009). atravs dele que o Product Owner ir determinar
ao Time de desenvolvimento o que deve ser desenvolvido e em qual ordem para
que ele possa atingir o mximo de retorno de investimento com o sistema em
menor tempo possvel;
Sprint Backlog: um conjunto de itens do Backlog do Produto selecionados para a

Sprint, juntamente com o plano de entrega do incremento do produto (release) para
atingir o objetivo da Sprint. O Backlog da Sprint a previso do Time sobre qual
funcionalidade estar no prximo incremento e do trabalho necessrio para
entregar a funcionalidade. O Backlog da Sprint define qual trabalho o Time
realizar para converter os itens do Backlog do Produto em um incremento
Pronto. Sempre que um novo trabalho necessrio, o Time adiciona este ao
Backlog da Sprint. Conforme o trabalho realizado ou completado, a estimativa do
trabalho restante atualizada. Quando elementos do plano so considerados
desnecessrios, eles so removidos. Somente o Time pode alterar o Backlog da
Sprint durante a Sprint;
Impediment Backlog: contm todos os itens que impedem o progresso do projeto e

geralmente esto associados a riscos. Estes itens podem possuir uma priorizao,
mas esto geralmente associados a algum item do Product Backlog ou a tarefas do
item (NEPONUCENO, ALVES e ALMEIDA, 2010). O controle desses itens
muito importante e o Scrum Master o grande responsvel pela liberao desses
impedimentos, abrindo caminho para o time de desenvolvimento executar a
realizao dos itens do Product Backlog;
Incremento de Funcionalidade do Produto (do ingls, Release): o time dever

entregar incrementos de funcionalidade a cada
Sprint. Os incrementos de
funcionalidade consistem de cdigos testados, bem estruturados e bem escritos,

que so executveis acompanhados da documentao necessria para a sua
operao (MARAL, 2009);
43
Quadro de Tarefas (Kanban): Quadro de trabalho onde o time organiza as

atividades, dos itens do Sprint Backlog, separando-as basicamente em cinco
estados: Para fazer, Em andamento (inclui o nome do responsvel por executar a
tarefa), Para Verificar, Pendente e Concludo. Este quadro muito prtico e
produtivo, pois facilmente pode-se realizar uma leitura do progresso do andamento
da Sprint, inclusive nele pode-se indicar se existe algum impedimento para que as
atividades sejam executadas conforme planejado (MARAL, 2009).
Ciclo de Execuo do Projeto no Scrum

Um projeto no Scrum se inicia com uma viso do produto que ser desenvolvido. A
viso contm a lista das caractersticas do produto estabelecidas pelo cliente (Product
Backlog), alm de algumas premissas e restries. Em seguida, o Product Backlog criado
contendo a lista de todos os requisitos conhecidos. O Product Backlog ento priorizado e
dividido em releases (SCHWABER e SUTHERLAND, 2010). A Figura 4 ilustra o ciclo de
execuo do Scrum e mostra os artefatos e principais planejamentos.
Reuni
es
Diria
s
Spri
nt
24 Horas
Product Backlog
Sprint Backlog
Incremento
do Produto
2-4 Semanas
Figura 4 - Ciclo de Execuo do Scrum. Elaborada pelo autor.

O Scrum planejado e executado em torno de iteraes chamadas de Sprints
conforme detalhado a seguir:
Sprint: uma iterao com durao fixa que pode durar de duas a quatro semanas
conforme o planejamento do projeto e durante a execuo da Sprint que a verso
44
incremental do produto (release) criada. Uma nova Sprint comea imediatamente aps a
concluso da anterior. Durante a Sprint, o Scrum Master garante que no ser feita
nenhuma mudana que possa afetar a meta da Sprint. Tanto a composio do time quanto
as metas de qualidade devem permanecer constantes durante a Sprint. O conceito de Sprint
nos remete necessidade de estarmos frequentemente entregando algo de valor para o
cliente. Diferentemente dos modelos tradicionais, onde voc desenvolve o produto em um
longo perodo de tempo e apenas no final, com o produto pronto, o entrega ao cliente, no
Scrum, voc sempre entregar parte do produto em pequenos intervalos de tempo, sendo
que esta parte a prioridade do cliente, ou seja, o que ele realmente est precisando
naquele momento. Uma Sprint composta das seguintes etapas:
o Planejamento (Sprint Planning Meeting): reunio que ocorre no incio de um
projeto com a presena do Product Owner, do Scrum Master e do Time. Para
uma Sprint de quatro de semanas, o recomendado que esta reunio tenha
durao de 8 (oito) horas, para Sprints menores o tempo reduzido
proporcionalmente. A reunio dividida em duas partes e respondem
objetivamente: o que ser entregue como resultado do incremento da prxima
Sprint (o Product Owner apresenta os requisitos de maior valor e prioriza
aqueles que devem ser implementados) e como o trabalho necessrio para
entregar o incremento ser realizado;
o Execuo: Durante a execuo do Sprint, para cada histria ou requisito todo o
time participa do processo de estimativa, podendo ser utilizado o Planning
Poker para a obteno de tais estimativas. O time controla o andamento do
desenvolvimento, realizando reunies dirias rpidas (Daily Meeting), no
mais que 15 minutos de durao. Quando no se consegue desenvolver um
incremento completo dentro de uma Sprint, surgem duas categorias de
incremento: o trabalho pronto e o trabalho no pronto. O trabalho no
pronto a poro de cada incremento que ter que ser completada mais tarde.
Nestas reunies dirias, cada membro do time responde a trs perguntas
bsicas: O que eu fiz no projeto desde a ltima reunio? O que irei fazer at a
prxima reunio? Quais so os impedimentos? O Product Owner sabe
exatamente o que ele est inspecionando ao final da Sprint, porque o
incremento atende definio de pronto e o Product Owner entende essa
45
definio. O trabalho no pronto adicionado a um item do Product
Backlog, de forma que ele se acumula. O progresso do Sprint observando
usando um grfico chamado Sprint Burndown (conforme a Figura 5), que
mostra ao longo do tempo a quantidade de trabalho que ainda resta ser feito,
um timo mecanismo para visualizar a correlao entre a quantidade de
trabalho que falta ser feita e o progresso do time do projeto em reduzir este
trabalho;
Figura 5 - Grfico Burndown (MAGNO, 2009, p. 33)

o Reviso (Sprint Review): Ao final do Sprint, realizada a reunio de reviso
(Sprint Review Meeting) para que o time apresente o resultado alcanado na
iterao ao Product Owner. Neste momento, as funcionalidades so
inspecionadas e adaptaes do projeto podem ser realizadas. Participam da
Sprint Review o Product Owner, o Scrum Master, os membros do time,
clientes, stakeholders, executivos, e qualquer pessoa que esteja interessada no
resultado da Sprint (MAGNO, 2009);
o Retrospectiva (Sprint Retrospective): Aps a reunio de reviso, o Scrum
Master conduz a reunio de retrospectiva (Sprint Retrospective Meeting),
com o objetivo de levantar informaes para melhorar o processo/time e/ou
produto para a prxima Sprint. O Product Owner, Scrum Master e os membros
do time devem participar da retrospectiva. Esta a oportunidade que o time
tem para discutir sobre o que funcionou e o que no funcionou durante a Sprint
(MAGNO, 2009).
46
1.5
CONSIDERAES FINAIS
A dinmica da metodologia gil Scrum favorece a entrega rpida do produto ou
partes dele para o cliente e com isso permite antecipar os benefcios da automatizao do
produto ou processo. A equipe de desenvolvimento focada na entrega do produto e portanto
utiliza poucos artefatos de documentao de requisitos e de gerncia de projetos. No entanto,
os responsveis por fazer tais adaptaes devem ter informao adequada para que possam
tomar as melhores decises para o projeto. Pelo fato do Scrum ser uma metodologia gil
focada na gerncia de projetos interessante analisar a possibilidade de sua integrao com
outras prticas que tambm visem um melhor gerenciamento dos projetos, como o caso do
modelo MPS.BR, permitindo agilidade nos processos, mas sem deixar de utilizar as boas
prticas de gerenciamento, permitindo assim que uma empresa tente se certificar com
maturidade nos seus processos pelo MPS.BR. A possibilidade desta integrao o alvo da
anlise no prximo captulo.
47
ANLISE DE COMPATIBILIDADE DO SCRUM COM O

PROCESSO GERNCIA DE PROJETOS DO MPS.BR
O propsito do processo Gerncia de Projetos estabelecer e manter planos que definem as

atividades, recursos e responsabilidades do projeto, bem como prover informaes sobre o
andamento do projeto que permitam a realizao de correes quando houver desvios
significativos no desempenho do projeto. O processo de Gerncia de Projetos precisa atingir a
capacidade esperada.
A capacidade do processo representada por um conjunto de atributos de processo
descrito em termos de resultados esperados. A capacidade do processo expressa o grau de
refinamento e institucionalizao com que o processo executado na unidade organizacional.
No MR-MPS-SW, medida que a unidade organizacional evolui nos nveis de maturidade,
um maior nvel de capacidade para desempenhar o processo deve ser atingido.
Para atingir o nvel de maturidade G, o processo de Gerncia de Projetos precisa
atender aos resultados esperados provenientes dos seguintes atributos de processo: AP1.1 - O
Processo Executado e AP 2.1 - O Processo Gerenciado, conforme Tabela 7.
Tabela 7 - Atributos de Processos para a Capacidade do Processos do Nvel G de
maturidade. Elaborada pelo autor com base em SOFTEX (2012c).
Atributo do Processo
Resultado Esperado do Atributo de Processo
AP 1.1. O Processo
Executado
RAP 1. O processo atinge seus resultados definidos.
AP 2.1. O Processo
Gerenciado
RAP 2. Existe uma poltica organizacional estabelecida e

mantida para o processo;
RAP 3. A execuo do processo planejada;
RAP 4. A execuo do processo monitorada e ajustes so
realizados;
RAP 5. As informaes e os recursos necessrios para a
execuo do processo so identificados e
disponibilizados;
RAP 6. As responsabilidades e a autoridade para executar
o processo so definidas, atribudas e comunicadas;
RAP 7. As pessoas que executam o processo so
competentes em termos de formao, treinamento e
experincia;
48
RAP 8. A comunicao entre as partes interessadas no
processo planejada e executada de forma a garantir o seu
envolvimento;
RAP 9. Os resultados do processo so revistos com a
gerncia de alto nvel para fornecer visibilidade sobre a
sua situao na organizao;
Para o nvel de maturidade G, o processo de Gerncia de Projetos exige os seguintes
Resultados Esperados, conforme detalhado no Captulo 2:
GPR 1. O escopo do trabalho para o projeto definido;
GPR 2. As tarefas e os produtos de trabalho do projeto so dimensionados utilizando

mtodos apropriados;
GPR 3. O modelo e as fases do ciclo de vida do projeto so definidos;
GPR 4. (At o nvel F) O esforo e o custo para a execuo das tarefas e dos produtos de
trabalho so estimados com base em dados histricos ou referncias tcnicas;
GPR 5. O oramento e o cronograma do projeto, incluindo a definio de marcos e

pontos de controle, so estabelecidos e mantidos;

ocorrncia e prioridade de tratamento so determinados e documentados;
GPR 7. Os recursos humanos para o projeto so planejados considerando o perfil e o

conhecimento necessrios para execut-lo;
GPR 8. (At o nvel F) Os recursos e o ambiente de trabalho necessrios para executar o

projeto so planejados;
GPR 9. Os dados relevantes do projeto so identificados e planejados quanto forma de

coleta, armazenamento e distribuio. Um mecanismo estabelecido para acess-los,
incluindo, se pertinente, questes de privacidade e segurana;
GPR 10. Um plano geral para a execuo do projeto estabelecido com a integrao de
planos especficos;
49

considerando restries e recursos disponveis. Se necessrio, ajustes so realizados;
GPR 12. O Plano do Projeto revisado com todos os interessados e o compromisso com
ele obtido e mantido;
GPR 13. O escopo, as tarefas, as estimativas, o oramento e o cronograma do projeto so

monitorados em relao ao planejado;
GPR 14. Os recursos materiais e humanos bem como os dados relevantes do projeto so
monitorados em relao ao planejado;
GPR 15. Os riscos so monitorados em relao ao planejado;
GPR 16. O envolvimento das partes interessadas no projeto planejado, monitorado e

mantido;
GPR 17. Revises so realizadas em marcos do projeto e conforme estabelecido no

planejamento;

pertinentes, incluindo dependncias crticas, so estabelecidos e tratados com as partes
interessadas;
GPR 19. Aes para corrigir desvios em relao ao planejado e para prevenir a repetio
dos problemas identificados so estabelecidas, implementadas e acompanhadas at a sua
concluso;
Com base na importncia dos resultados esperados no contexto do MPS.BR para o
Processo de Gerncia de Projetos, bem como suas contribuies para a satisfao dos
atributos de processo do modelo, este captulo do trabalho responsvel por avaliar a
compatibilidade do Scrum ao MPS.BR, atravs do modelo de avaliao MA-MPS, no que diz
respeito Gerncia de Projetos. A seo seguinte detalha como ser realizada a avaliao de
compatibilidade do Scrum com o MPS.BR. Na seo 1.7 realizada a anlise da
compatibilidade do Scrum com o MPS.BR aplicando o mtodo formal de avaliao MA-MPS.
Na seo 1.8 feita a classificao provvel do nvel de maturidade alcanado pelo Scrum
50
para o processo de Gerncia de Projetos caso um projeto utilizasse esta metodologia gil. E na
seo 1.9 so feitas as consideraes finais sobre a anlise realizada.
1.6
PREPARAO PARA A AVALIAO UTILIZANDO O MTODO MA-MPS
Conforme visto no Captulo 2, a preparao para a avaliao de uma unidade organizacional

que almeja se certificar MPS.BR exige grande dedicao, que vai desde da contratao de
uma instituio avaliadora, passando pela seleo de projetos, a avaliao propriamente dita, a
atribuio do nvel de maturidade e o encerramento. Como o foco deste trabalho no a
avaliao de uma unidade organizacional e sim de um framework de gerncia de projetos gil,
Scrum, este trabalho ir avaliar apenas os resultados esperados do processo de Gerncia de
Projetos frente ao Scrum, onde o mesmo ser aqui caracterizado como um projeto.
Diante do exposto, este trabalho ir executar a tarefa "Caracterizar o grau de
implementao de cada resultado esperado do processo em cada projeto" (adaptada, pois no
escopo do trabalho avaliar frente aos resultados esperados de cada atributo de processo) que
pertence atividade "Conduzir a Avaliao Final" do Subprocesso "Realizar a Avaliao
Final" do MA-MPS (vide seo 1.3). Para tanto, sero feitas as seguintes adaptaes:
Para cada resultado esperado do processo de Gerncia de Projeto (GPRs) ser exibida uma
tabela dos Indicadores de Implementao, conforme a Tabela 8;
No que diz respeito aos indicadores de implementao, o indicador Afirmaes (vide

Atividade Preparar a Avaliao, seo 1.3.1.3) no far parte desta avaliao, pelo fato da
avaliao ser realizada no Scrum e no em um projeto que utilize o Scrum. Assim no ser
feita nenhuma entrevista com os envolvidos;
Quando houver alguma ponto fraco identificado nos indicadores de implementao, ele
ser descrito na coluna Ponto(s) Fraco(s) na tabela de indicadores.
Tabela 8 - Exemplo de Indicadores de Implementao. Elaborada pelo autor com
base em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 1. O escopo do
trabalho para o projeto
definido;
Artefatos Diretos Scrum
Artefatos Indiretos Scrum
Product Backlog;
Sprint Backlog.
Reunio de Planejamento
(Sprint Planning Meeting).
Ponto(s) Fraco(s)
51
Para cada Resultado Esperado do processo de Gerncia de Projetos ser exibida uma tabela
com o resultado da escala para caracterizao do grau de implementao. A Tabela 9 exibe
um exemplo;
Tabela 9 - Exemplo de Escala de Caracterizao para cada Resultado Esperado.
Elaborada pelo autor com base em SOFTEX (2012c).
Classificao
Totalmente Implementado (T)
Significado
- O indicador direto est presente e julgado adequado;
- Existe pelo menos um indicador indireto e/ou afirmao
confirmando a implementao;
- No foi notado nenhum ponto fraco substancial.
Ao fim da avaliao de cada resultado esperado ser feita a explicao (anlise da

avaliao) de como se obteve tal concluso;
Ao final de todos os resultados esperados, na seo 1.8, ser feita a anlise de satisfao da
do processo, baseado na satisfao ou no de seus resultados esperados, resultando no
provvel nvel de maturidade do mesmo.
1.7
ANLISE DE COMPATIBILIDADE DO SCRUM COM O MPS.BR
Esta seo responsvel por realizar a anlise da compatibilidade do Scrum com o MPS.BR e
por fornecer os resultados desta anlise, visando esclarecer a possibilidade, ou no, da
integrao entre os dois. A anlise ser realizada conforme explicado na seo anterior, onde
sero avaliados os resultados esperados do processo de Gerncia de Projetos. Para tanto, ser
criado uma tabela com os Indicadores de Implementao para cada resultado esperado e, logo
em seguida, uma tabela com a escala de caracterizao se o Scrum est ou no aderente ao
MPS.BR para aquele resultado esperado especfico.
1.7.1
GPR 1. O escopo do trabalho para o projeto definido
a) Tabela com os Indicadores de Implementao
Tabela 10 - GPR 1. Indicadores de Implementao. Elaborada pelo autor com base

em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 1. O escopo do
trabalho para o projeto
definido;
Indicadores Diretos
Scrum
Product Backlog;
Sprint Backlog.
Indicadores Indiretos
Scrum
Ponto(s) Fraco(s)
No Scrum no existe um
documento formal para
documentar os limites e
52
restries do projeto. Isto
identificado no dia a dia,
nas reunies de dirias de
acompanhamento.
b) Escala de Caracterizao de acordo com os Indicadores

Tabela 11 - GPR 1. Classificao de acordo com os Indicadores de Implementao.
Classificao
Significado
c) Anlise da Avaliao
Este resultado esperado define a necessidade de se estabelecer e manter o escopo do
projeto. Conforme mostrado, o Scrum possui o artefato Product Backlog onde so
guardados todos os requisitos ou histrias de usurio do projeto e o Sprint Backlog onde
esto os requisitos da Sprint. O Scrum, por ser uma metodologia gil, no trabalha com
escopo fechado do projeto. Uma Sprint possui escopo previamente definido e por ter
durao de no mximo quatro semanas possui probabilidade menor de acontecer mudana
de escopo durante sua execuo. Caso acontea mudana de escopo, esse novo requisito
ser repriorizado e entrar ou no no ciclo de execuo da prxima Sprint. A Tabela 11
classifica este resultado esperado como Totalmente Implementado pelo Scrum, indicando a
presena de artefatos diretos e indiretos, e nenhuma fraqueza substancial percebida.
1.7.2
GPR 2. As tarefas e os produtos de trabalho do projeto so dimensionados
utilizando mtodos apropriado


em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
Indicadores Diretos
Scrum
Scrum
Ponto(s) Fraco(s)
53
GPR 2. As tarefas e os
produtos de trabalho do
projeto
so
dimensionados
utilizando
mtodos
apropriados
Story Points;
Product Backlog;
Sprint Backlog;
Priorizao baseada na
estimativa Planning Poker.
No observado.

Classificao
Significado
Este resultado esperado define a necessidade de se estabelecer uma estimativa de tamanho
de projeto. Conforme mostrado, o Scrum utiliza de tcnicas de estimativa geis, como
Planning Poker. No Planning Poker todos os membros da equipe do um valor de
complexidade tcnica (story point) e de esforo para o desenvolvimento de cada um dos
requisitos definidos. Baseado nisso, e no valor de negcio do requisito para o usurio
montado uma lista de priorizada dos requisitos do projeto (do maior para o menor, por
exemplo), que chamado de ROI (Return of Investment). Diante disso, os requisitos com
maior prioridade so executados na primeira Sprint. medida que a equipe vai executando
as Sprints calculado a velocidade da equipe (quantos requisitos, baseado no valor da
complexidade tcnica, a equipe suporta por Sprint). A Tabela 13 classifica este resultado
esperado como Totalmente Implementado pelo Scrum, indicando a presena de artefatos
diretos e indiretos, e nenhuma fraqueza percebida.
1.7.3
GPR 3. O modelo e as fases do ciclo de vida do projeto so definidos
54
em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 3. O modelo e as
fases do ciclo de vida
do
projeto
so
definidos;
Indicadores Diretos
Scrum
Release Plan;
Ciclo de vida iterativo da
Sprint composto por 4
fases: Planejamento,
Execuo, Reviso e
Retrospectiva.
Scrum
Reunio de Planejamento da
Sprint;
Ponto(s) Fraco(s)
No observado.

Classificao
Significado
- No foi notado pontos fracos.
Este resultado esperado define a necessidade de se estabelecer um planejamento de todo o
projeto. No incio de um projeto o time criar um Release Plan em alto nvel. O Release
Plan detalha: a quantidade e a durao dos Sprints, quantas pessoas ou times devero
participar do projeto, o nmero de releases, o valor a ser entregue em cada release e a data
de liberao dos release. Conforme mostrado, a Sprint possui quatro fases: Planejamento,
Execuo, Reviso e Retrospectiva. Cada uma dessas fases so executadas dentro de cada
Sprint. O Scrum trabalha com o Product Backlog, que composto por todos os requisitos
do projeto. Na reunio de priorizao do Product Backlog, definido quais os requisitos
entraro no primeiro ciclo de desenvolvimento, Sprint. Os demais requisitos que constam
no Product Backlog sero repriorizados para prxima Sprint. O Scrum trabalha com
projetos de escopo aberto, ou seja, a cada nova Sprint novos requisitos podem entrar e
serem priorizados. A Tabela 15 classifica este resultado esperado como Totalmente
Implementado pelo Scrum, indicando a presena de artefatos diretos e indiretos, e nenhuma
fraqueza percebida.
55
1.7.4
GPR 4. O esforo e o custo para a execuo das tarefas e dos produtos de trabalho
so estimados com base em dados histricos ou referncias tcnicas


em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 4. O esforo e o
custo para a execuo
das tarefas e dos
produtos de trabalho so
estimados com base em
dados histricos ou
referncias tcnicas;
Indicadores Diretos
Scrum
Product Backlog;
Sprint Backlog;
Scrum
Estimativas atravs do
Planning Poker;
Ponto(s) Fraco(s)
O Scrum no trabalha
explicitamente com custo
(MARAL, 2009);

Classificao
Largamente Implementado (L)
Significado
- Foi notado um ou mais pontos fracos substanciais.
Este resultado esperado define a necessidade de se estabelecer uma estimativa de esforo e
de custo do projeto. Conforme mostrado, o Scrum utiliza de tcnicas de estimativa geis,
como Planning Poker. No Planning Poker todos os membros da equipe do um valor de
complexidade tcnica e de esforo para o desenvolvimento de cada um dos requisitos
definidos. Baseado nisso, e no valor de negcio do requisito para o usurio montado uma
lista de priorizada dos requisitos do projeto (do maior para o menor, por exemplo), que
56
chamado de ROI (Return of Investment). Diante disso, os requisitos com maior prioridade
so executados na primeira Sprint. Apesar de explicitamente o Scrum no mencionar custo
do projeto e da Sprint, isto pode ser facilmente calculado tendo como base o valor hora de
cada papel envolvido na Sprint. A Tabela 17 classifica este resultado esperado como
Largamente Implementado pelo Scrum, indicando a presena de artefatos diretos e
indiretos, e a percepo de um ponto fraco.
1.7.5
GPR 5. O oramento e o cronograma do projeto, incluindo a definio de marcos
e pontos de controle, so estabelecidos e mantidos;


em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 5. O oramento e
o cronograma do
projeto, incluindo a
definio de marcos e
pontos de controle, so
estabelecidos e
mantidos;
Indicadores Diretos
Scrum
Product Backlog;
Sprint Backlog;
Quadro de Tarefas
(Kanban);
Scrum
Ponto(s) Fraco(s)
Sprint (Scrum Planning
Meeting);
O Scrum no trabalha
explicitamente com custo
(MARAL, 2009);

Classificao
Significado
Este resultado esperado define a necessidade de se estabelecer um oramento e cronograma
do projeto. Conforme mostrado, o cronograma pode ser obtido a partir do Product Backlog
que dividido em sprints considerando a alocao do time de acordo com a sua
57
capacidade. No Sprint Backlog elaborado uma lista de tarefas para que os requisitos da
Sprint sejam atendidos. Cada tarefa possui um responsvel e o tempo de execuo. O
cronograma obtido aps esta distribuio de tarefas. A execuo destas tarefas so
acompanhadas pelo Scrum Master diariamente atravs das Reunies Dirias (Daily
Meeting) e atravs do Quadro de Tarefas (Kanban), conforme mostrado na Tabela 18. A
Tabela 19 classifica este resultado esperado a como Largamente Implementado pelo
Scrum, indicando a presena de artefatos diretos e indiretos, e um ponto fraco percebido.
1.7.6
ocorrncia e prioridade de tratamento so determinados e documentados;


em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 6. Os riscos do
projeto so
identificados e seu
impacto, probabilidade
de ocorrncia e
prioridade de tratamento
so determinados e
documentados;
Indicadores Diretos
Scrum
Impediment Backlog;
Scrum
Resultado das Reunies
Dirias (Daily Meeting);
Ponto(s) Fraco(s)
A lista de impedimento do
Scrum no retrata a
probabilidade de ocorrncia.

Classificao
Significado
Este resultado esperado define a necessidade de se estabelecer um controle sobre os riscos
do projeto, atravs da identificados e acompanhamento dos mesmos. Conforme mostrado,
58
a lista de riscos do projeto o chamado Impediment Backlog onde so listados todos os
riscos/problemas que afetam a Sprint ou o projeto. Esta lista pode ser priorizada, mas
geralmente no , pois todos os impedimentos so acompanhados diariamente atravs das
reunies dirias onde cada membro do time diz o que fez, o que falta fazer e os seus
problemas ou dificuldades. Esse riscos so minimizados diariamente. A Tabela 21
classifica este resultado esperado como Largamente Implementado pelo Scrum, indicando
a presena de artefatos diretos e indiretos, e um ponto fraco percebido, pois o Scrum no
disciplina a formalizao desses riscos atravs da probabilidade de ocorrncia, visto que
so formalmente acompanhados diariamente.
1.7.7
GPR 7. Os recursos humanos para o projeto so planejados considerando o perfil
e o conhecimento necessrios para execut-lo;


em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
Indicadores Diretos
Scrum
GPR 7. Os recursos
humanos para o projeto
so planejados
considerando o perfil e
o conhecimento
necessrios para
execut-lo;
Scrum
Ponto(s) Fraco(s)
Sprint (Planning Scrum
Meeting) determina uma
equipe multifuncional e
auto-suficiente;
Reunies Dirias (Daily
Meeting);
O Scrum no possui um
documento formal com as
habilidades dos membros do
Time

Classificao
Parcialmente Implementado (P)
Significado
- O indicador direto no est presente ou julgado
inadequado;
- Artefatos/Afirmaes sugerem que alguns aspectos do
59
resultado esperado est implementado;
- Pontos Fracos foram implementados.
Este resultado esperado define a necessidade de se estabelecer e planejar os recursos
humanos do projeto atravs de suas habilidades. Conforme mostrado no captulo anterior, o
time Scrum composto pelo product owner, o time de desenvolvimento e o scrum master.
Times Scrum so auto-organizveis e multifuncionais. Equipes auto-organizveis escolhem
qual a melhor forma para completarem seu trabalho e possuem todas as competncias
necessrias para completar o trabalho sem depender de outros que no fazem parte da
equipe. O modelo de equipe no Scrum projetado para aperfeioar a flexibilidade,
criatividade e produtividade. Apesar de no possuir um documento formal para controle e
anlise das competncias, o Scrum determina que o time deve ser escolhido tendo como
meta pessoas com todas as habilidades relacionadas s fases de desenvolvimento de
software, uma vez que a mesma deve ser multidisciplinar e auto suficiente. A Tabela 23
classifica este resultado esperado como Parcialmente Implementado pelo Scrum, uma vez
que no existe um artefato direto com as habilidades do time e demais membros. Apesar
disso, o Scrum por ser uma metodologia gil permite adaptaes, podendo no incio do
projeto traar o perfil necessrio para cada papel.
1.7.8
GPR 8. Os recursos e o ambiente de trabalho necessrios para executar o projeto
so planejados;
em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 8. Os recursos e o
ambiente de trabalho
necessrios para
executar o projeto so
planejados;
Indicadores Diretos
Scrum
Product Backlog;
Sprint Backlog;
Scrum
Sprint (Planning Scrum
Meeting)
Reunies Dirias (Daily
Meeting);
Ponto(s) Fraco(s)
No observado.
60
Classificao
Significado

Este resultado esperado define a necessidade de se estabelecer e planejar os recursos e
ambiente de trabalho do projeto. Conforme mostrado, o Product Backlog e o Sprint
Backlog pode conter no apenas requisitos funcionais (user stories), mas tambm
requisitos no funcionais que necessitam de planejamento para a execuo do requisito
funcional. A Tabela 25 classifica este resultado esperado como Totalmente Implementado
pelo Scrum, uma vez que os requisitos no funcionais do projeto e a configurao do
ambiente de trabalho podem ser executados dentro da sprint ou antes da incio do projeto.
1.7.9
GPR 9. Os dados relevantes do projeto so identificados e planejados quanto
forma de coleta, armazenamento e distribuio. Um mecanismo estabelecido para

acess-los, incluindo, se pertinente, questes de privacidade e segurana;
em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 9. Os dados relevantes do
projeto so identificados e
planejados quanto forma de
coleta, armazenamento e
distribuio. Um mecanismo
estabelecido para acess-los,
incluindo, se pertinente,
questes de privacidade e
segurana;
Indicadores Diretos
Scrum
Scrum
Ponto(s) Fraco(s)
Dados coletados na
Reunio de
Planejamento;
Dados coletados
conforme as
necessidades do Time
Quadro de tarefas
(Kanban);
Reunio de
Planejamento da Sprint
(Planning Scrum
Meeting);
Reunies Dirias
(Daily Meeting);
No Scrum no existe um
plano
de
dados
que
formalize a identificao,
coleta, armazenamento e
distribuio
(MARAL,
2009).
61
Classificao
Significado

Este resultado esperado define a necessidade de identificar, coletar, armazenar e distribuir
os dados para garantir a integridade e segurana dos mesmos. importante identificar os
dados relevantes do projeto, para depois colet-los, armazen-los e distribu-los de forma
controlada, lembrando que isso implica em custo. No Scrum o planejamento e
armazenamentos dos dados so planejados e definidos na reunio de planejamento da
Sprint. Todos os membros do time seguem o que foi definido e so criadas tarefas para eles
executadas. Estas tarefas so monitoradas diariamente, atravs das reunies dirias e ficam
localizadas no quadro de tarefas, Kanban, de cada membro do time. Contudo, no Scrum
no h um plano de dados para formalizar a coleta, consolidao e divulgao das
informaes e dados do projeto, sendo esta a nica fraqueza identificada no Scrum para
este resultado esperado. Devido a esta fraqueza, na Tabela 27 este resultado esperado
classificado como Largamente Implementada para o Scrum.
1.7.10
GPR 10. Um plano geral para a execuo do projeto estabelecido com a
integrao de planos especficos;

em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 10. Um plano geral para a
execuo do projeto
estabelecido com a integrao
de planos especficos;
Indicadores Diretos
Scrum
Viso do Produto;
Product Backlog;
Sprint Backlog;
Scrum
Reunio de
(Planning Scrum
Meeting);
Ponto(s) Fraco(s)
No observado;
62
Classificao
Significado

Este resultado esperado tem por objetivo estabelecer e manter o contedo do plano de
projeto De acordo com Schwaber (SCHWABER e SUTHERLAND, 2010), o plano
mnimo necessrio para iniciar um projeto com o Scrum consiste de uma viso do produto
e do Product Backlog que so os artefatos diretos deste resultado esperado, conforme a
Tabela 28. A viso do produto descreve a razo pela qual o projeto est sendo realizado e o
estado final desejado para o projeto (CHAVES, 2011). J o Product Backlog define os
requisitos funcionais e no funcionais que o sistema dever atender para a entrega do
produto. O Sprint Backlog contm os requisitos que sero executados na prxima Sprint.
Unindo os trs documentos, a viso do produto, o Product Backlog e o Sprint Backlog,
tem-se a base para a elaborao de um plano de projeto. A reunio de planejamento
apontada como o artefato indireto da prtica e nenhum ponto fraco foi observado.
Classificando, portanto, conforme a Tabela 29, este resultado esperado foi classificado
como Totalmente Implementado para o Scrum.
1.7.11
considerando restries e recursos disponveis. Se necessrio, ajustes so realizados;

em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 11. A viabilidade de
atingir as metas do projeto
explicitamente avaliada
considerando restries e
recursos disponveis. Se
necessrio, ajustes so
realizados;
Indicadores Diretos
Scrum
Viso do Produto;
Product Backlog;
Sprint Backlog;
Impediment Backlog;
Scrum
Reunio de
(Planning Scrum
Meeting);
Sprint Review;
Ponto(s) Fraco(s)
No observado;
63

Classificao
Significado

Este resultado esperado tem por objetivo estabelecer o estudo de viabilidade do escopo do
projeto e examina aspectos tcnicos (requisitos e recursos), financeiros (capacidade da
organizao) e humanos (disponibilidade de pessoas com a capacitao necessria)
(SOFTEX, 2011d). medida que o projeto evolui, a viabilidade de sucesso pode ser
reavaliada com mais preciso. A cada nova sprint, na reunio de planejamento da sprint e
na sprint review todos os riscos do projeto so levantados e analisados, com isso a
viabilidade de continuidade do projeto analisada. Durante a reunio Sprint Review o
projeto avaliado baseado no objetivo, meta da Sprint. Outro ponto de anlise so as
reunies dirias que acompanha diariamente a execuo da sprint e analisa os problemas
enfrentados. Conforme mostrado, este resultado esperado foi classificado como Totalmente
Implementado, Tabela 31 ,e nenhum ponto fraco foi percebido.
1.7.12
GPR 12. O Plano do Projeto revisado com todos os interessados e o
compromisso com ele obtido e mantido;

em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 12. O Plano do Projeto
revisado com todos os
interessados e o compromisso
com ele obtido e mantido;
Indicadores Diretos
Scrum
Product Backlog;
Sprint Backlog;
Scrum
Reunio de
(Planning Scrum
Meeting);
Sprint Review;
Ponto(s) Fraco(s)
No observado;
64
Classificao
Significado

Este resultado esperado tem por objetivo estabelecer a reviso do plano de projeto com
todos os interessados e manter o compromisso acordado. No Scrum sempre no inicio de
cada Sprint e ao final de cada Sprint realizado o planejamento da prxima Sprint e a
reviso da Sprint que acabou de terminar, respectivamente. Com isso, nessas reunies
todos os interessados no projeto so envolvidos, Product Owner, Scrum Master e o Time.
Assim, reavaliado o escopo do projeto e nova priorizao de requisitos pode acontecer.
Conforme mostrado, este resultado esperado foi classificado como Totalmente
Implementado, Tabela 33, e nenhum ponto fraco foi percebido.
1.7.13
GPR 13. O escopo, as tarefas, as estimativas, o oramento e o cronograma do
projeto so monitorados em relao ao planejado;

em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 13. O escopo, as tarefas,
as estimativas, o oramento e o
cronograma do projeto so
monitorados em relao ao
planejado;
Indicadores Diretos
Scrum
Product Backlog;
Sprint Backlog;
Quadro de Tarefas
Kanban;
Scrum
Ponto(s) Fraco(s)
Reunio de
(Planning Scrum
Meeting);
Reunies Dirias
(Daily Meeting);
No h monitorao em
relao ao oramento do
projeto, pois o Scrum no
trabalha explicitamente com
custo (MARAL, 2009);
65
Classificao
Significado

O objetivo deste resultado esperado assegurar que haja monitorao do projeto em
relao a aspectos relacionados s tarefas, estimativas e cronograma. Em geral, durante um
monitoramento, faz-se uma anlise do que foi planejado anteriormente com os valores
atuais das variveis consideradas. No Scrum sempre no inicio de cada Sprint e ao final de
cada Sprint realizado o planejamento da prxima Sprint e a reviso da Sprint que acabou
de terminar, respectivamente. Nas reunies dirias so realizadas o acompanhamento dirio
da realizao das tarefas do time. A cada nova Sprint, as estimativas dos requisitos
funcionais e no funcionais necessrios so recalculadas e assim, um novo cronograma da
Sprint mantido. Conforme mostrado, este resultado esperado foi classificado como
Largamente Implementado, Tabela 35, pois foi observado o ponto fraco em relao ao
oramento do projeto, pois o Scrum no trabalha explicitamente com custos, apesar de
possibilitar adaptaes.
1.7.14
GPR 14. Os recursos materiais e humanos bem como os dados relevantes do
projeto so monitorados em relao ao planejado;

em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 14. Os recursos materiais
e humanos bem como os dados
relevantes do projeto so
planejado;
Indicadores Diretos
Scrum
Sprint Backlog;
Quadro de Tarefas,
Kanban;
Scrum
Reunio de
(Planning Scrum
Meeting);
Reunies Dirias
(Daily Meeting);
Ponto(s) Fraco(s)
No observado;
66

Classificao
Significado

O objetivo deste resultado esperado garantir que o projeto seja monitorado em relao
aos itens planejados referentes a recursos materiais e recursos humanos. Em geral, durante
um monitoramento, faz-se uma anlise do que foi planejado anteriormente com os valores
atuais das variveis consideradas. No Scrum existem vrios pontos de controle para cruzar
as informaes do que foi planejado com o que est sendo realizado, entre eles o backlog
da Sprint, a reunio de planejamento da Sprint e as reunies dirias. Caso algum
impedimento acontea, como a sada de algum membro da equipe ou a necessidade de
algum recurso material, isto estar sendo monitorado nessas reunies e as medidas
provenientes sero tomadas. Conforme mostrado, este resultado esperado foi classificado
como Totalmente Implementado, Tabela 37.
1.7.15
GPR 15. Os riscos so monitorados em relao ao planejado;

em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 15. Os riscos so
planejado;
Indicadores Diretos
Scrum
Impediment Backlog;
Scrum
Reunio de
(Planning Scrum
Meeting);
Reunies Dirias
(Daily Meeting);
Ponto(s) Fraco(s)
No observado;
67
Classificao
Significado

No decorrer do projeto novos riscos podem ser identificados para o projeto e os parmetros
dos riscos j identificados podem ser alterados. Alm disso, pode ser necessrio executar
aes de mitigao para evitar que os riscos aconteam ou, no caso de riscos terem se
concretizado, pode ser preciso executar aes de contingncia para minimizar seus efeitos.
Tambm importante que a lista de riscos seja reavaliada periodicamente em conjunto com
uma avaliao dos seus parmetros de anlise e prioridade (SOFTEX, 2011d). No Scrum a
lista de impedimentos da Sprint revisada diariamente atravs das reunies dirias de
acompanhamento. Todos os dias o time trabalha com intuito de minimizar concretizao
dos riscos e na resoluo de problemas. Conforme mostrado, este resultado esperado foi
classificado como Totalmente Implementado, Tabela 39.
1.7.16
GPR 16. O envolvimento das partes interessadas no projeto planejado,
monitorado e mantido;
em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 16. O envolvimento das
partes interessadas no projeto
planejado, monitorado e
mantido;
Indicadores Diretos
Scrum
Product Backlog;
Sprint Backlog;
Scrum
Reunio de
(Planning Scrum
Meeting);
Ponto(s) Fraco(s)
No observado;

Classificao
Significado
68

Devem ser identificados os interessados relevantes no projeto, em que fases eles so
importantes e como eles sero envolvidos. Uma vez identificado e planejado o
envolvimento, este dever ser seguido, monitorado e mantido ao longo de todo o projeto.
No Scrum a cada nova Sprint os envolvidos no projeto, o Product Owner, Scrum Master e
o Time se renem na reunio de planejamento da Sprint para revisar a priorizao dos
requisitos, mantendo constantemente os interessados nos projetos participando das
decises. Conforme mostrado, este resultado esperado foi classificado como Totalmente
Implementado, Tabela 41.
1.7.17
GPR 17. Revises so realizadas em marcos do projeto e conforme estabelecido
no planejamento;
em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 17. Revises so
realizadas em marcos do projeto
e conforme estabelecido no
planejamento;
Indicadores Diretos
Scrum
Sprint Review;
Retrospectiva da
Sprint;
Scrum
Reunio de
(Planning Scrum
Meeting);
Ponto(s) Fraco(s)
No observado;

Classificao
Significado
69
Este resultado importante porque as revises em marcos so oportunidades para verificar,
de forma ampla, o andamento de todo o projeto, independente do acompanhamento do diaa-dia. A Retrospectiva do Sprint o mecanismo principal para a visibilidade que o Scrum
proporciona a reas que potencialmente necessitam de melhorias, transformando-as em
resultados. Nesta reunio eles identificam pontos de melhoria. No Scrum a cada nova
Sprint os envolvidos no projeto, o Product Owner, Scrum Master e o Time se renem na
reunio de planejamento da Sprint para revisar a priorizao dos requisitos e, assim, os
interessados nos projetos esto constantemente participando das decises. Conforme
mostrado, este resultado esperado foi classificado como Totalmente Implementado, Tabela
43.
1.7.18
pertinentes, incluindo dependncias crticas, so estabelecidos e tratados com as partes

interessadas;
em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 18. Registros de
problemas identificados e o
resultado da anlise de questes
pertinentes, incluindo
dependncias crticas, so
estabelecidos e tratados com as
partes interessadas;
Indicadores Diretos
Scrum
Impediment Backlog;
Scrum
Sprint Review;
Reunies Dirias;
Ponto(s) Fraco(s)
No observado;
70
Classificao
Significado

As atividades de reviso em marcos e de monitoramento do projeto possibilitam a
identificao de problemas que estejam ocorrendo nos projetos. natural que problemas e
desvios em relao ao planejamento aconteam durante a execuo dos projetos. Estes
problemas e desvios devem ser analisados e registrados, por exemplo, por meio de
ferramentas especficas, planilhas ou outros tipos de mecanismos de gerenciamento de
problemas. No Scrum, diariamente, nas reunies dirias e mensalmente ao final da Sprint
feito um levantamento e acompanhamento dos problemas atravs de uma lista priorizada
de impedimentos. Conforme mostrado, este resultado esperado foi classificado como
Totalmente Implementado, Tabela 45.
1.7.19
GPR 19. Aes para corrigir desvios em relao ao planejado e para prevenir a
repetio
dos
problemas
identificados
so
estabelecidas,
implementadas
acompanhadas at a sua concluso;

em SOFTEX (2012c).
Gerncia de Projetos
Resultado Esperado
GPR 19. Aes para corrigir
desvios em relao ao planejado
e para prevenir a repetio dos
problemas identificados so
estabelecidas, implementadas e
acompanhadas at a sua
concluso;
Indicadores Diretos
Scrum
Impediment Backlog;
Quadro de Tarefas
Kanban;
Scrum
Sprint Review;
Reunies Dirias;
Retrospectiva da
Sprint;
Ponto(s) Fraco(s)
No observado;
71
Classificao
Significado
Como resultado do acompanhamento do projeto e das revises em marcos, problemas so
identificados, analisados e registrados. Aes corretivas devem ser estabelecidas para
resolver problemas que possam impedir o projeto de atingir seus objetivos se no forem
resolvidos de forma adequada. As aes corretivas definidas devem ser gerenciadas at
serem concludas. O controle dos problemas levantados, as aes tomadas, os responsveis
pelas aes e os resultados devem ser registrados. No Scrum, diariamente, nas reunies
dirias e mensalmente ao final da Sprint feito um levantamento e acompanhamento dos
problemas atravs de uma lista priorizada de impedimentos. Dependendo dos
impedimentos, este poder virar uma tarefa a ser executada por um dos membros do tipo e,
portanto, ir compor o quadro de tarefas Kanban. Na Retrospectiva do Sprint identificado
pontos de melhoria no processo. Conforme mostrado, este resultado esperado foi
classificado como Totalmente Implementado, Tabela 47.
72
1.8
CLASSIFICAO
DO
NVEL DE
MATURIDADE
DO
SCRUM
NO
PROCESSO DE GERNCIA DE PROJETOS
Conforme anlise feita, na seo anterior, pode-se observar que a maioria dos resultados
esperados atendida pela metodologia gil Scrum. De um total de 19 resultados esperados, 13
foram considerados Totalmente Implementado, 5 Largamente Implementado e 1 Parcialmente
Implementado (Seo 1.7.7). O resultado esperado que foi classificado como Parcialmente
Implementado, conforme j explicado anteriormente, foi em virtude do Scrum no prev um
plano claro de escolha de competncias e habilidades para compor o projeto. No entanto, por
se tratar de uma metodologia, pode sim ser adaptada e utilizar de tal funcionalidade a
depender do projeto. A Figura 6 ilustra em percentuais o grau de implementao do Processo
de Gerncia de Projetos do MPS.BR com a metodologia gil Scrum.
Caracterizao do grau de implementao do Scrum

Totalmente
Implementad
o
5%
Largamente
Implementad
o
26%
68%
Parcialmente
Implementad
o
Figura 6 - Caracterizao do grau de implementao do Scrum. Elaborada pelo

autor.
O processo de avaliao MA-MPS considera vrias regras para caracterizar uma empresa em
grau de maturidade ou de capacidade de um processo. Uma das regras justamente a anlise
dos resultados esperados frente um ou mais projetos da unidade organizacional. Conforme
explicado anteriormente, o objetivo deste trabalho era analisar se uma metodologia gil, no
caso Scrum, pode ser utilizada em uma instituio e ao mesmo tempo ser aderente s
melhores prticas do MPS.BR no tocante ao processo de Gerncia de Projetos. O que foi visto
que o Scrum pode sim ser implementado e aderente (compatvel) maioria dos resultados
73
esperados do MPS.BR. Alguns pontos fracos foram observados, o que requer ateno caso
uma empresa queira se certificar MPS.BR. Resolvendo a questo do resultado esperado GPR
7. que foi classificado como Parcialmente Implementado e sem considerar os atributos do
processos, a metodologia gil Scrum poder ser classificada no Nvel G de
maturidade/capacidade do MPS.BR. O trabalho de Maral (MARAL, 2009) mostra que o
Scrum tambm pode ser aderente ao CMMI (SEI, 2012).
1.9
CONSIDERAES FINAIS
Alguns trabalhos relacionados fizeram anlise de reas de processo do CMMI com a

metodologia gil Scrum, como os trabalhos de Zanatta (ZANATTA e VILAIN, 2005), Chaves
(CHAVES, 2011) e Maral (MARAL, 2009). Como dito, o foco deles foi em relao ao
CMMI (SEI, 2012) que um modelo de processo voltado para grandes empresas de software.
Este trabalho escolheu o MPS.BR por ser um modelo brasileiro e adequado realidade das
empresas de software do Brasil, cuja maior parte e caracterizada por Micro e Pequena
Empresa (MPE).
Com este escopo, o trabalho mostrou que a metodologia gil Scrum pode ser aderente
ao MPS.BR com algumas adaptaes, uma vez que o MPS.BR exige um grau maior de
formalismo para evidenciar a execuo das atividades, umas vez que o Scrum por se tratar de
uma metodologia gil, evita a utilizao de documentos excessivos, e foca no que ele
considera mais importante: a comunicao.
Como a avaliao do presente trabalho foi feita em conformidade com o que prope o
framework Scrum, possvel afirmar que tais pontos fracos podem ser corrigidos fazendo-se
as devidas adaptaes do Scrum para a realidade da empresa que decidir adot-lo, devendo-se
apenas tomar os devidos cuidados de no ferir as suas caractersticas de metodologia gil.
Como sugesto de adaptao ao Scrum seria interessante:
inserir no Sprint Backlog ou Product Backlog informaes de custo de

desenvolvimento para cada um dos user stories. Alm da formalizao de tcnica de
estimativa de custo (pode-se usar o prprio planning poker);
inserir algum plano de coleta, consolidao, armazenamento e rastreamento dos

dados; e
74
a adio de um documento que contenha informaes sobre os membros do time, suas

competncias e habilidades.
Alguns autores sugerem a utilizao de um Plano de Projeto para consolidao das
informaes em um nico documento, por exemplo, Maral (MARAL, 2009).
75
CONCLUSO E TRABALHOS FUTUROS
Conforme exposto neste trabalho, o desenvolvimento de software vem crescendo nos ltimos
anos em virtude, principalmente, do avano da tecnologia em geral. Para desenvolver
software necessrio seguir um conjunto de processos que auxiliam no controle e
organizao de todas as fases do processo de desenvolvimento. Os processos tradicionais de
desenvolvimento vem se mostrando burocrticos tornando os projetos sempre atrasados, o que
acabam desmoralizando a rea de TI. Recentemente, aproximadamente 10 anos, os processos
de desenvolvimento de software tomaram novos rumos e surgiram as metodologias geis com
o intuito de tornar o desenvolvimento mais rpido, eliminando as documentaes excessivas,
enfatizando a iterao entre as pessoas e focando no resultado final: entrega do produto para o
usurio. Em paralelo, os usurios tambm se tornaram mais exigentes e cobram cada mais vez
qualidade no desenvolvimento dos seus produtos.
A qualidade de software tambm se tornou cada vez mais forte e com isso surgiram
modelos de processos, baseados em melhores prticas e tendo como foco a melhoria dos
processos e consequentemente a melhoria da qualidade dos produtos. Entre os modelos esto
o CMMI e o MPS.BR, este ultimo abordado neste trabalho.
As empresas desenvolvedoras de software, que vem adotando e se certificando nestes
modelos de maturidade de processo, tem se interessado cada vez mais na possibilidade de
adoo de uma metodologia gil que propicie um maior controle das mudanas e maior
proximidade do usurio e dos desenvolvedores e assim prover um melhor gerenciamento de
seus projetos. Como o Scrum uma metodologia gil voltada para o gerenciamento de
projetos, uma boa soluo para estas empresas seria a unio das prticas do Scrum, trazendo a
agilidade das metodologias geis; com as prticas do MPS.BR focadas na melhoria de
processos das empresas desenvolvedoras de software brasileiras.
Acreditando na unio de uma metodologia gil com modelos de maturidade, este
trabalho se props a avaliar a possvel compatibilidade entre o MPS.BR e o Scrum,
especificamente no que diz respeito ao processo de Gerncia de Projetos. Tal avaliao foi
feita com a utilizao do mtodo de avaliao MA-MPS, que um mtodo para realizar
avaliaes em empresas que queiram se certificar MPS.BR.
76
Tendo como base as informaes resultantes da avaliao proposta, conclui-se que a
compatibilidade do Scrum com o MPS.BR no apenas possvel, mas recomendvel s
empresas que querem aderir s metodologias geis, mas que no querem abrir mo de se
certificarem nos modelos de capacitao e maturidade; pois conforme mostrado no captulo
anterior, a maioria dos resultados esperados (mas especificamente, 95%) so satisfeitas
utilizando o Scrum. Apesar disto, alguns pontos fracos foram apontadas referentes falta de
alguns documentos formais. Contudo, estes pontos fracos podem ser contornados atravs de
adaptaes metodologia gil, lembrando apenas de no ferir seu intuito principal que a
entrega rpida de valor ao usurio.
Pretendendo dar continuidade ao presente trabalho e tendo como foco a melhoria
continua dos processos de desenvolvimento, seguem algumas sugestes de trabalhos futuros:
A realizao de avaliao semelhante, utilizando o MA-MPS, para outras reas de processo

do MPS.BR, como a rea de Gerncia de Requisito que pertence ao nvel G de maturidade;
Realizar a avaliao de um ou mais projetos de uma empresa que utilize o Scrum,

utilizando o MA-MPS;
Com base nos resultados alcanados, considera-se que a compatibilidade do Scrum
com o MPS-BR possvel e til para as empresas, principalmente micro e pequenas empresas
de desenvolvimento de software, que pretendem realizar o gerenciamento dos seus projetos
unindo as metodologias geis com prticas tradicionais.
77
6
REFERNCIAS BIBLIOGRFICAS
ARAUJO, R. et al. A Definio de Processos de Software sob o ponto de vista da Gesto

de Processos de Negcio. VI Simpsio Internacional de Melhoria de Processos de Software.
So Paulo: [s.n.]. 2004.
BECK, K. E. A. Agile Manifesto. Manifesto for agile software development., 2001. Acesso
em: 2013 maio 10.
CHAVES, J. O. M. Uma Anlise da Compadibilidade da rea de Processo de
Planejamento de Projeto do CMMI com a Metodologia gil Scrum. Universidade
Estadual do Cear. Fortaleza. 2011.
FALBO, R. A. Universidade Federal do Espirito Santo, 2008. Disponivel em:
<www.inf.ufes.br>. Acesso em: 22 fev. 2013.
MAGNO,
A.
Falando
sobre
Scrum,
2009.
Disponivel
em:
<http://pt.scribd.com/doc/20007777/Falando-sobre-Scrum>. Acesso em: 03 abr. 2013.

MARAL, A. S. C. SCRUMMI: Um processo de gesto gil baseado no SCRUM e aderente
ao
CMMI.
UFPE,
Recife,
2009.
Disponivel
em:
<http://www.cin.ufpe.br/~if720/downloads/SCRUMMI%20-%20AnaSofia.pdf>. Acesso em:

10 maio 2013.
MCT. Ministrio de Cincia e Tecnologia. Pesquisa Nacional de Qualidade e
Produtividade no Setor de Software Brasileiro, Braslia, 2005. Disponivel em:
<http://www.mct.gov.br>. Acesso em: 06 novembrp 2008.
NEPONUCENO, B.; ALVES, L.; ALMEIDA, T. Metodologia e Documentao do Sistema
Scrum
BTD,
2010.
Disponivel
em:
<http://pt.scribd.com/doc/53963792/6/Listar-
impedimentos-dos-requisitos-Impediment-Backlog>. Acesso em: 15 maio 2013.

PEREIRA, P.; TORREO, P.; MARAL, A. S. Entendendo Scrum para Gerenciar Projetos
de Forma gil. Entendendo Scrum para Gerenciar Projetos de Forma gil, 2007.
Disponivel em: <http://www.lapjor.cce.ufsc.br/elgg/html/pg/file/benhur/read/349/entendendoscrum-para-gerenciar-projetos-de-forma-gil>. Acesso em: 10 abr. 2013.
SANDRONI, P. Dicionrio de Administrao e Finanas. So Paulo: Record, 2008.
78
SCHWABER,
K.;
SUTHERLAND,
J.
Scrum
Guide,
2010.
Disponivel
em:
<http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf, 2010>. Acesso em: 2013

maio 10.
SEI. CMMI for Development. Software Engineering Institute. [S.l.]. 2012. CMU/SEi-2006TR-008.
SOFTEX. Guia de Implementao Parte 1. [S.l.]: [s.n.], 2011d.
SOFTEX. Guia Geral MPS.BR. [S.l.]: [s.n.], 2012a.
SOFTEX. Guia Geral de Servios MPS.BR. Braslia: [s.n.], 2012b. Disponivel em:
<http://www.softex.br/mpsbr>. Acesso em: 10 maio 2013.
SOFTEX. MPS.BR Guia de Avaliao:2012. [S.l.]: [s.n.], 2012c. Disponivel em:
<www.softex.br>. Acesso em: 2013 maio 10.
TAKEUCHI; NONAKA. The New Product Development Game. [S.l.]: Harvard Business
Review, 1986.
ZANATTA, A. L.; VILAIN, P. Uma anlise do mtodo gil Scrum conforme abordagem
nas reas de processo Gerenciamento e Desenvolvimento de Requisitos do CMMI. WER
Workshop em Engenharia de Requisitos. [S.l.]: [s.n.]. 2005.

Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do

Hochgeladen von

Copyright:

Verfügbare Formate

RODRIGO LOPES DE SANTANA

ANLISE DE COMPATIBILIDADE DA METODOLOGIA

Carlos A. C. Salles Jr. (In memoriam)

O Trabalho de Concluso de Curso

Fortaleza, 13 de Outubro de 2013

Carlos A. C. Salles Jr. (In memoriam)

Sonia Lopes da Silva

O aluno Rodrigo Lopes de Santana, abaixo assinado, do curso de MBA em Gerenciamento

Fortaleza, 13 de Outubro de 2013

Rodrigo Lopes de Santana

Tabela 44 - GPR 18. Indicadores de Implementao.......................................................................68

3.2 GERNCIA DE PROJETOS NO SCRUM..................................................................40

4.2.3 GPR 3. O MODELO E AS FASES DO CICLO DE VIDA DO PROJETO SO DEFINIDOS..........52

4.2.5 GPR 5. O ORAMENTO E O CRONOGRAMA DO PROJETO, INCLUINDO A DEFINIO DE

4.2.6 GPR 6. OS RISCOS DO PROJETO SO IDENTIFICADOS E O SEU IMPACTO, PROBABILIDADE

4.2.7 GPR 7. OS RECURSOS HUMANOS PARA O PROJETO SO PLANEJADOS CONSIDERANDO O

4.2.8 GPR 8. OS RECURSOS E O AMBIENTE DE TRABALHO NECESSRIOS PARA EXECUTAR O

4.2.9 GPR 9. OS DADOS RELEVANTES DO PROJETO SO IDENTIFICADOS E PLANEJADOS

ESTABELECIDO PARA ACESS-LOS, INCLUINDO, SE PERTINENTE, QUESTES DE PRIVACIDADE E

4.2.11 GPR 11. A VIABILIDADE DE ATINGIR AS METAS DO PROJETO EXPLICITAMENTE

4.2.12 GPR 12. O PLANO DO PROJETO REVISADO COM TODOS OS INTERESSADOS E O

4.2.13 GPR 13. O ESCOPO, AS TAREFAS, AS ESTIMATIVAS, O ORAMENTO E O CRONOGRAMA

4.2.15 GPR 15. OS RISCOS SO MONITORADOS EM RELAO AO PLANEJADO;.....................65

4.2.17 GPR 17. REVISES SO REALIZADAS EM MARCOS DO PROJETO E CONFORME

4.2.18 GPR 18. REGISTROS DE PROBLEMAS IDENTIFICADOS E O RESULTADO DA ANLISE DE

4.3 CLASSIFICAO DO NVEL DE MATURIDADE DO SCRUM NO PROCESSO

Eficincia, termo que resume o objetivo de qualquer organizao interessada em se manter no

mtodo de avaliao MA-MPS (SOFTEX, 2012c), da compatibilidade do uso da metodologia

projetos de TI, considerando os atributos de processo do MPS.BR, para tanto, os seguintes

Detalhar o MPS.BR, explicar o modelo, descrever suas representaes e seus

Detalhar o Scrum, explicar seus papis, artefatos e sua estrutura de processo;

Avaliar a compatibilidade do processo Gerncia de Projetos do MPS.BR com

COMPATIBILIDADE DO SCRUM COM O PROCESSO GERNCIA DE PROJETOS DO

O Modelo de Processo de Software Brasileiro (MPS.BR) (SOFTEX, 2012a) um programa

Guia de Aquisio: descreve um processo de aquisio de software e servios

Guia de Avaliao: descreve o processo e o mtodo de avaliao MA-MPS, os

Guia de Implementao: srie de documentos que fornecem orientaes para

Figura 1 - Componentes do MPS (SOFTEX, 2012a, p. 14)

AP 1.1 O processo executado: este atributo evidencia o quanto o processo atinge o

AP 2.1 O processo gerenciado: Este atributo evidencia o quanto a execuo do

AP 2.2 Os produtos de trabalho do processo so gerenciados;

AP 3.1. O processo definido;

AP 3.2 O processo est implementado;

AP 4.1 O processo medido;

AP 4.2 O processo controlado;

AP 5.1 O processo objeto de melhorias incrementais e inovaes;

AP 5.2 O processo otimizado continuamente.

NIVEL G: PROCESSO DE GERNCIA DE PROJETOS

os seguintes resultados esperados (SOFTEX, 2011d) (SOFTEX, 2012a):

GPR 1. O escopo do trabalho para o projeto definido: o escopo do projeto define

GPR 2. As tarefas e os produtos de trabalho do projeto so dimensionados

GPR 3. O modelo e as fases do ciclo de vida do projeto so definidos: o ciclo de

GPR 4. O esforo e o custo para a execuo das tarefas e dos produtos de

GPR 5. O oramento e o cronograma do projeto, incluindo a definio de marcos

GPR 6. Os riscos do projeto so identificados e o seu impacto, probabilidade de

GPR 7. Os recursos humanos para o projeto so planejados considerando o perfil

GPR 8. Os recursos e o ambiente de trabalho necessrio para executar o projeto

componentes, viagens e requisitos de processo (processos especiais para o projeto).

GPR 9. Os dados relevantes do projeto so identificados e planejados quanto

GPR 10. Um plano geral para a execuo do projeto estabelecido com a

GPR 11. A viabilidade de atingir as metas do projeto explicitamente avaliada

GPR 12. O Plano do Projeto revisado com todos os interessados e o