Embed Size (px)
Citation preview
Universidade de Brasília
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 FRAMEWORKSCRUM NA GESTÃO DOS PROJETOS DE
DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITOBRASILEIRO
Brasília – DF
2019
LEONARDO ARTHUR ESTEVES LOURENÇO
APLICABILIDADE DAS PRÁTICAS DO FRAMEWORK SCRUM NA GESTÃO DOSPROJETOS DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO
BRASILEIRO
Monografia apresentada ao Departamentode Administração como requisito parcial àobtenção do título de Especialista emAdministração.
Professor Orientador: M.Sc. Maurício AbeMachado
Brasília – DF
2019
LEONARDO ARTHUR ESTEVES LOURENÇO
APLICABILIDADE DAS PRÁTICAS DO FRAMEWORK SCRUM NA GESTÃO DOSPROJETOS DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO
BRASILEIRO
A Comissão Examinadora, abaixo identificada, aprova o Trabalho de Conclusão doCurso de Administração da Universidade de Brasília do aluno
Leonardo Arthur Esteves Lourenço
M.Sc. Maurício Abe MachadoProfessor-Orientador
Dr. Aldery Silveira Jr. M.Sc. Luiz Cláudio de Oliveira Andrade Professor-Examinador Professor-Examinador
Brasília, 06 de setembro de 2019
Ao Senhor Deus do Céu e da Terra, por meagraciar mesmo quando não mereço e nãopercebo. À minha querida filha, Maria Ester, oamor materializado para mim em forma demenina, razão do meu viver e da minha alegria.
AGRADECIMENTOS
Agradeço primeiramente a Deus, por me concederforças para chegar ao final dessa difícil caminhada.Agradeço aos mestres do Departamento deAdministração da UnB, pelos valiosos ensinamentosministrados. Agradeço ao Escritório de Projetos doExército, por abrir as portas para realização de tãovaloroso curso. Agradeço à Diretoria de ServiçoGeográfico e ao 2º Centro de Geoinformação, peloapoio e pelo longo tempo concedido para ocumprimento dessa árdua missão. Agradeço a todosos alunos companheiros de curso, por termosescalado essa montanha lado a lado. Em especial,agradeço ao amigo Cap Maurício, por toda ajuda eapoio dispensado durante cada tarefa e momentodifícil. Agradeço ao professor Maurício Abe pelaajuda, paciência, compreensão e pela excepcionalorientação, sem a qual não seria possível concluireste trabalho. Agradeço à querida Sueli, pelo apoio epor orar tanto a Deus pelo meu sucesso. Por fim,agradeço à minha amada filha, Maria Ester, umverdadeiro anjinho, que possui a inexplicávelcapacidade de me animar, me fazer sorrir e me darforças em qualquer situação; amo você, minhapequena! Muito obrigado a todos!
“Se não podes entender, crê para que entendas.A fé precede, o intelecto segue.” (SantoAgostinho)
RESUMO
O Exército Brasileiro possui em seus quadros profissionais equipes de projetos dedesenvolvimento 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 deprojetos de software dentro da organização. No entanto, as equipes de projeto doExército lidam com situações adversas, como falta de pessoal, acúmulo de funçõese contingenciamento de recursos financeiros, entre outros fatores que afetamdiretamente o planejamento e o cumprimento dos objetivos dos projetos. Umaalternativa aos processos clássicos como o Unificado, que tem apresentado bonsresultados no mercado são os métodos ágeis. Entre os métodos ágeis, o FrameworkScrum tem sido muito utilizado em projetos de software. Nesse sentido, estetrabalho procurou identificar práticas do Framework Scrum que podem seradaptadas e integradas ao modelo atual do Exército, visando maior agilidade dosprocessos de gestão de projetos de software baseadas no MDS-EB. O trabalhofundamentou-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 desoftware no EB, foi possível identificar seis práticas com grande aceitação, quepodem ser objeto de avaliação pelo CDS e possibilitar evolução dos métodos degerenciamento de projetos de software do EB. Além disso, foi possível observar apercepção dos respondentes de que o Scrum pode contribuir para a otimização dosprocessos de gerenciamento.
Palavras-chave: Gestão de Projetos. Software. Métodos Ágeis. Scrum. Exército.
LISTA DE ILUSTRAÇÕES
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
LISTA DE TABELAS
Tabela 1 - Distribuição da população quanto ao posto...............................................19
Tabela 2 - Distribuição da população quanto à formação profissional.......................20
LISTA DE ABREVIATURAS E SIGLAS
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
SUMÁRIO
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
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
2
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 à
3
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
4
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
5
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:
6
• 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.
7
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.
8
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
9
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.
10
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).
11
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.
12
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).
13
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)
14
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-onós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho,passamos a valorizar: - Indivíduos e interações mais que processos eferramentas; - Software em funcionamento mais que documentaçãoabrangente; - Colaboração com o cliente mais que negociação de contratos; -Responder a mudanças mais que seguir um plano. Ou seja, mesmo havendovalor 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 econtínua de um software de valor; 2. Pessoas de negócio e programadoresdevem trabalhar juntos, diariamente, ao longo de todo o projeto; 3. Aceite asmudanças de requisitos, mesmo que numa etapa avançada dodesenvolvimento; 4. Entregue novas versões do software frequentemente; 5. Osoftware em funcionamento é a medida primária de progresso do projeto; 6.Construa projetos com pessoas motivadas. Ofereça a elas o ambiente e todo oapoio 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çãopara e entre uma equipe de desenvolvimento é a comunicação face a face; 9.Processos ágeis promovem desenvolvimento sustentado; 10. A atençãocontínua na excelência técnica e num bom projeto aprimora a agilidade; 11.Simplicidade é essencial; 12. Equipes de projeto avaliam seu desempenho emintervalos regulares e ajustam seu comportamento de acordo com osresultados. (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
15
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.
16
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.
17
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.
18
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.
19
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.
20
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.
21
Figura 1 - Atuação do respondente com Scrum ou outro método ágilFonte: o Autor
4.4 Resultados sobre a utilização do Product Backlog em substituição aoDocumento 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.
22
02468
101214
4,35%
17,39%
4,35%
47,83%
26,09%
Figura 2 - Utilização do Product Backlog em substituição ao Documento deDeclaração de Escopo
Fonte: o Autor
4.5 Resultados sobre a utilização do Product Backlog em substituição aoDocumento 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.
23
02468
1012
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 detrabalho
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 doexpediente
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.
24
02468
101214
13,04%4,35%
34,78%
47,83%
Figura 4 - Alocação da equipe do projeto no mesmo ambiente de trabalho
Fonte: o Autor
Discor
do to
talm
ente
Discor
do p
arcia
lmen
te
Indif
eren
te
Conco
rdo
parc
ialm
ente
Conco
rdo
tota
lmen
te0
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.
25
4.8 Resultados sobre a utilização de Sprints Scrum como ciclos de trabalho dosprojetos
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.
02468
10121416
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.
26
4.9 Resultados sobre a realização de reunião de avaliação ao fim de um ciclo detrabalho
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.
27
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.
Discor
do to
talm
ente
Discor
do p
arcia
lmen
te
Indif
eren
te
Conco
rdo
parc
ialm
ente
Conco
rdo
tota
lmen
te0
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).
28
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.
02468
101214
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.
29
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.
30
02468
10121416
8,70%
34,78%
56,52%
Figura 11 - Importância da comunicação interpessoal em relação à formal edocumental
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 projetossoftware 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.
31
02468
101214
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 dosprojetos 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
32
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 softwaredo 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.
33
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
34
metodologias tradicionais e ágeis. Deste modo, seria possível buscar maior generalização
dos resultados obtidos, alcançando outros contextos de pesquisa.
35
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ívelem: <www.swebok.org>. Acesso em: 12 ago. 2019.
BRASIL. Decreto-Lei no 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.
36
DIAS, Marisa Villas Bôas. Um novo enfoque para o gerenciamento de projetos de desenvolvimento de software. 2005. 202 p. Dissertação (Mestrado em Administração) –Universidade de São Paulo, São Paulo, 2005.
EB, EXÉRCITO BRASILEIRO. Portaria no 007-DCT de 28 de março de 2013: Manual Técnico para Metodologia de Desenvolvimento de Software do Exército. Departamento de Ciência e Tecnologia - DCT, Brasília, DF.
EB, EXÉRCITO BRASILEIRO. Portaria Ministerial nº 140 de 14 de março de 1997. Ministério do Exército, Brasília, DF.
HIGHSMITH, Jim. Agile Project Management: Creating Innovative Products. 2. ed. Boston: Addison-Wesley Professional, 2009.
HUGHES, B.; COTTERELL, M. Software Project Management. 5 ed. London: McGraw-Hill, 2009.
KERZNER, Harold. Project Management: A Systems Approach to Planning, Scheduling, and Controlling. 12. ed. Hoboken: John Wiley & Sons, 2017.
LEAL, Luciana De Queiroz. Uma Abordagem Ágil ao Gerenciamento de Projetos de Software Baseada no PMBOK® Guide. 2008. 129 p. Dissertação (Mestrado em Ciência da Computação) – Universidade Federal de Pernambuco, Recife, março de 2008.
LEI, Howard et al. A statistical analysis of the effects of Scrum and Kanban on software development projects. Robotics and Computer-Integrated Manufacturing Journal, [s. l.], v. 43, p. 59–67, 2017. Disponível em: <http://dx.doi.org/10.1016/j.rcim.2015.12.001>. Acesso em: 1 ago. 2019.
MAGALHÃES, Ana Liddy Cenni de Castro; ROUILLER, Ana Cristina; VASCONCELOS, Alexandre Marcos Lins De. O Gerenciamento de Projetos Desenvolvidos à Luz das Metodologias Ágeis: Uma Visão Comparativa. Revista ProQuality - Qualidade na Produção de Software, Lavras, v. 1, p. 29–45, 2005.
MEREDITH, Jack R.; MANTEL, Samuel J. Project Management: a Managerial Approach. 7. ed. New York: John Wiley & Sons, 2009.
MINGERS, John. Combining IS Research Methods: Towards a Pluralist Methodology.Information Systems Research, [s. l.], v. 12, n. 3, p. 240–259, 2001.
MIRANDA, Webert Araújo. Testes na Metodologia Ágil. 2018. Trabalho apresentado como requisito parcial para conclusão de Especialização em Métodos Ágeis e Práticas DevOps, Faculdade do Instituto de Educação Tecnológica (IETEC), Belo Horizonte, 10 set2018. Disponível em Disponível em: <http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/2300>. Acesso em: 20 ago. 2019.
37
MORAES, Ricardo Alves. Proposta de Melhoria para o Processo de Desenvolvimento de Software do Exército Brasileiro com base no Modelo de Gestão de Risco e na Metodologia Ágil. 2015. 199 p. Dissertação (Mestrado Profissional em Computação Aplicada) – Universidade de Brasília, Brasília, junho de 2015.
PAULK, Mark C. Agile Methodologies and Process Discipline. CROSSTALK - The Journal of Defense Software Engineering, Ogden, v. 15, n. 10, out. 2002, p. 15–18, Disponível em: <http://www.crosstalkonline.org/storage/issue-archives/2002/200210/200210-0-Issue.pdf>.Acesso em: 19 ago. 2019.
PHAM, Andrew; PHAM, Phuong-Van. Scrum em Ação: Gerenciamento e Desenvolvimento Ágil de Projetos de Software. 1. ed. São Paulo: Novatec, 2011.
PMI, Project Management Institute. Guia PMBOK®: Um Guia do Conhecimento em Gerenciamento de Projetos. 6. ed. Newtown Square: Project Management Institute, 2017.
PRESSMAN, Roger S. Engenharia de Software: Uma abordagem profissional. 7. ed. Porto Alegre: AMGH, 2011.
RIBEIRO, Lucio; GUSMÃO, Cristine. Definição de um Processo Ágil de Gestão de Riscos em Ambientes de Múltiplos Projetos. Revista HÍFEN, Uruguaiana, v. 32, n. 62, 2008- II sem., XIII Simpósio de Informática e VIII Mostra de Software Acadêmico, p. 67- 74. PUC, Uruguaiana, RS, 2008. Disponível em: <http://revistaseletronicas.pucrs.br/ojs/index.php/hifen/article/view/4580>. Acesso em: 4 out. 2018.
SCHWABER, Ken; SUTHERLAND, Jeff. Guia do Scrum® - Um guia definitivo para o Scrum: As regras do Jogo. 2017. Disponível em: <https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf>. Acesso em: 25 ago. 2019.
SERRADOR, Pedro; PINTO, Jeffrey K. Does Agile work? - A quantitative analysis of agile project success. International Journal of Project Management, [s. l.], v. 33, n. 5, p. 1040–1051, 2015. Disponível em: <http://dx.doi.org/10.1016/j.ijproman.2015.01.006>. Acesso em: 1 ago. 2019.
SILVA, Edson Coutinho da e LOVATO, Leandro Alvarez. Framework Scrum: Eficiência em Projetos de Software. Revista de Gestão e Projetos - GeP, v. 7, n. 2, p. 1-15, maio/ago. 2016. Disponível em: <http://www.revistagep.org/ojs/index.php/gep/article/view/330>. Acesso em: 01 jul. 2019.
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Education do Brasil, 2011.
38
TAKEUCHI, Hirotaka; NONAKA, Ikujiro. The new product development game. Harvard Business Review, Boston, v. jan-fev 86, p. 137–146, 1986. Disponível em: <https://hbr.org/1986/01/the-new-new-product-development-game>. Acesso em: 5 nov. 2018.
TCU, TRIBUNAL DE CONTAS DA UNIÃO. Acórdão 2314/2013-TCU, de 28 de agosto de 2013: Levantamento sobre aplicação de metodologias ágeis em desenvolvimentode software. Brasília, DF. Disponível em: <https://portal.tcu.gov.br/biblioteca-digital/levantamento-sobre-aplicacao-de-metodologias-ageis-em-desenvolvimento-de-software.htm>. Acesso em: 24 jun. 2019.
39
Apêndice A – Instrumento de Pesquisa
Aplicação do método ágil Scrum nos projetos dedesenvolvimento de software do Exército Prezado Participante,
Sou aluno do MBA em Gestão de Projetos do EB, curso fruto de uma parceria entre o EPEx e a UnB. Solicito sua ajuda para contribuir com o meu Trabalho de Conclusão de Curso.
A minha pesquisa tem por objetivo identificar práticas do Scrum, método ágil de gerenciamento de projetos, que podem ser aplicadas junto à Metodologia de Desenvolvimento de Software do Exército Brasileiro (MDS-EB), cujo Manual de aplicação (EB80-MT-78.001) foi aprovado pela Port. 007-DCT de 28 MAR 2013.
Ressalto que somente o pesquisador terá acesso aos dados e respostas.
A previsão de encerramento deste formulário é 30 AGO 2019.
Desde já, agradeço imensamente sua colaboração e coloco-me à disposição para esclarecimentos.
Cap Leonardo Arthur Esteves Lourenço
*Obrigatório
1. Qual o seu posto ou graduação? *Marcar apenas uma oval.
Of General
Of Superior
Of Intermediário
Of Subalterno
S Ten / Sgt
Outro / Civil
2. Qual sua formação profissional? *Marcar apenas uma oval.
Ensino médio
Ensino superior completo
Pós-graduação
Mestrado
Doutorado
3. O Senhor(a) já trabalhou com Scrum ou algum outro método ágil gerenciamento deprojetos? *Marcar apenas uma oval.
Sim
Não
40
4. O Product Backlog é uma lista ordenada de tudo que deve ser necessário no produto, e éuma origem única dos requisitos para qualquer mudança a ser feita no produto. Com baseno Modelo de Desenvolvimento de Software do Exército (MDS-EB), que contemplapráticas de desenvolvimento de software fundamentado no Processo Unificado, osenhor(a) considera que o Product Backlog pode substituir o documento de Declaraçãode Escopo do projeto de software? *Marcar apenas uma oval.
Discordo totalmente
Discordo parcialmente
Indiferente
Concordo parcialmente
Concordo totalmente
5. O senhor(a) considera que o Product Backlog pode substituir o Documento de Visão doprojeto de software? *Marcar apenas uma oval.
Discordo totalmente
Discordo parcialmente
Indiferente
Concordo parcialmente
Concordo totalmente
6. Com base no Modelo de Desenvolvimento de Software do Exército (MDS-EB), quecontempla práticas de desenvolvimento de software fundamentado no ProcessoUnificado, o senhor(a) considera importante que os membros do projeto dedesenvolvimento de software necessariamente estejam alocados no mesmo ambiente detrabalho para facilitar a comunicação e torná-la mais veloz? *Marcar apenas uma oval.
Discordo totalmente
Discordo parcialmente
Indiferente
Concordo parcialmente
Concordo totalmente
7. Com base no Modelo de Desenvolvimento de Software do Exército (MDS-EB), quecontempla práticas de desenvolvimento de software fundamentado no ProcessoUnificado, o senhor(a) considera útil realizar reuniões diárias e rápidas (10 a15 min) com aequipe do projeto, no início do expediente, para compartilhar os problemas ocorridos nodia anterior e balizar as atividades do dia? *Marcar apenas uma oval.
Discordo totalmente
Discordo parcialmente
Indiferente
Concordo parcialmente
Concordo totalmente
41
8. Um ciclo de trabalho no método Scrum é denominado Sprint. É um ciclo com 2 a 6semanas de duração, ao fim do qual uma versão incremental potencialmente utilizável doproduto é criada. É composto por uma reunião de planejamento, reuniões diárias,execução do desenvolvimento, acompanhamento, reunião de entrega e reunião deavaliação. Com base no Modelo de Desenvolvimento de Software do Exército (MDS-EB),que contempla práticas de desenvolvimento de software fundamentado no ProcessoUnificado, o senhor(a) considera que as iterações, presentes nas metodologiastradicionais de desenvolvimento, podem ser substituídas por Sprints? *
Marcar apenas uma oval.
Discordo totalmente
Discordo parcialmente
Indiferente
Concordo parcialmente
Concordo totalmente
9. Com base no Modelo de Desenvolvimento de Software do Exército (MDS-EB), quecontempla práticas de desenvolvimento de software fundamentado no ProcessoUnificado, o senhor(a) considera útil realizar uma reunião ao fim de cada iteração, Sprintou entrega, para avaliar o que precisa ser melhorado nos próximos ciclos de trabalho? *
Marcar apenas uma oval.
Discordo totalmente
Discordo parcialmente
Indiferente
Concordo parcialmente
Concordo totalmente
10. No método ágil Scrum existe a função do Product Owner na equipe do projeto. É oindivíduo que representa a a área requisitante, partes interessadas e clientes, sendo oresponsável pelas interações com os mesmos. É também o responsável por gerenciar oProduct Backlog. Com base no Modelo de Desenvolvimento de Software do Exército(MDS-EB), que contempla práticas de desenvolvimento de software fundamentado noProcesso Unificado, o senhor(a) considera que a existência de um Product Owner junto àequipe de desenvolvimento, é útil para o pleno entendimento dos requisitos do produto e,consequentemente, para a garantia de que o mesmo agregue valor ao negócio? *
Marcar apenas uma oval.
Discordo totalmente
Discordo parcialmente
Indiferente
Concordo parcialmente
Concordo totalmente
42
11. Com base no Modelo de Desenvolvimento de Software do Exército (MDS-EB), quecontempla práticas de desenvolvimento de software fundamentado no ProcessoUnificado, o senhor(a) considera que a aplicação da prática de Programação em Parespode evitar e diminuir a possibilidade de defeitos, melhorando a qualidade do códigogerado? *Marcar apenas uma oval.
Discordo totalmente
Discordo parcialmente
Indiferente
Concordo parcialmente
Concordo totalmente
12. Com base no Modelo de Desenvolvimento de Software do Exército (MDS-EB), quecontempla práticas de desenvolvimento de software fundamentado no ProcessoUnificado, o senhor(a) considera que a manutenção de um quadro ou lista de atividadesvisível, para acompanhamento do progresso da equipe, é útil no processo decomunicação entre os membros do projeto? *Marcar apenas uma oval.
Discordo totalmente
Discordo parcialmente
Indiferente
Concordo parcialmente
Concordo totalmente
13. Com base no Modelo de Desenvolvimento de Software do Exército (MDS-EB), quecontempla práticas de desenvolvimento de software fundamentado no ProcessoUnificado, o senhor(a) considera que a comunicação interpessoal e colaborativa entre osmembros da equipe do projeto é mais importante que a comunicação formal edocumental? *Marcar apenas uma oval.
Discordo totalmente
Discordo parcialmente
Indiferente
Concordo parcialmente
Concordo totalmente
14. O senhor(a) considera que a MDS-EB descreve e padroniza os processos para odesenvolvimento de software, atendendo plenamente as necessidades dedesenvolvimento de software para os projetos do EB? *Marcar apenas uma oval.
Discordo totalmente
Discordo parcialmente
Indiferente
Concordo parcialmente
Concordo totalmente
43
Powered by
15. O senhor(a) considera que uma metodologia ágil, como o Scrum, poderia contribuir para ootimizar os projetos de desenvolvimento de software para os projetos do EB? *Marcar apenas uma oval.
Discordo totalmente
Discordo parcialmente
Indiferente
Concordo parcialmente
Concordo totalmente
