Português (pdf)
Artigo em XML
Referências do artigo
Tradução automática
Enviar este artigo por email
Citado por SciELO 
Similares em
SciELO 
Permalink
1. Introdução
O interesse no gerenciamento da incerteza surgiu da evolução do pensamento sobre gerenciamento de projetos. Para Moura (2011), os projetos de software podem ser caracterizados como projetos que envolvem um alto nível de incerteza, e esse nível de incerteza está relacionado ao nível de inovação desses projetos. O gerenciamento de incertezas fornece estratégias para que o gestor transforme de forma mais eficiente o desconhecido em conhecido como forma de ter sucesso na gestão de projetos (Ramasesh & Browning, 2014). Um dos principais desafios é a necessidade do gerente de projetos de tomar decisões sobre o futuro. No entanto, essas decisões são tomadas no presente, tornando essa situação inerentemente incerta. Aplicar o gerenciamento de incertezas pode ser um fator determinante para o sucesso em projetos de software (Marinho et al., 2018).
Como uma alternativa às formas convencionais de gerenciamento de projetos, métodos ágeis podem ser usados para projetos de software. Os gerentes de projeto estão procurando maneiras de melhorar a forma como esses projetos são conduzidos. A agilidade coexiste com a incerteza, pois um dos princípios dos métodos ágeis é a possibilidade de mudanças rápidas. A tendência atual de empregar agilidade no desenvolvimento de software indica a necessidade de gerenciar a incerteza através de seus ciclos de inspeção e adaptação a alterações (Fontana et al., 2015).
Além disso, segundo Khodakarami et al. (2007), não medir os impactos da interdependência entre as relações existentes das diferentes fontes de incerteza pode fazer com que muitas fontes de incerteza não sejam identificadas, podendo causar danos ao projeto. Para medir e analisar as fontes de incerteza de forma adequada, deve-se levar em consideração que os projetos são experiências únicas, por isso o tipo de incerteza encontrada é chamado de incerteza epistêmica, ou seja, relacionada à falta de conhecimento sobre o projeto em vez de aleatória, ou seja, relacionado à aleatoriedade. Para ilustrar, a falta de conhecimento pode estar relacionada a muitos fatores, como a compreensão inadequada do processo ou uma avaliação imprecisa das características particulares de um determinado projeto (Basu, 2017).
A incerteza no contexto organizacional é geralmente medida como uma percepção. O problema é que, quando os indicadores objetivos e as medidas de percepção são comparados, eles se correlacionam mal, embora os gerentes de projeto estejam cientes das deficiências de medir a incerteza através da percepção. Portanto, como as estimativas de incerteza são baseadas na percepção dos gerentes de projeto, as fontes de incerteza identificadas são potencialmente enganosas porque as fontes de incerteza incorporam informações objetivas e subjetivas sobre as características do projeto (Mezias & Starbuck, 2003). De acordo com Oberkampf et al., (1998), vários métodos têm sido usados para estimar a incerteza, seja pela identificação de possíveis fontes de variabilidade, incerteza e erros em simulações de computador ou por meio de múltiplas fontes de incerteza provenientes de opiniões de diferentes especialistas. A aplicação desses métodos resulta na formulação de estruturas matemáticas que podem representar adequadamente a incerteza como por exemplo a Teoria da Evidência de Dempster Shafer (Shafer, 1976).
Este estudo tem como objetivo investigar o aspecto quantitativo da gestão da incerteza epistêmica em projetos de software. O foco está na ligação entre a incerteza epistêmica e as estratégias de quantificação da incerteza. Portanto, com base no contexto apresentado acima, a questão de pesquisa investigada por este trabalho é: como equipes ágeis abordam a quantificação da incerteza epistêmica em projetos de desenvolvimento de software?
Este artigo está organizado da seguinte forma: na seção 2, são expostos os conceitos e teorias que embasam este trabalho; na seção 3, são descritos os processos metodológicos; na seção 4, é apresentado um modelo preliminar para quantificação da incerteza epistêmica em projetos de software; por fim, na seção 5, estão as conclusões, retratando as limitações encontradas para o desenvolvimento deste trabalho e as prospecções de trabalhos futuros.
2. Fundamentação Teórica
O termo incerteza pode ser amplamente compreendido como “falta de certeza”, o que significa ausência de informação. Portanto, a incerteza abrange não apenas fatores probabilísticos ou resultados indefinidos, mas também fatores ambíguos ou falta de clareza sobre um dado fenômeno (Howell et al., 2010).
Para Sommer et al. (2009), os gerentes de projeto devem buscar ativamente novas informações e fazer ajustes nas atividades do projeto conforme novos dados surgem, aplicando novas soluções para os problemas que surgem como uma forma de lidar com a incerteza. Pode-se concluir, a partir das definições, que é possível lidar com a incerteza por meio da busca por mais informações. Então, a busca por informações é uma abordagem possível para lidar com a incerteza.
A literatura sobre incerteza apresenta uma caracterização importante para nosso trabalho. Os tipos de incertezas encontrados na literatura são incerteza aleatória (associada à variabilidade probabilística ou aleatoriedade), incerteza agnóstica (grau de confiança, conhecimento e suposições) e incerteza epistêmica (falta de informação ou falta de conhecimento) (Damnjanovic & Reinschmidt, 2020).
O foco deste trabalho está na quantificação da incerteza epistêmica por dois motivos: (i) é o tipo de incerteza associada à falta de informação, como encontrada no gerenciamento ágil de projetos, (ii) é o tipo de incerteza redutível, ou seja, que pode ser reduzida pela busca de mais informações sobre o projeto.
Uma confusão natural existe entre as definições de riscos e incertezas. O trabalho seminal de Knight Frank (1921), define que risco se refere a eventos que são estatisticamente capazes de serem modelados, com distribuição de probabilidades conhecidas e baseado em acontecimentos do passado e dados confiáveis, em contrapartida a incerteza pode caracterizar eventos onde não é possível ou viável ter probabilidades associadas aos resultados desse evento. Esses tipos de eventos incertos são característicos de projetos com alto grau de inovação.
A quantificação da incerteza pode ser descrita como o processo de caracterização quantitativa e propagação dos parâmetros de entrada de um modelo (Shah et al., 2015). Assim, essa caracterização quantitativa é essencial para fins comparativos e, portanto, avaliação de soluções alternativas para problemas do mundo real. Isso significa que a mensuração das incertezas permite comparações entre projetos.
Portanto, o posicionamento deste trabalho é que a incerteza epistêmica pode ser antecipada, gerenciada e mensurada por meio do uso de abordagens adequadas para trazer maior precisão ao processo de tomada de decisão no gerenciamento de projetos.
3. Método
Segundo Sagor (2000), uma Pesquisa Ação é um processo de investigação disciplinado onde o principal motivo para o uso de uma PA é ajudar o pesquisador e os participantes da indústria a refinar suas ações, ou seja, refinar e aprimorar quem as executa. Baskerville (1999), no entanto, é rápido em enfatizar que a Pesquisa Ação é perfeita para a Engenharia de Software como um método de pesquisa porque "É empírico, mas interpretativo. É experimental, mas multivariado. É observacional, mas intervencionista."
Esta Pesquisa Ação foi conduzida e reportada seguindo o protocolo proposto por Staron (2020). Este tipo de apresentação é focado em ações e seus resultados e não no tipo de apresentação focado em ciclos. A Pesquisa Ação inclui os seguintes ciclos: Diagnóstico, Planejamento das Ações, Execução das Ações, Avaliação e Aprendizagem. Na fase de Diagnóstico, deve-se identificar e explorar um problema inicial e identificar problemas de pesquisa mais tangíveis a serem resolvidos. A formulação do problema deve ser precisa e inequívoca. Na fase de Planejamento das Ações, precisa-se identificar quais ações serão realizadas, quando e o porquê. Nesta fase divide-se o problema de pesquisa em um conjunto de ações que visem a solução do problema diagnosticado. Na fase de Execução das Ações, as ações planejadas antecipadamente serão executadas. Na fase de Avaliação, avalia-se a ação realizada pela equipe de pesquisadores e praticantes envolvidas no processo. É na fase de Aprendizagem que se apresenta o aspecto mais importante da Pesquisa Ação, a característica da aprendizagem. Esta fase ajuda a elevar a competência da organização e dos pesquisadores. Disseminar o aprendizado é crucial em qualquer projeto de Pesquisa Ação.
3.1. Diagnóstico
3.1.1. Contexto da Empresa e Projeto
Este trabalho foi realizado com uma equipe ágil de desenvolvimento de software do Ministério Público Estadual (MPE), com sede na Paraíba, Brasil. O projeto Pandora trata do desenvolvimento de um software baseado na web que começou em 2016 com o objetivo de automatizar uma demanda recorrente por informações, como endereços atualizados de pessoas investigadas em operações por promotores e procuradores de justiça. Atualmente, o sistema Pandora evoluiu e pode ser definido como um software analítico/consultivo. O software utiliza técnicas de mineração de dados e inteligência artificial para produzir relatórios de alta precisão e nível de exatidão
A equipe do projeto Pandora é composta de um Scrum Master (SM) com 7 anos de experiência em projetos de engenharia de software, dois desenvolvedores com três anos de experiência cada, um Administrador de Banco de Dados (DBA) com 3 anos de experiência no projeto Pandora, mais um Engenheiro de Infraestrutura com 4 anos de experiência no MPE e o coordenador do órgão um promotor de justiça, sem experiência com desenvolvimento de software, porém com 25 anos de atuação na área criminal. A equipe trabalha com um formato adaptado de metodologia ágil. O promotor de justiça na perspectiva do Scrum pode ser compreendido como sendo o Product Owner (PO). Esse promotor é responsável pelos requisitos do sistema Pandora e por validar os entregáveis que são disponibilizados após cada Sprint.
Assim pode-se concluir que os participantes do projeto Pandora tem pelo menos 3 anos de experiência na área de desenvolvimento de sistemas e Engenharia de Software. Todos têm formação em Ciência da Computação ou áreas afins (com exceção do promotor de justiça que é formado em Direito). Dois deles, o SM e o DBA têm pós-graduação em Gerenciamento de Projetos e experiência de atuação em Engenharia de Software anterior ao projeto Pandora. O Engenheiro de Infraestrutura é formado em Redes de Computadores.
3.1.2. Descrição do Problema
O projeto Pandora não é o primeiro projeto de desenvolvimento de software feito pela equipe do MPE. Outros projetos foram desenvolvidos utilizando a metodologia tradicional de gerenciamento de projetos. Porém, não foram bem-sucedidos do ponto de vista do cumprimento dos objetivos do projeto, cumprimento do cronograma e custos envolvidos nas entregas do projeto.
Uma das características presentes nos projetos realizados por esta equipe é que nem todos os requisitos de software são conhecidos a priori, sendo necessário utilizar uma metodologia mais adequada para este tipo de projeto. Depois de algumas pesquisas identificou-se a necessidade de uma abordagem mais objetiva para o gerenciamento ágil de projetos. Assim, adotou-se o uso de práticas como sprints, Kanban, reuniões retrospectivas de sprint, entre outras práticas que pudessem trazer maiores probabilidades de sucesso para os projetos desenvolvidos de software.
Reuniões realizadas entre os participantes do estudo e a equipe do projeto identificaram que o MPE não possui processo formal de identificação de incerteza aplicável aos seus projetos de desenvolvimento de software. Essa atividade tem sido realizada de forma ad-hoc, o que não traz segurança para o desenvolvimento contínuo das atividades do órgão. Assim, foi proposto um estudo para investigar como esta equipe ágil poderia realizar o gerenciamento da incerteza em seus projetos de software.
Também como resultado dessa reunião os pesquisadores identificaram a necessidade, não só da identificação da incerteza mas de encontrar alguma forma de mensuração dessa incerteza, uma vez que a equipe do projeto é pequena e não tem condições de atuar em todas as frentes que inúmeras incertezas identificadas exigiriam, sem uma devida enumeração de prioridades que permitam focar nas incertezas consideradas mais iminentes. Assim, a equipe do projeto precisava entender como medir a incerteza para melhor gerenciar a incerteza associada ao projeto Pandora. A equipe precisava mensurar a quantidade de incerteza existente no projeto, bem como encontrar maneiras de levar em consideração o impacto das relações de dependência existentes entre as várias fontes de incertezas no projeto.
Assim, foi proposto pelo SM realizar uma Pesquisa Ação com o objetivo de investigar como o gerenciamento da incerteza epistêmica pode contribuir para o sucesso do projeto, levando em consideração os aspectos quantitativos do gerenciamento da incerteza epistêmica. A proposta foi aceita pelo coordenador do órgão onde a equipe trabalha no MPE. Toda a equipe do projeto concordou em participar da Pesquisa Ação.
Os métodos utilizados nesta fase da Pesquisa Ação foram observação participativa, entrevistas semiestruturadas e uma revisão quasi-sistemática da literatura. A utilização de três métodos para a fase de diagnóstico pode ser observada como uma forma de triangulação para combater ameaças à validade desta pesquisa. A observação participativa permite ao pesquisador fazer parte equipe e observar a equipe do projeto simultaneamente e é muito popular em pesquisas do tipo Pesquisa Ação (Staron, 2020).
O processo de observação nos permitiu acompanhar e registrar de forma mais focada o processo de desenvolvimento de software da equipe. A coleta de dados através do sistema de gerenciamento de projetos Redmine1 nos permitiu a identificação de incertezas anteriormente registadas e as entrevistas semiestruturadas contribuíram para o diagnóstico através da Análise Temática onde foram identificados padrões e temas. O protocolo das perguntas realizadas nas entrevistas semiestruturadas pode ser encontrado neste link2. Antes da condução das entrevistas, considerações éticas foram observadas. Um formulário de consentimento foi assinado pelos participantes e foi feita uma breve explicação sobre quais ações (intervenções) seriam esperadas de cada membro da equipe.
De acordo com o cenário apresentado acima, o objeto desta Pesquisa Ação é definido como investigar, em um cenário de projeto real, como equipes ágeis abordam a quantificação da incerteza epistêmica em projetos de desenvolvimento de software.
3.2. Planejamento das Ações
Esta fase inicia com o planejamento e condução de uma revisão quasi-sistemática da literatura seguindo protocolo de Travassos et al. (2008) onde artigos foram analisados para identificar quais abordagens na literatura são utilizadas para quantificar a incerteza epistêmica em projetos de software.
Esta Pesquisa Ação foi planejada em três ciclos. Os ciclos da Pesquisa Ação e as respectivas sprints acompanhadas em cada ciclo foram: ciclo 1 de 1º de setembro até 15 de setembro de 2020 (Sprint 1) e 28 de setembro até 13 de outubro de 2020 (Sprint 2); ciclo 2 de 19 de outubro até 2 de novembro de 2020 (Sprint 3) e 9 de novembro até 23 de novembro de 2020 (Sprint 4); ciclo 3 de 30 de novembro até 14 de dezembro de 2020 (Sprint 5).
Como aspecto operacional, ferramentas online foram utilizadas para apoiar a Pesquisa Ação, como o software Wiki (Media Wiki3), para centralizar o conhecimento produzido durante a Pesquisa Ação e ferramentas de transcrição de áudio dentro da estrutura do Google Docs4 para ajudar no processo de transcrição dos áudios das entrevistas e a suíte Atlas.ti5 para visualização das relações de identificação de temas a partir dos textos das transcrições. A coleta e mensuração de dados foi feita dentro das sprints e através do sistema de gerenciamento de projetos utilizado pela equipe para registro das demandas e atividades do projeto como também registro dos eventos incertos que ocorreram ao longo do projeto.
3.3. Execução das Ações
As ações reportadas nesta seção contêm informações sobre como essas ações foram executadas a partir do planejamento feito na fase de planejamento da PA.
Ação 1 - Pesquisar abordagens para quantificação das incertezas em projetos
Através da condução das entrevistas semiestruturadas foi possível indagar a equipe do projeto se eles têm a noção do conceito de incerteza e por questões de alinhamento conceitual foi feita uma apresentação dos temas associados a incerteza e riscos presentes na literatura. Posteriormente foi questionado aos participantes se, agora com entendimento do conceito de incerteza, eles poderiam recordar a ocorrência de incertezas acontecidas durante o projeto Pandora. A identificação de incertezas ocorridas em momentos passados do projeto será apresentada nas próximas ações ainda dentro desta seção. Essa foi a ação associada a rever as estratégias para identificação e compreensão das incertezas ocorridas no projeto. A conclusão do questionário feito a equipe do projeto é que eles não adotavam nenhuma abordagem para gerenciamento ou quantificação das incertezas no projeto Pandora.
Ao final desta ação concluiu-se que é necessária a adaptação ou construção de uma abordagem para quantificação da incerteza epistêmica em projetos de software.
Ação 2 -Identificar fontes de incertezas
Após a identificação das abordagens presentes na literatura para quantificação da incerteza epistêmica, surgiu a necessidade de identificar as fontes de incertezas presentes no projeto. Como forma de auxiliar o processo, pesquisou-se na literatura por fontes de incertezas que pudessem apoiar o processo de identificação de incertezas.
De acordo com Marinho et al. (2018), fontes de incertezas são: tecnológicas, mercado, ambiental, sócio humanas e organizacionais. As fontes de incerteza puderam ser utilizadas para orientar a busca e identificação de incertezas por parte dos integrantes da equipe do projeto.
Ao final desta ação a equipe pode contar com quatro fontes de incertezas que puderam ser utilizadas na próxima ação para identificação das incertezas no projeto Pandora.
Ação 3 -Revisar as experiências da equipe com as incertezas do projeto
A partir das fontes de incertezas identificadas na literatura e que puderam servir de suporte para a identificação e registro de incertezas no projeto Pandora, iniciou-se uma ação que teria como objetivo a identificação das incertezas que ocorreram ou que podem ocorrer no projeto Pandora.
A análise da transcrição das entrevistas semiestruturadas feitas com a equipe do projeto gerou três incertezas a partir das fontes Tecnológica e Ambiental. A análise do sistema de gerenciamento de projetos utilizado pela equipe para gerenciamento das atividades do projeto Pandora também contribuiu no processo de identificação de incertezas. Desse sistema pode-se coletar duas incertezas a partir da fonte de incerteza Tecnológica. O processo de observação das sprints do projeto contribuiu com mais três incertezas a partir das fontes Tecnológica, Ambiental e Sócio Humana. Todas essas incertezas mapeadas no projeto Pandora podem ser observadas na Tabela 1.
Tabela 1 Incertezas e Fontes de Incertezas
| # | Instrumento de Coleta | Fonte de Incerteza | Incerteza |
|---|---|---|---|
| 1 | Entrevistas semiestruturassem | Tecnológica | U1 - Falta de expertise na tecnologia / linguagem de programação utilizada no projeto. |
| 2 | Entrevistas semiestruturassem | Tecnológica | U2 - Ausência de processo formal para o gerenciamento de incertezas |
| 3 | Entrevistas semiestruturadas | Ambiental | U3 - Danos estruturas na infraestrutura civil do datacenter |
| 4 | Observação Sprint | Tecnológica | U4 -Falta de expertise no processo de adoção de nova tecnologia de contêiners (Docker8). |
| 5 | Observação Sprint | Ambiental | U5 - Danos na estrutura civil (predial) do datacenter. |
| 6 | Observação Sprint | Sócio Humano | U6 - Ausência parcial ou total de integrantes da equipe por causa do Covid-19. |
| 7 | Sistema de gerenciamento de projetos | Tecnológica | U7 - Instalação elétrica inadequada para o datacenter. |
| 8 | Sistema de gerenciamento de projetos | Tecnológica | U8 - Suspeita de invasão do sistema Pandora. |
A primeira coluna apresenta uma sequência numérica para codificação das incertezas identificadas e registradas no projeto. A segunda coluna apresenta o instrumento utilizado para coleta e identificação da incerteza. A terceira coluna apresenta a classificação da fonte de incerteza dentre as fontes de incerteza descritas. A quarta coluna é composta pela incerteza identificada nesta ação precedida por um código de identificação da incerteza (a letra U é referência a palavra Incerteza no inglês Uncertainty).
Ao final desta ação a equipe contava com um catálogo de oito incertezas identificadas com o auxílio da equipe do projeto Pandora a partir de três fontes de incertezas. A próxima ação trata do processo de quantificação das incertezas registradas.
Ação 4 -Quantificação das incertezas epistêmicas
Para efeito da necessidade observada no projeto Pandora, a abordagem para quantificação da incerteza epistêmica utilizada foi a quantificação da incerteza através da Teoria da Evidência de Dempster-Shafer (TEDS) (Shafer, 1976) e (Dempster, 2008).
A TEDS foi escolhida como técnica de quantificação da incerteza para esta ação pois ela tem a vantagem de permitir o tratamento da incerteza baseado no conhecimento de especialistas (equipe do projeto), que com base em suas experiências, conhecimento e informações preliminares sobre as atividades do projeto, atribuem massa aos elementos (incertezas) no intervalo [0, 1]. Essa quantificação está associada a crença de cada especialista na hipótese escolhida da ocorrência ou não de determinada incerteza.
Outro indicativo para a escolha da TEDS foi a facilidade com que os autores deste artigo encontraram de poder compreendê-la e pela disponibilidade de bibliotecas de programação utilizando a linguagem R para produção dos scripts para automatização do processo de quantificação da incerteza epistêmica. O pacote em R utilizado para codificação do script para aplicação da Teoria da Evidência foi o pacote dst que pode ser encontrado no seu repositório no CRAN-R9 (Boivin, 2019).
Seguindo os passos descritos em (dos Santos, Ademilton and Cardoso-Junior, 2018) esta ação contou com as etapas a seguir:
1ª Etapa: Foi solicitado a cada especialista (expert) da equipe do projeto que indique quais incertezas do quadro de incertezas apresentado na ação anterior têm maiores chances de ocorrer de acordo com seus conhecimentos atuais, conhecimentos anteriores e evidências de incertezas similares que possam ter ocorrido e assim atribuir massa a esses elementos (incertezas).
2ª Etapa: Foi feito o registro das evidências coletadas de cada especialista no script em R que utilizou o pacote EvCombR6 para obtenção dos resultados de crença e de plausibilidade de ocorrência das incertezas por parte de cada especialista. Segundo o indicativo na TEDS, essas massas foram atribuídas dentro do intervalo [0, 1].
3ª Etapa: Nesta etapa foi feito o monitoramento das incertezas do projeto com o objetivo de acompanhar a evolução das atividades e incertezas associadas, e caso seja necessário, uma nova avaliação das incertezas do projeto usando a TEDS seja realizada.
O script utilizado nessa Pesquisa Ação pode ser encontrado no github7 criado para armazenar os códigos-fonte em R.
Ação 5 -Relacionar fontes de incertezas
Também através da Revisão quasi-Sistemática da Literatura executada pelos autores foi possível a identificação de abordagens que tivessem como objetivo não só a quantificação da incerteza epistêmica, mas também levasse em consideração as relações de interdependência que existem entre as diversas fontes de incerteza identificadas no projeto Pandora. A abordagem identificada na revisão da literatura que melhor se adequa a essa necessidade foi a abordagem conhecida como Rede Bayesiana (Scutari, 2010).
De acordo com Scutari (2010), o processo de construção de uma rede bayesiana passa pelos seguintes passos:
1ª Etapa: Definição da topologia da rede. Essa etapa é feita utilizando-se das incertezas identificadas para o projeto Pandora e foi realizada junto com a equipe do projeto para compreensão de quais incertezas (Us) podem ter alguma relação de interdependência. A definição da topologia da rede bayesiana tem como objetivo criar grafos que possam representar as relações causais (interdependências) entre incertezas. Esses gráficos chamados de Directed Acyclic Graph (DAGs) tem como principal característica serem não cíclicos.
2ª Etapa: Definição de uma Tabela de Probabilidade Condicional (TPC). Essa etapa é feita através da produção de uma tabela de probabilidades de ocorrência das incertezas no projeto. Esta tabela de probabilidades é o resultado da ação anterior que utilizou a TEDS para quantificação das incertezas. Sendo assim o número ou intervalo associada a cada incerteza pode ser utilizado como TPC e entrada para produção da a rede bayesiana.
A Figura 1 mostra a rede bayesiana criada durante essa ação. Para utilização de redes bayesianas aplicadas as incertezas identificas no projeto Pandora também foi possível encontrar bibliotecas de código na linguagem R. A biblioteca para redes bayesianas utilizada foi a bnlearn8 (Scutari, 2010).
Ao final deste processo pode-se ter a quantificação de oito incertezas e suas relações de interdependência. Agora é possível priorizar as ações associadas ao tratamento das incertezas uma vez que a equipe do projeto possui sua mensuração e levou em consideração, no processo, as relações de dependência entre as incertezas identificadas no projeto Pandora.
Como interpretação do grafo apresentada na Figura 1 é possível perceber, não só que foi identificada uma dependência entre a incerteza U1 (Falta de expertise na tecnologia / linguagem de programação utilizada no projeto) e U4 (U4 -Falta de expertise no processo de adoção de nova tecnologia de contêiners) como também é possível quantificar essa relação de interdependência e assim perceber em que grau (quantificação) uma incerteza pode impactar ou estar impactando em outra incerteza. Questionamentos do tipo “quanto da incerteza U1 impacta ou está associada a incerteza U4?” pode ser feito e respondido através do uso dessa técnica. Esse processo demonstra os benefícios que a equipe do projeto pode alcançar com a quantificação da incerteza epistêmica no projeto Pandora através do uso das técnicas utilizadas nas ações anteriores.
Ação 6 -Desenvolvimento de um modelo preliminar para quantificar a incerteza epistêmica em projetos de software
Após a aplicação do processo de quantificação da incerteza epistêmica com a utilização da TEDS e identificação das relações de interdependência com o uso de redes bayesianas entre as incertezas identificadas no projeto Pandora, a equipe do projeto, junto com os pesquisadores, teve segurança para propor a criação de um modelo que pudesse ser aplicado em outros projetos de forma sistêmica.
O objetivo desta ação foi formalizar a criação do modelo. A linguagem escolhida para a formalização dos processos do modelo foi a Business Process Model and Notation (BPMN9). O modelo foi criado levando-se em consideração os três processos extraídos das ações anteriores: (i) Identificação de fontes de incerteza e identificação de incertezas no projeto; (ii) Aplicação da Teoria da Evidência de Dempster-Shafer (DST) para quantificação das incertezas identificadas; (iii) Aplicação de redes bayesianas para identificação das relações de interpendência entre as incertezas identificadas no projeto. Ao final desta ação a equipe pode contar com uma versão do modelo com três etapas.
A saída do primeiro processo serve de entrada para o segundo processo que trata da quantificação da incerteza associada a esse conjunto de incertezas identificadas no primeiro processo. O segundo processo produz como saída um conjunto de incertezas mensuradas e que servem de entrada para o processo seguinte que trata da identificação das inter-relações existentes entre as fontes de incerteza utilizando para isso os conceitos de redes bayesianas.
Ação 7 -Aplicar piloto do modelo desenvolvido a uma sprint
Após a formalização de um modelo para quantificação da incerteza epistêmica em projetos, uma sprint foi escolhida como piloto para aplicação do modelo em sua versão preliminar (até esse momento ainda com três processos). A sprint escolhida foi a de número cinco que aconteceu entre novembro e dezembro de 2020.
O objetivo desta ação foi observar o uso do modelo não mais fragmentado como utilizado nas ações anteriores, mas na sua versão preliminar unindo formalmente a saída de um processo a entrada do processo seguinte. Ao final da sprint foi percebido pela equipe do projeto e pesquisadores, a necessidade de inserção de mais dois processos complementares aos processos existentes no modelo.
Primeiro foi discutido que o modelo deveria ter uma etapa de interpretação visual dos seus resultados através da análise do grafo da rede bayesiana. Sendo, conforme destacado na literatura, uma das vantagens do uso de redes bayesianas, o registro visual das incertezas caracterizadas por seus nós (incertezas) e relações de interdependência existentes.
A segunda discussão girou em torno do fato de que o modelo deveria ter uma etapa de registro dos eventos ocorridos em uma base de informações que funcionaria como corpo de conhecimento das incertezas do projeto. Esse corpo de conhecimento poderia ser utilizado em projetos futuros e funcionaria de forma muito semelhante ao processo de registro de lições aprendidas em projetos.
Como última contribuição desta ação de avaliação do modelo piloto em uma sprint, foi destacada a necessidade do modelo ter um caráter cíclico, aos moldes do ciclo PDCA (Plan, Do, Check, Act) (Johnson, 2002). O aspecto cíclico está caracterizado na necessidade de execução contínua do modelo durante o ciclo de vida do projeto, pois sabe-se que uma incerteza pode surgir em qualquer etapa do projeto, sendo no seu no início ou nas fases finais. Esse modelo em sua versão preliminar será apresentado na seção 4 deste artigo.
3.4. Avaliação e Aprendizado
Sabe-se que de acordo com a literatura do método de Pesquisa Ação, os seus ciclos devem ser executados até que um critério de parada seja alcançado. Para essa Pesquisa Ação, a avaliação do modelo construído foi feita registrando-se o número de novas incertezas identificadas no projeto e o número que representa a mensuração da incerteza identificada. Então, este foi o critério de parada para essa Pesquisa Ação.
Como um resumo geral do ciclo de Aprendizagem da Pesquisa Ação (PA) pode-se observar na Tabela 2 o cenário antes e depois da aplicação da Pesquisa Ação no MPE e de forma direta comparar seus respectivos avanços e aprendizados.
Tabela 2 Cenário antes e depois da aplicação da PA no MPE
| Antes da PA | Depois da PA |
|---|---|
| Análise baseada na percepção de especialistas | Análise baseada na elicitação de experts usando TEDS para quantificar a percepção dos especialistas |
| Incertezas não quantificadas (assumindo seu impacto potencial) | Possibilidade de quantificar as incertezas do projeto, o que permite priorizar aquelas com potencial mais significativo |
| Falha em mapear as relações que existem entre as incertezas e fontes de incerteza | Agora mapeando as relações que existem entre as várias fontes de incerteza pode-se perceber dependências entre as mesmas |
| Fontes não mapeadas de incerteza | Fontes de incerteza mapeadas de forma sistemática, pois agora existe um processo formal |
| Não existia modelo ou abordagem para quantificar a incerteza epistêmica | Existência de um modelo formal para quantificar a incerteza epistêmica |
Após a fase de Avaliação e Aprendizagem pode-se recapitular a questão de pesquisa que norteia este trabalho: como as equipes ágeis abordam a quantificação da incerteza epistêmica em projetos de desenvolvimento de software?
4. Euler - Um Modelo para Quantificação da Incerteza Epistêmica em Projetos de Software
De acordo com (Kühne, 2004), em Engenharia de Software, um modelo pode ser tradicionalmente representado por um artefato formulado em uma linguagem de modelagem como UML, ou no caso desta pesquisa, BPMN. Esse modelo pode descrever um sistema através da utilização de vários tipos de diagramas. De forma geral, esses modelos são baseados em diagramas e são tipicamente montados de forma visual. Um modelo, tendo na sua construção interna processos, pode focar em uma parte da realidade que precisa ser compreendida e gerenciada.
Para os autores deste artigo, essa parte da realidade pode ser compreendida como sendo o fenômeno da quantificação da incerteza epistêmica em projetos de software, assim a construção de um modelo que se utilize internamente de processos e diagramas para o gerenciamento das incertezas em projetos estaria justificada. Como resultado dos ciclos de Pesquisa Ação, foi construído o modelo Euler, acrônimo em inglês para Epistemic Uncertainty ModeL for SoftwarE PRoejct.
A Figura 2 apresenta uma visão geral do modelo Euler para quantificação da incerteza epistêmica em projetos de software surgido a partir da Pesquisa Ação conduzida no MPE. Essa visualização destaca o caráter cíclico do modelo e uma sequência de execução dos processos pertencentes ao modelo.
A Figura 3 apresenta o processo do modelo Euler em notação de processos de negócio (BPMN).
Conforme pode-se observar existem subprocessos dentro de cada processo para a completa execução das atividades do modelo e uma atividade associada a um processo de decisão onde é verificada a necessidade de retorno dos processos ao início do seu ciclo para identificação e quantificação de novas incertezas ou seguir para o final do seu ciclo para encerramento do processo de quantificação da incerteza. Como próximos passos desta pesquisa, deve-se realizar a avaliação do modelo através da aplicação do mesmo em outras equipes de desenvolvimento ágil, de preferência no contexto de uma equipe ágil de empresa privada a título de comparação dos seus resultados.
Espera-se que esse modelo possa contribuir para o dia a dia do gerente de projetos, de forma prática, através da redução das incertezas associadas as fases e entregas do projeto. Com a aplicação do modelo, o gestor terá um cenário de melhor planejamento aplicando a quantificação das incertezas. Ao aplicar o processo de quantificação das incertezas um gerente de projetos pode priorizar melhor as ações a serem executadas para mitigar os impactos das incertezas no projeto. Com um melhor gerenciamento das incertezas também pode-se ter maior previsibilidade no projeto trazendo assim uma maior segurança com relação as suas fases e entregas. Ao final do processo de gerenciamento da incerteza os riscos se tornam mais evidentes, sendo possível aplicar as técnicas conhecidas para gerenciamento de riscos. Assim de forma geral, pode-se coordenar melhor um projeto de desenvolvimento de software realizando entregas mais precisas resultando em melhores projetos, sendo esse, em si, um diferencial competitivo dentro do arsenal de ferramentas necessárias às equipes de desenvolvimento de software.
5. Conclusões
Apesar do crescente interesse pelo gerenciamento da incertezas em projetos de software, muitos projetos ainda falham. Estudos mostram que não se tem dado a devida atenção ao aspecto quantitativo do gerenciamento de incerteza em projetos de software. Este artigo apresentou o processo de construção de um modelo para quantificação da incerteza epistêmica em projetos de software através do uso de uma Pesquisa Ação dentro do contexto real de uma equipe de desenvolvimento de software. Como forma de contribuição, espera-se que os resultados possam ser utilizados, tanto por pesquisadores quando por praticantes do gerenciamento de projetos como forma de melhor entender os desafios associados ao gerenciamento da incerteza em projetos. Para os autores, o processo de quantificação, pode auxiliar na priorização das incertezas que agora podem ser numericamente comparáveis com outras incertezas, melhorando assim, a percepção do seu impacto nos objetivos do projeto. A melhora nesse processo de percepção resulta no melhor gerenciamento do projeto. Com relação as limitações, existem limitações associadas a condução de uma Pesquisa Ação, desde o próprio acesso a um ambiente real, passando pelo processo de como engajar os pesquisadores e praticantes para que estes compreendam os benefícios do processo de Pesquisa Ação. Uma das principais limitações enfrentadas por este trabalho está associado ao período de pandemia em que ele foi conduzido e todas as preocupações associadas a doença. Como trabalhos futuros, espera-se que o modelo seja refinado e aplicado em contextos diferentes como equipes de desenvolvimento ágil de empresas privadas e seus resultados comparados, resultando no desenvolvimento de uma nova versão do modelo.
