Upload
rafaelneves
View
226
Download
0
Embed Size (px)
DESCRIPTION
Artigo
Citation preview
RODRIGO LOPES DE SANTANA
ANÁLISE DE COMPATIBILIDADE DA METODOLOGIA
ÁGIL SCRUM COM O MODELO DE PROCESSO DE
GERÊNCIA DE PROJETOS DO MPS.BR
Trabalho apresentado ao curso MBA em
Gerenciamento de Projetos, pós-graduação lato
sensu, nível de especialização, do Programa
FGV Management da Fundação Getúlio
Vargas, como pré-requisito para a obtenção do
título de especialista.
Carlos A. C. Salles Jr. (In memoriam)Coordenador Acadêmico Executivo
Edmarson B. MotaCoordenador Acadêmico Executivo
Sonia Lopes da SilvaOrientadora
Fortaleza – CE
2013FUNDAÇÃO GETULIO VARGASPROGRAMA FGV MANAGEMENT
MBA EM GERÊNCIAMENTO DE PROJETOS
O Trabalho de Conclusão de Curso
Análise de Compatibilidade da Metodologia Ágil SCRUM com o Modelo de Processo de
Gerência de Projetos do MPS.BR
elaborado por Rodrigo Lopes de Santana e aprovado pela Coordenação Acadêmica, foi aceito
como pré-requisito para a obtenção do certificado do Curso de Pós-Graduação lato sensu
MBA em Gerenciamento de Projetos, nível de especialização, do programa FGV
Management.
Fortaleza, 13 de Outubro de 2013
Carlos A. C. Salles Jr. (In memoriam)Coordenador Acadêmico Executivo
Edmarson B. MotaCoordenador Acadêmico Executivo
Sonia Lopes da SilvaOrientadora
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
dependências da instituição conveniada MRH, no período de 06/05/2010 a 10/11/2011,
declara que o conteúdo do Trabalho de Conclusão de Curso intitulado Análise de
Compatibilidade da Metodologia Ágil SCRUM com o Modelo de Processo de Gerência
de Projetos do MPS.BR é autêntico e original.
Fortaleza, 13 de Outubro de 2013
Rodrigo Lopes de Santana
Dedico esse trabalho especialmente à minha família, que forma os meus pilares, como pessoa
e como profissional e, ao mesmo tempo, são o objetivo fim de todo o meu esforço nessa vida.
Dedico também aos meus mestres, não somente os professores, mas também à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 organizações esteve nos produtos. No entanto, com
o passar do tempo e a globalização do mercado, a competição se tornou mais acirrada e os
clientes passaram a ser o foco, que exigem cada vez mais um tratamento individualizado e
satisfatório. Nessa corrida por satisfazer o cliente e consequentemente maior competitividade,
as organizações precisam adaptar-se constante e rapidamente para responder às mudanças e
demandas do mercado e, portanto, estão cada vez mais preocupadas em oferecer e prover
serviços com qualidade. Neste contexto, as organizações que proveem serviços de TI
começaram a adotar formalmente conceitos, metodologias e ferramentas de gestão de
projetos. Quando essas organizações são micro e pequenas empresas de software, a gestão de
projetos possui algumas limitações em virtude de problemas relacionados à própria natureza
de tais empresas, como: quadro reduzido de funcionários, limitações financeiras, baixa
intensidade de capital, imaturidade na definição de suas metodologias, crescimento por
demanda, acúmulo de papéis entre os funcionários e utilização de mão 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 gestão de projetos SCRUM com o processo de Gerência de Projetos do MPS.BR. A
análise de compatibilidade será realizada utilizando-se do método formal de avaliação 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, agradeço em especial a Deus por abençoar a minha vida com a minha
família que, apesar das dificuldades, propiciou um ambiente favorável para a construção e o
sucesso desse trabalho. Voltando aos meros mortais, mas tão amados como amo a Deus,
agradeço imensamente à minha esposa Tarciane pela ajuda, não só nos momentos de grande
produtividade, mas principalmente nos momentos mais difíceis desse trabalho. Agradeço
profundamente aos meus pais, Raul e Fátima, 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. Agradeço também ao Banco do Nordeste do Brasil pelo patrocínio
financeiro e o pelo valoroso incentivo profissional. Por fim, agradeço a todos os meus
professores que participaram dessa construção, parentes próximos, amigos e colegas de
trabalho que de alguma forma ajudaram ou torceram pelo meu sucesso acadêmico e
profissional.
LISTA DE FIGURAS
Figura 1 - Componentes do MPS (SOFTEX, 2012a)......................................................................15Figura 2 - Subprocesso Preparar a Realização da Avaliação (FALBO, 2008)...................................27Figura 3 - Subprocesso Realizar a Avaliação Final (FALBO, 2008)................................................31Figura 4 - Ciclo de Execução do Scrum.........................................................................................42Figura 5 - Gráfico Burndown (MAGNO, 2009).............................................................................44Figura 6 - Caracterização do grau de implementação do Scrum.......................................................71
LISTA DE TABELAS
Tabela 1 - Níveis de Maturidade e Atributos de Processos do MR-MPS-SW (SOFTEX, 2012a).......18Tabela 2 – Detalhe do Processo de Avaliação (SOFTEX, 2012c)....................................................26Tabela 3 - Escala para caracterização do grau de implementação de um resultado esperado do processo e de um resultado esperado de atributo do processo nos projetos (SOFTEX, 2012c).........................32Tabela 4 - Regras para agregar a caracterização dos resultados esperados dos processos e dos resultados esperados de atributos do processo nos projetos e chegar à caracterização da unidade organizacional (SOFTEX, 2012c).................................................................................................33Tabela 5 - Regras para caracterizar o grau de implantação dos atributos do processos na unidade organizacional (SOFTEX, 2012c).................................................................................................34Tabela 6 - Caracterização de atributos de processos para satisfazer aos níveis MR-MPS (SOFTEX, 2012c)........................................................................................................................................35Tabela 7 - Atributos de Processos para a Capacidade do Processos do Nível G de maturidade..........46Tabela 8 - Exemplo de Indicadores de Implementação...................................................................49Tabela 9 - Exemplo de Escala de Caracterização para cada Resultado Esperado...............................49Tabela 10 - GPR 1. Indicadores de Implementação........................................................................50Tabela 11 - GPR 1. Classificação de acordo com os Indicadores de Implementação.........................50Tabela 12 - GPR 2. Indicadores de Implementação........................................................................51Tabela 13 - GPR 2. Classificação de acordo com os Indicadores de Implementação.........................51Tabela 14 - GPR 3. Indicadores de Implementação........................................................................52Tabela 15 - GPR 3. Classificação de acordo com os Indicadores de Implementação.........................52Tabela 16 - GPR 4. Indicadores de Implementação........................................................................53Tabela 17 - GPR 4. Classificação de acordo com os Indicadores de Implementação.........................54Tabela 18 - GPR 5. Indicadores de Implementação........................................................................54Tabela 19 - GPR 5. Classificação de acordo com os Indicadores de Implementação.........................55Tabela 20 - GPR 6. Indicadores de Implementação........................................................................55Tabela 21 - GPR 6. Classificação de acordo com os Indicadores de Implementação.........................56Tabela 22 - GPR 7. Indicadores de Implementação........................................................................57Tabela 23 - GPR 7. Classificação de acordo com os Indicadores de Implementação.........................57Tabela 24 - GPR 8. Indicadores de Implementação........................................................................58Tabela 25 - GPR 8. Classificação de acordo com os Indicadores de Implementação.........................58Tabela 26 - GPR 9. Indicadores de Implementação........................................................................59Tabela 27 - GPR 9. Classificação de acordo com os Indicadores de Implementação.........................59Tabela 28 - GPR 10. Indicadores de Implementação......................................................................60Tabela 29 - GPR 10. Classificação de acordo com os Indicadores de Implementação.......................60Tabela 30 - GPR 11. Indicadores de Implementação......................................................................61Tabela 31 - GPR 11. Classificação de acordo com os Indicadores de Implementação.......................61Tabela 32 - GPR 12. Indicadores de Implementação......................................................................62Tabela 33 - GPR 12. Classificação de acordo com os Indicadores de Implementação.......................62Tabela 34 - GPR 13. Indicadores de Implementação......................................................................63Tabela 35 - GPR 13. Classificação de acordo com os Indicadores de Implementação.......................63Tabela 36 - GPR 14. Indicadores de Implementação......................................................................64Tabela 37 - GPR 14. Classificação de acordo com os Indicadores de Implementação.......................64Tabela 38 - GPR 15. Indicadores de Implementação......................................................................65Tabela 39 - GPR 15. Classificação de acordo com os Indicadores de Implementação.......................65Tabela 40 - GPR 16. Indicadores de Implementação......................................................................66Tabela 41 - GPR 16. Classificação de acordo com os Indicadores de Implementação.......................66Tabela 42 - GPR 17. Indicadores de Implementação......................................................................67
Tabela 43 - GPR 17. Classificação de acordo com os Indicadores de Implementação.......................67Tabela 44 - GPR 18. Indicadores de Implementação......................................................................68Tabela 45 - GPR 18. Classificação de acordo com os Indicadores de Implementação.......................68Tabela 46 - GPR 19. Indicadores de Implementação......................................................................69Tabela 47 - GPR 19. Classificação de acordo com os Indicadores de Implementação.......................69
SUMÁRIO
RESUMO...................................................................................................................................5
ABSTRACT...............................................................................................................................6
AGRADECIMENTOS.....................................................................................................................7
1 INTRODUÇÃO.................................................................................................................10
1.1 OBJETIVOS GERAIS.........................................................................................................12
1.2 OBJETIVOS ESPECÍFICOS................................................................................................12
1.3 ORGANIZAÇÃO DO TRABALHO.......................................................................................13
2 MPS.BR..............................................................................................................................14
2.1 DESCRIÇÃO DO MR-MPS-SW.......................................................................................15
2.2 NIVEL G: PROCESSO DE GERÊNCIA DE PROJETOS.......................................18
2.2.1 RESULTADOS ESPERADOS..............................................................................................19
2.3 MODELO DE AVALIAÇÃO: MA-MPS.....................................................................25
2.3.1 SUBPROCESSO PREPARAR A REALIZAÇÃO DA AVALIAÇÃO..........................................27
2.3.1.1 Atividade Viabilizar a Avaliação...............................................................................28
2.3.1.2 Atividade Planejar a Avaliação..................................................................................28
2.3.1.3 Atividade Preparar a Avaliação..................................................................................29
2.3.1.4 Atividade Conduzir a Avaliação Inicial.....................................................................29
2.3.1.5 Atividade Completar a preparação da avaliação........................................................30
2.3.2 SUBPROCESSO REALIZAR A AVALIAÇÃO FINAL............................................................31
2.3.2.1 Atividade Conduzir a Avaliação Final.......................................................................31
2.3.2.2 Atividade Avaliar a execução do processo de avaliação............................................35
2.4 CONSIDERAÇÕES FINAIS........................................................................................36
3 METODOLOGIA ÁGIL SCRUM...................................................................................37
3.1 PAPÉIS............................................................................................................................38
3.2 GERÊNCIA DE PROJETOS NO SCRUM..................................................................40
3.2.1 ARTEFATOS....................................................................................................................40
3.2.2 CICLO DE EXECUÇÃO DO PROJETO NO SCRUM..............................................................42
3.3 CONSIDERAÇÕES FINAIS................................................................................................45
4 ANÁLISE DE COMPATIBILIDADE DO SCRUM COM O PROCESSO
GERÊNCIA DE PROJETOS DO MPS.BR.........................................................................46
4.1 PREPARAÇÃO PARA A AVALIAÇÃO UTILIZANDO O MÉTODO MA-MPS.48
4.2 ANÁLISE 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 SÃO DIMENSIONADOS
UTILIZANDO MÉTODOS APROPRIADO.........................................................................................51
4.2.3 GPR 3. O MODELO E AS FASES DO CICLO DE VIDA DO PROJETO SÃO DEFINIDOS..........52
4.2.4 GPR 4. O ESFORÇO E O CUSTO PARA A EXECUÇÃO DAS TAREFAS E DOS PRODUTOS DE
TRABALHO SÃO ESTIMADOS COM BASE EM DADOS HISTÓRICOS OU REFERÊNCIAS TÉCNICAS. .53
4.2.5 GPR 5. O ORÇAMENTO E O CRONOGRAMA DO PROJETO, INCLUINDO A DEFINIÇÃO DE
MARCOS E PONTOS DE CONTROLE, SÃO ESTABELECIDOS E MANTIDOS;....................................54
4.2.6 GPR 6. OS RISCOS DO PROJETO SÃO IDENTIFICADOS E O SEU IMPACTO, PROBABILIDADE
DE OCORRÊNCIA E PRIORIDADE DE TRATAMENTO SÃO DETERMINADOS E DOCUMENTADOS;. . .55
4.2.7 GPR 7. OS RECURSOS HUMANOS PARA O PROJETO SÃO PLANEJADOS CONSIDERANDO O
PERFIL E O CONHECIMENTO NECESSÁRIOS PARA EXECUTÁ-LO;................................................57
4.2.8 GPR 8. OS RECURSOS E O AMBIENTE DE TRABALHO NECESSÁRIOS PARA EXECUTAR O
PROJETO SÃO PLANEJADOS;.......................................................................................................58
4.2.9 GPR 9. OS DADOS RELEVANTES DO PROJETO SÃO IDENTIFICADOS E PLANEJADOS
QUANTO À FORMA DE COLETA, ARMAZENAMENTO E DISTRIBUIÇÃO. UM MECANISMO É
ESTABELECIDO PARA ACESSÁ-LOS, INCLUINDO, SE PERTINENTE, QUESTÕES DE PRIVACIDADE E
SEGURANÇA;..............................................................................................................................59
4.2.10 GPR 10. UM PLANO GERAL PARA A EXECUÇÃO DO PROJETO É ESTABELECIDO COM A
INTEGRAÇÃO DE PLANOS ESPECÍFICOS;.....................................................................................60
4.2.11 GPR 11. A VIABILIDADE DE ATINGIR AS METAS DO PROJETO É EXPLICITAMENTE
AVALIADA CONSIDERANDO RESTRIÇÕES E RECURSOS DISPONÍVEIS. SE NECESSÁRIO, AJUSTES
SÃO 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 ORÇAMENTO E O CRONOGRAMA
DO PROJETO SÃO MONITORADOS EM RELAÇÃO AO PLANEJADO;...............................................63
4.2.14 GPR 14. OS RECURSOS MATERIAIS E HUMANOS BEM COMO OS DADOS RELEVANTES
DO PROJETO SÃO MONITORADOS EM RELAÇÃO AO PLANEJADO;...............................................64
4.2.15 GPR 15. OS RISCOS SÃO MONITORADOS EM RELAÇÃO 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. REVISÕES SÃO REALIZADAS EM MARCOS DO PROJETO E CONFORME
ESTABELECIDO NO PLANEJAMENTO;..........................................................................................67
4.2.18 GPR 18. REGISTROS DE PROBLEMAS IDENTIFICADOS E O RESULTADO DA ANÁLISE DE
QUESTÕES PERTINENTES, INCLUINDO DEPENDÊNCIAS CRÍTICAS, SÃO ESTABELECIDOS E
TRATADOS COM AS PARTES INTERESSADAS;.............................................................................68
4.2.19 GPR 19. AÇÕES PARA CORRIGIR DESVIOS EM RELAÇÃO AO PLANEJADO E PARA
PREVENIR A REPETIÇÃO DOS PROBLEMAS IDENTIFICADOS SÃO ESTABELECIDAS,
IMPLEMENTADAS E ACOMPANHADAS ATÉ A SUA CONCLUSÃO;.................................................69
4.3 CLASSIFICAÇÃO DO NÍVEL DE MATURIDADE DO SCRUM NO PROCESSO
DE GERÊNCIA DE PROJETOS..........................................................................................71
4.4 CONSIDERAÇÕES FINAIS................................................................................................72
5 CONCLUSÃO E TRABALHOS FUTUROS.................................................................74
6 REFERÊNCIAS BIBLIOGRÁFICAS............................................................................76
10
1 INTRODUÇÃO
Eficiência, termo que resume o objetivo de qualquer organização interessada em se manter no
mercado de forma competitiva, ou seja, maximização da produção com o menor esforço e
menor custo possível. No entanto, para isso, e não menos importante, essas organizações
precisam também se preocupar com a eficácia 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 definição de trabalho eficiente e eficaz. Para isso, é
necessário conhecer profundamente os melhores métodos de produção, as melhores práticas
de gestão, o mercado onde se deseja atuar, suas condições e necessidades e, acima de tudo, ter
um planejamento estratégico bem definido para conhecer bem onde se deseja chegar.
Durante muito tempo o foco principal das organizações esteve nos produtos. O
mais importante era produzir um grande número de produtos padronizados, tratando todos os
clientes da mesma forma. No entanto, com o passar do tempo, com a globalização do
mercado, a competição se tornou mais acirrada e, somando ainda as evoluções tecnológicas,
as organizações 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 organizações em geral procuram utilizar novas técnicas, tecnologias, padrões e
paradigmas que ajudem a alcançar eficiência e eficácia em seus processos, produtos e serviços
e, assim, atender as necessidades individuais dos seus clientes.
Dentro das organizações de software existe um nicho de empresas caracterizadas
como Micro e Pequenas Empresas de Software (MPES) que, segundo (MCT, 2005), são
empresas com até 50 empregados e representam uma parcela significativa no percentual de
empresas brasileiras desse ramo, além de possuírem características típicas, como por
exemplo: baixa intensidade de capital, imaturidade nas metodologias, crescimento por
demanda, acúmulo de papéis entre os funcionários e utilização de mão de obra não
qualificada. Outro problema crítico enfrentado pelas MPES está relacionado à própria cultura
organizacional, onde os funcionários estão acostumados à informalidade ou até mesmo
ausência de processos. Em alguns casos, a implantação de processo é vista como aumento da
burocracia e restrição à liberdade individual. Esta ausência de processos bem definidos
caracteriza um dos fatores para a grande quantidade de falências entre as MPES. No Brasil,
cerca de 50% das MPES fecham após os três primeiros anos de vida (MCT, 2005). Este
cenário também se repete em vários outros países 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 adaptação constante às
mudanças do mundo externo, as MPES precisam ajustar-se constante e rapidamente para
responder às mudanças (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
documentação excessiva e burocrática, enfatizando a interação entre as pessoas e as atividades
que efetivamente trazem valor e produzem software com qualidade (BECK, 2001). As MPES
estão cada vez mais interessadas na possibilidade de adoção de uma metodologia ágil para a
melhoria de seus processos, devido à diminuição de documentação, um maior controle no
ritmo acelerado de mudanças e a participação do cliente durante o processo de
desenvolvimento, alem da possibilidade de propiciar um melhor gerenciamento de seus
projetos.
Com a introdução de princípios e práticas advindas das metodologias ágeis, o
desenvolvimento de software ganhou um novo impulso. Influenciando não só a forma de se
desenvolver software, mas também 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 vários
métodos 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
construção 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, serviços e
consequentemente nos seus produtos.
As empresas de TI , em geral, se esforçam para manter altos níveis de satisfação
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 práticas proativas e estruturadas
de trabalho. O desenvolvimento e a melhoria das práticas de serviços são
12
chaves para um melhor desempenho, aumento da satisfação do cliente e a
lucratividade do setor. Desta forma, assim como para outros setores,
qualidade é fator crítico de sucesso. Para que se tenha um setor
competitivo, nacional e internacionalmente, é essencial que as empresas
de TI coloquem a eficiência e a eficácia dos seus processos em foco nas
empresas, visando à oferta de serviços conforme padrões internacionais
de qualidade."
Uma solução prática que atenda às necessidades destas empresas é a união das
práticas do MPS.BR com o Scrum, porém, para que isto ocorra, é necessário um estudo que
conclua se as práticas do Scrum são aderentes às práticas do MPS.BR, visto que o Scrum foi
projetado para atender o desenvolvimento de software. Visando esta união, este trabalho
propõe-se a analisar, através do Modelo de Avaliação MPS.BR (MA-MPS) (SOFTEX,
2012c), a compatibilidade entre as práticas do Scrum e as práticas do processo de Gerência de
Projetos que se encontra no nível G de maturidade do MPS.BR, e fornecer as informações
necessárias para que as dúvidas a respeito desta compatibilidade sejam esclarecidas.
1.1 OBJETIVOS GERAIS
O objetivo principal deste trabalho é realizar uma análise, através da utilização do
método de avaliação MA-MPS (SOFTEX, 2012c), da compatibilidade do uso da metodologia
ágil Scrum atendendo aos resultados esperados dos atributos de processo relativos ao processo
de Gerência de Projetos do Nível G de maturidade do MPS.BR, e, de acordo com o resultado
desta análise, concluir se a prática do Scrum é compatível com o MPS.BR no que diz respeito
ao processo citado. A escolha do Scrum para a realização desta avaliação justifica-se por se
tratar de uma metodologia ágil específica para o gerenciamento de projetos.
1.2 OBJETIVOS ESPECÍFICOS
Analisar a aplicabilidade da metodologia Scrum dentro da área de gestão de
projetos de TI, considerando os atributos de processo do MPS.BR, para tanto, os seguintes
objetivos específicos serão detalhados:
Detalhar o MPS.BR, explicar o modelo, descrever suas representações e seus
níveis, apresentar seu método de avaliação MA-MPS e detalhar os atributos e
resultados de atributos do processo de Gerência de Projetos do Nível G;
Detalhar o Scrum, explicar seus papéis, artefatos e sua estrutura de processo;
13
Avaliar a compatibilidade do processo Gerência de Projetos do MPS.BR com
a metodologia Scrum, através do uso do método formal de avaliação MA-
MPS no que diz respeito à análise dos resultados esperados do processo;
1.3 ORGANIZAÇÃO DO TRABALHO
Este trabalho se baseia, principalmente, na análise de compatibilidade da
metodologia ágil Scrum com o processo de Gerência de Projetos do MPS.BR . Para tanto, este
trabalho está organizado em 5 capítulos, sendo o presente capítulo introdutório enquanto os
demais capítulos estão organizados da seguinte forma:
O capítulo , MPS.BR, abordará os principais conceitos relacionados ao modelo de
melhoria de processos MPS.BR e a importância do processo de Gerência de Projetos. Será
apresentado como o MPS.BR está organizado, os diversos níveis de maturidade e com mais
detalhes o processo que será objeto de estudo deste trabalho que é o processo de Gerência de
Projetos, pertencente ao nível G de maturidade. Também neste capítulo será apresentado o
modelo de avaliação formal do MPS.BR chamado de MA-MPS.BR.
O capítulo Error: Reference source not found, SCRUM, descreverá os princípios e
características do Scrum, seus papéis, artefatos, a dinâmica do planejamento de projetos e sua
estrutura de processo.
No capítulo Error: Reference source not found, ANÁLISE DE
COMPATIBILIDADE DO SCRUM COM O PROCESSO GERÊNCIA DE PROJETOS DO
MPS.BR, é feita a análise, propriamente dita, da compatibilidade do Scrum com processo de
Gerência de Projetos do MPS.BR do nível G utilizando o método de avaliação MA-MPS.
O capítulo Error: Reference source not found, Error: Reference source not found,
pretende fechar este trabalho com uma visão geral dos conceitos no que diz respeito à sua
contribuição às MPES, no que diz respeito à compatibilidade entre o modelo de processo
MPS.BR e a metodologia ágil Scrum, dentro do escopo do trabalho, além disso, esboçará
futuros passos no desenvolvimento de trabalhos que explorarão a potencialidade desse tema.
14
2 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 Associação para
Promoção da Excelência do Software Brasileiro (SOFTEX), que conta com apoio do
Ministério da Ciência, Tecnologia e Inovação (MCT) (MCT, 2005), Financiadora de Estudos
e Projetos (FINEP), Serviço 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 serviços, com duas metas a alcançar a médio e longo
prazos respectivamente: a) meta técnica, visando à criação e aprimoramento do Modelo MPS;
b) meta de negócio, visando à disseminação e adoção do Modelo MPS, em todas as regiões do
país, em um intervalo de tempo justo, a um custo razoável, tanto em micro, pequenas e
médias empresas (foco principal) quanto em grandes organizações privadas e governamentais,
com resultados esperados tais como: (i) criação e aprimoramento do modelo de negócio MN-
MPS; (ii) cursos, provas e workshops MPS; (iii) organizações que implementaram o Modelo
MPS; (iv) organizações com avaliação MPS publicada (prazo de validade de três anos) MA-
MPS (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: contém a descrição geral do modelo MPS e detalha o
Modelo de Referência MPS para Software (MR-MPS-SW), seus componentes e as
definições comuns necessárias para seu entendimento e aplicação;
Guia Geral MPS de Serviços: contém a descrição geral do modelo MPS e detalha o
Modelo de Referência MPS para Serviços (MR-MPS-SV), seus componentes e as
definições comuns necessárias para seu entendimento e aplicação;
Guia de Aquisição: descreve um processo de aquisição de software e serviços
correlatos. É descrito como forma de apoiar as instituições que queiram adquirir
produtos de software e serviços correlatos apoiando-se no MR-MPS-SW;
Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os
requisitos para avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras
(IA) (SOFTEX, 2012c);
15
Guia de Implementação: série de documentos que fornecem orientações para
implementar nas organizações os níveis de maturidade descritos no Modelo de
Referência MR-MPS-SW (SOFTEX, 2011d).
Figura 1 - Componentes do MPS (SOFTEX, 2012a, p. 14)
Este trabalho está focado na descrição resumida do Guia Geral MPS de Software (MR-
MPS-SW), o Guia de Avaliação de Software (MA-MPS) e o Guia de Implementação que
detalha a implementação de cada um dos processos descritos no Guia Geral MPS de Software.
2.1 DESCRIÇÃO DO MR-MPS-SW
O Modelo de Referência MPS para Software (MR-MPS-SW) (SOFTEX, 2012a)
define níveis de maturidade que são uma combinação entre processos e sua capacidade. A
capacidade do processo é a caracterização da habilidade do processo para alcançar os
objetivos de negócio, atuais e futuros; estando relacionada com o atendimento aos atributos de
processo associados aos processos de cada nível de maturidade.
Os níveis de maturidade estabelecem patamares de evolução de processos,
caracterizando estágios de melhoria da implementação de processos na organização. O nível
de maturidade em que se encontra uma organização permite prever o seu desempenho futuro
16
ao executar um ou mais processos. O MR-MPS- SW define sete níveis de maturidade: A (Em
Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E
(Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A escala de
maturidade se inicia no nível G e progride até o nível A. Para cada um destes sete níveis de
maturidade é atribuído um perfil de processos que indicam onde a organização deve colocar o
esforço de melhoria. O progresso e o alcance de um determinado nível de maturidade do MR-
MPS-SW se obtêm quando são atendidos os propósitos e todos os resultados esperados dos
respectivos processos e os resultados esperados dos atributos de processo estabelecidos para
aquele nível. A divisão em 7 estágios tem o objetivo de possibilitar uma implementação e
avaliação adequada às micros, pequenas e médias empresas. A possibilidade de se realizar
avaliações considerando mais níveis também 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
institucionalização com que o processo é executado na organização ou unidade
organizacional. No MR-MPS-SW, na medida em que a organização ou a unidade
organizacional evolui nos níveis de maturidade, um maior nível de capacidade para
desempenhar o processo deve ser atingido.
Os diferentes níveis de capacidade dos processos são 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 são utilizados no nível G de maturidade do MPS.BR e
que compõe a base de estudo deste trabalho. Os demais atributos serão apenas citados como
forma de compor todos os níveis 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 propósito.
o Resultado esperado: RAP 1. O processo atinge seus resultados definidos.
AP 2.1 O processo é gerenciado: Este atributo evidencia o quanto a execução do
processo é gerenciada.
17
o Resultados esperados: RAP 2. Existe uma política organizacional
estabelecida e mantida para o processo;
o RAP 3. A execução do processo é planejada;
o RAP 4. A execução do processo é monitorada e ajustes são realizados;
o RAP 5. As informações e os recursos necessários para a execução do processo
são identificados e disponibilizados;
o RAP 6. As responsabilidades e a autoridade para executar o processo são
definidas, atribuídas e comunicadas;
o RAP 7. As pessoas que executam o processo são competentes em termos de
formação, treinamento e experiência;
o RAP 8. A comunicação entre as partes interessadas no processo é planejada e
executada de forma a garantir o seu envolvimento;
o RAP 9. Os resultados do processo são revistos com a gerência de alto nível
para fornecer visibilidade sobre a sua situação na organização;
AP 2.2 Os produtos de trabalho do processo são 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 inovações;
AP 5.2 O processo é otimizado continuamente.
A Tabela 1 ilustra os níveis de maturidade e os atributos de processos exigidos para
cada nível. Como os atributos de processos são compostos de resultados esperados, para que
uma empresa alcance determinado nível de maturidade a mesma deve prover a
implementação dos atributos de processos e obter os resultados esperados conforme detalhado
na tabela.
Na seção seguinte será descrito detalhamento o Processo de Gerência de Projetos que
pertence ao nível G de maturidade.
18
Tabela 1 - Níveis de Maturidade e Atributos de Processos do MR-MPS-SW (SOFTEX, 2012a, p. 23)
2.2 NIVEL G: PROCESSO DE GERÊNCIA DE PROJETOS
O propósito do processo Gerência de Projetos (SOFTEX, 2011d) é estabelecer e
manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como
prover informações sobre o andamento do projeto que permitam a realização de correções
quando houver desvios significativos no desempenho do projeto. O propósito deste processo
evolui à medida que a organização cresce em maturidade. O processo Gerência de Projetos
(GPR) envolve várias atividades, como: desenvolver um plano geral de controle do projeto;
obter o comprometimento e mantê-lo ao longo de toda a execução do projeto; e conhecer o
progresso do projeto, de maneira que ações corretivas possam ser tomadas quando a execução
do projeto desviar do planejado.
19
O desenvolvimento do plano do projeto inclui: identificar e estimar o escopo, os
produtos de trabalho e as tarefas do projeto; estabelecer recursos necessários; identificar e
analisar riscos do projeto; estabelecer compromissos; e definir cronograma de execução
baseado no ciclo de vida definido para o projeto.
O acompanhamento do projeto é realizado através da comparação dos atributos reais
de produtos de trabalho e tarefas, esforço, custo e cronograma com o que foi planejado, nos
marcos (pontos de revisão) predefinidos no planejamento do projeto. A revisão de início de
fase de projeto tem por objetivo verificar se as condições para que uma fase seja iniciada
estão atendidas. Pode ser que, mesmo que a fase anterior não esteja encerrada, seja possível
iniciar a nova fase, nas condições atendidas e com prazos para o cumprimento de algumas
outras condições. A revisão de fim de fase de projeto tem por objetivo verificar se todos os
critérios de encerramento de fase foram cumpridos. As revisões em marcos podem ter um
caráter formal, com participação de gerências superiores, representantes do cliente e outras
partes interessadas no projeto. Sempre que necessário, deve-se realizar um replanejamento e
uma nova análise de sua viabilidade.
Os pontos de controle representam pontos entre um marco e outro nos quais revisões
são realizadas para avaliar o andamento do projeto, porém, não fazem parte do caminho
crítico do projeto. O projeto pode prosseguir mesmo que a revisão de um ponto de controle
não tenha sido concluída. A visibilidade apropriada do estado do projeto, através dos pontos
de controle, possibilita a tomada de ações corretivas quando o estado do projeto se desvia
significativamente do esperado. Tais ações podem exigir o replanejamento, o estabelecimento
de novos acordos ou atividades adicionais de mitigação de riscos no plano.
2.2.1 Resultados esperados
O Processo de Gerência de Projetos, nível G, para ser implementado necessita alcançar
os seguintes resultados esperados (SOFTEX, 2011d) (SOFTEX, 2012a):
GPR 1. O escopo do trabalho para o projeto é definido: o escopo do projeto define
todo o trabalho necessário, e somente ele, para entregar um produto que satisfaça as
necessidades, características e funções especificadas para o projeto, de forma a
concluí-lo com sucesso. O escopo é o ponto de partida para o planejamento do projeto.
A definição do escopo deve estabelecer o que está e o que não está incluído no projeto.
Para isso, o escopo contém a definição do objetivo e da motivação, os limites e
20
restrições, todos os produtos que serão entregues e os outros produtos gerados pelo
projeto, entre outras informações. Este resultado também pode ser descrito por meio
de um Documento de Visão ou outro documento que defina, claramente, o escopo do
trabalho;
GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados
utilizando métodos apropriados: o tamanho é a principal entrada de muitos modelos
utilizados para estimar o esforço, custo e cronograma. O tamanho é a dimensão das
funcionalidades sob o ponto de vista do usuário. São contadas tabelas internas e
externas ao sistema, classes, objetos, relatórios, telas, consultas a banco de dados,
cálculos, transações e atores dos casos de uso, linhas de código, etc;
GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos: o ciclo de
vida de um projeto consiste de fases e atividades que são 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 necessários para o
desenvolvimento de fases posteriores. Essa organização em fases permite planejar o
projeto, incluindo marcos importante para o controle e revisões;
GPR 4. O esforço e o custo para a execução das tarefas e dos produtos de
trabalho são estimados com base em dados históricos ou referências técnicas: as
estimativas de esforço e custo são, normalmente, baseadas nos resultados de análises
utilizando modelos e/ou dados históricos aplicados ao tamanho, atividades e outros
parâmetros de planejamento. É importante destacar que dados históricos incluem os
dados de custo, esforço e tempo de projetos executados anteriormente, além de dados
apropriados de escala para equilibrar as diferenças de tamanho e complexidade. As
estimativas de esforço e custo tipicamente consideram o escopo do projeto e os riscos;
GPR 5. O orçamento e o cronograma do projeto, incluindo a definição de marcos
e pontos de controle, são estabelecidos e mantidos: as dependências entre tarefas
são estabelecidas e potenciais gargalos são identificados e resolvidos quando possível
utilizando métodos apropriados (por exemplo, análise de caminho crítico). O
cronograma das atividades com início, duração e término é estabelecido e os recursos
requeridos são refletidos nos custos estimados. O orçamento do projeto é estabelecido
com base no cronograma e na estimativa de custos;
GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de
ocorrência e prioridade de tratamento são determinados e documentados:
21
projetos têm riscos e estes precisam ser identificados, analisados e priorizados através
de uma lista de riscos priorizada com análise da probabilidade de ocorrência e da
gravidade dos problemas decorrentes de sua ocorrência. A monitoração dos riscos, os
problemas gerados devido à materialização dos riscos e o acompanhamento podem ser
garantidos através do GPR15, GPR 18 e GPR19, respectivamente. No nível G, os
riscos são acompanhados para verificar como afetam o projeto e para se tomar ações,
mesmo que ainda sem um gerenciamento completo;
GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil
e o conhecimento necessários para executá-lo: o planejamento de recursos humanos
inclui informações de como e quando o recurso será envolvido no projeto, critérios
para sua liberação, competência necessária para a execução das atividades, mapa de
competências da equipe e identificação de necessidades de treinamento. A existência
de registros das necessidades e disponibilidade evita a alocação com base em critérios
subjetivos. Este resultado esperado possui dois pontos principais: (a) planejamento
prévio das necessidades de pessoal em relação a competências (conhecimento,
habilidades, atitudes e experiências); (b) a alocação dos recursos humanos ao projeto
de acordo com o planejamento realizado;
GPR 8. Os recursos e o ambiente de trabalho necessário para executar o projeto
são planejados: Este resultado faz referência à necessidade de se planejar, com base
na EAP (ou estrutura equivalente), as tarefas previstas, os recursos e o ambiente
necessários, incluindo, por exemplo, equipamentos, ferramentas, serviços,
componentes, viagens e requisitos de processo (processos especiais para o projeto).
GPR 9. Os dados relevantes do projeto são identificados e planejados quanto à
forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido
para acessá-los, incluindo, se pertinente, questões de privacidade e segurança: os
dados do projeto são as várias formas de documentação exigidas para sua execução,
por exemplo: relatórios; dados informais; estudos e análises; atas de reuniões;
documentação; lições aprendidas; artefatos gerados; itens de ação; e indicadores. Os
dados podem estar em qualquer formato e existir em qualquer meio, como: impressos
ou desenhados em diversos materiais; fotografias; meio eletrônico; e multimídia. É
importante identificar os dados relevantes do projeto, para depois coletá-los,
armazená-los e distribuí-los de forma controlada, mesmo que isso gere custos;
22
GPR 10. Um plano geral para a execução do projeto é estabelecido com a
integração de planos específicos: o objetivo deste resultado esperado é garantir que
todos os planos que afetam o projeto estejam integrados e que a dependência entre
estes planos tenha sido identificada e levada em consideração durante o planejamento.
A reunião 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 organização adequada destas
informações de planejamento. Ao longo do projeto, elas deverão ser comparadas aos
dados obtidos durante sua execução, em busca de uma maior visibilidade do
andamento do projeto;
GPR 11. A viabilidade de atingir as metas do projeto é explicitamente avaliada
considerando restrições e recursos disponíveis. Se necessário, ajustes são
realizados: o estudo de viabilidade considera o escopo do projeto e examina aspectos
técnicos (requisitos e recursos), financeiros (capacidade da organização) e humanos
(disponibilidade de pessoas com a capacitação necessária). No início do projeto, uma
avaliação preliminar pode ser conduzida, a partir da visão geral dos objetivos e
características dos resultados pretendidos, dos recursos financeiros, técnicos e
humanos. À medida que o projeto evolui, as mudanças de requisitos são 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
relevantes, é importante revisar o planejamento com eles e conciliar as diferenças
existentes entre os recursos estimados e disponíveis. A integração dos planos e o
planejamento global dos recursos da organização contribuem para a resolução prévia
de conflitos envolvendo, por exemplo, a alocação de profissionais compartilhados em
diferentes projetos ou a conciliação de datas de profissionais das áreas de apoio (por
exemplo, Garantia da Qualidade e Gerência de Configuração). A solução 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 orçamento e o cronograma do
projeto são monitorados em relação ao planejado: os resultados e os critérios de
conclusão de cada tarefa são analisados, as entregas são avaliadas em relação às suas
características (por meio de revisões e auditorias, por exemplo), a aderência ao
23
cronograma e o dispêndio de esforços são 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 monitoração do projeto em relação a aspectos relacionados às tarefas, estimativas,
orçamento e cronograma (vide GPR2, GPR3, GPR4, GPR5). Em geral, durante um
monitoramento, faz-se uma análise do que foi planejado anteriormente com os valores
atuais das variáveis consideradas;
GPR 14. Os recursos materiais e humanos bem como os dados relevantes do
projeto são monitorados em relação ao planejado: o objetivo deste resultado
esperado é garantir que o projeto seja monitorado em relação aos itens planejados
referentes a recursos materiais e recursos humanos (ver GPR7 e GPR8). Por exemplo,
a saída de um membro da equipe pode disparar a alocação de uma nova pessoa. Da
mesma forma, pode ser necessária a compra de novos equipamentos ou softwares ao
longo da execução do projeto. Outro ponto a ser considerado é identificar se novos
documentos devem ser incluídos no repositório do projeto ou se os produtos de
trabalho intermediários do projeto estão de fato sendo produzidos e armazenados
adequadamente. Em todo o caso, o planejamento do projeto deve ser revisto para
adequação dos itens pertinentes. Caso seja necessário, planos de ação devem ser
gerados (ver GPR18 e GPR19) para corrigir problemas ou evitar que outros problemas
aconteçam posteriormente;
GPR 15. Os riscos são monitorados em relação ao planejado: no decorrer do
projeto novos riscos podem ser identificados e os parâmetros dos riscos já
identificados podem ser alterados (vide GPR6). Além disso, pode ser necessário
executar ações de mitigação para evitar que os riscos aconteçam ou, no caso de riscos
terem se concretizado, pode ser preciso executar ações de contingência para minimizar
seus efeitos. A lista de riscos deve ser reavaliada periodicamente em conjunto com
uma avaliação dos seus parâmetros de análise (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 são importantes e como eles serão envolvidos (comunicações,
revisões 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 comunicação envolve, por exemplo, questões
24
relativas a prazos, custos, recursos, comprometimentos e também requisitos, pois estes
afetam as outras variáveis. Um plano de gerenciamento das comunicações pode cobrir
este resultado esperado;
GPR 17. Revisões são realizadas em marcos do projeto e conforme estabelecido
no planejamento: revisões em marcos do projeto não 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 revisões em marcos são oportunidades para verificar, de forma
ampla, o andamento de todo o projeto, independente do acompanhamento do dia-a-dia.
Em projetos grandes essas revisões são fundamentais, questionando, inclusive, a
viabilidade de continuidade do projeto. Além das revisões em marcos, outras revisões
poderão ser estabelecidas no planejamento do projeto;
GPR 18. Registros de problemas identificados e o resultado da análise de
questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados
com as partes interessadas: as atividades de revisão em marcos (GPR17) e de
monitoramento (GPR13, GPR14 e GPR15) do projeto possibilitam a identificação de
problemas que estejam ocorrendo nos projetos. Estes problemas e desvios devem ser
analisados e registrados, por exemplo, por meio de ferramentas específicas, 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 resolução, com base em planos de ações, estabelecidos
especificamente para resolver os problemas levantados e registrados (GPR19). Caso
não se consiga resolver os problemas neste nível, deve-se escalonar a resolução das
ações a níveis superiores de gerência;
GPR 19. Ações para corrigir desvios em relação ao planejado e para prevenir a
repetição dos problemas identificados são estabelecidas, implementadas e
acompanhadas até a sua conclusão: como resultado do acompanhamento do projeto
(GPR13, GPR14 e GPR15) e das revisões em marcos (GPR17), problemas são
identificados, analisados e registrados (GPR18). Ações corretivas devem ser
estabelecidas para resolver problemas que possam impedir o projeto de atingir seus
objetivos se não forem resolvidos de forma adequada. As ações corretivas definidas
devem ser gerenciadas até serem concluídas. Acompanhar o andamento de uma ação
25
corretiva até sua conclusão inclui verificar, com uma certa frequência, se ela já foi
resolvida e atuar em possíveis pendências. Caso não se consiga resolver neste nível,
deve-se escalonar a resolução das ações a níveis superiores de gerência. As ações
corretivas estabelecidas podem ser reportadas para a gerência de alto nível da
organização e para os interessados no projeto, como clientes e usuários.
2.3 MODELO DE AVALIAÇÃO: MA-MPS
O propósito do Processo e Método de Avaliação MA-MPS é verificar a maturidade da
unidade organizacional na execução de seus processos de software. O processo de avaliação
descreve o conjunto de atividades e tarefas a serem realizadas para atingir este propósito. Ele
tem início com a seleção de uma Instituição Avaliadora (IA) e encerra com o registro dessa
avaliação na base de dados confidencial da SOFTEX (SOFTEX, 2012c). O patrocinador pode
ser um representante da alta gerência da unidade organizacional a ser avaliada, ou de outra
organização que solicita a avaliação da unidade organizacional por uma terceira parte para
fins de contrato.
O Processo e o Método de Avaliação MA-MPS foram definidos de forma a (SOFTEX,
2012c):
Permitir a avaliação objetiva dos processos de software de uma organização/unidade
organizacional;
Permitir a atribuição de um nível de maturidade do MR-MPS com base no resultado
da avaliação;
Ser aplicável a qualquer domínio na indústria de software;
Ser aplicável a organizações/unidades organizacionais de qualquer tamanho.
O processo de avaliação é composto de 4 subprocessos:
Subprocesso 1: Contratar a avaliação;
Subprocesso 2: Preparar a realização da avaliação;
Subprocesso 3: Realizar a avaliação final;
Subprocesso 4: Documentar os resultados da avaliação.
Como resultado da execução deste processo:
26
São obtidos dados e informações que caracterizam os processos de software da
organização/unidade organizacional;
É determinado o grau em que os resultados esperados são alcançados e os processos
atingem o seu propósito;
É atribuído um nível de maturidade do MR-MPS à organização/unidade
organizacional.
Para alcançar os resultados previstos para a execução do processo de avaliação de uma
organização com domínio de software é necessário executar um conjunto de tarefas que estão
agrupadas dentro de cada subprocesso. A Tabela 2 mostra as atividades que compõem o
processo de avaliação do MPS.BR. Por se tratar de um processo longo que envolve desde a
busca de instituições que executam as avaliações, passando pela contratação e preparação da
avaliação, este trabalho irá detalhar apenas a parte da avaliação que trata da análise dos
artefatos e responsabilidades de um projeto que está sendo avaliado, no caso será considerado
a avaliação do Framework Scrum (Capítulo 3) na sua essência.
Tabela 2 – Detalhe do Processo de Avaliação. Elaborada pelo autor com base em Softex (2012c)
Processo de Avaliação
SUBPROCESSO ATIVIDADE
Contratar a avaliação Pesquisar Instituições Avaliadoras
Estabelecer contrato
Preparar a realização da
avaliação(*)
Viabilizar a avaliação
Planejar a avaliação
Preparar a avaliação
Conduzir a avaliação inicial
Completar a preparação da avaliação
Realizar a avaliação final (*)
Conduzir a avaliação final
Avaliar a execução do processo de avaliação
Documentar os resultados
da avaliação
Relatar os resultados
Registrar resultados
27
(*) Apenas estes subprocessos serão detalhados neste trabalho
2.3.1 Subprocesso Preparar a Realização da Avaliação
O propósito deste subprocesso é planejar a avaliação, preparar a documentação necessária e
fazer uma avaliação inicial que permita verificar se a Unidade Organizacional (UO) está
pronta para a avaliação no nível de maturidade pretendido. A Figura 2 ilustra o detalhe do
subprocesso e os artefatos de entrada de saída.
Figura 2 - Subprocesso Preparar a Realização da Avaliação (FALBO, 2008, p. 60)
2.3.1.1 Atividade Viabilizar a Avaliação
Esta atividade possui como objetivo é participar à SOFTEX a contratação da Instituição
Avaliadora (IA) para uma avaliação MPS.BR e obter aprovação para a sua realização.
A atividade possui as seguintes tarefas:
Comunicar à SOFTEX a contratação da avaliação;
Analisar a composição da equipe de avaliação e indicar o auditor da avaliação:
o No mínimo 3 pessoas: 1 Avaliador Líder; 1 ou mais Avaliadores Adjuntos; 1 ou mais
Representante da Unidade Organizacional;
o Deve ter assistido ao Curso Oficial de Introdução ao MPS.BR.
o Deve ter experiência em desenvolvimento de software, preferencialmente em
gerência de projetos;
o Não pode ser superior hierárquico dos participantes da avaliação;
28
o Não pode ter tido participação significativa em nenhum dos projetos que serão
avaliados;
Solicitar à unidade organizacional participação de avaliador em formação;
Pagar contribuição SOFTEX;
Autorização a realização da avaliação;
2.3.1.2 Atividade Planejar a Avaliação
Esta atividade tem como objetivo elaborar o plano de avaliação a ser seguido para se realizar
a avaliação na unidade organizacional.
A atividade possui as seguintes tarefas:
Enviar modelo do Plano de Avaliação e modelo da Planilha para Seleção de Projetos à
unidade organizacional:
o Projetos devem ser representativos tanto em termos de processos quanto em termos
de negócio da unidade organizacional:
Uma avaliação MPS considera uma amostra composta, normalmente, de dois (2) a
quatro (4) projetos. Nível G: pelo menos 1 projeto concluído e 1 em andamento a
partir da implementação do MR-MPS na UO definida no escopo da avaliação. Para
os níveis F e superiores: pelo menos 2 projetos concluídos e 2 em andamento a
partir da implementação do MR-MPS na UO definida no escopo da avaliação.
Caso necessário, podem ser incluídos mais um ou dois projetos para evidenciar
algum resultado ou para ter uma amostragem mais adequada da UO avaliada.
Planejar a avaliação inicial, o que inclui: preencher os dados da unidade organizacional e
dos projetos selecionados para avaliação, confirmar a data da avaliação, definir quais
serão as tarefas da avaliação inicial e seu cronograma. A avaliação inicial presencial é
obrigatória para todos os níveis de maturidade.
2.3.1.3 Atividade Preparar a Avaliação
O principal objetivo desta atividade é preencher a planilha com os indicadores (evidências)
que comprovem a implementação dos processos e que será utilizada na avaliação.
Esta atividade possui as seguintes tarefas:
29
Enviar modelo da Planilha de Indicadores e Acordo de Confidencialidade à Unidade
Organizacional;
Preencher Planilha de Indicadores; o Indicadores de implementação evidenciam que os resultados foram alcançados e que
as atividades foram realizadas. Podem ser de três tipos:
Indicadores Diretos: São o objetivo de uma atividade. Tipicamente artefatos
produzidos no processo;
Indicadores Indiretos: São utilizados para confirmar que a organização tem
condições de implementar um resultado. Tipicamente são documentos que indicam
que a atividade pode ser realizada. Ex.: Um modelo de documento.
Afirmações: São obtidas de entrevistas ou apresentações e confirmam a
implementação do processo, seus resultados e atributos.
o 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
afirmação) que comprovem que o resultado foi alcançado.
2.3.1.4 Atividade Conduzir a Avaliação Inicial
Esta atividade tem como objetivo realizar a avaliação inicial dos indicadores e verificar se a
unidade organizacional está pronta para a avaliação MR-MPS.
A atividade possui as seguinte tarefas:
Assinar comprometimento com o Plano de Avaliação de Avaliação;
Assinar o Acordo de Confidencialidade;
Treinar Equipe de Avaliação para a Avaliação Inicial;
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 experiência e perfil.
o O avaliador líder pode fazer parte de uma das mini-equipes de avaliação ou verificar
um ou mais processos sozinho. Pode, também, não avaliar nenhum processo,
dedicando o seu tempo a apoiar as mini-equipes.
Apresentar os processos da Unidade Organizacional;
Verificar os Indicadores de Implementação;
30
Analisar os dados da avaliação inicial;
Enviar ao auditor a documentação da avaliação inicial;
Auditar a Avaliação Inicial;
Realizar ajustes na documentação da avaliação inicial:
o Um Relatório de Avaliação Inicial é produzido, indicando os ajustes requeridos;
o Com o relatório, o avaliador líder completa o Plano de Avaliação que será assinado
pelo patrocinador e pelo coordenador local, formalizando o comprometimento.
o A data da avaliação poderá ser até 6 meses após a avaliação inicial. Durante esse
período, a UO deve realizar os ajustes obrigatórios indicados.
2.3.1.5 Atividade Completar a preparação da avaliação
Esta atividade tem como objetivo completar o planejamento da avaliação final e realizar os
ajustes indicados no Relatório de Avaliação Inicial dos indicadores.
A atividade possui as seguintes tarefas:
Completar Plano de Avaliação;
Realizar Ajustes.
2.3.2 Subprocesso Realizar a Avaliação Final
O propósito deste subprocesso é treinar a equipe para a avaliação final, conduzir a avaliação
final, comunicar seus resultados à UO avaliada e avaliar a execução do processo de avaliação
na UO. A Figura 3 ilustra as atividades que compõem este subprocesso.
31
Figura 3 - Subprocesso Realizar a Avaliação Final (FALBO, 2008, p. 63)
2.3.2.1 Atividade Conduzir a Avaliação Final
O propósito do subprocesso “Realizar a avaliação final” é treinar a equipe para a realização da
avaliação final, conduzir a avaliação final, comunicar seus resultados à unidade organizacional
avaliada e avaliar a execução do processo de avaliação na unidade organizacional. A atividade
"Conduzir Avaliação Final" é composta por várias tarefas a saber:
Realizar Reunião de Abertura;
Assinar Comprometimento com o Plano de Avaliação;
Completar assinaturas do Acordo de Confidencialidade;
Treinar equipe para avaliação fina;
Verificar Evidências: a avaliação é feita com base nos indicadores (diretos, indiretos e
afirmações). A equipe de avaliação pode solicitar mais documentos quando um
entrevistado menciona um documento não disponível para a equipe de avaliação ou
quando a equipe nota a falta de uma evidência direta necessária à avaliação.
Realizar Entrevistas: é um dos mais importantes componentes de uma avaliação MPS.
Mostram o grau em que os colaboradores da organização entendem e usam os processos.
Podem ser individuais ou em grupo. Se guarda rigorosa confidencialidade das entrevistas:
Nenhuma informação é atribuída a uma pessoa individualmente.
Registrar afirmações na Planilha de Indicadores;
32
Caracterizar o grau de implementação de cada resultado esperado do processo e de cada
resultado do atributo do processo em cada projeto. Decisão para cada projeto e processo,
vide Tabela 3:
Tabela 3 - Escala para caracterização do grau de implementação de um resultado esperado do processo e de um resultado esperado de atributo do processo nos
projetos (SOFTEX, 2012c, p. 60)
Caracterizar o grau de implementação de cada resultado esperado do processo e de cada
resultado do atributo do processo na unidade organizacional, vide Tabela 4.
33
Tabela 4 - Regras para agregar a caracterização dos resultados esperados dos processos e dos resultados esperados de atributos do processo nos projetos e chegar
à caracterização da unidade organizacional (SOFTEX, 2012c, p. 62)
Caracterizar, inicialmente, o grau de implementação de cada atributo do processo na
unidade organizacional, vide Tabela 5.
34
Tabela 5 - Regras para caracterizar o grau de implantação dos atributos do processos na unidade organizacional (SOFTEX, 2012c, p. 64)
Caracterizar o grau de implementação, na unidade organizacional, de cada resultado
esperado do processo, de cada resultado esperado de atributo do processo e de cada
atributo do processo em reunião de consenso;
Caracterizar o grau de implementação dos processo na unidade organizacional. A equipe
de avaliação por meio de consenso, caracteriza o grau de implementação de cada
processo na unidade organizacional como SATISFEITO ou NÃO 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 caracterização dos atributos de processo satisfaz às exigências de acordo com a
Tabela 6;
o Em qualquer outra situação o processo é caracterizado como NÃO SATISFEITO.
35
Tabela 6 - Caracterização de atributos de processos para satisfazer aos níveis MR-MPS (SOFTEX, 2012c, p. 67)
Apresentar pontos fortes, pontos fracos e oportunidades de melhoria;
Rever a caracterização e finalizar a redação dos pontos fortes, pontos fracos e
oportunidades de melhoria;
Atribuir nível MR-MPS: A atribuição do nível de maturidade é feita a uma UO se cada
processo pertencente àquele nível e incluído no escopo da avaliação tiver sido
caracterizado como SATISFEITO. A UO pode ter solicitado um Nível MR-MPS e lhe ser
atribuído um nível inferior.
Organizar ambiente de trabalho da avaliação;
Comunicar o resultado da avaliação ao patrocinador;
Comunicar o resultado da avaliação aos colaboradores da unidade organizacional.
2.3.2.2 Atividade Avaliar a execução do processo de avaliação
Esta atividade tem como objetivo avaliar a execução da avaliação na unidade organizacional de
forma a fornecer feedback à SOFTEX acerca do Processo e Método de Avaliação MA-MPS. Esta
atividade é composta pelas seguintes tarefas:
Avaliar a execução da avaliação pela equipe de avaliação;
Avaliar a execução da avaliação pelo patrocinador;
Avaliar a execução da avaliação pelo coordenador da IA (opcional);
36
Avaliar a execução da avaliação pelo coordenador da Instituição Organizadora do Grupo
de Empresas (se pertinente e opcional);
Avaliar a execução da avaliação pela Instituição Implementadora (se pertinente e
opcional).
2.4 CONSIDERAÇÕES FINAIS
O MPS.BR tem como objetivo padronizar e disciplinar um conjunto de boas de práticas de
desenvolvimento de software. Para isto, o modelo é organizado e detalha a implementação de
vários processos, desde processo de Gerência de Projetos, até processo de Gerência de
Configuração e Aquisição. Para que uma unidade organizacional de desenvolvimento de
software de qualquer porte se adeque ao modelo MPS.BR é necessário 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 padrão exigido
pelo MPS.BR é preciso ser avaliada por uma instituição avaliadora utilizando o guia de
avaliação MA-MPS. O MA-MPS detalha o passo a passo para avaliar uma unidade
organizacional e mostra quais resultados esperados devem ser alcançados para atingir o
objetivo e se tornar certificada em um nível de maturidade do MPS.BR.
37
3 METODOLOGIA ÁGIL SCRUM
O Scrum é uma metodologia ágil de Gerenciamento de Projetos. As metodologias ágeis
permitem responder rapidamente às mudanças, pois é focado nas pessoas e é indicado para
ambientes em que os requisitos surgem e mudam rapidamente, reduzindo o impacto das
mudanças nos projetos, permitindo inclusive mudanças 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 próprio negócio.
O papel do Scrum é fazer transparecer a eficácia relativa das suas práticas 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 também com as mãos. No rugby, o scrum é utilizado para reposição da bola,
após faltas ou penalidades. Oito jogadores de cada equipe posicionam-se frente à frente,
formando um círculo. Um jogador da equipe que não cometeu a infração lança a bola no
espaço entre os jogadores alinhados que tentam, com os pés, ganhar a bola – para isso, a
grupo deve trabalhar em conjunto, como se fosse uma unidade. A utilização 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 idéia 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 fabricação de automóveis e produtos de consumo. Sua
popularização no desenvolvimento de software ocorreu em 1995, após a formalização de sua
definição, 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.
38
O Scrum como uma metodologia ágil, aceita que o desenvolvimento de software
seja imprevisível e formaliza a abstração, sendo aplicável a ambientes voláteis. É uma
abordagem empírica baseada na flexibilidade, adaptabilidade e produtividade em que a
escolha das técnicas de desenvolvimento fica a cargo do time (MARÇAL, 2009). O Scrum
destaca-se dos demais pela maior ênfase dada ao gerenciamento do projeto e reúne atividades
de monitoramento e feedback, em geral, reuniões rápidas e diárias com toda a equipe, visando
a identificação e correção de quaisquer deficiências e/ou impedimentos no processo de
desenvolvimento.
O Scrum assume a premissa de que o desenvolvimento de software é muito
complexo e imprevisível para ser planejado totalmente no seu início e que ao invés de
realizarmos um planejamento detalhado prescritivo do projeto, deve-se usar o modelo
empírico de controle de processos para garantir a visibilidade, inspeção e adaptação do
planejamento do projeto. O método baseia-se ainda, em princípios como: equipes pequenas de
no máximo 7 pessoas; requisitos que são pouco estáveis ou desconhecidos; com ciclos curtos
em que divide o desenvolvimento em intervalos de tempos de no máximo 30 dias, também
chamados de Sprints.
3.1 PAPÉIS
O Scrum implementa um esqueleto iterativo e incremental através de três papéis
principais (SCHWABER e SUTHERLAND, 2010):
Scrum Master: é responsável por garantir que Scrum seja entendido e aplicado por todos
os outros papéis e verifica se eles estão aderindo aos valores do Scrum, às práticas e às
regras; ajuda o Time e a organização 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-organização e multidisciplinaridade. O Scrum Master também ajuda
o Time a fazer o seu melhor em um ambiente organizacional que pode ainda não ser
otimizado para o desenvolvimento de produtos complexos. Quando o Scrum Master ajuda
a realizar essas mudanças, isso é chamado de “remoção de impedimentos”. O papel de
Scrum Master é o de líder-servidor para o Time do Scrum. Quando o Scrum Master
trabalha para o Product Owner, o Scrum Master serve o Product Owner de várias
maneiras, por exemplo: a) Encontra técnicas para o gerenciamento efetivo do Backlog do
39
Produto; b) Claramente comunica a visão, objetivo e itens do Backlog do Produto para o
Time; c) 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 empírico e etc.
Quando o Scrum Master trabalha para o Time, o Scrum Master serve o Time de várias
maneiras, incluindo: a) Treinar Time em auto-gerenciamento e interdisciplinaridade; b)
Ensinar e liderar o Time na criação de produtos de alto valor; c) Remover impedimentos
para o progresso do Time;
Product Owner: ou dono do produto, é a pessoa responsável pelo gerenciamento do
Product Backlog (do inglês Backlog do Produto ou lista dos requisitos do sistema) e por
garantir o valor do trabalho realizado pelo Time. Essa pessoa mantém o Backlog do
Produto e garante que ele está visível 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 alcançar melhor as metas e missões; c) Garantir o valor do
trabalho realizado pelo Time; d) Garantir que o Backlog do Produto seja visível,
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 nível necessário
(SCHWABER e SUTHERLAND, 2010). Todos sabem quais itens têm a maior prioridade,
de forma que todos sabem em que se irá trabalhar. O Product Owner é uma pessoa, e não
um comitê. Podem existir comitês 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 métodos para definir
prioridades e requisitos ao longo do tempo. Para que o Product Owner obtenha sucesso,
todos na organização precisam respeitar suas decisões. Ninguém tem a permissão de dizer
ao Time para trabalhar em um ou outro conjunto de prioridades, e os Times não podem dar
ouvidos a ninguém que diga o contrário. As decisões do Product Owner são visíveis no
conteúdo e na priorização do Backlog do Produto. Essa visibilidade requer que o Product
Owner faça seu melhor, o que faz o papel de Product Owner exigente e recompensador ao
mesmo tempo;
Team (em português, Time, Equipe de Desenvolvimento): transforma o Product Backlog
em incrementos de funcionalidades potencialmente entregáveis (do inglês, releases) em
cada Sprint (iteração do ciclo de execução). Apenas integrantes do Time geram
40
incrementos de funcionalidades e são multidisciplinares, ou seja, devem possuir todo o
conhecimento necessário para criar um incremento no trabalho. Os Times também não
contêm subtimes dedicados a áreas particulares como testes ou análise de negócios, são
auto-organizáveis; ninguém – nem mesmo o Scrum Master – diz ao time como transformar
o Product Backlog em incrementos de funcionalidades entregáveis. O Time descobre por si
só. Cada membro do Time aplica sua especialidade a todos os problemas. A sinergia que
resulta disso melhora a eficiência e eficácia 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 interação e, como resultado, há
menor ganho de produtividade. Mais do que isso, o time poderá encontrar limitações de
conhecimento durante partes da Sprint e não ser capaz de entregar uma parte pronta do
produto. Se há mais do que nove membros, há simplesmente a necessidade de muita
coordenação. Os times grandes geram muita complexidade para gerenciar um processo
empírico. O Product Owner e o Scrum Master não estão incluídos nessa conta, a menos
que também estejam trabalhando em tarefas do Sprint Backlog. A composição do Time
pode mudar ao final da Sprint. Toda vez que o Time muda, a produtividade ganha através
da auto-organização é reduzida.
3.2 GERÊNCIA DE PROJETOS NO SCRUM
O Scrum define conceitos importantes referentes à aplicação do processo no
período do projeto. Esses conceitos fundamentam práticas importantes para definir a
estratégia de inspeção e adaptação do projeto, fornecendo uma excelente visibilidade do
andamento dos trabalhos, juntamente com uma importante previsibilidade do que acontecerá
no futuro.
3.2.1 Artefatos
Conforme Schwaber (SCHWABER e SUTHERLAND, 2010), o Scrum introduz
alguns importantes artefatos utilizados ao longo do ciclo de execução do projeto:
Product Backlog (do português, Backlog do Produto): o Backlog do Produto é uma
lista ordenada de tudo que deve ser necessário no produto, e é uma origem única
dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é
responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e
41
ordenação. Deve estar priorizado por ordem de importância para o negócio. O
Backlog do Produto é dinâmico; mudando constantemente para identificar o que o
produto necessita para ser mais apropriado, competitivo e útil e existirá enquanto o
produto também existir. Este é o artefato mais importante utilizado dentro da
metodologia (MAGNO, 2009). É através 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 máximo de retorno de investimento com o sistema em
menor tempo possível;
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 previsão do Time sobre qual
funcionalidade estará no próximo incremento e do trabalho necessário 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 é necessário, o Time adiciona este ao
Backlog da Sprint. Conforme o trabalho é realizado ou completado, a estimativa do
trabalho restante é atualizada. Quando elementos do plano são considerados
desnecessários, eles são removidos. Somente o Time pode alterar o Backlog da
Sprint durante a Sprint;
Impediment Backlog: contém todos os itens que impedem o progresso do projeto e
geralmente estão associados a riscos. Estes itens podem possuir uma priorização,
mas estão 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 responsável pela liberação desses
impedimentos, abrindo caminho para o time de desenvolvimento executar a
realização dos itens do Product Backlog;
Incremento de Funcionalidade do Produto (do inglês, Release): o time deverá
entregar incrementos de funcionalidade a cada Sprint. Os incrementos de
funcionalidade consistem de códigos testados, bem estruturados e bem escritos,
que são executáveis acompanhados da documentação necessária para a sua
operação (MARÇAL, 2009);
Quadro de Tarefas (Kanban): Quadro de trabalho onde o time organiza as
atividades, dos itens do Sprint Backlog, separando-as basicamente em cinco
42
estados: Para fazer, Em andamento (inclui o nome do responsável por executar a
tarefa), Para Verificar, Pendente e Concluído. Este quadro é muito prático 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 (MARÇAL, 2009).
3.2.2 Ciclo de Execução do Projeto no Scrum
Um projeto no Scrum se inicia com uma visão do produto que será desenvolvido. A
visão contém a lista das características do produto estabelecidas pelo cliente (Product
Backlog), além de algumas premissas e restrições. Em seguida, o Product Backlog é criado
contendo a lista de todos os requisitos conhecidos. O Product Backlog é então priorizado e
dividido em releases (SCHWABER e SUTHERLAND, 2010). A Figura 4 ilustra o ciclo de
execução do Scrum e mostra os artefatos e principais planejamentos.
Figura 4 - Ciclo de Execução do Scrum. Elaborada pelo autor.
O Scrum é planejado e executado em torno de iterações chamadas de Sprints
conforme detalhado a seguir:
Sprint: é uma iteração com duração fixa que pode durar de duas a quatro semanas
conforme o planejamento do projeto e é durante a execução da Sprint que a versão
incremental do produto (release) é criada. Uma nova Sprint começa imediatamente após a
conclusão da anterior. Durante a Sprint, o Scrum Master garante que não será feita
Product BacklogSprint Backlog
2-4 Semanas
24 Horas
Incremento do Produto
Reuniões Diárias
Sprint
43
nenhuma mudança que possa afetar a meta da Sprint. Tanto a composição 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 período 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): reunião que ocorre no início de um
projeto com a presença do Product Owner, do Scrum Master e do Time. Para
uma Sprint de quatro de semanas, o recomendado é que esta reunião tenha
duração de 8 (oito) horas, para Sprints menores o tempo é reduzido
proporcionalmente. A reunião é dividida em duas partes e respondem
objetivamente: o que será entregue como resultado do incremento da próxima
Sprint (o Product Owner apresenta os requisitos de maior valor e prioriza
aqueles que devem ser implementados) e como o trabalho necessário para
entregar o incremento será realizado;
o Execução: Durante a execução do Sprint, para cada história ou requisito todo o
time participa do processo de estimativa, podendo ser utilizado o Planning
Poker para a obtenção de tais estimativas. O time controla o andamento do
desenvolvimento, realizando reuniões diárias rápidas (Daily Meeting), não
mais que 15 minutos de duração. Quando não se consegue desenvolver um
incremento completo dentro de uma Sprint, surgem duas categorias de
incremento: o trabalho “pronto” e o trabalho “não pronto”. O trabalho “não
pronto” é a porção de cada incremento que terá que ser completada mais tarde.
Nestas reuniões diárias, cada membro do time responde a três perguntas
básicas: O que eu fiz no projeto desde a última reunião? O que irei fazer até a
próxima reunião? Quais são os impedimentos? O Product Owner sabe
exatamente o que ele está inspecionando ao final da Sprint, porque o
incremento atende à definição de “pronto” e o Product Owner entende essa
definição. O trabalho “não pronto” é adicionado a um item do Product
Backlog, de forma que ele se acumula. O progresso do Sprint é observando
usando um gráfico chamado Sprint Burndown (conforme a Figura 5), que
44
mostra ao longo do tempo a quantidade de trabalho que ainda resta ser feito,
um ótimo mecanismo para visualizar a correlação entre a quantidade de
trabalho que falta ser feita e o progresso do time do projeto em reduzir este
trabalho;
Figura 5 - Gráfico Burndown (MAGNO, 2009, p. 33)
o Revisão (Sprint Review): Ao final do Sprint, é realizada a reunião de revisão
(Sprint Review Meeting) para que o time apresente o resultado alcançado na
iteração ao Product Owner. Neste momento, as funcionalidades são
inspecionadas e adaptações 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): Após a reunião de revisão, o Scrum
Master conduz a reunião de retrospectiva (Sprint Retrospective Meeting),
com o objetivo de levantar informações para melhorar o processo/time e/ou
produto para a próxima 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 não funcionou durante a Sprint
(MAGNO, 2009).
45
3.3 CONSIDERAÇÕES FINAIS
A dinâmica da metodologia ágil Scrum favorece a entrega rápida do produto ou
partes dele para o cliente e com isso permite antecipar os benefícios da automatização do
produto ou processo. A equipe de desenvolvimento é focada na entrega do produto e portanto
utiliza poucos artefatos de documentação de requisitos e de gerência de projetos. No entanto,
os responsáveis por fazer tais adaptações devem ter informação adequada para que possam
tomar as melhores decisões para o projeto. Pelo fato do Scrum ser uma metodologia ágil
focada na gerência de projetos é interessante analisar a possibilidade de sua integração com
outras práticas que também visem um melhor gerenciamento dos projetos, como é o caso do
modelo MPS.BR, permitindo agilidade nos processos, mas sem deixar de utilizar as boas
práticas de gerenciamento, permitindo assim que uma empresa tente se certificar com
maturidade nos seus processos pelo MPS.BR. A possibilidade desta integração é o alvo da
análise no próximo capítulo.
46
4 ANÁLISE DE COMPATIBILIDADE DO SCRUM COM O
PROCESSO GERÊNCIA DE PROJETOS DO MPS.BR
O propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as
atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o
andamento do projeto que permitam a realização de correções quando houver desvios
significativos no desempenho do projeto. O processo de Gerência 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 institucionalização com que o processo é executado na unidade organizacional.
No MR-MPS-SW, à medida que a unidade organizacional evolui nos níveis de maturidade,
um maior nível de capacidade para desempenhar o processo deve ser atingido.
Para atingir o nível de maturidade G, o processo de Gerência 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 Nível 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 política organizacional estabelecida e mantida para o processo;RAP 3. A execução do processo é planejada;
RAP 4. A execução do processo é monitorada e ajustes são realizados;
RAP 5. As informações e os recursos necessários para a execução do processo são identificados e disponibilizados;
RAP 6. As responsabilidades e a autoridade para executar o processo são definidas, atribuídas e comunicadas;
RAP 7. As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência;
47
RAP 8. A comunicação entre as partes interessadas no processo é planejada e executada de forma a garantir o seu envolvimento;
RAP 9. Os resultados do processo são revistos com a gerência de alto nível para fornecer visibilidade sobre a sua situação na organização;
Para o nível de maturidade G, o processo de Gerência de Projetos exige os seguintes
Resultados Esperados, conforme detalhado no Capítulo 2:
GPR 1. O escopo do trabalho para o projeto é definido;
GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando
métodos apropriados;
GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos;
GPR 4. (Até o nível F) O esforço e o custo para a execução das tarefas e dos produtos de
trabalho são estimados com base em dados históricos ou referências técnicas;
GPR 5. O orçamento e o cronograma do projeto, incluindo a definição de marcos e
pontos de controle, são estabelecidos e mantidos;
GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de
ocorrência e prioridade de tratamento são determinados e documentados;
GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil e o
conhecimento necessários para executá-lo;
GPR 8. (Até o nível F) Os recursos e o ambiente de trabalho necessários para executar o
projeto são planejados;
GPR 9. Os dados relevantes do projeto são identificados e planejados quanto à forma de
coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los,
incluindo, se pertinente, questões de privacidade e segurança;
GPR 10. Um plano geral para a execução do projeto é estabelecido com a integração de
planos específicos;
GPR 11. A viabilidade de atingir as metas do projeto é explicitamente avaliada
considerando restrições e recursos disponíveis. Se necessário, ajustes são 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 orçamento e o cronograma do projeto são
monitorados em relação ao planejado;
48
GPR 14. Os recursos materiais e humanos bem como os dados relevantes do projeto são
monitorados em relação ao planejado;
GPR 15. Os riscos são monitorados em relação ao planejado;
GPR 16. O envolvimento das partes interessadas no projeto é planejado, monitorado e
mantido;
GPR 17. Revisões são realizadas em marcos do projeto e conforme estabelecido no
planejamento;
GPR 18. Registros de problemas identificados e o resultado da análise de questões
pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes
interessadas;
GPR 19. Ações para corrigir desvios em relação ao planejado e para prevenir a repetição
dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua
conclusão;
Com base na importância dos resultados esperados no contexto do MPS.BR para o
Processo de Gerência de Projetos, bem como suas contribuições para a satisfação dos
atributos de processo do modelo, este capítulo do trabalho é responsável por avaliar a
compatibilidade do Scrum ao MPS.BR, através do modelo de avaliação MA-MPS, no que diz
respeito à Gerência de Projetos. A seção seguinte detalha como será realizada a avaliação de
compatibilidade do Scrum com o MPS.BR. Na seção 4.2 é realizada a análise da
compatibilidade do Scrum com o MPS.BR aplicando o método formal de avaliação MA-MPS.
Na seção 4.3 é feita a classificação provável do nível de maturidade alcançado pelo Scrum
para o processo de Gerência de Projetos caso um projeto utilizasse esta metodologia ágil. E na
seção 4.4 são feitas as considerações finais sobre a análise realizada.
4.1 PREPARAÇÃO PARA A AVALIAÇÃO UTILIZANDO O MÉTODO MA-MPS
Conforme visto no Capítulo 2, a preparação para a avaliação de uma unidade organizacional
que almeja se certificar MPS.BR exige grande dedicação, que vai desde da contratação de
uma instituição avaliadora, passando pela seleção de projetos, a avaliação propriamente dita, a
atribuição do nível de maturidade e o encerramento. Como o foco deste trabalho não é a
avaliação de uma unidade organizacional e sim de um framework de gerência de projetos ágil,
Scrum, este trabalho irá avaliar apenas os resultados esperados do processo de Gerência de
Projetos frente ao Scrum, onde o mesmo será aqui caracterizado como um projeto.
49
Diante do exposto, este trabalho irá executar a tarefa "Caracterizar o grau de
implementação de cada resultado esperado do processo em cada projeto" (adaptada, pois não
é escopo do trabalho avaliar frente aos resultados esperados de cada atributo de processo) que
pertence à atividade "Conduzir a Avaliação Final" do Subprocesso "Realizar a Avaliação
Final" do MA-MPS (vide seção 2.3). Para tanto, serão feitas as seguintes adaptações:
Para cada resultado esperado do processo de Gerência de Projeto (GPRs) será exibida uma
tabela dos Indicadores de Implementação, conforme a Tabela 8;
No que diz respeito aos indicadores de implementação, o indicador Afirmações (vide
Atividade Preparar a Avaliação, seção 2.3.1.3) não fará parte desta avaliação, pelo fato da
avaliação ser realizada no Scrum e não em um projeto que utilize o Scrum. Assim não será
feita nenhuma entrevista com os envolvidos;
Quando houver alguma ponto fraco identificado nos indicadores de implementação, ele
será descrito na coluna Ponto(s) Fraco(s) na tabela de indicadores.
Tabela 8 - Exemplo de Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Artefatos Diretos Scrum Artefatos Indiretos Scrum Ponto(s) Fraco(s)
GPR 1. O escopo do trabalho para o projeto é definido;
Product Backlog;Sprint Backlog.
Reunião de Planejamento (Sprint Planning Meeting).
Para cada Resultado Esperado do processo de Gerência de Projetos será exibida uma tabela
com o resultado da escala para caracterização do grau de implementação. A Tabela 9 exibe
um exemplo;
Tabela 9 - Exemplo de Escala de Caracterização para cada Resultado Esperado. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Totalmente Implementado (T) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Não foi notado nenhum ponto fraco substancial.
Ao fim da avaliação de cada resultado esperado será feita a explicação (análise da
avaliação) de como se obteve tal conclusão;
50
Ao final de todos os resultados esperados, na seção 4.3, será feita a análise de satisfação da
do processo, baseado na satisfação ou não de seus resultados esperados, resultando no
provável nível de maturidade do mesmo.
4.2 ANÁLISE DE COMPATIBILIDADE DO SCRUM COM O MPS.BR
Esta seção é responsável por realizar a análise da compatibilidade do Scrum com o MPS.BR e
por fornecer os resultados desta análise, visando esclarecer a possibilidade, ou não, da
integração entre os dois. A análise será realizada conforme explicado na seção anterior, onde
serão avaliados os resultados esperados do processo de Gerência de Projetos. Para tanto, será
criado uma tabela com os Indicadores de Implementação para cada resultado esperado e, logo
em seguida, uma tabela com a escala de caracterização se o Scrum está ou não aderente ao
MPS.BR para aquele resultado esperado específico.
4.2.1 GPR 1. O escopo do trabalho para o projeto é definido
a) Tabela com os Indicadores de Implementação
Tabela 10 - GPR 1. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 1. O escopo do trabalho para o projeto é definido;
Product Backlog;Sprint Backlog.
Reunião de Planejamento (Sprint Planning Meeting).
No Scrum não existe um documento formal para documentar os limites e restrições do projeto. Isto é identificado no dia a dia, nas reuniões de diárias de acompanhamento.
b) Escala de Caracterização de acordo com os Indicadores
Tabela 11 - GPR 1. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Totalmente Implementado (T) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Não foi notado nenhum ponto fraco substancial.
51
c) Análise da Avaliação
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 são
guardados todos os requisitos ou histórias de usuário do projeto e o Sprint Backlog onde
estão os requisitos da Sprint. O Scrum, por ser uma metodologia ágil, não trabalha com
escopo fechado do projeto. Uma Sprint possui escopo previamente definido e por ter
duração de no máximo quatro semanas possui probabilidade menor de acontecer mudança
de escopo durante sua execução. Caso aconteça mudança de escopo, esse novo requisito
será repriorizado e entrará ou não no ciclo de execução da próxima Sprint. A Tabela 11
classifica este resultado esperado como Totalmente Implementado pelo Scrum, indicando a
presença de artefatos diretos e indiretos, e nenhuma fraqueza substancial percebida.
4.2.2 GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados
utilizando métodos apropriado
a) Tabela com os Indicadores de Implementação
Tabela 12 - GPR 2. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados
Story Points;Product Backlog;Sprint Backlog;
Priorização baseada na estimativa Planning Poker.Reunião de Planejamento (Sprint Planning Meeting).
Não observado.
b) Escala de Caracterização de acordo com os Indicadores
Tabela 13 - GPR 2. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Totalmente Implementado (T) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Não foi notado nenhum ponto fraco substancial.
52
c) Análise da Avaliação
Este resultado esperado define a necessidade de se estabelecer uma estimativa de tamanho
de projeto. Conforme mostrado, o Scrum utiliza de técnicas de estimativa ágeis, como
Planning Poker. No Planning Poker todos os membros da equipe dão um valor de
complexidade técnica (story point) e de esforço para o desenvolvimento de cada um dos
requisitos definidos. Baseado nisso, e no valor de negócio do requisito para o usuário é
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 são executados na primeira Sprint. À medida que a equipe vai executando
as Sprints é calculado a velocidade da equipe (quantos requisitos, baseado no valor da
complexidade técnica, a equipe suporta por Sprint). A Tabela 13 classifica este resultado
esperado como Totalmente Implementado pelo Scrum, indicando a presença de artefatos
diretos e indiretos, e nenhuma fraqueza percebida.
4.2.3 GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos
a) Tabela com os Indicadores de Implementação
Tabela 14 - GPR 3. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos;
Release Plan;Ciclo de vida iterativo da Sprint composto por 4 fases: Planejamento, Execução, Revisão e Retrospectiva.
Reunião de Planejamento da Sprint;
Não observado.
b) Escala de Caracterização de acordo com os Indicadores
Tabela 15 - GPR 3. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Totalmente Implementado (T) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Não foi notado pontos fracos.
53
c) Análise da Avaliação
Este resultado esperado define a necessidade de se estabelecer um planejamento de todo o
projeto. No início de um projeto o time criará um Release Plan em alto nível. O Release
Plan detalha: a quantidade e a duração dos Sprints, quantas pessoas ou times deverão
participar do projeto, o número de releases, o valor a ser entregue em cada release e a data
de liberação dos release. Conforme mostrado, a Sprint possui quatro fases: Planejamento,
Execução, Revisão e Retrospectiva. Cada uma dessas fases são executadas dentro de cada
Sprint. O Scrum trabalha com o Product Backlog, que é composto por todos os requisitos
do projeto. Na reunião de priorização do Product Backlog, é definido quais os requisitos
entrarão no primeiro ciclo de desenvolvimento, Sprint. Os demais requisitos que constam
no Product Backlog serão repriorizados para próxima 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 presença de artefatos diretos e indiretos, e nenhuma
fraqueza percebida.
4.2.4 GPR 4. O esforço e o custo para a execução das tarefas e dos produtos de
trabalho são estimados com base em dados históricos ou referências técnicas
a) Tabela com os Indicadores de Implementação
Tabela 16 - GPR 4. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 4. O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas;
Product Backlog;Sprint Backlog;
Estimativas através do Planning Poker;
O Scrum não trabalha explicitamente com custo (MARÇAL, 2009);
54
b) Escala de Caracterização de acordo com os Indicadores
Tabela 17 - GPR 4. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Largamente Implementado (L) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Foi notado um ou mais pontos fracos substanciais.
c) Análise da Avaliação
Este resultado esperado define a necessidade de se estabelecer uma estimativa de esforço e
de custo do projeto. Conforme mostrado, o Scrum utiliza de técnicas de estimativa ágeis,
como Planning Poker. No Planning Poker todos os membros da equipe dão um valor de
complexidade técnica e de esforço para o desenvolvimento de cada um dos requisitos
definidos. Baseado nisso, e no valor de negócio do requisito para o usuário é 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
são executados na primeira Sprint. Apesar de explicitamente o Scrum não 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 presença de artefatos diretos e
indiretos, e a percepção de um ponto fraco.
4.2.5 GPR 5. O orçamento e o cronograma do projeto, incluindo a definição de marcos
e pontos de controle, são estabelecidos e mantidos;
a) Tabela com os Indicadores de Implementação
Tabela 18 - GPR 5. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 5. O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são
Product Backlog;Sprint Backlog;Quadro de Tarefas (Kanban);
Reunião de Planejamento da Sprint (Scrum Planning Meeting);
O Scrum não trabalha explicitamente com custo (MARÇAL, 2009);
55
estabelecidos e mantidos;
b) Escala de Caracterização de acordo com os Indicadores
Tabela 19 - GPR 5. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Largamente Implementado (L) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Foi notado um ou mais pontos fracos substanciais.
c) Análise da Avaliação
Este resultado esperado define a necessidade de se estabelecer um orçamento e cronograma
do projeto. Conforme mostrado, o cronograma pode ser obtido a partir do Product Backlog
que é dividido em sprints considerando a alocação do time de acordo com a sua
capacidade. No Sprint Backlog é elaborado uma lista de tarefas para que os requisitos da
Sprint sejam atendidos. Cada tarefa possui um responsável e o tempo de execução. O
cronograma é obtido após esta distribuição de tarefas. A execução destas tarefas são
acompanhadas pelo Scrum Master diariamente através das Reuniões Diárias (Daily
Meeting) e através 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 presença de artefatos diretos e indiretos, e um ponto fraco percebido.
4.2.6 GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de
ocorrência e prioridade de tratamento são determinados e documentados;
a) Tabela com os Indicadores de Implementação
Tabela 20 - GPR 6. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 6. Os riscos do projeto são identificados e seu impacto,
Impediment Backlog; Resultado das Reuniões Diárias (Daily Meeting);
A lista de impedimento do Scrum não retrata a probabilidade de ocorrência.
56
probabilidade de ocorrência e prioridade de tratamento são determinados e documentados;
b) Escala de Caracterização de acordo com os Indicadores
Tabela 21 - GPR 6. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Largamente Implementado (L) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Foi notado um ou mais pontos fracos substanciais.
c) Análise da Avaliação
Este resultado esperado define a necessidade de se estabelecer um controle sobre os riscos
do projeto, através da identificados e acompanhamento dos mesmos. Conforme mostrado,
a lista de riscos do projeto é o chamado Impediment Backlog onde são listados todos os
riscos/problemas que afetam a Sprint ou o projeto. Esta lista pode ser priorizada, mas
geralmente não é, pois todos os impedimentos são acompanhados diariamente através das
reuniões diárias onde cada membro do time diz o que fez, o que falta fazer e os seus
problemas ou dificuldades. Esse riscos são minimizados diariamente. A Tabela 21
classifica este resultado esperado como Largamente Implementado pelo Scrum, indicando
a presença de artefatos diretos e indiretos, e um ponto fraco percebido, pois o Scrum não
disciplina a formalização desses riscos através da probabilidade de ocorrência, visto que
são formalmente acompanhados diariamente.
57
4.2.7 GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil
e o conhecimento necessários para executá-lo;
a) Tabela com os Indicadores de Implementação
Tabela 22 - GPR 7. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo;
Reunião de Planejamento da Sprint (Planning Scrum Meeting) determina uma equipe multifuncional e auto-suficiente;Reuniões Diárias (Daily Meeting);
O Scrum não possui um documento formal com as habilidades dos membros do Time
b) Escala de Caracterização de acordo com os Indicadores
Tabela 23 - GPR 7. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Parcialmente Implementado (P) - O indicador direto não está presente ou é julgado inadequado;- Artefatos/Afirmações sugerem que alguns aspectos do resultado esperado está implementado;- Pontos Fracos foram implementados.
c) Análise da Avaliação
Este resultado esperado define a necessidade de se estabelecer e planejar os recursos
humanos do projeto através de suas habilidades. Conforme mostrado no capítulo anterior, o
time Scrum é composto pelo product owner, o time de desenvolvimento e o scrum master.
Times Scrum são auto-organizáveis e multifuncionais. Equipes auto-organizáveis escolhem
qual a melhor forma para completarem seu trabalho e possuem todas as competências
necessárias para completar o trabalho sem depender de outros que não fazem parte da
equipe. O modelo de equipe no Scrum é projetado para aperfeiçoar a flexibilidade,
criatividade e produtividade. Apesar de não possuir um documento formal para controle e
análise das competências, o Scrum determina que o time deve ser escolhido tendo como
meta pessoas com todas as habilidades relacionadas às fases de desenvolvimento de
58
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 não existe um artefato direto com as habilidades do time e demais membros. Apesar
disso, o Scrum por ser uma metodologia ágil permite adaptações, podendo no início do
projeto traçar o perfil necessário para cada papel.
4.2.8 GPR 8. Os recursos e o ambiente de trabalho necessários para executar o projeto
são planejados;
a) Tabela com os Indicadores de Implementação
Tabela 24 - GPR 8. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 8. Os recursos e o ambiente de trabalho necessários para executar o projeto são planejados;
Product Backlog;Sprint Backlog;
Reunião de Planejamento da Sprint (Planning Scrum Meeting)Reuniões Diárias (Daily Meeting);
Não observado.
b) Escala de Caracterização de acordo com os Indicadores
Tabela 25 - GPR 8. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Totalmente Implementado (T) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Não foi notado nenhum ponto fraco substancial.
c) Análise da Avaliação
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 não apenas requisitos funcionais (user stories), mas também
requisitos não funcionais que necessitam de planejamento para a execução do requisito
funcional. A Tabela 25 classifica este resultado esperado como Totalmente Implementado
pelo Scrum, uma vez que os requisitos não funcionais do projeto e a configuração do
ambiente de trabalho podem ser executados dentro da sprint ou antes da início do projeto.
59
4.2.9 GPR 9. Os dados relevantes do projeto são identificados e planejados quanto à
forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para
acessá-los, incluindo, se pertinente, questões de privacidade e segurança;
a) Tabela com os Indicadores de Implementação
Tabela 26 - GPR 9. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 9. Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança;
Dados coletados na Reunião de Planejamento;Dados coletados conforme as necessidades do TimeQuadro de tarefas (Kanban);
Reunião de Planejamento da Sprint (Planning Scrum Meeting);Reuniões Diárias (Daily Meeting);
No Scrum não existe um plano de dados que formalize a identificação, coleta, armazenamento e distribuição (MARÇAL,2009).
b) Escala de Caracterização de acordo com os Indicadores
Tabela 27 - GPR 9. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Largamente Implementado (L) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Foi notado um ou mais pontos fracos substanciais.
c) Análise da Avaliação
Este resultado esperado define a necessidade de identificar, coletar, armazenar e distribuir
os dados para garantir a integridade e segurança 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 são planejados e definidos na reunião de planejamento da
Sprint. Todos os membros do time seguem o que foi definido e são criadas tarefas para eles
executadas. Estas tarefas são monitoradas diariamente, através das reuniões diárias e ficam
localizadas no quadro de tarefas, Kanban, de cada membro do time. Contudo, no Scrum
não há um plano de dados para formalizar a coleta, consolidação e divulgação das
60
informações 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.
4.2.10 GPR 10. Um plano geral para a execução do projeto é estabelecido com a
integração de planos específicos;
a) Tabela com os Indicadores de Implementação
Tabela 28 - GPR 10. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 10. Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos;
Visão do Produto;Product Backlog;Sprint Backlog;
Reunião de Planejamento da Sprint (Planning Scrum Meeting);
Não observado;
b) Escala de Caracterização de acordo com os Indicadores
Tabela 29 - GPR 10. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Totalmente Implementado (T) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Não foi notado nenhum ponto fraco substancial.
c) Análise da Avaliação
Este resultado esperado tem por objetivo estabelecer e manter o conteúdo do plano de
projeto De acordo com Schwaber (SCHWABER e SUTHERLAND, 2010), o plano
mínimo necessário para iniciar um projeto com o Scrum consiste de uma visão do produto
e do Product Backlog que são os artefatos diretos deste resultado esperado, conforme a
Tabela 28. A visão do produto descreve a razão 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 não funcionais que o sistema deverá atender para a entrega do
produto. O Sprint Backlog contém os requisitos que serão executados na próxima Sprint.
61
Unindo os três documentos, a visão do produto, o Product Backlog e o Sprint Backlog,
tem-se a base para a elaboração de um plano de projeto. A reunião de planejamento é
apontada como o artefato indireto da prática e nenhum ponto fraco foi observado.
Classificando, portanto, conforme a Tabela 29, este resultado esperado foi classificado
como Totalmente Implementado para o Scrum.
4.2.11 GPR 11. A viabilidade de atingir as metas do projeto é explicitamente avaliada
considerando restrições e recursos disponíveis. Se necessário, ajustes são realizados;
a) Tabela com os Indicadores de Implementação
Tabela 30 - GPR 11. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 11. A viabilidade de atingir as metas do projeto é explicitamente avaliada considerando restrições e recursos disponíveis. Se necessário, ajustes são realizados;
Visão do Produto;Product Backlog;Sprint Backlog;Impediment Backlog;
Reunião de Planejamento da Sprint (Planning Scrum Meeting);Sprint Review;
Não observado;
b) Escala de Caracterização de acordo com os Indicadores
Tabela 31 - GPR 11. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Totalmente Implementado (T) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Não foi notado nenhum ponto fraco substancial.
c) Análise da Avaliação
Este resultado esperado tem por objetivo estabelecer o estudo de viabilidade do escopo do
projeto e examina aspectos técnicos (requisitos e recursos), financeiros (capacidade da
organização) e humanos (disponibilidade de pessoas com a capacitação necessária)
(SOFTEX, 2011d). À medida que o projeto evolui, a viabilidade de sucesso pode ser
reavaliada com mais precisão. A cada nova sprint, na reunião de planejamento da sprint e
62
na sprint review todos os riscos do projeto são levantados e analisados, com isso a
viabilidade de continuidade do projeto é analisada. Durante a reunião Sprint Review o
projeto é avaliado baseado no objetivo, meta da Sprint. Outro ponto de análise são as
reuniões diárias que acompanha diariamente a execução 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.
4.2.12 GPR 12. O Plano do Projeto é revisado com todos os interessados e o
compromisso com ele é obtido e mantido;
a) Tabela com os Indicadores de Implementação
Tabela 32 - GPR 12. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 12. O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido e mantido;
Product Backlog;Sprint Backlog;
Reunião de Planejamento da Sprint (Planning Scrum Meeting);Sprint Review;
Não observado;
b) Escala de Caracterização de acordo com os Indicadores
Tabela 33 - GPR 12. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Totalmente Implementado (T) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Não foi notado nenhum ponto fraco substancial.
c) Análise da Avaliação
Este resultado esperado tem por objetivo estabelecer a revisão 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 próxima Sprint e a
revisão da Sprint que acabou de terminar, respectivamente. Com isso, nessas reuniões
todos os interessados no projeto são envolvidos, Product Owner, Scrum Master e o Time.
Assim, é reavaliado o escopo do projeto e nova priorização de requisitos pode acontecer.
63
Conforme mostrado, este resultado esperado foi classificado como Totalmente
Implementado, Tabela 33, e nenhum ponto fraco foi percebido.
4.2.13 GPR 13. O escopo, as tarefas, as estimativas, o orçamento e o cronograma do
projeto são monitorados em relação ao planejado;
a) Tabela com os Indicadores de Implementação
Tabela 34 - GPR 13. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 13. O escopo, as tarefas, as estimativas, o orçamento e o cronograma do projeto são monitorados em relação ao planejado;
Product Backlog;Sprint Backlog;Quadro de Tarefas Kanban;
Reunião de Planejamento da Sprint (Planning Scrum Meeting);Reuniões Diárias (Daily Meeting);
Não há monitoração em relação ao orçamento do projeto, pois o Scrum não trabalha explicitamente com custo (MARÇAL, 2009);
b) Escala de Caracterização de acordo com os Indicadores
Tabela 35 - GPR 13. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Largamente Implementado (L) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Foi notado um ou mais pontos fracos substanciais.
c) Análise da Avaliação
O objetivo deste resultado esperado é assegurar que haja monitoração do projeto em
relação a aspectos relacionados às tarefas, estimativas e cronograma. Em geral, durante um
monitoramento, faz-se uma análise do que foi planejado anteriormente com os valores
atuais das variáveis consideradas. No Scrum sempre no inicio de cada Sprint e ao final de
cada Sprint é realizado o planejamento da próxima Sprint e a revisão da Sprint que acabou
de terminar, respectivamente. Nas reuniões diárias são realizadas o acompanhamento
diário da realização das tarefas do time. A cada nova Sprint, as estimativas dos requisitos
funcionais e não funcionais necessários são recalculadas e assim, um novo cronograma da
Sprint é mantido. Conforme mostrado, este resultado esperado foi classificado como
64
Largamente Implementado, Tabela 35, pois foi observado o ponto fraco em relação ao
orçamento do projeto, pois o Scrum não trabalha explicitamente com custos, apesar de
possibilitar adaptações.
4.2.14 GPR 14. Os recursos materiais e humanos bem como os dados relevantes do
projeto são monitorados em relação ao planejado;
a) Tabela com os Indicadores de Implementação
Tabela 36 - GPR 14. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 14. Os recursos materiais e humanos bem como os dados relevantes do projeto são monitorados em relação ao planejado;
Sprint Backlog;Quadro de Tarefas, Kanban;
Reunião de Planejamento da Sprint (Planning Scrum Meeting);Reuniões Diárias (Daily Meeting);
Não observado;
b) Escala de Caracterização de acordo com os Indicadores
Tabela 37 - GPR 14. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Totalmente Implementado (T) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Não foi notado nenhum ponto fraco substancial.
c) Análise da Avaliação
O objetivo deste resultado esperado é garantir que o projeto seja monitorado em relação
aos itens planejados referentes a recursos materiais e recursos humanos. Em geral, durante
um monitoramento, faz-se uma análise do que foi planejado anteriormente com os valores
atuais das variáveis consideradas. No Scrum existem vários pontos de controle para cruzar
as informações do que foi planejado com o que está sendo realizado, entre eles o backlog
da Sprint, a reunião de planejamento da Sprint e as reuniões diárias. Caso algum
impedimento aconteça, como a saída de algum membro da equipe ou a necessidade de
algum recurso material, isto estará sendo monitorado nessas reuniões e as medidas
65
provenientes serão tomadas. Conforme mostrado, este resultado esperado foi classificado
como Totalmente Implementado, Tabela 37.
4.2.15 GPR 15. Os riscos são monitorados em relação ao planejado;
a) Tabela com os Indicadores de Implementação
Tabela 38 - GPR 15. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 15. Os riscos são monitorados em relação ao planejado;
Impediment Backlog; Reunião de Planejamento da Sprint (Planning Scrum Meeting);Reuniões Diárias (Daily Meeting);
Não observado;
b) Escala de Caracterização de acordo com os Indicadores
Tabela 39 - GPR 15. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Totalmente Implementado (T) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Não foi notado nenhum ponto fraco substancial.
c) Análise da Avaliação
No decorrer do projeto novos riscos podem ser identificados para o projeto e os parâmetros
dos riscos já identificados podem ser alterados. Além disso, pode ser necessário executar
ações de mitigação para evitar que os riscos aconteçam ou, no caso de riscos terem se
concretizado, pode ser preciso executar ações de contingência para minimizar seus efeitos.
Também é importante que a lista de riscos seja reavaliada periodicamente em conjunto
com uma avaliação dos seus parâmetros de análise e prioridade (SOFTEX, 2011d). No
Scrum a lista de impedimentos da Sprint é revisada diariamente através das reuniões
diárias de acompanhamento. Todos os dias o time trabalha com intuito de minimizar
concretização dos riscos e na resolução de problemas. Conforme mostrado, este resultado
esperado foi classificado como Totalmente Implementado, Tabela 39.
66
4.2.16 GPR 16. O envolvimento das partes interessadas no projeto é planejado,
monitorado e mantido;
a) Tabela com os Indicadores de Implementação
Tabela 40 - GPR 16. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 16. O envolvimento das partes interessadas no projeto é planejado, monitorado e mantido;
Product Backlog;Sprint Backlog;
Reunião de Planejamento da Sprint (Planning Scrum Meeting);
Não observado;
b) Escala de Caracterização de acordo com os Indicadores
Tabela 41 - GPR 16. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Totalmente Implementado (T) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Não foi notado nenhum ponto fraco substancial.
c) Análise da Avaliação
Devem ser identificados os interessados relevantes no projeto, em que fases eles são
importantes e como eles serão 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 reúnem na reunião de planejamento da Sprint para revisar a priorização dos
requisitos, mantendo constantemente os interessados nos projetos participando das
decisões. Conforme mostrado, este resultado esperado foi classificado como Totalmente
Implementado, Tabela 41.
67
4.2.17 GPR 17. Revisões são realizadas em marcos do projeto e conforme estabelecido
no planejamento;
a) Tabela com os Indicadores de Implementação
Tabela 42 - GPR 17. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 17. Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento;
Sprint Review;Retrospectiva da Sprint;
Reunião de Planejamento da Sprint (Planning Scrum Meeting);
Não observado;
b) Escala de Caracterização de acordo com os Indicadores
Tabela 43 - GPR 17. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Totalmente Implementado (T) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Não foi notado nenhum ponto fraco substancial.
c) Análise da Avaliação
Este resultado é importante porque as revisões em marcos são oportunidades para verificar,
de forma ampla, o andamento de todo o projeto, independente do acompanhamento do dia-
a-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 reunião eles identificam pontos de melhoria. No Scrum a cada nova
Sprint os envolvidos no projeto, o Product Owner, Scrum Master e o Time se reúnem na
reunião de planejamento da Sprint para revisar a priorização dos requisitos e, assim, os
interessados nos projetos estão constantemente participando das decisões. Conforme
mostrado, este resultado esperado foi classificado como Totalmente Implementado, Tabela
43.
68
4.2.18 GPR 18. Registros de problemas identificados e o resultado da análise de questões
pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes
interessadas;
a) Tabela com os Indicadores de Implementação
Tabela 44 - GPR 18. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 18. Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas;
Impediment Backlog; Sprint Review;Reuniões Diárias;
Não observado;
b) Escala de Caracterização de acordo com os Indicadores
Tabela 45 - GPR 18. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Totalmente Implementado (T) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Não foi notado nenhum ponto fraco substancial.
c) Análise da Avaliação
As atividades de revisão em marcos e de monitoramento do projeto possibilitam a
identificação de problemas que estejam ocorrendo nos projetos. É natural que problemas e
desvios em relação ao planejamento aconteçam durante a execução dos projetos. Estes
problemas e desvios devem ser analisados e registrados, por exemplo, por meio de
ferramentas específicas, planilhas ou outros tipos de mecanismos de gerenciamento de
problemas. No Scrum, diariamente, nas reuniões diárias e mensalmente ao final da Sprint é
feito um levantamento e acompanhamento dos problemas através de uma lista priorizada
de impedimentos. Conforme mostrado, este resultado esperado foi classificado como
Totalmente Implementado, Tabela 45.
69
4.2.19 GPR 19. Ações para corrigir desvios em relação ao planejado e para prevenir a
repetição dos problemas identificados são estabelecidas, implementadas e
acompanhadas até a sua conclusão;
a) Tabela com os Indicadores de Implementação
Tabela 46 - GPR 19. Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Gerência de ProjetosResultado Esperado
Indicadores Diretos Scrum
Indicadores Indiretos Scrum
Ponto(s) Fraco(s)
GPR 19. Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão;
Impediment Backlog;Quadro de Tarefas Kanban;
Sprint Review;Reuniões Diárias;Retrospectiva da Sprint;
Não observado;
b) Escala de Caracterização de acordo com os Indicadores
Tabela 47 - GPR 19. Classificação de acordo com os Indicadores de Implementação. Elaborada pelo autor com base em SOFTEX (2012c).
Classificação Significado
Totalmente Implementado (T) - O indicador direto está presente e é julgado adequado;- Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação;- Não foi notado nenhum ponto fraco substancial.
c) Análise da Avaliação
Como resultado do acompanhamento do projeto e das revisões em marcos, problemas são
identificados, analisados e registrados. Ações corretivas devem ser estabelecidas para
resolver problemas que possam impedir o projeto de atingir seus objetivos se não forem
resolvidos de forma adequada. As ações corretivas definidas devem ser gerenciadas até
serem concluídas. O controle dos problemas levantados, as ações tomadas, os responsáveis
pelas ações e os resultados devem ser registrados. No Scrum, diariamente, nas reuniões
diárias e mensalmente ao final da Sprint é feito um levantamento e acompanhamento dos
problemas através 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
70
pontos de melhoria no processo. Conforme mostrado, este resultado esperado foi
classificado como Totalmente Implementado, Tabela 47.
71
4.3 CLASSIFICAÇÃO DO NÍVEL DE MATURIDADE DO SCRUM NO
PROCESSO DE GERÊNCIA DE PROJETOS
Conforme análise feita, na seção 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 (Seção 4.2.7). O resultado esperado que foi classificado como Parcialmente
Implementado, conforme já explicado anteriormente, foi em virtude do Scrum não prevê um
plano claro de escolha de competências 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 implementação do Processo
de Gerência de Projetos do MPS.BR com a metodologia ágil Scrum.
68%
26%
5%
Caracterização do grau de implemen-tação do Scrum
Totalmente ImplementadoLargamente ImplementadoParcialmente Implementado
Figura 6 - Caracterização do grau de implementação do Scrum. Elaborada pelo autor.
O processo de avaliação MA-MPS considera várias regras para caracterizar uma empresa em
grau de maturidade ou de capacidade de um processo. Uma das regras é justamente a análise
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 instituição e ao mesmo tempo ser aderente às
melhores práticas do MPS.BR no tocante ao processo de Gerência de Projetos. O que foi visto
é que o Scrum pode sim ser implementado e é aderente (compatível) à maioria dos resultados
72
esperados do MPS.BR. Alguns pontos fracos foram observados, o que requer atenção caso
uma empresa queira se certificar MPS.BR. Resolvendo a questão 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 Nível G de
maturidade/capacidade do MPS.BR. O trabalho de Marçal (MARÇAL, 2009) mostra que o
Scrum também pode ser aderente ao CMMI (SEI, 2012).
4.4 CONSIDERAÇÕES FINAIS
Alguns trabalhos relacionados fizeram análise de áreas de processo do CMMI com a
metodologia ágil Scrum, como os trabalhos de Zanatta (ZANATTA e VILAIN, 2005), Chaves
(CHAVES, 2011) e Marçal (MARÇAL, 2009). Como dito, o foco deles foi em relação 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 adaptações, uma vez que o MPS.BR exige um grau maior de
formalismo para evidenciar a execução das atividades, umas vez que o Scrum por se tratar de
uma metodologia ágil, evita a utilização de documentos excessivos, e foca no que ele
considera mais importante: a comunicação.
Como a avaliação do presente trabalho foi feita em conformidade com o que propõe o
framework Scrum, é possível afirmar que tais pontos fracos podem ser corrigidos fazendo-se
as devidas adaptações do Scrum para a realidade da empresa que decidir adotá-lo, devendo-se
apenas tomar os devidos cuidados de não ferir as suas características de metodologia ágil.
Como sugestão de adaptação ao Scrum seria interessante:
inserir no Sprint Backlog ou Product Backlog informações de custo de
desenvolvimento para cada um dos user stories. Além da formalização de técnica de
estimativa de custo (pode-se usar o próprio planning poker);
inserir algum plano de coleta, consolidação, armazenamento e rastreamento dos
dados; e
73
a adição de um documento que contenha informações sobre os membros do time, suas
competências e habilidades.
Alguns autores sugerem a utilização de um Plano de Projeto para consolidação das
informações em um único documento, por exemplo, Marçal (MARÇAL, 2009).
74
5 CONCLUSÃO E TRABALHOS FUTUROS
Conforme exposto neste trabalho, o desenvolvimento de software vem crescendo nos últimos
anos em virtude, principalmente, do avanço da tecnologia em geral. Para desenvolver
software é necessário seguir um conjunto de processos que auxiliam no controle e
organização de todas as fases do processo de desenvolvimento. Os processos tradicionais de
desenvolvimento vem se mostrando burocráticos 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 rápido, eliminando as documentações excessivas,
enfatizando a iteração entre as pessoas e focando no resultado final: entrega do produto para o
usuário. Em paralelo, os usuários também se tornaram mais exigentes e cobram cada mais vez
qualidade no desenvolvimento dos seus produtos.
A qualidade de software também se tornou cada vez mais forte e com isso surgiram
modelos de processos, baseados em melhores práticas e tendo como foco a melhoria dos
processos e consequentemente a melhoria da qualidade dos produtos. Entre os modelos estão
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
adoção de uma metodologia ágil que propicie um maior controle das mudanças e maior
proximidade do usuário 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 solução para estas empresas seria a união das práticas do Scrum, trazendo a
agilidade das metodologias ágeis; com as práticas do MPS.BR focadas na melhoria de
processos das empresas desenvolvedoras de software brasileiras.
Acreditando na união de uma metodologia ágil com modelos de maturidade, este
trabalho se propôs a avaliar a possível compatibilidade entre o MPS.BR e o Scrum,
especificamente no que diz respeito ao processo de Gerência de Projetos. Tal avaliação foi
feita com a utilização do método de avaliação MA-MPS, que é um método para realizar
avaliações em empresas que queiram se certificar MPS.BR.
75
Tendo como base as informações resultantes da avaliação proposta, conclui-se que a
compatibilidade do Scrum com o MPS.BR não é apenas possível, mas recomendável às
empresas que querem aderir às metodologias ágeis, mas que não querem abrir mão de se
certificarem nos modelos de capacitação e maturidade; pois conforme mostrado no capítulo
anterior, a maioria dos resultados esperados (mas especificamente, 95%) são satisfeitas
utilizando o Scrum. Apesar disto, alguns pontos fracos foram apontadas referentes à falta de
alguns documentos formais. Contudo, estes pontos fracos podem ser contornados através de
adaptações à metodologia ágil, lembrando apenas de não ferir seu intuito principal que é a
entrega rápida de valor ao usuário.
Pretendendo dar continuidade ao presente trabalho e tendo como foco a melhoria
continua dos processos de desenvolvimento, seguem algumas sugestões de trabalhos futuros:
A realização de avaliação semelhante, utilizando o MA-MPS, para outras áreas de processo
do MPS.BR, como a área de Gerência de Requisito que pertence ao nível G de maturidade;
Realizar a avaliação de um ou mais projetos de uma empresa que utilize o Scrum,
utilizando o MA-MPS;
Com base nos resultados alcançados, considera-se que a compatibilidade do Scrum
com o MPS-BR é possível 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 práticas tradicionais.
76
6 REFERÊNCIAS BIBLIOGRÁFICAS
ARAUJO, R. et al. A Definição de Processos de Software sob o ponto de vista da Gestão
de Processos de Negócio. VI Simpósio Internacional de Melhoria de Processos de Software.
São 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 Análise 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.
MARÇAL, A. S. C. SCRUMMI: Um processo de gestão á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. Ministério de Ciência e Tecnologia. Pesquisa Nacional de Qualidade e
Produtividade no Setor de Software Brasileiro, Brasília, 2005. Disponivel em:
<http://www.mct.gov.br>. Acesso em: 06 novembrp 2008.
NEPONUCENO, B.; ALVES, L.; ALMEIDA, T. Metodologia e Documentação 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.; TORREÃO, P.; MARÇAL, 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/entendendo-
scrum-para-gerenciar-projetos-de-forma-gil>. Acesso em: 10 abr. 2013.
SANDRONI, P. Dicionário de Administração e Finanças. São Paulo: Record, 2008.
77
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-2006-
TR-008.
SOFTEX. Guia de Implementação Parte 1. [S.l.]: [s.n.], 2011d.
SOFTEX. Guia Geral MPS.BR. [S.l.]: [s.n.], 2012a.
SOFTEX. Guia Geral de Serviços MPS.BR. Brasília: [s.n.], 2012b. Disponivel em:
<http://www.softex.br/mpsbr>. Acesso em: 10 maio 2013.
SOFTEX. MPS.BR – Guia de Avaliação: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 análise do método á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.