LEONARDO ARTHUR ESTEVES LOURENÇOAPLICABILIDADE DAS PRÁTICAS DO FRAMEWORKSCRUM NA GESTÃO DOS PROJETOS DEDESENVOLVIMENTO DE SOFTWARE DO EXÉRCITOBRASILEIRO

Faculdade de Economia, Administração, Contabilidade e Gestão de Políticas Públicas

Departamento de Administração

LEONARDO ARTHUR ESTEVES LOURENÇO

APLICABILIDADE DAS PRÁTICAS DO FRAMEWORK SCRUM NA GESTÃO DOS PROJETOS DE

DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO BRASILEIRO

Brasília – DF

2019

APLICABILIDADE DAS PRÁTICAS DO FRAMEWORK SCRUM NA GESTÃO DOS PROJETOS DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO

BRASILEIRO

Monografia apresentada ao Departamento de Administração como requisito parcial à obtenção do título de Especialista em Administração.

Professor Orientador: M.Sc. Maurício Abe Machado

Brasília – DF

2019

APLICABILIDADE DAS PRÁTICAS DO FRAMEWORK SCRUM NA GESTÃO DOS PROJETOS DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO

BRASILEIRO

A Comissão Examinadora, abaixo identificada, aprova o Trabalho de Conclusão do Curso de Administração da Universidade de Brasília do aluno

Leonardo Arthur Esteves Lourenço

M.Sc. Maurício Abe Machado Professor-Orientador

Dr. Aldery Silveira Jr. M.Sc. Luiz Cláudio de Oliveira Andrade Professor-Examinador Professor-Examinador

Brasília, 06 de setembro de 2019

agraciar mesmo quando não mereço e não

percebo. À minha querida filha, Maria Ester, o

amor materializado para mim em forma de

menina, razão do meu viver e da minha alegria.

Agradeço primeiramente a Deus, por me conceder forças para chegar ao final dessa difícil caminhada.

Agradeço aos mestres do Departamento de

Administração da UnB, pelos valiosos ensinamentos

ministrados. Agradeço ao Escritório de Projetos do

Exército, por abrir as portas para realização de tão

valoroso curso. Agradeço à Diretoria de Serviço

Geográfico e ao 2º Centro de Geoinformação, pelo

apoio e pelo longo tempo concedido para o

cumprimento dessa árdua missão. Agradeço a todos

os alunos companheiros de curso, por termos

escalado essa montanha lado a lado. Em especial,

agradeço ao amigo Cap Maurício, por toda ajuda e

apoio dispensado durante cada tarefa e momento

difícil. Agradeço ao professor Maurício Abe pela

ajuda, paciência, compreensão e pela excepcional

orientação, sem a qual não seria possível concluir

este trabalho. Agradeço à querida Sueli, pelo apoio e

por orar tanto a Deus pelo meu sucesso. Por fim,

agradeço à minha amada filha, Maria Ester, um

verdadeiro anjinho, que possui a inexplicável

capacidade de me animar, me fazer sorrir e me dar

forças em qualquer situação; amo você, minha

pequena! Muito obrigado a todos!

A fé precede, o intelecto segue.” (Santo

Agostinho)

O Exército Brasileiro possui em seus quadros profissionais equipes de projetos de desenvolvimento de software. As atividades de produção de software concentram- se, principalmente, no Centro de Desenvolvimento de Sistemas (CDS). Em 2012, esse Centro elaborou a Metodologia de Desenvolvimento de Software (MDS-EB) baseada no Processo Unificado, objetivando padronizar as atividades de gestão de projetos de software dentro da organização. No entanto, as equipes de projeto do Exército lidam com situações adversas, como falta de pessoal, acúmulo de funções e contingenciamento de recursos financeiros, entre outros fatores que afetam diretamente o planejamento e o cumprimento dos objetivos dos projetos. Uma alternativa aos processos clássicos como o Unificado, que tem apresentado bons resultados no mercado são os métodos ágeis. Entre os métodos ágeis, o Framework Scrum tem sido muito utilizado em projetos de software. Nesse sentido, este trabalho procurou identificar práticas do Framework Scrum que podem ser adaptadas e integradas ao modelo atual do Exército, visando maior agilidade dos processos de gestão de projetos de software baseadas no MDS-EB. O trabalho fundamentou-se com uma revisão bibliográfica sobre gerenciamento de projetos, desenvolvimento de software, metodologias ágeis e Framework Scrum. Em seguida, na pesquisa de campo com os profissionais que atuam com desenvolvimento de software no EB, foi possível identificar seis práticas com grande aceitação, que podem ser objeto de avaliação pelo CDS e possibilitar evolução dos métodos de gerenciamento de projetos de software do EB. Além disso, foi possível observar a percepção dos respondentes de que o Scrum pode contribuir para a otimização dos processos de gerenciamento.

Palavras-chave: Gestão de Projetos. Software. Métodos Ágeis. Scrum. Exército.

Figura 1 - Atuação do respondente com Scrum ou outro método ágil...21

Figura 2 - Utilização do Product Backlog em substituição ao Documento de Declaração de Escopo...22

Figura 3 - Utilização do Product Backlog em substituição ao Documento de Visão..23

Figura 4 - Alocação da equipe do projeto no mesmo ambiente de trabalho...24

Figura 5 - Realização de reuniões diárias e rápidas ao início do expediente...24

Figura 6 - Utilização de Sprints Scrum como ciclos de trabalho dos projetos...25

Figura 7 - Realização de reunião de avaliação ao fim de um ciclo de trabalho...26

Figura 8 - Existência de um Product Owner na equipe do projeto...27

Figura 9 - Utilização da prática de Programação em Pares...28

Figura 10 - Manutenção de um quadro ou lista de atividades visível à equipe...29

Figura 11 - Importância da comunicação interpessoal em relação à formal e documental...30

Figura 12 - Grau de atendimento às necessidades dos projetos software pelo MDS- EB...31

Figura 13 - Possível contribuição do Scrum na otimização dos projetos de software

do EB...32

Tabela 1 - Distribuição da população quanto ao posto...19

Tabela 2 - Distribuição da população quanto à formação profissional...20

CDS – Centro de Desenvolvimento de Sistemas COTer – Comando de Operações Terrestres CSTB – Cartografia Sistemática Terrestre Básica DCT – Departamento de Tecnologia

DSG – Diretoria de Serviço Geográfico EB – Exército Brasileiro

IEEE - Institute of Electrical and Electronics Engineers

MDS-EB – Metodologia de Desenvolvimento de Software do Exército PMBOK

– Project Management Body of Knowledge

PMI – Project Management Institute RUP – Rational Unified Process SCN – Sistema Cartográfico Nacional

SWEBOK® - Software Engineering Body of Knowledge

TCU – Tribunal de Contas da União

1 INTRODUÇÃO...1

1.1 Contextualização...1

1.2 Formulação do problema...4

1.3 Objetivo Geral...5

1.4 Objetivos Específicos...5

1.5 Justificativa...6

2 REVISÃO TEÓRICA...7

2.1 Gerenciamento de Projetos...7

2.2 Projetos de Desenvolvimento de Software...8

2.3 Metodologia de Desenvolvimento de Software do Exército Brasileiro (MDS-EB) ...10

2.4 Framework Scrum...11

2.5 O Manifesto Ágil...13

3 MÉTODOS E TÉCNICAS DE PESQUISA...16

3.1 Tipologia e descrição geral dos métodos de pesquisa...16

3.2 Caracterização da organização, setor ou área, indivíduos objeto do estudo...17

3.3 População e amostra ou Participantes da pesquisa...17

3.4 Caracterização e descrição dos instrumentos de pesquisa...18

3.5 Procedimentos de coleta e de análise de dados...18

4 RESULTADO E DISCUSSÃO...19

4.1 Amostra da população quanto ao posto...19

4.2 Amostra da população quanto à formação profissional...20

4.3 Resultados sobre experiência com Scrum ou outro método ágil...20

5 CONCLUSÃO E RECOMENDAÇÃO...33

REFERÊNCIAS...35

Apêndice A – Instrumento de Pesquisa...39

1 INTRODUÇÃO

Este trabalho busca identificar algumas práticas do método ágil Scrum que podem agregados à gestão de projetos de desenvolvimento de software do Exército. Este Capítulo 1 apresenta a introdução, a contextualização da pesquisa, a formulação do problema, os objetivos e justificativa do trabalho. O Capítulo 2 apresenta a revisão teórica do trabalho. onde literatura a respeito de gerenciamento de projetos, desenvolvimento de software, métodos ágeis e Scrum são referenciados e auxiliam o desenvolvimento da pesquisa. No Capítulo 3, são apresentados os métodos e técnicas de pesquisa utilizados no trabalho para coletar os dados de profissionais da área de desenvolvimento a respeito do tema e questão. No Capítulo 4, são apresentados os resultados obtidos por meio do instrumento de pesquisa. O Capítulo 5 apresenta as conclusões do trabalho, sugestões sobre a aplicabilidade das práticas do Scrum nos projetos do Exército, discorre sobre as limitações do trabalho e possibilidades de pesquisas futuras.

1.1 Contextualização

Os recursos de Tecnologia de Informação (TI) são, hoje, parte integrante da estratégia das organizações. Estas alcançaram um grau de crescimento e complexidade tão elevado que o uso de sistemas computacionais se tornou essencial nos diversos processos de gestão, seja na iniciativa privada quanto na administração pública. Por este motivo, as organizações, como um todo, têm realizado uma busca inesgotável em melhorar seus processos e suas entregas, garantindo a sua competitividade no mercado (MIRANDA, 2018).

Como em outras áreas do conhecimento, a abordagem dos processos de

desenvolvimento de software como projeto surgiu como uma evolução da forma de gerir

esse tipo de produto, visto que o gerenciamento de projetos promove melhorias nas

habilidades dos profissionais para planejar, implantar e gerenciar atividades de acordo

com os objetivos da organização, por meio de um conjunto de ferramentas (BERSSANETI et al., 2016).

As organizações públicas, devido as exigências de seguir as recomendações dos órgãos de controle, necessitam utilizar metodologias reconhecidas no mercado e/ou no meio científico em seus projetos de desenvolvimento de software, como forma de mitigar os riscos ao erário relacionados a esse tipo de atividade (MORAES, 2015).

O Exército Brasileiro, cumprindo as exigências dos órgãos de controle, elaborou, por intermédio de seu Centro de Desenvolvimento de Sistemas (CDS), o Manual Técnico para a Metodologia de Desenvolvimento de Software do Exército (MDS-EB). Sua utilização foi aprovada por meio da Portaria nº 007 do Departamento de Tecnologia (DCT), de 28 de março de 2012.

O MDS-EB baseia-se nos princípios do Rational Unified Process (RUP), processo clássico e tradicional da Engenharia de Software que fornece uma série de técnicas e ferramentas bem estabelecidas, a serem seguidas pela equipe de um projeto de desenvolvimento de software, a fim de melhorar a produtividade, mitigar riscos e evitar retrabalho. O RUP é considerado um “processo pesado” de desenvolvimento e indicado para grandes projetos, a fim de garantir a qualidade. Segundo Beck et al. (2001a), este tipo de processo é caracterizado pelo foco excessivo na criação de uma documentação completa. Ou seja, possui alto grau burocrático e documental. Neste trabalho, metodologias pesadas como o RUP serão referenciadas como “metodologias tradicionais”.

Um outro paradigma de gerenciamento de projetos, e que será explorado ao longo deste trabalho, são os métodos ágeis. Esses métodos têm se destacado, em especial, junto a equipes de desenvolvimento de software. Magalhães et al.

(2005) considera que as metodologias ágeis possuem algumas características que as

diferenciam das metodologias tradicionais: são adaptativas, orientadas a pessoas,

flexíveis, iterativas e buscam constantemente a simplicidade, sendo especialmente

adequados para projetos pequenos ou médios, com requisitos imprecisos ou em

constante mudança. Highsmith (2009) comenta que o Gerenciamento Ágil de Projetos

busca a simplicidade e a agilidade, que é traduzida em soluções rápidas, econômicas e

de valor para o cliente e a equipe de desenvolvimento, e aumenta o incentivo à

construção de produtos de forma evolutiva e adaptativa. O software produzido deve entrar em operação o mais rápido possível, para que tenha a chance de evoluir (LEAL, 2008).

No Exército Brasileiro, o autor, como observador participante, percebe que, em muitos casos, as equipes de desenvolvimento são de pequeno porte, cujos membros frequentemente acumulam a responsabilidade do projeto com outras atividades inerentes à sua organização militar. Esta realidade levou ao interesse em práticas alternativas às metodologias tradicionais de gestão de projetos que melhor se adequassem ao cenário da instituição. Nesse sentido, observou-se nos últimos anos que os desafios das técnicas de gerenciamento de projetos com métodos ágeis foram ganhando popularidade (MORAES, 2015).

No próprio Exército, algumas iniciativas de empregar metodologias ágeis já foram levantadas. O CDS tem a intenção futura de publicar um manual para padronizar o uso de práticas ágeis nas atividades de desenvolvimento do EB. Este trabalho pode vir a fornecer informações relevantes aos técnicos envolvidos nessa tarefa.

Conforme aponta Carvalho e Mello (2012) , o método ágil traz benefícios, como:

o aumento da satisfação de clientes, por meio da diminuição das reclamações; melhoria na comunicação e aumento da colaboração entre envolvidos nos projetos; aumento da motivação da equipe de desenvolvimento de produtos; melhoria da qualidade do produto produzido; aumento de produtividade da equipe de desenvolvimento; diminuição no tempo gasto para terminar projetos de desenvolvimento de novos produtos; e diminuição do risco em projetos de desenvolvimento de novos produtos.

Visando agregar as metodologias ágeis à realidade das organizações, o Tribunal de Contas da União (TCU) apresentou o Acórdão 2314/2013 (TCU, 2013), cujo objetivo era levantar os riscos decorrentes da utilização de métodos ágeis nos projetos e contratações de desenvolvimento de software pela Administração Pública Federal (APF).

Tais práticas já eram uma realidade no mercado e já ganhavam espaço na própria APF.

Essa publicação do principal órgão de controle visava orientar os órgãos da APF interessados nessa maneira inovadora de gerenciar projetos de software, demonstrando o interesse em do Estado na aplicação da gestão ágil em seus nos processos internos.

Levando em consideração este contexto, este trabalho se propõe a confrontar

pontos das metodologias tradicionais com práticas dos métodos ágeis na gestão de

projetos de software no âmbito do Exército Brasileiro, verificando vantagens e desvantagens do uso de ambas e identificando em que situações é mais adequado adaptar características de uma ou outra.

1.2 Formulação do problema

Os processos de desenvolvimento de software constituem um fator crítico para o bom andamento das atividades do Exército Brasileiro, assim como outras instituições públicas. Segundo a Portaria Ministerial nº 140 de 14 de março de 1997 (EB, 1997), o Ministro de Estado do Exército criou, Centro de Desenvolvimento de Sistemas (CDS) (CDS, 2015a), a quem compete conceber, elaborar e executar projetos de Sistemas Corporativos de Tecnologia da Informação e Comunicações Estratégicas, coordenar a execução da manutenção de tais sistemas, além de pesquisar e desenvolver ferramentas de segurança da informação para a proteção e a defesa dos sistemas da Força (CDS, 2015b). Esse Centro cumpre esta missão institucional seja alocando pessoal próprio, seja contratando e fiscalizando serviços de fábricas de software, ou mesmo unindo ambas as práticas num processo híbrido.

Existem outras Organizações Militares ou Departamentos que, para atender demandas próprias, também possuem equipes que gerenciam projetos de desenvolvimento de software. É o caso da Diretoria de Serviço Geográfico (DSG) que, integra o Sistema Cartográfico Nacional (SCN) e é encarregada por normatizar os padrões da Cartografia Sistemática Terrestre Básica (CSTB) (BRASIL, 1967). Por deter o conhecimento das tecnologias de geoinformação, alocam sua equipe de engenheiros e técnicos no desenvolvimento de sistemas voltados para a produção cartográfica e para a disseminação do acervo cartográfico dessa Diretoria na internet.

Seja qual for o projeto de desenvolvimento, a recomendação do Exército, ainda

que de forma não impositiva, é que sejam seguidos os padrões apresentados pelo MDS-

EB. Esta recomendação é materializada pela Portaria 007-DCT, de 2013 (EB, 2013), que

aprova o Manual de aplicação do MDS-EB. A metodologia ora apresentada toma por base

os processos e boas práticas do RUP, processo consolidado, com forte base na literatura da engenharia de software e amplamente utilizada (EB, 2013).

Contudo, outras práticas surgiram no mercado, tomando espaço das metodologias clássicas como o RUP. O conceito ágil de desenvolvimento tem ganhado destaque e espaço nas organizações, em especial nas desenvolvedoras de software.

Entre os métodos ágeis existentes, as organizações desenvolvedoras de software têm dado grande atenção ao Framework Scrum, método que será explorado ao longo desse trabalho e cujas práticas serão sugeridas para serem aplicadas no Exército Brasileiro.

Visto o exposto neste tópico, o problema de pesquisa foi formulado considerando as seguintes observações: a) no Exército a realidade dos projetos de desenvolvimento de software é de equipes pequenas, prazos escassos e orçamentos incertos, dificultando a aplicação de metodologias tradicionais de gerenciamento; b) apesar de já existir uma metodologia de desenvolvimento de software, há iniciativas na utilização do Scrum dentro do Exército, indicando que a metodologia atual não atende todas as necessidades; c) existe interesse da Administração Pública Federal em analisar riscos e impactos das metodologias ágeis nos projetos gerenciados pelos órgãos públicos, manifestado pelo Acórdão 2314/2013 do TCU (TCU, 2013). Considera-se, então, como problema de pesquisa: quais pontos da Metodologia de Desenvolvimento de Software, instituída no Exército desde 2013, podem sofrer adaptações com práticas do método Scrum?

1.3 Objetivo Geral

Identificar práticas do método Scrum de que podem ser aplicadas na Metodologia de Desenvolvimento de Software do Exército Brasileiro.

1.4 Objetivos Específicos

Os objetivos específicos do presente trabalho são:

• Enumerar os principais pontos do Scrum que podem ser aplicados no método tradicional do Exército;

• Enumerar os pontos do MDS-EB que podem ser reforçadas ou adaptadas com práticas do Scrum;

• Identificar as práticas do Scrum e do MDS-EB que apresentam funções semelhantes, possibilitando adaptação ou substituição de uma pela outra.

1.5 Justificativa

Esse trabalho partiu da conjunção de três fatores que despertaram a curiosidade do autor. O primeiro fator vem de uma constatação do pesquisador, na posição de profissional que atua na organização, atuando no posto de Capitão do Quadro de Engenheiros Militares, na DSG, cuja atribuição está voltada para o desenvolvimento de software na área de geoinformação desde o ano de 2007. Nesta posição, o autor identificou de forma empírica a possibilidade de melhorias no processo de desenvolvimento de softwares dentro do Exército Brasileiro com o uso de técnicas e práticas ágeis.

O segundo fator foi a iniciativa de coletar duas percepções dos profissionais da organização que atuam com desenvolvimento de software: a) sobre a metodologia praticada atualmente; e b) sobre o grau de aceitabilidade de uma metodologia ágil de desenvolvimento de software no Exército Brasileiro. Por ventura, seria possível suscitar o estabelecimento de meios adequados de discussão entre os órgãos do EB e amadurecer o entendimento de que o modelo atual de desenvolvimento de software pode ser apoiado por uma metologia ágil em prol do cumprimento da estratégia organizacional.

O terceiro e último fator deve-se a identificação das técnicas e práticas ágeis que

podem contribuir com o modelo atual de desenvolvimento de software no EB. Práticas

ágeis em projetos de software estão sendo aplicadas nos ambientes corporativos e, em

acréscimo, estão surgindo novas proposições, modelos e abordagens no universo da

gestão de projetos. Trata-se, portanto, de um tema atual e de interesse para as

organizações, pesquisadores e praticantes da gestão de projetos.

2 REVISÃO TEÓRICA

Este tópico aborda os tópicos da literatura consultados para sustentar a pesquisa.

As fontes procuradas envolvem artigos científicos, dissertações e fontes literárias que abordam Gerenciamento de Projetos, as especificidades do Gerenciamento de Projetos de Software e as duas diferentes abordagens que envolvem a pesquisa: a abordagem tradicional e a ágil.

2.1 Gerenciamento de Projetos

O conceito de projeto como objeto de estudo começou a ganhar forma na década de 60, sendo reconhecido como disciplina e ganhando estruturação em sua prática (MEREDITH; MANTEL, 2009).

O PMI (2017) define projeto como um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Ou seja, tem início e um fim definidos e geram um produto, serviço ou resultado que sejam tenham característica única em relação a todos os outros.

O projeto deve alcançar o objetivo ao qual foi proposto e ser encerrado. Sua implementação deve ser autorizado e estar alinhado ao cumprimento de uma das estratégias da organização (PMI, 2017; KERZNER, 2017), como suprir uma necessidade interna, dominar uma tecnologia, atender um cliente importante etc. (DIAS, 2005).

Implementar um projeto exige um processo de gerenciamento. A definição de

Gerenciamento de Projetos é conceituada de maneiras diferentes na literatura. Mas, em

geral, as definições convergem. Kerzner (2017) define o Gerenciamento de Projetos como

o planejamento, a organização, a direção e o controle dos recursos das organizações

para um objetivo de curto prazo que foi estabelecido para concluir metas específicas. Já

em PMI (2017), consta que o Gerenciamento de Projetos é a aplicação do conhecimento,

habilidades, ferramentas e técnicas às atividades do projeto de forma a atingir e exceder

as necessidades e expectativas dos interessados pelo projeto.

Gerenciar um projeto significa, portanto, coordenar as fases, planejar a execução, executar, controlar e concluir (LEAL, 2008). A estruturação e formalidade dos processos de gerenciamento aumentam proporcionalmente à complexidade e à dimensão do projeto.

Como nenhum projeto é igual, é difícil elaborar um manual que contemple todos os possíveis cenários. Cabe ao gerente decidir os melhores rumos do projeto. No entanto, a existência de um método que guie a equipe é um fator importante para o sucesso (LEAL, 2008).

O PMI é uma associação internacional que trabalha em prol dos profissionais que buscam evoluir como gerentes de projetos e das organizações que desejam aumentar sua maturidade na implantação de projetos, oferecendo consultoria e certificações reconhecidas em todo mundo.

Visando apoiar a comunidade, o PMI elaborou o Guia PMBOK

(Project Management Body of Knowledge), que descreve conceitos e processos de gerência, apresenta técnicas e termos consagrados e compila as boas práticas entre as existentes na disciplina de Gerenciamento de Projetos. Cabe ao gerente identificar quais práticas são as mais adequadas ao seu caso (PMI, 2017).

O PMBOK

é aplicável a diversas áreas (indústria, engenharia civil, mecânica, publicidade, desenvolvimento de software etc.). É altamente adaptável a diferentes cenários. Está em constante evolução, compilando práticas tradicionais e a agregando as práticas inovadoras que surgem no mercado e na academia.

O PMBOK

é organizado em dez áreas de conhecimento (Integração, Escopo, Cronograma, Custos, Qualidade, Recursos, Comunicações, Riscos, Aquisições e Partes Interessadas). Cada uma delas é apresentada como um conjunto de processos (PMI, 2017). Atualmente, é considerado no mercado e na academia como base do conhecimento sobre gestão de projetos.

2.2 Projetos de Desenvolvimento de Software

Projetos de software possuem algumas características particulares em relação a

outros tipos de projetos (HUGHES, 2009), entre elas: o fato do produto não ser visível de

imediato, a complexidade dos produtos devido ao aumento da sofisticação dos computadores e usuários, e a facilidade com que o produto pode ser modificado (LEAL, 2008).

Sendo assim, as técnicas e ferramentas utilizadas em projetos de forma genérica, como as que constam no PMBOK

, precisam ser adaptadas às especificidades dos projetos de software. Escopo e cronograma, por exemplo, precisam ser tratados de forma especial, visto a flexibilidade dos requisitos do produto final. No entanto, é interessante observar que, na APF, focos deste trabalho, existem formalidades que precisam ser obedecidas devido à própria natureza das instituições públicas e dos órgãos de controle.

Cabe ao gerente do projeto encontrar o equilíbrio entre a flexibilidade inerente aos projetos de software e a rigidez burocrática da APF.

Sommerville (2011), define um projeto de software como uma descrição de estrutura de software a ser implementada, dos dados que são parte do sistema, das interfaces entre os componentes do sistema e, algumas vezes, dos algoritmos utilizados.

Já Bourque e Fairley (2014), no guia SWEBOK

da IEEE Computer Society, afirmam que o Gerenciamento de Projetos de Software pode ser definido como a aplicação das atividades de gerenciamento: planejamento, coordenação, medição, monitoramento, controle e geração de relatórios, a fim de assegurar que o desenvolvimento e a manutenção do software seja sistemática, disciplinada e quantificada.

O Gerenciamento de Projetos Tradicional utiliza as ferramentas clássicas do Gerenciamento de Projetos, como as apresentadas no PMBOK

, adaptando-as às características desse tipo de projeto. Entretanto esse método não leva em consideração a dinamicidade dos projetos de software, onde as mudanças devem ser consideradas como parte do projeto, e não apenas como uma possibilidade (LEAL, 2008). Mais uma vez, levando em consideração que o objeto deste estudo pertence à APF, cabe a reflexão sobre o contraponto entre as constantes mudanças dos projetos de software e das amarrações às quais os gestores públicos estão sujeitos.

O gerente de projeto de software deve garantir que o projeto cumpra as restrições

de orçamento e de prazo, e entregar um produto de software que contribua para as metas

da organização (SOMMERVILLE, 2011). Ele deve se responsabilizar pelo planejamento e

controle do desenvolvimento.

No início do projeto, o cliente tem maior participação nas atividades. Isso ocorre nos primeiros meses, quando os requisitos do produto são levantados e os objetivos definidos. Nas fases posteriores, o cliente participa menos, passando apenas a validar e aprovar artefatos de projeto.

Nota-se, portanto, certo grau de burocracia. Há uma exigência de documentação e formalidade em toda a comunicação durante o projeto, para que todos os fatos sejam registrados e evitar conflitos. Porém, a comunicação burocrática pode atrapalhar, impedindo, por exemplo, que informações importantes não sejam passadas e não façam parte do processo decisório.

2.3 Metodologia de Desenvolvimento de Software do Exército Brasileiro (MDS-EB)

O Manual Técnico para a Metodologia de Desenvolvimento de Software do Exército (MDS-EB) foi aprovado por intermédio da Portaria 007-DCT de 2013 (EB, 2013).

Ele segue os princípios de um dos processos tradicionais mais utilizados na área de desenvolvimento de software, o RUP.

Esse Manual padroniza diversos processos relacionados ao desenvolvimento de software, em especial o processo de documentação, para possibilitar futura manutenção.

Além disso, especifica papéis e responsabilidades bem definidos em todo o processo, desde o cliente e o gerente do projeto até o testador do software.

O MDS-EB divide-se em quatro fases:

• Iniciação, onde é definido e aprovado o escopo;

• Elaboração, onde é definida e validada a arquitetura;

• Construção, onde é feita codificação e testes;

• Transição, quando o software é homologado.

Cada uma dessas quatro fases é composta por diversas atividades e

subprocessos, utilizam artefatos de entrada, geram outros artefatos e envolvem diversos

atores que ocupam papéis bem definidos (MORAES, 2015).

No total, o processo de Desenvolvimento de Software adotado pelo EB define 62 atividades a serem realizadas, 07 subprocessos, gera 68 artefatos de projeto e envolve 09 tipos de atores diferentes no processo (MORAES, 2015).

2.4 Framework Scrum

Na literatura, há autores que defendem que o uso de metodologias tradicionais limita a interação com o cliente e congelam o escopo do projeto e as especificações, o que pode ser bom para a fiscalização dos órgãos de controle da APF, mas não para a dinâmica necessária às equipes de projeto de software. Serrador e Pinto (2015) consideram que o uso de métodos alternativos para a implementação de projetos seriam mais eficientes que os métodos tradicionais, colocação reforçada pelo fato de que os desafios das técnicas de gerenciamento de projetos com o Ágil estão ganhando popularidade.

O conceito ágil de desenvolvimento tem ganhado destaque e espaço nas organizações, em especial nas desenvolvedoras de software. Entre os métodos ágeis existentes, o Framework Scrum tem se destacado e ganhado espaço junto a essa categoria de organização.

A primeira referência que se tem sobre o método é o artigo de Takeuchi e Nonaka (1986), The New Product Development Game. Baseando-se em experiências no setor automobilístico, o artigo procura apresentava um novo modelo para o desenvolvimento de produtos, de maneira mais flexível, veloz, minimamente burocrática e onde as fases do processo apresentam grande interseção. Em 1990, a técnica começou a ser utilizada em desenvolvimento de software, onde aplicado com mais frequência até os dias de hoje.

Ribeiro e Gusmão (2008), descrevem que a estrutura de processo do Scrum

inicia-se com uma visão do produto. As características do mesmo, pela óptica do cliente,

são coletadas, assim como as premissas e restrições. A comunicação com o cliente é

fundamental em todas as fases do processo, a fim de evitar erros de interpretação na

concepção que se propaguem pelas fases futuras, aumentando o custo de correção.

Os requisitos conhecidos do produto, coletados junto ao cliente, são organizados numa lista denominada Product Backlog. É uma lista priorizada de requisitos que se pode incluir tudo, desde os aspectos de negócios até aspectos de tecnologia, correção de bugs e questões técnicas (PHAM, A; PHAM, P., 2011). É utilizada como base para todas as fases futuras. O Product Backlog deve ser dividido em lançamentos a serem entregues em períodos de tempo regulares, conforme priorização estabelecida por todas as partes envolvidas.

Um ciclo de trabalho, ou iteração, no Scrum é denominado Sprint. O Sprint é o coração do Scrum. É um time-boxed de cerca de um mês, durante o qual um “Pronto”, versão incremental potencialmente utilizável do produto, é criado. Sprints tem durações coerentes em todo o esforço de desenvolvimento. Um novo Sprint inicia imediatamente após a conclusão do anterior (SCHWABER; SUTHERLAND, 2017, p. 9).

Ribeiro e Gusmão (2008) comentam que um subconjunto dos requisitos do produto é escolhido para fazer parte da entrega parcial, sendo denominado Sprint Backlog. O Sprint Backlog é, portanto, é um conjunto de itens do Product Backlog selecionados para o Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo do Sprint (SCHWABER; SUTHERLAND, 2017, p. 16).

Em suma, o Scrum baseia-se na teoria do controle empírico de processos, conforme comenta Lei et al. (2017). Transparência, inspeção e constante adaptação são fundamentais para que todos os processos de gestão funcionem.

De acordo com Pham, A. e Pham, P. (2011), a equipe do Scrum (Scrum Team) é formada por um Scrum Master, uma equipe de desenvolvimento e por um Product Owner.

Cada um desses papéis tem extrema importância para que as práticas Scrum sejam aplicadas da melhor forma, de acordo com as características do projeto.

O Scrum Master é responsável por promover e suportar o Scrum, ajudando todos a entenderem a teoria, as práticas, as regras e os valores do Scrum. Ele é um servo-líder para o Scrum Team, ajudando aqueles que estão fora do time entender quais as suas interações com o Scrum Team são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo Time Scrum. (SCHWABER;

SUTHERLAND, 2017, p. 7).

O Product Owner é o responsável por maximizar o valor do produto resultado do trabalho do Time de Desenvolvimento, decidindo a melhor maneira de fazer isso de acordo com a característica da organização e dos indivíduos. O Product Owner é a única pessoa responsável por gerenciar o Product Backlog, realizando as seguintes atividades:

expressando claramente os itens do Product Backlog; ordenando os itens do Product Backlog para alcançar melhor as metas e missões; otimizando o valor do trabalho que o Time de Desenvolvimento realiza; garantindo que o Product Backlog seja visível e transparente; mostrando com clareza quais itens do Product Backlog serão trabalhados a seguir; e, garantindo que o Time de Desenvolvimento entenda os itens do Product Backlog no nível necessário. (SCHWABER; SUTHERLAND, 2017, p. 6).

O Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar um incremento (produto parcial) potencialmente funcional “Pronto” ao final de cada Sprint. Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de Desenvolvimento como um todo.

(SCHWABER; SUTHERLAND, 2017, p. 7).

Moraes (2015) afirma que as regras do Scrum reúnem os artefatos, eventos e papéis, de forma a administrar as interações e relações entre eles, sendo um framework onde as pessoas podem resolver e tratar problemas adaptativos e complexos enquanto se entrega produtos com o mais alto valor possível de forma produtiva e criativa.

Para Pressman (2011), o Scrum deve ser utilizados como guia para as atividades de desenvolvimento inseridas em um processo que incorpore as de análise, requisito, projeto, entrega e evolução.

2.5 O Manifesto Ágil

No início de 2001, representantes dos conhecidos como Métodos Ágeis de

Desenvolvimento de Software, entre eles o Scrum, reuniram-se e discutiram alternativas

aos processos tradicionais de desenvolvimento de software, chamados de “processos

pesados” (BECK et al., 2001a)

Esse grupo de pessoas declarava não ser contra métodos, processos, metodologias tradicionais, mas defendiam que a modelagem e documentação não deveriam ser excessivas. Afirmavam que, num ambiente turbulento, há limites para o planejamento e previsibilidade (BECK et al., 2001a).

Como fruto desse encontro, foi publicado o Manifesto para Desenvolvimento Ágil de Software. Um trecho importante do conteúdo segue abaixo:

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: - Indivíduos e interações mais que processos e ferramentas; - Software em funcionamento mais que documentação abrangente; - Colaboração com o cliente mais que negociação de contratos; - Responder a mudanças mais que seguir um plano. Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. (BECK et al., 2001a).

Cohen et al. (2003) afirmam que o Manifesto Ágil se tornou a peça-chave do movimento pelo desenvolvimento ágil de software, compilando as principais características que o diferencia dos métodos clássicos. Foram definidos também princípios que regem a maioria das práticas Ágeis de Desenvolvimento de Software, descritos a seguir:

1. Nossa maior prioridade é satisfazer o cliente através da entrega rápida e contínua de um software de valor; 2. Pessoas de negócio e programadores devem trabalhar juntos, diariamente, ao longo de todo o projeto; 3. Aceite as mudanças de requisitos, mesmo que numa etapa avançada do desenvolvimento; 4. Entregue novas versões do software frequentemente; 5. O software em funcionamento é a medida primária de progresso do projeto; 6.

Construa projetos com pessoas motivadas. Ofereça a elas o ambiente e todo o apoio necessários e acredite em sua capacidade de realização do trabalho; 7.

As melhores arquiteturas, requisitos e projetos emergem de equipes auto- organizadas; 8. O método mais eficiente e efetivo de distribuir a informação para e entre uma equipe de desenvolvimento é a comunicação face a face; 9.

Processos ágeis promovem desenvolvimento sustentado; 10. A atenção contínua na excelência técnica e num bom projeto aprimora a agilidade; 11.

Simplicidade é essencial; 12. Equipes de projeto avaliam seu desempenho em intervalos regulares e ajustam seu comportamento de acordo com os resultados. (BECK et al., 2001b)

É importante salientar que os métodos tradicionais não são descartados pelos

defensores do ágil. Paulk (2002) defende que os princípios dos Métodos Ágeis devem ser

seguidos por todos os desenvolvedores de software, mas ressalta que não se deve

abandonar formalismo e disciplina, pois software envolve requisitos de confiabilidade e

qualidade. A integração de ambos os tipos de abordagem em conjunto, caracterizando um

método híbrido, também é visto como uma prática recomendada. Para os órgãos da APF,

aliar as duas abordagens constitui um bom caminho para lidar com a formalidade exigida

pelos órgãos de controle e com a dinamicidade dos métodos ágeis.

3 MÉTODOS E TÉCNICAS DE PESQUISA

Mingers (2001, p. 242) considera uma metodologia como “um conjunto de recomendações ou atividades que visam auxiliar a geração confiável e válida dos resultados da pesquisa”, consistindo de “vários métodos ou técnicas, nem todos necessitando sempre serem aplicados”. Esses conceitos estão presentes neste trabalho, sendo abordados neste capítulo, através das seguintes seções:

a) Tipologia e descrição geral dos métodos de pesquisa;

b) Caracterização da organização, setor ou área, indivíduos objeto do estudo;

c) População e amostra ou Participantes da pesquisa;

d) Caracterização e descrição dos instrumentos de pesquisa;

e) Procedimentos de coleta e de análise de dados.

3.1 Tipologia e descrição geral dos métodos de pesquisa

Este trabalho teve por objetivo apresentar uma análise exploratória para identificar as possibilidades de utilização de práticas do Scrum junto à Metodologia de Desenvolvimento de Software do Exército.

A pesquisa tem natureza aplicada, pois visa gerar conhecimento para aplicação prática nos projetos do Exército, possui abordagem quantitativa e possui objetivo exploratório.

A pesquisa tem caráter primário. Foram realizados procedimentos técnicos documentais, analisando-se literatura cientificamente autêntica. Os principais tópicos revisados na literatura técnica foram: gerenciamento tradicional de projetos (em especial de desenvolvimento de software), metodologias ágeis de gestão e Framework Scrum.

A pesquisa também tem caráter secundário, pois foi realizada pesquisa de

campo, por meio de questionário.

Por fim, a temporalidade é transversal, analisando a situação dos projetos de desenvolvimento num espaço curto e recente de tempo.

3.2 Caracterização da organização, setor ou área, indivíduos objeto do estudo

O CDS é a organização militar do Exército Brasileiro responsável por gerir o desenvolvimento de software da instituição, concentrando a maior parte dos recursos humanos da instituição envolvidos nessa área.

Entretanto, há focos menores de desenvolvimento em outras unidades, como na DSG e suas unidades subordinadas, responsáveis pelo desenvolvimento de sistemas aplicados à produção cartográfica, o COTer, que, apoiado pelo CDS, envolve-se no desenvolvimento de sistemas de simulação de comando e controle, entre outras Diretorias e Organizações Militares.

O estudo concentrou-se, principalmente, nos militares do CDS, militares engenheiros cartógrafos da DSG e das unidades subordinadas a essa Diretoria e militares e civis ex-integrantes de projetos de desenvolvimento da DSG. Outros militares envolvidos com projetos diversos do Exército, em menor quantidade, também foram incluídos no estudo.

3.3 População e amostra ou Participantes da pesquisa

A população alvo da pesquisa foi constituída de profissionais militares e civis que

trabalham ou já trabalharam em projetos de desenvolvimento do software no Exército, em

especial, no CDS e na DSG. O instrumento de pesquisa foi direcionado ao universo de

profissionais da área de estudo em questão. As respostas foram voluntárias. 32

instrumentos de pesquisa foram respondidos.

3.4 Caracterização e descrição dos instrumentos de pesquisa

Foi utilizada a pesquisa Survey junto à amostra de profissionais do Exército Brasileiro. O instrumento foi publicado na internet e os respondentes foram convidados a participar da pesquisa via pedidos de participação por mensagem eletrônica e e-mail, juntamente ao endereço eletrônico de acesso à pesquisa.

O instrumento de pesquisa foi avaliado por meio da escala Likert de cinco pontos (1-Discordo totalmente, 2-Discordo parcialmente, 3-Indiferente, 4-Concordo parcialmente e 5-Concordo totalmente). Ele se dividiu em três partes: a) identificação do respondente;

b) identificação da experiência do participante com o método ágil Scrum; e c) percepção do participante em pontos que as técnicas ágeis podem ser aplicadas no MDS-EB. Para visualizar mais detalhes do instrumento em questão, vide Apêndice A.

3.5 Procedimentos de coleta e de análise de dados

Foi criado um formulário eletrônico na plataforma Google Forms, que oferece acesso ao instrumento de pesquisa por meio de um endereço eletrônico da internet. O formulário ficou disponível do dia 27 de agosto ao dia 29 de agosto de 2019. O autor remeteu o endereço do formulário aos participantes por meio de aplicativo mensagem eletrônica e e-mail ao universo de profissionais selecionado.

O formulário de pesquisa possibilitou ao pesquisador e ao orientador realizarem o

acompanhamento dos resultados em tempo real, criar relatórios personalizados, criar

gráficos personalizados e fazer tabulação cruzada dos dados.

4 RESULTADO E DISCUSSÃO

Este capítulo objetiva apresentar os resultados e as análises relativos à pesquisa realizada, ou seja, a identificação dos respondentes, a identificação de sua experiência com o método ágil Scrum e sua percepção em pontos que as técnicas ágeis podem ser aplicadas no MDS-EB.

4.1 Amostra da população quanto ao posto

No que tange ao posto ocupado no Exército, os resultados da amostra da população se apresentam da seguinte forma:

Tabela 1 - Distribuição da população quanto ao posto Distribuição da população

Of General 1 3,12%

Of Superior 7 21,87%

Of Intermediário 11 34,38%

Of Subalterno 5 15,63%

S Ten / Sgt 2 6,25%

Outro / Civil 6 18,75%

TOTAL 32 100,00%

Fonte: o Autor

Dada a Tabela 1, percebe-se que o posto que apresenta maior relevância é o de

oficiais intermediários (Capitão). Em seguida, de Oficiais Superiores (Major, Tenente-

Coronel e Coronel). A soma dos dois universos corresponde a 56,25% dos respondentes.

4.2 Amostra da população quanto à formação profissional

No que tange à formação profissional, os resultados da amostra da população se apresentam da seguinte forma:

Tabela 2 - Distribuição da população quanto à formação profissional Distribuição da população

Doutorado 1 3,12%

Mestrado 14 43,75%

Especialização 11 34,38%

Ensino superior completo 6 18,75%

TOTAL 32 100,00%

Fonte: o Autor

Dada a Tabela 2 acima, percebe-se que os respondentes apresentam grau de formação elevado, sendo 81,25% pós-graduados.. Quase metade da amostra é formada por mestres ou doutores.

4.3 Resultados sobre experiência com Scrum ou outro método ágil

Os resultados referentes ao questionamento se o participante trabalhou com Scrum ou outro método ágil demonstrou que 71,9% dos respondentes atuam ou atuaram em projetos dessa natureza, conforme a Figura 1. Consequentemente, 28,1%

não têm experiência com métodos ágeis.

Tendo em vista que o problema de pesquisa deste trabalho é identificar práticas

do Scrum que podem ser aplicadas no MDS-EB, o pesquisador considerou somente as

respostas dos participantes que possuem experiência com métodos ágeis para a alcançar

o objetivo da pesquisa. No caso, 23 respondentes foram considerados.

Figura 1 - Atuação do respondente com Scrum ou outro método ágil Fonte: o Autor

4.4 Resultados sobre a utilização do Product Backlog em substituição ao Documento de Declaração de Escopo

Os resultados referentes à pergunta se o Product Backlog poderia substituir o documento de Declaração de Escopo do projeto de software, podem ser observados na Figura 2.

Observa-se no gráfico da Figura 2. que aproximadamente 74% dos participantes

apresentam opinião a favor da utilização do Product Backlog em detrimento do

documento de Declaração de Escopo. No entanto, a parcela de opiniões desfavoráveis é

significante, devendo ser levada em consideração na decisão de aplicação ou não da

prática. Pode ocorrer que uma equipe de projetos possua uma parcela considerável de

integrantes que preferem trabalhar com a Declaração de Escopo.

0 2 4 6 8 10 12 14

4,35%

17,39%

4,35%

47,83%

26,09%

Figura 2 - Utilização do Product Backlog em substituição ao Documento de Declaração de Escopo

Fonte: o Autor

4.5 Resultados sobre a utilização do Product Backlog em substituição ao Documento de Visão

Os resultados referentes à pergunta se o Product Backlog poderia substituir o Documento de Visão do projeto de software, podem ser observados na Figura 3.

Observa-se no gráfico da Figura 3 que 56,52% dos participantes apresentam

opinião a favor da utilização do Product Backlog em detrimento do documento do

Documento de Visão, e 26,09% se mostram contra. A parcela dos respondentes que

concorda com a prática alcança pouco mais da metade do universo. Este pesquisador

considera que não houve um consenso claro entre os participantes nesse quesito. O

Documento de Visão é um artefato muito utilizado nos projetos de software, dando uma

visão ampla do produto e descrevendo os requisitos em alto nível. É compreensível que a

adoção do Documento de Visão seja apreciada por boa parte dos desenvolvedores,

mesmo os atuantes em equipes ágeis de projeto.

0 2 4 6 8 10 12

17,39%

8,70%

17,39%

43,48%

13,04%

Figura 3 - Utilização do Product Backlog em substituição ao Documento de Visão Fonte: o Autor

4.6 Resultados sobre a alocação da equipe do projeto no mesmo ambiente de trabalho

Os resultados referentes à pergunta sobre se é importante importante que os membros do projeto de desenvolvimento de software necessariamente estejam alocados no mesmo ambiente de trabalho, podem ser observados na Figura 4.

Observa-se no gráfico da Figura 4 que 82,61% dos participantes apresentam opinião a favor de que a equipe do projeto seja alocada no mesmo ambiente de trabalho para que a comunicação seja mais eficiente. O resultado mostra indícios de que a prática deve ser experimentada nos projetos do Exército e sua eficácia avaliada.

4.7 Resultados sobre a realização de reuniões diárias e rápidas ao início do expediente

Os resultados referentes à pergunta sobre se é útil realizar reuniões diárias e

rápidas com a equipe do projeto, no início do expediente, podem ser observados na

Figura 5.

0 2 4 6 8 10 12 14

13,04%

4,35%

34,78%

47,83%

Figura 4 - Alocação da equipe do projeto no mesmo ambiente de trabalho Fonte: o Autor

Di sc or do to ta lm en te

Di sc or do p ar cia lm en te

In dif er en te

Co nc or do p ar cia lm en te

Co nc or do to ta lm en te

0 4 8 12 16

34,78%

65,22%

Figura 5 - Realização de reuniões diárias e rápidas ao início do expediente Fonte: o Autor

O resultado chama a atenção, visto que 100% dos profissionais da amostra que

atuam ou já atuaram com Scrum ou outro método ágil apresentam opinião favorável à

adoção da prática das reuniões rápidas e diárias. Essa é uma forte evidência de que a

aplicação da prática pode trazer bons resultados às equipes de desenvolvimento de

software do Exército.

4.8 Resultados sobre a utilização de Sprints Scrum como ciclos de trabalho dos projetos

Os resultados referentes à pergunta sobre se as iterações, presentes nas metodologias tradicionais de desenvolvimento, podem ser substituídas por Sprints, podem ser observados na Figura 6.

0 2 4 6 8 10 12 14 16

4,35%

39,13%

56,52%

Figura 6 - Utilização de Sprints Scrum como ciclos de trabalho dos projetos Fonte: o Autor

O resultado mostra um alto índice de concordância (95,65%), evidenciando que

os respondentes têm ou tiveram impressões positivas em suas experiências com o uso de

ciclos de trabalho como Sprints. É uma prática que merece ser levada em consideração,

aplicada nos projetos do Exército e ter sua eficácia avaliada.

4.9 Resultados sobre a realização de reunião de avaliação ao fim de um ciclo de trabalho

Os resultados referentes à pergunta sobre se é útil realizar uma reunião ao fim de cada iteração, Sprint ou entrega, para avaliar o que precisa ser melhorado nos próximos ciclos de trabalho, podem ser observados na Figura 7.

0 5 10 15 20 25

17,39%

82,61%

Figura 7 - Realização de reunião de avaliação ao fim de um ciclo de trabalho Fonte: o Autor

Como aconteceu em pergunta anterior, salta aos olhos neste questionamento o

fato de 100% dos profissionais da amostra que atuam ou já atuaram com Scrum ou outro

método ágil apresentam opinião favorável à adoção da reunião de avaliação ao fim de um

ciclo de trabalho, a fim de melhorar os próximos. No método Scrum, essa reunião

denomina-se Scrum Retrospective. Visto a unanimidade na concordância, a aplicação da

prática merece atenção e pode trazer bons resultados às equipes de desenvolvimento de

software do Exército, já que a adesão das equipes à essa prática é muito provável.

4.10 Resultados sobre a existência de um Product Owner na equipe do projeto

Os resultados referentes à pergunta sobre se a existência de um Product Owner junto à equipe de desenvolvimento é útil para o pleno entendimento dos requisitos do produto, podem ser observados na Figura 8.

Di sc or do to ta lm en te

Di sc or do p ar cia lm en te

In dif er en te

Co nc or do p ar cia lm en te

Co nc or do to ta lm en te

0 4 8 12 16

4,35%

30,43%

65,22%

Figura 8 - Existência de um Product Owner na equipe do projeto Fonte: o Autor

O resultado mostra um alto índice de concordância (95,65%) entre os

profissionais da amostra que já tiveram contato com ágil, evidenciando que incluir o papel

do Product Owner na equipe do projeto pode trazer benefícios aos times de

desenvolvimento do Exército, evitando que as atividades se desalinhem das reais

necessidades da parte demandante. Este resultado ilustra que os participantes viveram

experiências positivas com os Product Owners, similares às relatadas por Silva e Lovato

(2016).

4.11 Resultados sobre a utilização da prática de Programação em Pares

Os resultados referentes à pergunta sobre se a aplicação da prática de Programação em Pares pode melhorar a qualidade do código gerado, podem ser observados na Figura 9.

0 2 4 6 8 10 12 14

8,70% 8,70% 13,04%

21,74%

47,83%

Figura 9 - Utilização da prática de Programação em Pares Fonte: o Autor

Observa-se que aproximadamente 70% dos participantes são favoráveis à prática da Programação em Pares, e aproximadamente 17% discordam. É uma prática que se baseia na crença de que um erro no código passa com menos facilidade pelos olhos de dois programadores. Além disso, normalmente emprega um desenvolvedor mais experiente atuando ao lado de outro menos experiente, visando aumentar a maturidade dos iniciantes.

A desvantagem clara é a alocação do dobro de recursos humanos em uma tarefa do projeto. Portanto, é compreensível que o índice de concordância não seja tão elevado quanto o observado nos resultados de outras perguntas. Ainda assim, é um ponto que merece ser avaliado no âmbito dos projetos do EB, com aplicação à critério da equipe.

Uma sugestão seria usar a prática em casos específicos, como quando se lida com

inovação tecnológica ou produtos complexos de software.

4.12 Resultados sobre a manutenção de um quadro ou lista de atividades visível à equipe

Os resultados referentes à pergunta sobre se a manutenção de um quadro ou lista de atividades visível é útil no processo de comunicação entre os membros do projeto, podem ser observados na Figura 10.

0 4 8 12 16 20

8,70% 13,04%

78,26%

Figura 10 - Manutenção de um quadro ou lista de atividades visível à equipe Fonte: o Autor

Nota-se no resultado um índice de concordância elevado (91,30%), uma pequena parcela indiferente e nenhuma opinião discordante. Um quadro ou lista de atividades é uma ferramenta simples e de fácil aplicação. As respostas dos profissionais indicam que a adoção desta prática pode trazer benefícios às equipes de projeto de software do EB.

Silva e Lovato (2016) também encontraram aceitação positiva ao utilizar gráficos de burndown no monitoramento e controle.

4.13 Resultados sobre a importância da comunicação interpessoal em relação à formal e documental

Os resultados referentes à pergunta sobre se a comunicação interpessoal e

colaborativa entre os membros da equipe do projeto é mais importante que a

comunicação formal e documental, podem ser observados na Figura 11.

0 2 4 6 8 10 12 14 16

8,70%

34,78%

56,52%

Figura 11 - Importância da comunicação interpessoal em relação à formal e documental

Fonte: o Autor

Nota-se nos resultados que o índice de profissionais que tende a concordar que a comunicação interpessoal supera a documental em grau de importância supera os 90%.

Ressalta-se que formalização e disciplina nos processos de gerenciamento sempre devem existir. Contudo, o resultado desta pesquisa leva à crença de que pode haver ganho de eficiência das equipes ao se dar atenção às formas de comunicação diretas e se reduzir a comunicação formal e burocrática ao estritamente necessário.

4.14 Resultados sobre a grau de atendimento às necessidades dos projetos software pelo MDS-EB

Os resultados referentes à pergunta sobre se a a MDS-EB descreve e padroniza

os processos, atendendo plenamente às necessidades dos projetos de software do

EB, podem ser observados na Figura 12.

0 2 4 6 8 10 12 14

13,04%

47,83%

13,04% 17,39%

8,70%

Figura 12 - Grau de atendimento às necessidades dos projetos software pelo MDS- EB

Fonte: o Autor

Os resultados desta pergunta demonstram 60,87% do universo considerado tendem a discordar de que o MDS-EB atende plenamente às necessidades do EB quanto aos projetos de desenvolvimento de software. Já 26,09% acham que o MDS-EB atende adequadamente. O resultado é pouco determinante, evidenciando, talvez, que identificar os pontos fortes das duas abordagens e agregá-las nos processos de gerenciamento seja um bom caminho a ser seguido pelas equipes de projetos de software do EB.

4.15 Resultados sobre a possível contribuição do Scrum na otimização dos projetos de software do EB

Os resultados referentes à pergunta sobre se uma metodologia ágil, como o Scrum, poderia contribuir para o otimizar os projetos de desenvolvimento de software do EB, podem ser observados na Figura 13.

Observa-se no resultado deste questionamento um alto índice de concordância no

universo considerado (95,65%), havendo apenas 01 discordância. É um resultado

significativo. Evidencia que as práticas ágeis, em especial o Scrum, devem ser levadas

em consideração. São técnicas que tem aparecido constantemente no mercado, a ponto

da APF, por meio do Acórdão 2314/2013 do TCU (TCU, 2013) mostrar interesse em

analisar riscos e impactos de sua utilização, vislumbrando aplicação posterior. Portanto, merece atenção a possibilidade de sua agregação também nos projetos de desenvolvimento de software do EB.

0 5 10 15 20 25

4,35% 8,70%

86,96%

Figura 13 - Possível contribuição do Scrum na otimização dos projetos de software do EB

Fonte: o Autor

Cabe ressaltar que não se está recomendando abandonar os procedimentos já

em utilização e descritos no MDS-EB, mas estudar alguns pontos que podem ser

adaptados, integrando práticas do Scrum, em prol da maior eficiência das equipes.

5 CONCLUSÃO E RECOMENDAÇÃO

O estudo investigou a opinião de profissionais atuantes ou que já atuaram em projetos de desenvolvimento de software no âmbito do EB, procurando identificar práticas do método Scrum que podem trazer benefícios ao gerenciamento de projetos dessa natureza na instituição. O trabalho atuou diretamente nas práticas do Scrum que podem ser adaptadas para integrarem a metodologia já existente.

A questão de pesquisa foi respondida em 13 fatores que se mostraram relevantes por meio de uma pesquisa survey, utilzando uma escala Likert de cinco pontos. O pesquisador considerou apenas as respostas dos participantes possuidores de experiência com Scrum ou outro método ágil.

Houve sete práticas que apresentaram alto índice de concordância (acima de 90%). Essas práticas merecem atenção das autoridades e técnicos envolvidos na elaboração das metodologias de desenvolvimento de software do EB.

Dessa forma este estudo atingiu o objetivo geral definido, ou seja, identificar práticas do Scrum que podem ser aplicadas na Metodologia de Desenvolvimento de Software do Exército Brasileiro.

As contribuições deste estudo são de ordem prática, visando aplicação futura dos pontos do Scrum identificados como promissores. Portanto, contribui para o aperfeiçoamento das práticas gerenciais na esfera dos projetos de software do EB.

Esta pesquisa mostra que algumas iniciativas de aplicação de métodos ágeis, já tomadas no Exército, em especial no CDS, será muito bem recebida pela maioria dos desenvolvedores. Mas também apresenta indícios de que, em determinadas situações, o processo atualmente previsto pelo MDS-EB já é o suficiente.

A pesquisa possui a limitações de estudar o caso de uma única instituição.

Apesar do trabalho focar no aprimoramento gerencial dos projetos de software do

Exército, em oportunidades futuras, poder-se-ia aplicar questionários semelhantes a um

universo maior de profissionais, envolver mais instituições e analisar mais pontos das

metodologias tradicionais e ágeis. Deste modo, seria possível buscar maior generalização

dos resultados obtidos, alcançando outros contextos de pesquisa.

REFERÊNCIAS

BECK, Kent et al. Manifesto para Desenvolvimento Ágil de Software. 2001a.

Disponível em: <https://agilemanifesto.org/iso/ptbr/manifesto.html>. Acesso em: 20 ago.

2019.

BECK, Kent et al. Princípios por trás do Manifesto Ágil. 2001b. Disponível em: <https://

agilemanifesto.org/iso/ptbr/principles.html>. Acesso em: 20 ago. 2019.

BERSSANETI, Fernando Tobal; CARVALHO, Marly Monteiro Muscat De; NAMUR, Antonio Rafael. O impacto de fatores críticos de sucesso e da maturidade em gerenciamento de projetos no desempenho: um levantamento com empresas brasileiras. Production Journal, São Paulo, v. 26, n. 4, p. 707–723, out. /dez., 2016.

Disponível em: <http://dx.doi.org/10.1590/0103-6513.065012>. Acesso em: 19 ago. 2019.

BOURQUE, Pierre; FAIRLEY, Richard E. SWEBOK® v3.0: Guide to the Software

Engineering Body of Knowledge. Piscataway: IEEE Computer Society, 2014. Disponível em: <www.swebok.org>. Acesso em: 12 ago. 2019.

BRASIL. Decreto-Lei n

243, de 28 de fevereiro de 1967: Diretrizes e Bases da Cartografia Brasileira e outras providências. Presidência da República, Brasília, DF.

Disponível em:

<http://www.planalto.gov.br/ccivil_03/Decreto-Lei/1965-1988/Del0243.htm>. Acesso em:

21 ago. 2019.

CARVALHO, Bernardo Vasconcelos De; MELLO, Carlos Henrique Pereira. Aplicação do método ágil Scrum no desenvolvimento de produtos de software em uma pequena empresa de base tecnológica. Gestão & Produção, São Carlos, v. 19, n. 3, p. 557–573, 2012.

CDS, Centro de Desenvolvimento de Sistemas. Histórico do CDS. 2015a. Disponível em:

<http://www.cds.eb.mil.br/index.php/historico>. Acesso em: 20 ago. 2019.

CDS, Centro de Desenvolvimento de Sistemas. Missão do CDS. 2015b. Disponível em:

<http://www.cds.eb.mil.br/index.php/missao>. Acesso em: 20 ago. 2019.

COHEN, David; LINDVALL, Mikael; COSTA, Patricia. Agile Software Development: A DACS State-of-the-Art / Practice Report. Fraunhofer Center Maryland, NY, 2003.

Disponível em: <http://users.jyu.fi/~mieijala/kandimateriaali/Agile software

development.pdf>. Acesso em: 25 ago. 2019.