119
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. Mota

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

Embed Size (px)

DESCRIPTION

Artigo

Citation preview

Page 1: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 2: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 3: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 4: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 5: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 6: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 7: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 8: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 9: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 10: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 11: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 12: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 13: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 14: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 15: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 16: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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;

Page 17: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 18: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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);

Page 19: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 20: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 21: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 22: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 23: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 24: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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:

Page 25: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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;

Page 26: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 27: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 28: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 29: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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:

Page 30: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 31: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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;

Page 32: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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:

Page 33: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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;

Page 34: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 35: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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;

Page 36: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 37: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 38: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 39: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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);

Page 40: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 41: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos 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.

Page 42: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 43: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 44: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 45: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 46: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 47: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 48: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 49: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 50: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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;

Page 51: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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;

Page 52: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 53: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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;

Page 54: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 55: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 56: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 57: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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);

Page 58: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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);

Page 59: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 60: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 61: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 62: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 63: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 64: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 65: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 66: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 67: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 68: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 69: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 70: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 71: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 72: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 73: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 74: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

70

pontos de melhoria no processo. Conforme mostrado, este resultado esperado foi

classificado como Totalmente Implementado, Tabela 47.

Page 75: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 76: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 77: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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

Page 78: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 79: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do 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.

Page 80: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.

Page 81: Análise de Compatibilidade Da Metodologia Ágil Scrum Com o Modelo de Processo de Gerência de Projetos Do Mps.br

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.