• Nenhum resultado encontrado

Modelo de monitoramento e controle de projetos de desenvolvimento de software conduzidos sob o Scrum

N/A
N/A
Protected

Academic year: 2017

Share "Modelo de monitoramento e controle de projetos de desenvolvimento de software conduzidos sob o Scrum"

Copied!
74
0
0

Texto

(1)

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

(2)

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

(3)

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.

(4)
(5)
(6)

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

(7)

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.

(8)

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.

(9)

LISTA DE FIGURAS

Figura 1 – Product burndown chart ... 26 

Figura 2 – Modelo de pesquisa ... 30 

Figura 3 – Desenho da pesquisa ... 37 

(10)

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 

(11)

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

(12)

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 

(13)

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

(14)

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

(15)

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

(16)

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

(17)

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.

(18)

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

(19)

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

(20)

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

(21)

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

(22)

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:

(23)

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

(24)

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

(25)

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

(26)

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

(27)

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

(28)

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

(29)

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

(30)

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

(31)

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)

(32)

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

(33)

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 é

(34)

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

(35)

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

(36)

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

Imagem

Figura 1 – Product burndown chart
Figura 2 – Modelo de pesquisa
Figura 3 – Desenho da pesquisa
Figura 4 – Modelo de Monitoramento e Controle para projetos sob o Scrum

Referências

Documentos relacionados

A função gerente de obras torna-se cada vez mais necessária na construção civil, pois o setor está cada vez mais desenvolvendo e aprimorando a área de coordenação

Na Nova Zelândia em sistemas pastoris as vacas produzem em média 17 litros de leite ao dia, enquanto nos produtores analisados neste estudo a média de

Além disso, a falta de esclarecimento de toda a comunidade escolar sobre sua importância para a melhoria do desempenho dos educandos também contribuiu para que os pais não o

O trabalho intitulado PROJETO DE INTERVENÇÃO SOBRE A IMPLANTAÇÃO DA SISTEMATIZAÇÃO DA ASSISTÊNCIA DE ENFERMAGEM (SAE) PARA PACIENTES COM DIABETES MELLITUS NO

Para atingir este fim, foram adotados diversos métodos: busca bibliográfica sobre os conceitos envolvidos na relação do desenvolvimento de software com

Objetivo: Garantir estimativas mais realistas e precisas para o projeto, ao considerar nesta estimativa o esforço necessário (em horas ou percentual do projeto) para

auxiliar na criação de KPI’s. Fonte: Elaborado pela autora com base nos Quadros de 1 a 10 dessa dissertação.. O Quadro 13 apresenta os resultados trabalhados e que possuem

A tabela 25 apresenta os resultados brutos desta avaliação em relação à característica busca e a tabela 26 exibe o resultado ponderado para esta característica.. A tabela 27