Programa de Pós-Graduação
Stricto Sensu
em
Gestão do Conhecimento e da Tecnologia da Informação
MODELO DE MONITORAMENTO E CONTROLE DE
PROJETOS DE DESENVOLVIMENTO DE SOFTWARE
CONDUZIDOS SOB O SCRUM
Brasília - DF
2015
ALEXANDRE GUIDO VALLERÃO
MODELO DE MONITORAMENTO E CONTROLE DE PROJETOS DE DESENVOLVIMENTO DE SOFTWARE CONDUZIDOS SOB O SCRUM
Dissertação apresentada ao Programa de Pós-Graduação Stricto Sensu em Gestão do Conhecimento e da Tecnologia da Informação da Universidade Católica de Brasília, como requisito parcial para obtenção do Título de Mestre em Gestão do Conhecimento e da Tecnologia da Informação.
Orientador: Prof. Dr. Luís Kalb Roses
7,5cm
Ficha elaborada pela Biblioteca Pós-Graduação da UCB
V184m Vallerão, Alexandre Guido.
Modelo de monitoramento e controle de projetos de desenvolvimento de software conduzidos sob o Scrum. / Alexandre Guido Vallerão – 2015.
84 f.; il.: 30 cm
Dissertação (Mestrado) – Universidade Católica de Brasília, 2015. Orientação: Prof. Dr. Luís Kalb Roses
1. Tecnologia da informação. 2. Scrum. 3. Métodos ágeis. 4. Monitoramento e controle. I. Roses, Luís Kalb, orient. II. Título.
AGRADECIMENTOS
Ao final desta longa jornada de construção de um trabalho de mestrado, é importante
destacar a colaboração de algumas pessoas e instituições, sem as quais não teria sido possível
alcançar o resultado final. Assim, gostaria de agradecer à Universidade Católica de Brasília e
ao Mestrado em Gestão do Conhecimento e da Tecnologia da Informação, que proveram um
programa capaz de unir dois mundos que muitas vezes são vistos como irremediavelmente
apartados. É importante também destacar o esmerado trabalho dos docentes desse programa,
que fazem do dia a dia do Mestrado uma experiência estimulante.
Um agradecimento especial deve ser feito também à Instituição pesquisada e aos
gestores do seu departamento de TI, que colaboraram imensamente com esta pesquisa. Da
mesma forma, muito deste trabalho foi obtido graças à ajuda dos gerentes que participaram da
pesquisa, disponibilizando parte do seu escasso tempo no compartilhamento de valiosas
experiências.
Ao longo de toda a pesquisa, contei com um grande apoio do Prof. Dr. Kalb, que na
condição de meu orientador, guiou meus primeiros passos na pesquisa acadêmica, oferecendo
revisões críticas, que possibilitaram um rico aprendizado tanto no campo da metodologia da
pesquisa científica como na Gestão de TI.
Durante todo este período, contei com o apoio constante de meus pais, Jorge e Loiva,
que mesmo distantes sempre se mostraram dispostos a ajudar-me naquilo que fosse possível.
Por fim, gostaria de agradecer a Sandra, minha esposa, pelo carinho, paciência e compreensão
RESUMO
Referência: VALLERÃO, Alexandre Guido Vallerão. Modelo de Monitoramento e
Controle de Projetos de Desenvolvimento de Software Conduzidos sob o Scrum. 2015. 73
p. Dissertação (Mestrado em Gestão do Conhecimento e da Tecnologia da Informação) – Universidade Católica de Brasília (UCB), Brasília, 2015.
O objetivo principal deste estudo é a elaboração de um modelo de monitoramento e controle aplicável aos projetos de desenvolvimento de software sob o Scrum. Para tal, foi desenvolvido um estudo de caso em uma entidade governamental, que examinou um conjunto de projetos de desenvolvimento de software conduzidos sob o Scrum. A coleta de dados foi realizada por meio de análise documental e de entrevistas com gerentes integrantes de diferentes níveis hierárquicos, dados esses analisados por meio da técnica de análise de conteúdo temática. As práticas de monitoramento e controle evidenciadas nas entrevistas originaram uma relação de práticas – internas e externas – aplicáveis a projetos conduzidos sob o Scrum, que constituíram o modelo objeto deste estudo. Esse modelo representa o fenômeno do monitoramento e controle por meio de um laço duplo, sendo que o interno é executado pelo Scrum Team e representa as práticas de automonitoramento e autocontrole da equipe; enquanto o mais externo é executado pelos gerentes da hierarquia funcional da instituição e representa a ação dela sobre os rumos do projeto.
ABSTRACT
The main objective of this study is to create a control and monitoring model applicable to software development projects managed through Scrum method. For this, a case study was conducted in a governmental institution that examined a set of software development projects under Scrum. Data were collected through documental analysis and interviews with managers from different hierarchical levels, which were analyzed through thematic content analysis approach. The control and monitoring practices identified originated a model with a set of internal and external practices related to Scrum method applicable to projects in the institution researched. This model describes the control and monitoring phenomena by a double loop control cycle, in which the internal one depicts the self-monitoring and self-controlling practices, whereas the external one is run by functional managers and depicts the institutional influence in project conduction.
LISTA DE FIGURAS
Figura 1 – Product burndown chart ... 26
Figura 2 – Modelo de pesquisa ... 30
Figura 3 – Desenho da pesquisa ... 37
LISTA DE QUADROS
Quadro 1 – Modelo de quatro camadas ... 24
Quadro 2 – Metas e práticas específicas da área monitoramento e controle de projetos ... 28
Quadro 3 – Disposição dos métodos na Instituição ... 34
LISTA DE SIGLAS
APF Administração Pública Federal Brasileira
ATDD Acceptance Test Driven Development
CMMI Capability Maturity Model Integration
COBIT Control Objectives for Information and Related Technology
GP Gerente de Projeto
GL Gerente de Linha
PMI Project Management Institute
PMI-ACP PMI Agile Certified Practitioner
PO Product Owner
RUP Rational Unified Process
SEI Software Engineering Institute
SG CMMI Specific Goal
SM Scrum Master
SP CMMI Specific Practice
TCU Tribunal de Contas da União
TDD Test Driven Development
TI Tecnologia da Informação
SUMÁRIO
1 INTRODUÇÃO ... 12
1.1 BIBLIOMETRIA ... 14
1.2 PROBLEMA E QUESTÃO DE PESQUISA ... 16
1.3 OBJETIVOS ... 18
1.3.1 Objetivo Geral ... 18
1.3.2 Objetivos Específicos ... 18
1.4 JUSTIFICATIVAS ... 19
1.5 RELEVÂNCIA ... 19
1.6 ESTRUTURA ... 20
2 MONITORAMENTO E CONTROLE DE PROJETOS DE SOFTWARE ... 21
2.1 VISÃO DOS MÉTODOS ÁGEIS ... 21
2.2 VISÃO DO SCRUM ... 23
2.2.1 Papéis-chave ... 24
2.2.2 Mecanismos de Monitoramento e Controle ... 25
2.3 VISÃO DE MODELOS TRADICIONAIS: PMI, COBIT E CMMI ... 27
2.4 MODELO DE PESQUISA ... 29
3 METODOLOGIA ... 31
3.1 CLASSIFICAÇÃO ... 31
3.2 ESTUDO DE CASO ÚNICO ... 32
3.2.1 Local do Estudo ... 33
3.2.2 Métodos de gerenciamento de projetos na Instituição ... 33
3.2.3 Estrutura de monitoramento e controle de projetos na Instituição ... 34
3.2.4 Unidade de análise, Fontes de evidência e Protocolo de Pesquisa ... 35
3.3 DESENHO DA PESQUISA ... 36
3.3.1 Fase da Imersão Inicial ... 37
3.3.2 Fase de Obtenção de Informações Metodológicas ... 39
3.3.3 Fase de Entrevistas com GP e GL ... 40
3.3.4 Análise dos Resultados e Encerramento do Estudo ... 41
4 RESULTADOS E ANÁLISES ... 43
4.1 OBTENÇÃO DE INFORMAÇÕES METODOLÓGICAS ... 43
4.2 ENTREVISTAS COM OS GP ... 44
4.3 ENTREVISTAS COM OS GL ... 47
4.4 MODELO DE MONITORAMENTO E CONTROLE ... 49
5 CONSIDERAÇÕES FINAIS ... 53
REFERÊNCIAS ... 55
APÊNDICE A – PRÁTICAS E SUBPRÁTICAS DO CMMI ... 60
APÊNDICE B – PROTOCOLO DE PESQUISA ... 62
APÊNDICE C – ROTEIRO DAS ENTREVISTAS COM OS GP ... 64
APÊNDICE D – ROTEIRO DAS ENTREVISTAS COM OS GL ... 67
1 INTRODUÇÃO
Ao longo da década 2001-2010, popularizou-se um grupo métodos de
desenvolvimento de software influenciado pela filosofia de produção enxuta, que busca a
minimização do trabalho desnecessário (DINGSOYR et al., 2012); o foco na entrega de valor
ao negócio; a melhoria contínua (COBB, 2011); e a manutenção de ciclos de feedback curtos,
de forma a permitir a realização mais dinâmica de correções no software (COCKBURN,
2006). Esse grupo de métodos teve como marco fundador o Manifesto for Agile Software
Development, de 2001 (AGILE MANIFESTO, 2001), que define uma série de princípios que
objetivam uma construção de software mais colaborativa e adaptável às mudanças. As raízes
desses métodos, no entanto, remontam às décadas anteriores.
Já em 1986, Takeuchi e Nonaka publicaram um artigo que descreve as experiências de
algumas empresas japonesas em projetos de criação de produtos com equipes
multidisciplinares, com grande autonomia de decisão e desprovidas de uma hierarquia formal
(TAKEUCHI; NONAKA, 1986). Nesse artigo, frequentemente citado na produção científica
relacionada aos métodos ágeis, os autores usam pela primeira vez o termo Scrum, traçando
um paralelo entre as equipes de desenvolvimento e as equipes de rugby, onde todo o time atua
em bloco para permitir o avanço rumo à meta. De destaque também é o artigo de Schwaber
(1995), que definiu formalmente o Scrum, o método ágil mais usado no mercado atualmente
(VERSIONONE, 2014). No caso do Extreme Programming (XP), outro método ágil com
forte uso no mercado, o ano oficial do seu lançamento pode ser considerado 1999, com a
publicação de Beck (1999).
Posteriormente, o Manifesto Ágil indicou um conjunto de princípios a serem seguidos
pelos projetos que buscam o desenvolvimento de software com agilidade, como a
auto-organização da equipe de desenvolvimento, a interação face a face com o cliente, a
disponibilização de software utilizável em pequenos intervalos de tempo, o foco na agregação
de valor ao negócio, a capacidade de resposta às mudanças, etc. (AGILE MANIFESTO,
2001). Desse documento derivam várias características dos métodos ágeis, algumas delas
destacadas como especialmente relevantes pela literatura. Sheffield e Lemétayer (2013), por
exemplo, consideram que os elementos mais determinantes para a agilidade dos projetos são o
foco nas necessidades dos clientes e a delegação de poder à equipe do projeto.
Fowler (2000), por sua vez, destaca a mudança de foco nos processos – que figuram
proveem adaptabilidade e flexibilidade diante de mudanças frequentes. Por sua vez, a entrega
regular de software, que torna mais rápido o ciclo de feedback sobre os resultados obtidos, é
também considerada de especial relevância (HIGHSMITH; COCKBURN, 2001), figurando
como um importante elemento no monitoramento dos projetos (SCHWABER, 2004).
Dessa forma, o conjunto das características orgânicas dos métodos ágeis, naturalmente
alinhadas com o dinamismo do mercados contemporâneos, e o bom nível de entrega atingido
pelo emprego desses métodos têm despertado grande interesse nas organizações. Segundo
pesquisa de 2013 da VersionOne (2014), realizada em organizações usuárias de métodos
ágeis, tais métodos são percebidos por apresentarem maior produtividade (87% das
organizações respondentes), maior flexibilidade para mudanças (92%), menor tempo para
disponibilização dos produtos no mercado (83%), melhoria no alinhamento TI-negócio (82%)
e redução de riscos (82%).
Nesse contexto, pesquisa do PMI (2011) identificou que 27% das organizações
respondentes possuíam iniciativas em gerenciamento de projetos com métodos ágeis. O
mesmo estudo identificou a tendência de aumento desse percentual nos próximos anos. Essa
tendência incentivou o PMI a criar uma certificação de proficiência em gerenciamento de
projetos com métodos ágeis – a PMI-ACP (Agile Certified Practitioner) – (PMI, 2012), o que
deve contribuir ainda mais à adoção de tais métodos. Os resultados da pesquisa do PMI são
corroborados por outras pesquisas, como a de WEST et al. (2010), que em 2009 alertava para
o fato que esse conjunto de métodos figurava como a principal forma de desenvolvimento de
software no mercado.
Nos anos subsequentes à publicação do Manifesto Ágil, surgiu um grande número de
diferentes métodos ágeis com variados graus de aderência aos princípios nele contidos
(DINGSOYR et al., 2012). Posteriormente, o panorama do desenvolvimento ágil convergiu
para uns poucos métodos, como mostra aquela pesquisa de 2013 da VersionOne (2014), que
indica o predomínio do Scrum em dois terços das organizações usuárias de métodos ágeis –
55% utilizando só o Scrum e 11% utilizando métodos híbridos com Scrum e XP. O XP é
usado isoladamente em apenas alguns casos (1%), o Scrumban é usado em 7% das
organizações respondentes, o Kanban é usado em 5% daquelas organizações, enquanto o
Lean é usado em apenas 3% delas.
No entanto, apesar da grande difusão no uso desses métodos, convém lembrar que as
características dos processos ágeis, que propiciam um bom nível de entrega de valor às áreas
interação humana, a inexistência de hierarquia dentro das equipes, o alto nível de delegação
decisória às equipes, o planejamento resumido e o foco na entrega de valor apresentam um
novo cenário para os processos de gestão de projetos, que primam pelo monitoramento e
controle no andamento dos mesmos. Nesse sentido, pode-se destacar que entre as principais
preocupações das organizações com relação à adoção de métodos ágeis estão justamente a
falta de um planejamento claro (30% das organizações respondentes), a perda de controle
gerencial (30%) e a perda de previsibilidade (23%) (VERSIONONE, 2014).
Nesse contexto, as organizações que adotam massivamente os métodos ágeis como
forma de melhor atender as suas áreas de negócio necessitam também de níveis de controle
externo sobre o desenvolvimento de software conduzido pela suas equipes. Em função disso,
surge, nas organizações que fazem uso dos métodos ágeis, a necessidade de reflexão sobre as
formas adequadas de monitoramento e controle. Convém observar que esses processos
figuram com necessidades típicas da gestão e da governança de TI, conforme apresentado no
modelo COBIT 5 (ISACA, 2012, p. 126) e a sua adequada execução é uma das práticas de
gerenciamento de projetos que garante a qualidade e o valor dos produtos desenvolvidos
(p.119).
1.1 BIBLIOMETRIA
A revisão de bibliografia deste estudo se amparou em uma pesquisa bibliométrica
sobre o seu tema de interesse, ou seja, monitoramento e controle de projetos de
desenvolvimento de software que fazem uso de métodos ágeis. Ela cobriu o período
2009-2013 e teve como alvo as bases mais relevantes de artigos científicos, além de bases
brasileiras de teses e dissertações, dando origem ao artigo de Vallerão e Roses (2013), onde
são detalhados todos os procedimentos adotados e a análise que sumariamente é exposta a
seguir.
A publicação científica sobre os métodos ágeis se desenvolve fortemente a partir de
2008 (DINGSOYR et al., 2012). Por sua vez, o tema monitoramento e controle aplicado a
projetos conduzidos com esses métodos é abordado por um número reduzido de publicações,
normalmente com um baixo número de citações, o que revela um baixo índice de maturidade
da produção relacionada a esse tema. Assim, infere-se que as publicações ainda não foram
Uma única publicação foi considerada relevante pelos critérios adotados na
bibliometria, ou seja, o artigo de Maruping, Venkatesh e Agarwal (2009), que trata da criação
de um modelo de controle para métodos ágeis, estudando as relações entre o uso dos métodos
ágeis, os modos de controle dos resultados e a dinâmica de mudança dos requisitos. Esse
trabalho mostra que os modos de controle que proveem maior autonomia às equipes,
proporcionam também maiores níveis de qualidade em cenários de intensa mudança de
requisitos. Por outro lado, alerta para a dificuldade no gerenciamento das equipes ágeis e para
as limitações do autogerenciamento em dar respostas organizacionalmente orquestradas em
ambientes de grandes mudanças.
As demais publicações abordam o monitoramento e o controle a partir de perspectivas
distintas, mas podem ser agrupadas em alguns eixos temáticos relativamente claros, tais
como: monitoramento amplo; monitoramento e controle de dimensões específicas do
gerenciamento de projetos; gestão de equipes; e balanceamento entre métodos ágeis e
tradicionais1.
Há publicações de caráter propositivo, enfocando os métodos ágeis primordialmente
sob a ótica do monitoramento de projetos, como os trabalhos de Miranda e Bourque (2010) e
Mahnic e Zabkar (2012). Na mesma linha, o trabalho de Cervino (2011) versa sobre
indicadores de desempenho em ambientes de desenvolvimento de software, tratando, no
entanto, da avaliação de uma abordagem baseada em um ferramenta de monitoramento
específica.
Por sua vez, os trabalhos de Santos (2011), Souza (2010) e Conforto (2009) propõem
métodos ou técnicas para avaliação e gerenciamento de dimensões específicas do
gerenciamento de projetos, como custos, riscos, escopo e tempo. A dimensão da qualidade é
tratada na pesquisa de Concas et al. (2012), que busca relações entre a qualidade interna do
software desenvolvido e a adoção das várias práticas ágeis. A comunicação nos projetos ágeis,
em especial naqueles desenvolvidos por equipes geograficamente dispersas, é tratada por
Persson, Mathiassen e Aaen (2012), enquanto o trabalho de Mariz (2009) é dedicado à gestão
de equipes sob o método Scrum e está focado na análise da composição das mesmas.
As questões de controle no interior das esquipes são abordadas no artigo de Hodgson e
Briand (2013), que explora as relações de poder nas equipes usuárias de métodos ágeis,
1
mostrando que a característica democrática e não hierárquica apregoada por tais métodos é, na
verdade, uma ilusão, visto que nessas equipes as relações de natureza hierárquica coexistem
com certo grau de autogerenciamento, que é relegado principalmente ao microgerenciamento.
Um outro eixo temático bastante significativo pode ser representado por trabalhos
como o de Conforto e Amaral (2010), que propõem a combinação dos métodos ágeis com
métodos de gerenciamento tradicionais. Nesse sentido, o balanceamento entre os dois
modelos surge como forma de minimização dos riscos inerentes a esses projetos. O mesmo
ocorre com o trabalho de Pikkarainen (2009), que trata da integração dos métodos ágeis com
o CMMI2, visando a uma abordagem mais leve para esse framework com a inclusão de
práticas de métodos ágeis no seu escopo.
Nesse mesmo eixo temático, ainda que sob uma abordagem distinta, o artigo de
Indelicato (2012) fornece um resumo de uma obra mais extensa (COBB, 2011), que mostra
que os métodos ágeis apresentam um cenário onde é necessário fazer uma escolha entre dois
elementos, um em detrimento do outro: a agilidade, por um lado, e o controle, por outro. Esse
autor pondera que, em um ambiente adequado, essa permuta – ceder certo nível de controle
em troca de maior agilidade – pode ser bastante vantajosa (COBB, 2011). Para isso, é
necessário definir quais são os pontos essenciais onde o controle é indispensável,
flexibilizando nos demais.
1.2 PROBLEMA E QUESTÃO DE PESQUISA
A bibliografia relacionada aos métodos ágeis usualmente aborda o monitoramento e o
controle sob a ótica do autocontrole exercido pela equipe de desenvolvimento. Assim,
evidências de monitoramento e controle internos – visto que ocorrem no interior das
equipes – podem ser observadas no trabalho de Highsmith (2009) e no controle empírico do
processo, proposto por Schwaber (2004) para o Scrum, encontrando ecos em De Carlo (2004)
e Pichler (2010), por exemplo. No entanto, não se observa – ou é reduzida a pesquisa sobre –
o monitoramento e o controle externos sobre os projetos, ou seja, aqueles exercidos pela
organização na qual o empreendimento está inserido. Essa observação é importante, visto que
os principais modelos de governança de TI tratam o monitoramento e controle como
processos externos à equipe.
Uma decorrência imediata da ênfase dedicada ao autocontrole é que uma relação de
confiança mútua entre gerência e equipe torna-se imprescindível (MCHUGH; CONVOY;
LANG, 2012), já que o sucesso do projeto depende, em última análise, da capacidade da
equipe refletir sobre os problemas que surgem ao longo do seu desenvolvimento e endereçar
corretamente as ações corretivas. No entanto, se por um lado os gestores precisam confiar nas
equipes, por outro, o excesso de confiança pode levar a um modelo gerencial frágil, onde
projetos relevantes para a organização são inteiramente delegados às equipes, sem o
acompanhamento adequado, a partir de um “gerenciamento baseado em esperança” (COBB,
2011).
Por sua vez, a necessidade do exercício de um monitoramento menos invasivo nas
equipes sob métodos ágeis é possibilitado pelo uso do software funcional como medida da
evolução do projeto (AGILE MANIFESTO, 2001). Isso permite uma avaliação mais acurada
da evolução do projeto, visto que se baseia no produto final do processo de desenvolvimento.
Assim, configura-se um cenário que exige dos gestores a renúncia ao domínio sobre o que
ocorre dentro das equipes; e, em contrapartida, fornece produtos de software visíveis, que
permitem um monitoramento efetivo – ou controle por resultados, como apresentado por
Maruping, Venkatesh e Agarwal (2009).
Por outro lado, acrescentando complexidade a esse cenário, as práticas ágeis trazem
algumas inovações que dificultam a realização do monitoramento e do controle dos projetos.
O monitoramento, por exemplo, é dificultado pela ausência de planos formais detalhados, que
indiquem um balizador contra o qual a evolução física de um projeto possa ser comparada e
pelas características especulativas do escopo, que potencializam alterações a qualquer
momento (HIGHSMITH, 2000). Já o controle é dificultado pela delegação de poder às
equipes, que figura como um fator fundamental de agilidade (SHEFFIELD; LEMÉTAYER,
2013).
Nesse sentido, o autogerenciamento da equipe tende a reduzir o grau de controle
exercido pela hierarquia organizacional sobre as equipes, dificultando o seu controle externo.
A esse respeito, Cho (2010) alerta que o autogerenciamento das equipes, quando não operado
corretamente, pode levar à perda da capacidade de supervisão e da noção de responsabilidade
nas equipes, acarretando problemas significativos no andamento dos projetos. Por sua vez, o
Scrum adiciona a esse cenário elementos ímpares como a abordagem de tempo fixo e a
Dessa forma, é razoável supor que os vários elementos destacados acima determinam
que os processos de monitoramento e controle devem passar por adaptações quando aplicados
aos métodos ágeis. Afinal, em um contexto onde as organizações buscam a agilidade, mas
necessitam manter graus mínimos de monitoramento e controle, emergem ponderações sobre
a forma adequada de monitorar e controlar projetos de desenvolvimento de software
conduzidos sob métodos ágeis. Convém observar que qualquer processo de controle aplicado
a esses métodos deve preservar a agilidade do projeto, visto que certamente essa característica
foi determinante na sua adoção pela organização.
Por sua vez, a adoção de práticas de monitoramento e controle externo pode assegurar
os elementos essenciais para o sucesso dos projetos conduzidos com métodos ágeis,
permitindo identificar, por exemplo, falhas na formação da equipe; dificuldades no seu
autogerenciamento; ambientes de projeto inadequados; colaboração insuficiente da área de
negócio; etc. A partir desse cenário, a pergunta de interesse deste estudo é a seguinte: Como
exercer o monitoramento e o controle de projetos de desenvolvimento de software
conduzidos sob o Scrum com a adoção de práticas externas?
1.3 OBJETIVOS
1.3.1 Objetivo Geral
O objetivo geral deste trabalho é o de desenvolver um modelo de práticas internas
(Scrum) e externas de monitoramento e controle aplicável aos projetos de desenvolvimento de
software conduzidos sob o Scrum.
1.3.2 Objetivos Específicos
Os seguintes objetivos específicos foram definidos para o desenvolvimento desse
objetivo geral:
• Identificar práticas de monitoramento e controle utilizadas no Scrum (internas);
• Identificar práticas externas de monitoramento e controle de projetos conduzidos
• Definir um modelo de monitoramento e controle aplicável aos projetos de
desenvolvimento de software conduzidos sob o Scrum.
1.4 JUSTIFICATIVAS
Os métodos ágeis de desenvolvimento de software foram criados a partir de
experiências de profissionais da área de desenvolvimento de software, sendo posteriormente
tratados pela academia. Esse fato, somado ao pouco tempo de uso efetivo desses métodos, faz
com que subáreas específicas do gerenciamento de projetos ágeis não estejam integralmente
cobertos pelos meios acadêmicos. Isso ocorre, por exemplo, com os processos de
monitoramento e controle, como mostra o estudo bibliométrico realizado.
Esse cenário tem implicações para a academia e para a indústria de software. No
campo teórico, a lacuna de produção científica identificada atinge toda uma gama de métodos
de desenvolvimento de software que partilham características comuns. Assim, estudos que
ampliem o acervo científico relacionado aos métodos ágeis são necessários para permitir o
surgimento de uma base teórica que englobe todos os elementos intrincadamente relacionados
nos métodos ágeis – equipe, comunicação, priorização, foco na geração de valor, agilidade e,
naturalmente, monitoramento e controle.
A indústria, por sua vez, em seu movimento em direção aos métodos ágeis, se expõe
aos riscos decorrentes do baixo nível de entendimento sobre o ciclo de monitoramento e
controle nesses contextos. Esses riscos se apresentam em duas dimensões: a primeira é
decorrente da escassez de trabalhos devotados a esses processos em projetos sob métodos
ágeis; a segunda, da exiguidade de pesquisas relacionadas ao Scrum, em um cenário de
importante crescimento do uso desse método no universo das iniciativas ágeis
(VERSIONONE, 2014; WEST et al., 2010; MELO et al., 2012; DINGSOYR et al., 2012).
Cabe lembrar que, embora o Scrum e os demais métodos ágeis tenham uma raiz comum,
alguns aspectos do Scrum são ímpares, como a centralização dos requisitos no PO.
1.5 RELEVÂNCIA
A governança de TI se ampara na governança de projetos de TI (MARNEWICK;
aderentes à estratégia organizacional e, dessa forma, garantirem o efetivo alinhamento entre
as ações de TI e de negócio. Isso se torna especialmente crítico em instituições com um
grande número de projetos em execução concomitantemente. Em função disso, um aspecto
relevante a ser considerado é o risco para a governança de TI do conhecimento restrito sobre
os mecanismos de monitoramento e controle de projetos sob métodos ágeis.
Assim, este trabalho busca o desenvolvimento de instrumentos que possam fortalecer
os processos de governança de TI nas organizações que fazem uso dos métodos ágeis e, mais
especificamente, do Scrum. Do ponto de vista teórico, este trabalho busca incrementar o
entendimento sobre o monitoramento e o controle nos projetos de desenvolvimento ágil de
software, bem como, em um panorama mais genérico, nas equipes que operam com alta
autonomia, em modelos multidisciplinares e autogerenciáveis.
Dessa forma, a relevância deste estudo está na adequação da estrutura de controle
gerencial das instituições aos cenário de adoção ampla do Scrum; na ampliação do
entendimento sobre a dinâmica de monitoramento e controle dos métodos ágeis; e na
apresentação de instrumentos que permitam monitorar e controlar projetos sob o método
Scrum, de forma viável no dia a dia.
1.6 ESTRUTURA
Além desta introdução, este projeto apresenta um segundo capítulo dedicado ao
monitoramento e controle de projetos de desenvolvimento de software, que explora algumas
características desses processos nos métodos ágeis e, em particular, no Scrum, ademais de
mostrar a abordagem desses processos nos métodos tradicionais. A seguir, o terceiro capítulo
trata dos aspectos metodológicos da presente pesquisa, abordando a classificação da pesquisa,
o seu desenho e as suas fases e atividades, enquanto o quarto apresenta os resultados e
2 MONITORAMENTO E CONTROLE DE PROJETOS DE SOFTWARE
O monitoramento e o controle de projetos são abordados pela literatura como
processos altamente relacionados, sendo frequentemente tratados de forma associada (ISACA,
2012; PMI, 2013; SEI, 2011). Assim, o monitoramento consiste na “coleta, medição e
distribuição das informações de desempenho e a avaliação das medições e tendências para
efetuar melhorias no processo” (PMI, 2013, p. 88). Essas ações passam a fazer sentido apenas
quando ligadas ao processo de controle, que “inclui a determinação de ações corretivas ou
preventivas ou o replanejamento e acompanhamento dos planos de ação para definir se as
ações tomadas resolveram a questão de desempenho” (p. 88).
Com pequenas variações de foco, o monitoramento e o controle são especificados em
alguns dos principais modelos de governança em uso no mercado, como o PMI (PMI, 2013),
o COBIT 5 (ISACA, 2012) e o CMMI (SEI, 2011). Embora existam algumas variações
estruturais nesses modelos, eles geralmente detalham o monitoramento e o controle por meio
de processos e práticas, onde os processos se ocupam da transformação de insumos em saídas,
com o objetivo de cumprir um determinado propósito (SEI, 2011, p. 448); enquanto as
práticas podem ser definidas como qualquer atividade relevante para o alcance das metas de
um processo (SEI, 2011, p. 461). Por sua vez, nos métodos ágeis, a definição dos processos de
monitoramento e controle não é apresentada formalmente, ainda que algumas de suas práticas
supram parte das funções dos mesmos.
2.1 VISÃO DOS MÉTODOS ÁGEIS
Já nas iniciativas pioneiras envolvendo conceitos-chave, que anos mais tarde dariam
origem aos métodos ágeis de desenvolvimento de software, o monitoramento e o controle de
projetos com o uso desses métodos foram abordados em suas características únicas. Takeuchi
e Nonaka (1986, p.144), por exemplo, exploraram o tema e criaram um conceito que foi
denominado “controle sutil”, conforme abaixo:
Esse pequeno parágrafo mostra alguns dos elementos mais importantes no
monitoramento e controle de projetos sob métodos ágeis. Inicialmente, há vários pontos de
monitoramento, mas o controle rígido é substituído por abordagens mais suaves, como o
autocontrole, a pressão dos pares, etc. O controle baseado em estímulos negativos é evitado,
dando lugar a uma forma de controle baseada no diálogo, na motivação e nos estímulos
positivos – o “controle pelo amor”. Obviamente, nos pontos de controle, a gerência tem a
oportunidade de influenciar os destinos do projeto, ao cobrar o cumprimento das expectativas
sobre os mesmos.
Posteriormente, Highsmith (2009) incluiu o monitoramento e o controle em seu
modelo de gerenciamento de projetos sob métodos ágeis, que está amparado em dois ciclos
distintos: releases e iterações. Nesse modelo o ciclo de release tem início após o
desenvolvimento da visão inicial do produto e é composto pelas seguintes fases: a)
especulação, onde o escopo é explorado em linhas gerais; b) planejamento da release; c)
exploração, onde ocorrerá o ciclo de iteração; e d) adaptação, onde serão realizados os ajustes
necessários para o andamento do projeto. Na fase de exploração, ocorre o planejamento de
cada iteração, o seu desenvolvimento e revisão, e a sua adaptação em decorrência da evolução
do projeto.
O autor evita associar a fase de adaptação à correção de desempenho frente ao
planejado. Nesse sentido, “adaptar” significa mudança para adequação à realidade do projeto
(HIGHSMITH, 2009), em alinhamento com o valor do desenvolvimento ágil, que assevera
que “responder à mudança [é] mais [importante] que seguir um plano” (AGILE
MANIFESTO, 2001). Esse aspecto revela uma das facetas mais importantes do ciclo de
controle nos métodos ágeis, ou seja, a inexistência de um plano formal e detalhado torna sem
sentido o conceito de monitoramento definido anteriormente, que pressupõe a comparação do
andamento real do projeto com o esperado no plano.
Com relação a esse aspecto, Rawsthorne (2009) salienta que nos projetos sob métodos
tradicionais de gerenciamento é esperada a disponibilização de funcionalidades do documento
de requisitos, sendo necessário apenas verificar a eficiência e a efetividade da entrega. Nos
projetos sob métodos ágeis, em contrapartida, não se sabe exatamente o que será entregue e,
por isso, é necessário constantemente avaliar se o produto disponibilizado oferece suficiente
valor ao negócio, sob a perspectiva do cliente.
Nesse sentido, Highsmith (2009) questiona a tendência tradicional de avaliação do
avaliação do valor ao negócio como principal medida de resultado. É importante observar
que, de acordo com as definições do COBIT 5, o processo de controle é lançado a partir do
momento no qual é percebida a existência de uma lacuna de desempenho, que potencializa um
atraso significativo, um custo superior ao estimado ou padrões de qualidade inferiores aos
previstos (ISACA, 2012). Assim, embora a necessidade de monitoramento das restrições seja
clara, o valor de negócio gerado figura como um importante elemento a ser controlado em
projetos com escopo variável.
2.2 VISÃO DO SCRUM
O Scrum é um método de gerenciamento de projetos adequado a contextos de alta
complexidade e se baseia em equipes auto-organizadas e autogerenciáveis, que desenvolvem
um produto de forma iterativa e incremental (SCHWABER, 2004). O arcabouço desse
método está amparado em uma série de ciclos temporais, com um ciclo diário e um ciclo de
iteração (sprint), normalmente com duração de até quatro semanas (HIGHSMITH;
COCKBURN, 2001). O conjunto de vários ciclos de iteração compõe o projeto como um
todo, sendo que os ciclos do Scrum se caracterizam por possuírem um tempo fixo (timeboxed)
(DEEMER et al., 2010).
Para Highsmith (2009), o Scrum possui um foco no gerenciamento das atividades
cotidianas do projeto, mas sem adentrar em aspectos técnicos do desenvolvimento de
software, como ocorre, por exemplo, com o método XP. Esse autor propõe um modelo de
quatro camadas para situar os métodos ágeis com relação ao seu foco, conforme Quadro 1. Na
primeira camada, figuram as práticas técnicas, representadas por métodos como o XP. Na
segunda, aparece o gerenciamento da iteração, representado por métodos como o Scrum. Na
terceira, está o gerenciamento de projetos, que poderia ser implementada com o PMBOK ou a
APM, modelo proposto pelo autor. Finalmente, na quarta camada, encontra-se a gerência de
portfólio3.
Esse esquema de camadas explica as razões do uso corrente do Scrum associado ao
XP, já que enquanto o primeiro organiza as atividades do dia a dia, com técnicas como o
timeboxing e a priorização; o segundo fornece ferramentas técnicas como o refactoring, o test
3
driven development, o pair programming, etc. Desse foco gerencial do Scrum, por sua vez,
decorre o seu potencial de uso no gerenciamento de projetos em um sentido amplo, não
necessariamente só de software (SUTHERLAND; SUTHERLAND; HEGARTY, 2009).
Quadro 1 – Modelo de quatro camadas
Camadas
4 Gerenciamento do portfolio
3 Gerenciamento de projetos
2 Gerenciamento da iteração
1 Práticas técnicas
Fonte: Highsmith (2009), adaptado pelo Autor.
2.2.1 Papéis-chave
O Scrum se ampara em alguns papéis-chave que conduzirão o processo até a entrega
do produto: o Product Owner (PO), o Scrum Master (SM) e o Team. A função principal do
PO reside na elaboração, manutenção e priorização de uma lista de requisitos do sistema,
denominada product backlog (SCHWABER, 2004). A execução de tais tarefas terá
implicações amplas no desenvolvimento do produto, incluindo a necessidade de criar uma
visão do produto; de envolver todos os stakeholders relevantes; de preparar os requisitos; e de
proporcionar suporte à equipe de desenvolvimento (PICHLER, 2010) – o Team.
Em última análise, o PO é responsável pela maximização do retorno sobre o
investimento, na medida em que prioriza o product backlog com os itens onde a relação entre
valor agregado e custo seja favorável (DEEMER et al., 2010). Boa parte da complexidade
externa do processo de desenvolvimento de software é, dessa forma, centralizada em uma
única pessoa (PO), que fará o contato com os vários stakeholders para dinamizar o processo.
Como Deemer et al. (2010, p. 6) alertam, “é importante notar que no Scrum há uma e apenas
uma pessoa que atua como (...) Product owner e é ela a responsável pelo valor do trabalho
executado”.
Já o SM é o responsável pelo uso correto do Scrum no projeto. Ele deve garantir que
esse método esteja sendo seguido, orientar os integrantes da equipe com relação às suas
práticas e assegurar que a sua aplicação esteja em harmonia com a cultura da organização, de
um Gerente de Projeto (GP), uma vez que não é responsável pela distribuição de tarefas
dentro da equipe e não estabelece os compromissos assumidos (DEEMER, 2009). Essas
responsabilidades cabem à equipe como um todo, que deve se auto-organizar com relação à
distribuição de tarefas e aos compromissos assumidos com o PO. Dessa forma, as funções do
SM se voltam principalmente à proteção da equipe das interferências externas e à remoção
dos obstáculos – ou “impedimentos”, no jargão usual do Scrum – que surjam ao longo do
projeto (DEEMER et al., 2010).
Finalmente, o Team – ou equipe de desenvolvimento – é um grupo auto-organizado,
autogerenciável e multifuncional responsável pelo desenvolvimento do produto
(SCHWABER, 2004). Ele deve possuir um alto grau de autonomia e responsabilidade no
processo, devendo definir que compromissos de desenvolvimento podem ser assumidos
dentro de cada sprint (ou iteração), conforme destacam Deemer et al. (2010). Esses autores,
entre outros, definem uma entidade chamada ScrumTeam (ou equipe Scrum), composta pela
equipe de desenvolvimento (Team), pelo SM e pelo PO. O Scrum Team seria, dessa forma, a
equipe Scrum abrangendo a totalidade comprometida com o desenvolvimento do produto.
2.2.2 Mecanismos de Monitoramento e Controle
O ciclo básico de monitoramento e controle do método Scrum está amparado no que
Schwaber (2004) chama de “controle empírico do processo”, pois a grande complexidade do
desenvolvimento de software exige que os mecanismos desses processos sejam dinâmicos e
flexíveis. O monitoramento e o controle no Scrum ocorrem em três fases (SCHWABER,
2004): visibilidade, inspeção e adaptação. Assim, os ciclos temporais previstos nesse método
proveem visibilidade do andamento dos projetos ao PO e ao SM, o que permite a inspeção do
processo e a adaptação, de forma a corrigir eventuais problemas.
O Scrum fornece quatro artefatos que, conjuntamente, permitem o gerenciamento e o
monitoramento do projeto (BARTON; SCHWABER; RAWSTHORNE, 2007): o product
backlog, o product burndown, o sprint burndown, e o sprint backlog. O product backlog é
composto por uma relação de itens, normalmente composta por funcionalidades do novo
produto, mas que pode também conter melhorias técnicas, atividades exploratórias – ou de
pesquisa – e problemas conhecidos (PICHLER, 2010). Para que o PO possa priorizar o
backlog, é necessária a ajuda do Team para estimar o custo de desenvolvimento de cada um
para um dos principais mecanismos de monitoramento da evolução do produto no Scrum: o
product burndown chart, também conhecido por gráfico de burndown do produto.
Esse gráfico consiste na comparação entre a quantidade de trabalho planejada e o
trabalho remanescente ao logo do tempo (BARTON; SCHWABER; RAWSTHORNE, 2007).
Um exemplo dele pode ser visto na Figura 1, que considera a quantidade de trabalho (eixo das
ordenadas) estimada em qualquer unidade de trabalho e o número de sprints previstas para o
projeto (eixo das abscissas). Uma linha reta mostra a evolução ideal para o projeto,
considerando uma velocidade constante da equipe. Os pontos referentes ao desempenho são
plotados ao final de cada sprint, sendo que os pontos acima da linha do desempenho ideal
representam atrasos; enquanto os pontos abaixo representam o adiantamento de atividades.
Similar ao product burndown, o sprint burndown chart pode ser usado no monitoramento da
evolução da sprint (PICHLER, 2010).
Figura 1 – Product burndown chart
Fonte: Barton, Schwaber e Rawsthorne (2007), adaptado pelo Autor.
A aparente simplicidade e efetividade dos métodos de monitoramento do Scrum, no
entanto, deve ser analisada tendo em perspectiva as limitações de monitoramento dos métodos
ágeis, em especial as relacionadas à possibilidade de oscilação do escopo e à ausência de
planos detalhados. Além disso, o Scrum acrescenta pelo menos um complicador adicional: a
centralização das decisões de negócio no PO.
Esse aspecto gera alguns riscos, conforme salienta relatório do TCU (2013) sobre
aspectos de contratação de software com métodos ágeis, que mostrou especial preocupação
com o PO, relacionada a riscos de sua colaboração insatisfatória do PO, da sua falta de
0" 50" 100" 150" 200" 250" 300" 350" 400" 450"
0" 1" 2" 3" 4" 5" 6" 7" 8"
Ideal Realizado
Número da Sprint
conhecimento de negócio e da excessiva dependência da sua visão como única pessoa com
esse papel no projeto. Nesse sentido, a importância do PO para o sucesso do projeto tem sido
enfatizada por vários autores (PICHLER, 2010; DEEMER, 2009), de forma que a criticidade
desse papel motiva a existência de processos de monitoramento para averiguar se a concepção
do produto e a priorização estabelecidas pelo PO estão atendendo aos objetivos de negócio.
Por fim, apesar da dificuldade de se monitorar projetos sob métodos ágeis, convém
ressaltar que o monitoramento4 dos resultados é um elemento indispensável à autonomia da
equipe, conforme atesta o trabalho de Maruping, Venkatesh e Agarwal (2009). Essa visão é,
em certa medida, harmônica com a visão de Schwaber (2004), que coloca a visibilidade em
um patamar de grande importância no modo de controle dos métodos ágeis. Assim, a
disponibilização de entregáveis em curtos espaços de tempo torna possível aos gerentes
monitorar a capacidade de entrega das equipes e atuem em caso de não conformidades. Ao
mesmo tempo, esse arranjo permite que seja concedida uma grande autonomia à equipe, já
que os gestores podem se sentir seguros com relação à detecção de qualquer desvio em um
curto espaço de tempo.
2.3 VISÃO DE MODELOS TRADICIONAIS: PMI, COBIT E CMMI
O COBIT 5 dedica uma das práticas gerenciais-chave do processo de Gerenciamento
de Programas e Projetos ao monitoramento e controle de projetos. Ela tem como objetivo a
comparação da performance do projeto com critérios-chave preestabelecidos (cronograma,
qualidade, custo e risco) e a avaliação do impacto dos desvios no projeto e no programa como
um todo, reportando os resultados aos envolvidos (ISACA, 2012). À essa prática vinculam-se
10 atividades, algumas delas claramente ligadas ao monitoramento dos projetos, tratando, por
exemplo, do estabelecimento dos critérios de avaliação para os projetos ou da comparação da
performance do projeto com critérios previamente determinados; enquanto outras remetem
aos processos de controle, como as que tratam de recomendar e monitorar as ações corretivas
(ISACA, 2012).
A visão do PMI (2013) sobre os processos monitoramento e controle está contida num
grupo de processos (monitoring and controlling process group). Esse grupo é formado por 11
4
processos, que tratam de temas como o controle de mudanças; o monitoramento e controle de
escopo, cronograma, custos e qualidade; e o controle do engajamento dos stakeholders. A
análise mais detalhada desse grupo mostra a existência de 10 processos divididos entre as
várias áreas temáticas (custo, riscos, qualidade, etc.) e mais um processo, denominado
monitoramento e controle do trabalho do projeto, da área de integração, que se relaciona com
todos os demais processos do grupo, permitindo um controle abrangente do projeto.
O CMMI Development, por sua vez, traz uma abordagem que considera aspectos
típicos das atividades de desenvolvimento de produtos e define o monitoramento e controle
como uma área de processos ligada ao gerenciamento de projetos, associada ao segundo nível
de maturidade (SEI, 2011). A área de processos é dividida em duas metas específicas (SG –
Specific Goals), uma claramente ligada ao monitoramento (Monitorar o projeto com base no
plano) e outra ao controle (Gerenciar ações corretivas), que por sua vez são divididas em
práticas específicas (SP – Specific Practices), conforme Quadro 2. As práticas são detalhadas
em subpráticas, cobrindo, assim, os temas mais relevantes no ciclo de vida dos projetos, como
o monitoramento dos parâmetros de planejamento, dos compromissos assumidos, a análise de
problemas e a tomada de ações corretivas, o que proporciona um grau de especificidade
superior àquele praticado nos outros dois modelos de governança (COBIT e PMI).
Quadro 2 – Metas e práticas específicas da área monitoramento e controle de projetos
Metas Práticas
Mo n it o ra m en to
(SG 1) Monitorar o Projeto com base no Plano
(SP 1.1) Monitorar parâmetros de planejamento
(SP 1.2) Monitorar compromissos
(SP 1.3) Monitorar riscos
(SP 1.4) Monitorar o gerenciamento de dados
(SP 1.5) Monitorar o envolvimento dos stakeholders
(SP 1.6) Conduzir revisões do progresso do projeto
(SP 1.7) Conduzir revisões dos marcos do projeto
Co
n
tr
o
le
(SG 2) Gerenciar ações corretivas
(SP 2.1) Analisar problemas
(SP 2.2) Tomar ações corretivas
(SP 2.3) Gerenciar as ações corretivas
Fonte: SEI (2011), adaptado pelo Autor.
Por exemplo, a prática tomar ações corretivas, da meta específica gerenciar ações
corretivas, está associada às seguintes sub-práticas (SEI, 2011): a) determinar e documentar
as ações apropriadas para correção dos problemas identificados; b) revisar e obter acordo com
compromissos internos e externos. O Apêndice A relaciona as subpráticas de cada uma das
práticas das metas específicas de monitoramento e controle do CMMI.
A comparação dos três modelos citados mostra diferentes graus de especificidade,
considerando a vocação de cada um deles. Ou seja, a visão do COBIT e PMI abrange projetos
de qualquer natureza; enquanto a do CMMI, projetos de desenvolvimento de novos produtos e
serviços. Em comum, esses modelos apresentam uma forte associação entre o monitoramento,
ou o processo que averigua a evolução dos projetos sob várias dimensões; e o controle, ou o
processo intervencionista que atua na correção de eventuais problemas.
2.4 MODELO DE PESQUISA
A investigação sobre as práticas de monitoramento e controle que possam ser
aplicáveis à condução de projetos sob o Scrum pressupõe a obtenção das informações a partir
de projetos que utilizem esse método. Nesse cenário, espera-se que as práticas cotidianas
aplicadas nos projetos convivam em harmonia com a base conceitual do método. Por sua vez,
as práticas externas propostas não devem ser excessivamente invasivas, situando-se,
idealmente, em uma camada superior, que tenha o objetivo de garantir o sucesso do projeto
sem se imiscuir na administração do seu dia a dia.
Assim, o modelo proposto por Highsmith (2009), apresentado no Quadro 1, se mostra
adequado a esse cenário, visto que propõe uma distribuição dos diferentes métodos em
camadas, de acordo com o foco de cada um deles. Nesse contexto, este estudo investigará as
práticas de gerenciamento da iteração aplicáveis ao Scrum (práticas internas), disponíveis na
segunda camada. Na camada superior, de gerenciamento do projeto, o presente estudo proporá
práticas externas, tomando as práticas do CMMI como ponto de partida, mas não se
Figura 2 – Modelo de pesquisa
Para o desenvolvimento deste trabalho, buscou-se um sistema de categorias
relacionado aos processos de monitoramento e controle, que fornecesse uma estrutura para a
investigação dos processos análogos nos métodos ágeis. Dentre os três modelos analisados
neste estudo, o CMMI demonstrou-se o mais adequado para esse papel em função (1) do seu
foco em desenvolvimento de produtos e serviços; (2) da precisão da definição de suas
práticas, cuja divisão em subpráticas proporciona maior concretude aos conceitos; e (3) da
linearidade da sua estrutura, que facilita a categorização.
No entanto, cabe ressaltar, que no modelo de pesquisa proposto, as práticas do CMMI
figuram apenas como um ponto de partida para a pesquisa, que não deve se limitar a elas.
Assim, o estudo em campo de projetos conduzidos sob o Scrum pode mostrar aplicabilidade
de práticas do CMMI e, ao mesmo tempo, indicar a utilização de outras com base teórica
distinta, ou mesmo, de características inteiramente empíricas.
Práticas do Scrum
Gerenciamento da Iteração
Gerenciamento do Projeto
Práticas externas (CMMI)
3 METODOLOGIA
A investigação de um fenômeno por meio científico envolve a realização de uma
pesquisa, que pode ser entendida como um conjunto de procedimentos sistemáticos, críticos e
empíricos aplicados ao estudo de aspectos do mundo real (SAMPIERI; COLLADO; LÚCIO,
2013, p. 30). Nesse contexto, a metodologia da pesquisa provê uma indispensável reflexão
sobre os aspectos metodológicos envolvidos, devendo indicar o processo de construção
realizado pelo pensamento humano para a compreensão da realidade, explorar as concepções
filosóficas relacionadas ao conhecimento no contexto da pesquisa, além de definir o conjunto
de passos que o pesquisador realizará na sua aproximação do objeto em estudo
(GONSALVES, 2005, p. 61).
3.1 CLASSIFICAÇÃO
Convém observar que muitos aspectos metodológicos são implicitamente definidos na
problematização (GONSALVES, 2005, p. 65), ou seja, a forma de abordagem do problema
carrega consigo implicações sobre as perspectivas filosóficas associadas a ela e sobre a forma
de condução da pesquisa. Nesse sentido, a exploração bibliográfica prévia realizada sobre o
tema do monitoramento e controle de projetos sob o método Scrum revela uma área de
conhecimento que ainda carece de teorias consolidas e apresenta lacunas de conhecimento
significativas. Por sua vez, os objetivos estabelecidos para este trabalho indicam a busca por
práticas de monitoramento e controle, bem como o estabelecimento de um modelo capaz de
representar esses processos. O fato desses elementos serem desconhecidos a priori
determinará vários aspectos metodológicos importantes na condução do presente estudo.
Primeiramente, a busca por práticas de monitoramento e controle aplicáveis aos
projetos de desenvolvimento de software sob métodos ágeis, mais especificamente sob o
Scrum, determina que será necessário explorar junto aos praticantes de tais métodos
experiências que demonstrem a utilização das referidas práticas. Essa característica associa a
presente pesquisa ao construtivismo social, concepção filosófica que afirma que os
indivíduos procuram estabelecer significados para o ambiente onde vivem por meio da
interação social (CRESWELL, 2010, p. 31). Assim, como os métodos ágeis são
caracterizados por interações humanas intensas, torna-se indispensável considerar todas as
Por sua vez, o conjunto dos objetivos determina a realização de uma pesquisa
exploratória, que busca “o desenvolvimento e esclarecimento de ideias com objetivo de
oferecer uma visão panorâmica, uma primeira aproximação a um determinado fenômeno que
é pouco explorado” (GONSALVES, 2005, p. 65). Os estudos exploratórios são utilizados
quando a revisão de literatura mostra apenas orientações pouco pesquisadas e ideias
relacionadas ao tema (SAMPIERI; COLLADO; LÚCIO, 2013, p. 101) e, nesse sentido,
mostram-se aderentes à presente pesquisa.
Além disso, as características do problema proposto indicam a realização de uma
pesquisa qualitativa, que é adequada quando os conceitos envolvidos ainda são imaturos
devido à falta de teorias prévias (MORSE, 1991). Essa abordagem permite o estudo do
problema a partir da perspectiva dos participantes dos processos e do aprofundamento das
suas experiências, pontos de vista, opiniões e significados, ou seja, da sua percepção subjetiva
da realidade (SAMPIERI; COLLADO; LÚCIO, 2013, p. 376). Afinal, as pesquisas
construtivistas sociais utilizam normalmente métodos qualitativos na sua implementação
(CRESWELL, 2010, p.31), onde os problemas típicos desse perfil qualitativo de pesquisas
qualitativas são expressos por perguntas iniciadas por como ou o quê (p. 163).
A necessidade de buscar dados para o estudo em meio aos praticantes do método
Scrum determina, de forma mandatória, a realização de uma pesquisa decampo, que consiste
no estudo de um fenômeno no ambiente onde ele ocorre (GONSALVES, 2005, p. 67). Para
tal foi selecionada uma instituição que faz uso amplo dos métodos ágeis de desenvolvimento
de software e possui uma carteira de projetos desse tipo que responde por uma fatia
significativa do montante total de projetos de software da organização.
3.2 ESTUDO DE CASO ÚNICO
A decisão de centrar a pesquisa em uma única instituição decorre da necessidade de
estudar o tema em profundidade, assumindo, em contrapartida, a redução da amplitude das
conclusões (MARCONI; LAKATOS, 2005, p. 274). Dessa forma, este estudo estará
amparado em um estudo de caso, modalidade de pesquisa que investiga fenômenos
contemporâneos em profundidade e em seu ambiente real, especialmente em situações onde a
fronteira entre o fenômeno e seu contexto não é claramente divisada, conforme a definição de
Yin (1981). Esse mesmo autor (YIN, 2009, p. 1) afirma que esse tipo de pesquisa é
contemporâneo em um contexto real; e c) as perguntas geradoras da pesquisa buscam as
razões (por que) ou alternativas de tratamento de situações (como).
3.2.1 Local do Estudo
O local selecionado para o estudo é uma instituição da APF – doravante identificada
por Instituição – atuante no setor financeiro, com mais de 4.000 servidores, distribuídos em
algumas capitais brasileiras. Ela apresenta um nível de maturidade no uso de métodos ágeis
reconhecidamente alto e realiza desenvolvimento de software para as suas unidades de
negócio, com base em servidores do quadro e em equipes terceirizadas, que operam com um
método de desenvolvimento de software resultado de uma hibridização do Scrum com o XP.
3.2.2 Métodos de gerenciamento de projetos na Instituição
Há aproximadamente dez anos, a Instituição desenvolveu uma customização do
Rational Unified Process (RUP), que era usado concomitantemente com uma versão do
processo de gerenciamento de projetos do PMI. O baixo nível de entrega evidenciado nessa
época ensejou a busca de processos alternativos de desenvolvimento, sendo constituído um
grupo de trabalho, que propôs a realização de um projeto piloto, com o uso dos métodos
ágeis. Tal projeto foi implementado com bons resultados há aproximadamente cinco anos e, a
partir dessa data, a maior parte dos projetos da Instituição seguiu o novo método.
Por algum tempo, a Instituição manteve formalmente os dois métodos: o híbrido
Scrum e XP, responsável pela maior parte dos novos projetos; e o baseado no RUP,
contemplando projetos já iniciados e em franco processo de descontinuidade. Recentemente, a
Instituição retirou o método baseado no RUP do seu conjunto de metodologias oficiais, sendo
que atualmente toda a carteira de projetos de desenvolvimento de software está formalmente
amparada no XP/Scrum.
A Instituição, no entanto, mantém o método baseado no PMI como base para os
processos de gerenciamento de projetos, ainda que o gerenciamento das tarefas do dia a dia
esteja primordialmente amparado no Scrum. Dessa forma, é possível representar os métodos
de trabalhos utilizados por meio do modelo de múltiplas camadas proposto por Highsmith
Quadro 3 – Disposição dos métodos na Instituição
Camada Método
Gerenciamento do portfolio PMI
Gerenciamento de projetos PMI
Gerenciamento da iteração Scrum
Práticas técnicas XP
Fonte: Highsmith (2009), adaptado pelo Autor.
O desenvolvimento de software na Instituição é realizado por equipes pequenas, em
geral com até oito desenvolvedores, que operam em contato direto com um PO designado pela
área de negócios demandante. Todos os projetos são gerenciados por servidores próprios, que
acumulam também as responsabilidades do SM. Nos casos onde as equipes são total ou
parcialmente terceirizadas, é designado obrigatoriamente um gerente responsável na empresa
contratada, que divide as suas responsabilidades no projeto com o GP da Instituição.
3.2.3 Estrutura de monitoramento e controle de projetos na Instituição
Os GP da Instituição normalmente se reportam a um gerente de nível tático, enquanto
grupamentos de gerentes de nível tático reportam-se a um gerente de nível estratégico. Esses
gestores acompanham o andamento dos projetos com um nível de atenção que varia de acordo
com o grau de importância do empreendimento. A Instituição conta ainda com equipes de
suporte às metodologias de desenvolvimento de software – Scrum e XP – e com um
Escritório de Projetos, responsável pela elaboração de indicadores de desempenho dos
projetos e pelo suporte metodológico ao método do PMI.
Por sua vez, a plataforma de desenvolvimento da Instituição está apoiada em uma
arquitetura de referência; em um conjunto de padrões arquiteturais e de implementação, que
incluem o emprego massivo do desenvolvimento orientado a testes; e num serviço de
integração contínua com geração de indicadores de qualidade interna do código, que são
usados pelos gerentes para monitoramento da qualidade dos produtos desenvolvidos.
Do ponto de vista da sua estrutura formal, os projetos de desenvolvimento de software
são normalmente entendidos como um desdobramento de um projeto de negócio, que é
gerenciado pela área demandante, na qual existirá também uma estrutura de monitoramento e
executivo com gestores estratégicos das áreas de negócio e de TI, representantes de áreas
envolvidas de maior relevância e os GP de TI e de negócio. Esse comitê acompanha o
andamento dos trabalhos e atua como decisor de última instância para os assuntos de projeto.
3.2.4 Unidade de análise, Fontes de evidência e Protocolo de Pesquisa
Yin (2009, p. 29) salienta que a unidade de análise de um estudo de caso está ligada
intimamente à questão de pesquisa, que deve ser estudada de forma a indicar as informações
relevantes que devem ser coletadas. Assim, a unidade de análise desta pesquisa é o processo
de desenvolvimento de software da Instituição, visto que a problematização e os objetivos
descritos anteriormente exploram fenômenos que ocorrem no dia a dia dos projetos. Além
disso, a Instituição é reconhecida na APF pela utilização de métodos ágeis, situação que
corrobora a adequabilidade de um estudo de caso único (YIN, 2009, p. 48).
Por sua vez, o desenvolvimento de estudos de caso exige o uso de múltiplas fontes de
evidência, que devem ser combinadas de forma a triangular na análise de dados (YIN, 2009,
p. 19). Assim, nesta pesquisa, foram utilizadas como fontes de evidência a análise documental
e as entrevistas, nas modalidades aberta e semiestruturada. Nesse sentido, a pesquisa foi
estruturada de forma a permitir a obtenção de três visões diferenciadas sobre o fenômeno do
monitoramento e controle. A primeira reflete a metodologia de desenvolvimento de software
da Instituição e foi obtida por meio da análise documental e de uma entrevista aberta; a
segunda investiga a perspectiva dos GP a partir de entrevistas semiestruturadas; enquanto a
terceira colhe a percepção dos gerentes de linha, que foram entrevistados de forma
semiestruturada com base em um instrumento diferente do utilizado na fase anterior.
No presente estudo, as entrevistas semiestruturadas foram usadas como instrumento
para a coleta das concepções dos envolvidos na maior parte das situações. As entrevistas
qualitativas permitem a obtenção de informações sobre as concepções e opiniões de
indivíduos relevantes em um determinado contexto de problema (CRESWELL, 2010, p. 214)
e, ao mesmo tempo, propiciam ao pesquisador um bom nível de controle sobre a linha dos
questionamentos (p. 213). Essa modalidade de entrevista caracteriza-se pela existência de um
roteiro básico de assuntos e perguntas, mas permitindo ao entrevistador a liberdade de fazer
outros questionamentos pertinentes para o entendimento dos conceitos estudados