Visualização de informação numa transformação Agile – gestão de equipas

Universidade do Minho Escola de Engenharia David José Martins Ferreira Visualização de Informação numa Transformação Agile – Gestão de Equipas Visualização de Informação numa Transformação Agile – gestão de Equipas David José Martins Ferreira UMinho | 2022 junho de 2022 David José Martins Ferreira A80865 Visualização de Informação numa Transformação Agile – Gestão de Equipas junho de 2022 Dissertação de Mestrado Mestrado [integrado] em Engenharia e Gestão de Sistemas de Informação Trabalho efetuado sob a orientação de Professor Doutor Jorge Oliveira e Sá DIREITOS DE AUTOR Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Atribuição-NãoComercial CC BY-NC https://creativecommons.org/licenses/by-nc/4.0/ vi AGRADECIMENTOS O espaço desta secção de agradecimentos é insuficiente para agradecer, como devia, a todas as pessoas que ao longo da concretização deste projeto me acompanharam e contribuíram para a conclusão do mesmo. Uma dissertação nunca é um projeto individual, várias são as pessoas que à sua maneira nos vão ajudando, nem que seja com uma palavra de conforto. Não sei se algum dia conseguirei agradecer de forma adequada a todas estas pessoas! O meu primeiro agradecimento é endereçado ao Professor Doutor Jorge Oliveira e Sá por todo o apoio e conhecimento partilhado neste percurso. A todos os meus amigos que me acompanharam nesta vida académica ao longo destes 5 anos e fizeram deles os melhores anos da minha vida! Aos amarillos por estarem presentes nos bons e maus momentos desde que a minha adolescência começou. Por fim, o agradecimento mais importante, a toda a minha família. Aos meus pais pelo apoio incondicional em toda a minha vida, permitindo-me atingir os meus objetivos e ser o homem que sou hoje. Ao Fábio por todos os momentos de diversão e rivalidade saudável que me proporcionou. Ao Bruno por todos os ensinamentos, ajudas e mentoria que me deu ao longo de toda a minha vida. Sem vocês os quatro nada disto seria possível. vii DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio, nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. viii RESUMO Visualização de Informação numa Transformação Agile – Gestão de Equipas As empresas estão em constante evolução e a quantidade de dados recolhidos pelas mesmas é cada vez maior. Esta evolução leva a que apostem cada vez mais na utilização e aproveitamento destes dados para a alteração da sua estratégia interna de trabalho ou a estratégia de negócio. A procura pela otimização de performances nas áreas internas guiou a que as empresas começassem a encarar de diferente forma o desenvolvimento de um projeto implementando novas metodologias. Este projeto insere-se numa empresa que está numa transformação interna, sendo que começaram a adotar uma metodologia Agile para o desenvolvimento de alguns dos seus projetos, alterando assim toda a forma de os abordar e realizar. Esta metodologia não é de fácil perceção e compreensão, é necessário existir uma correta formação desde o product owner à equipa de desenvolvimento. De forma, a poder avaliar se as formações estão a corresponder às expectativas, o foco deste projeto é a avaliação da produtividade das equipas Agile comparativamente às equipas Waterfall, através da análise de dados fornecidos pela empresa. Isto vai permitir descobrir se esta nova implementação consegue aumentar o rendimento dos elementos das equipas e desta forma otimizar a eficiência dos projetos. Estes índices de produtividade serão possíveis ser visualizados e comparados através de uma dashboard . Palavras chave: Waterfall; Agile; Análise de dados; Dashboard. ix ABSTRACT Data Visualization in an Agile Transformation – Team Management Companies are in constant evolution and the amount of data collected by them are increasing. This evolution leads them to bet more and more on using and take advantage of this data to change their internal work strategy or their business strategy. The search for performance optimization in internal areas led companies to start looking at the development of a project differently implementing new methodologies. This project is included in a company that is undergoing an internal transformation, and they have started to adopt an Agile methodology for the development of some of their projects, changing the whole way they approach and carry them out. This methodology is not easy to understand, and it is necessary to have precise training from the product owner to the development team. To evaluate if the training is meeting expectations, the focus of this project is to evaluate the productivity of Agile teams compared to Waterfall teams, through the analysis of data provided by the company. This will allow us to find out whether this new implementation can increase the performance of the team members and optimize the efficiency of the projects. These KPI’s will be able to be visualized and compared via a dashboard. Keywords: Waterfall; Agile; Data Analysis; Dashboard. ÍNDICE xvi LISTA DE TABELAS Tabela 1Comparação entre Waterfall e Scrum (Mahalakshmi & Sundararajan, 2013)....................................................... 10 1 1. INTRODUÇÃO Neste capítulo é apresentado o enquadramento do tema, assim como os principais motivos que levaram à realização deste projeto. Posteriormente, é definida a estrutura do documento, onde de uma forma breve são explícitos os capítulos que o compõe. Por último, são descritos os objetivos e resultados esperados. 1.1 Enquadramento Nos últimos anos as empresas têm procurado novas soluções de modelos de desenvolvimento para as suas equipas para substituir o tradicional modelo Waterfall, uma vez que, este está-se a tornar obsoleto. A principal solução para este problema tem passado por uma adoção de um caminho de transformação Agile. Numa fonte de dados obtida no âmbito desta transformação, fornecida pela empresa com a qual esta dissertação foi realizada, foram definidos cenários sobre o modelo de convergência, quer em termos de equipas propostas em cada momento de planeamento, quer em termos de arquétipo de equipa em função dos diversos roles dos elementos que a compõem. Esta evolução está a ser acompanhada através da criação de vários modelos de análise, tanto na vertente de evolução dos portefólios de épicos, como na vertente de recursos. Nesta última evolução estão a ser criados modelos de análise da capacidade, do esforço e foco dos recursos, pois existe uma necessidade de automatizar os modelos de análise desenvolvidos, criando dashboards que permitam fazer o acompanhamento continuo da evolução. Desta forma é permitida a monitorização da composição e performance das equipas, assim como a identificação de ações de alinhamento e gestão da transformação. É assumido que estas equipas constituam um conjunto de recursos com competências complementares e, também, com percentagens de dedicação em função dos roles . O método utilizado nesta análise permite acompanhar a evolução da constituição das equipas em dados agregados e poder com maior facilidade, monitorizando decisões de composição e performance das equipas. 1.2 Objetivos e Resultados Esperados 2 Os objetivos principais desta dissertação são, através do estudo de métodos ou abordagens sobre a produtividade das equipas presentes nas organizações, elaborar uma lista de KPI’s utilizando como fator de medição a sua produtividade. Através deste resultado elaborar uma dashboard , através da visualização dos indicadores identificados anteriormente, que permitam o acompanhamento contínuo das equipas, a visualização da diferença de produtividade de equipa para equipa e também dos membros que integram as mesmas. 1.3 Abordagem Metodológica Uma vez que, esta dissertação é realizada em parceria com uma empresa, são propostas tarefas e também objetivos de forma a delinear uma solução que vai de encontro ao pretendido no projeto, mas também às necessidades da empresa. Por este motivo não foi aplicada nenhuma abordagem metodológica genérica, contudo as atividades que serão necessárias realizar vão servir de orientação para atingir os melhores resultados possíveis e obter o máximo de conhecimento. Posto isto, a lista de tarefas a serem abordadas neste projeto é a seguinte. Compreensão das temáticas envolventes no projeto da dissertação: Nesta tarefa foi realizado um estudo sobre todas as temáticas que envolvem esta dissertação e desenvolvido o máximo de conhecimento possível de forma a aplicá-lo nas atividades que se seguem. Esta etapa detém uma importância diferenciada das restantes pois reúne todos os conceitos teóricos necessários para o sucesso da dissertação. Compreensão dos dados: Para iniciar a parte prática desta dissertação foi entregue, pela empresa para a qual este projeto foi realizado, uma fonte de dados sobre a produtividade das equipas na mesma. O objetivo desta etapa é a compreensão de todas as colunas no datamart e posteriormente filtrar e tratar apenas as colunas necessárias para a criação dos KPI’s. Elaboração de uma lista de KPI’s: Durante esta fase foi elaborada uma lista dos KPI’s que visam responder com sucesso todos os objetivos do projeto. Estes foram criados com base na fonte de dados fornecida, no conhecimento adquirido nas etapas anteriores e também nas limitações da ferramenta utilizada para a construção dos dashboards . Criação do dashboard : Com base na etapa anterior, foi desenvolvido um dashboard objetiva e clara para todos as pessoas que a visualizarem, sendo que este responde a todos os KPI’s anteriormente 3 criados. O objetivo do dashboard passa por reproduzir em conjuntos de gráficos de fácil perceção e que apresente toda a informação importante que está presente no datamart recebido. 1.4 Estrutura do Documento Neste documento são apresentados os quatro capítulos que perfazem a estrutura do presente documento. No primeiro capítulo é apresentado o enquadramento da dissertação, de forma a dar a conhecer o seu tema, como surgiu a necessidade do mesmo e quais as suas motivações. É também descrito os objetivos e resultados esperados e a abordagem metodológica aplicada durante o desenvolvimento da mesma. No segundo capítulo, é realizado o levantamento do estado da arte sobre os temas envolvidos no projeto. Numa primeira instância é desenvolvida uma estratégia de pesquisa para verificar a melhor abordagem possível aos conceitos abordados, em seguida, os mesmos são apresentados. Após isso, são apresentadas diferentes metodologias de desenvolvimento de software, iniciando com uma breve introdução sobre o seu conceito e quais as mais utilizadas. Prontamente, são descritas as metodologias Waterfall e Agile, abordando como surgiram, em que é que consistem e a sua evolução até ao momento. Posteriormente é realizada uma discussão entre ambas, para compreender as principais diferenças. São ainda apresentadas as plataformas para o desenvolvimento de data analysis . Antes de descrever a sua utilidade é realizada uma introdução relativa ao tema data analysis , de forma a entender a necessidade da utilização destas ferramentas de analise neste tema. Para concluir esta secção do documento, são apresentadas as ferramentas de visualização em que é feita a descrição das mesmas por forma a compreender a sua utilização e as suas funcionalidades. No capítulo três, é realizada uma análise do problema que originou o pedido deste projeto e o processo de determinação dos KPI’s. Numa primeira fase foi necessária a marcação de várias reuniões com a equipa que requisitou o dashboard para perceber o seu ponto de vista e definir a melhor abordagem ao problema. Após esta identificação procedeu-se à sua avaliação através da definição de métricas que respondem às preocupações e necessidades da equipa. Para a construção do dashboard estas métricas são abstratas, portanto foi necessário conceber os KPI’s. O quarto capítulo desta dissertação, numa primeira fase é descrito a funcionalidade dos três softwares e programas que foram utilizados para completar o projeto. De seguida, é retratada toda a fase de ETL, parte fundamental para o sucesso deste projeto. Nesta fase é descrito as quatro explorações criadas que originaram as tabelas de dados necessárias para completar o projeto e explicado como 4 funciona o processo de uma exploração desde a extração de dados à publicação da tabela em produção para ficar disponível no software de criação dos dashboards . O capítulo, Dashboards, ilustra todos os dashboards que foram concebidos, explicando ao pormenor os detalhes e funcionalidades que cada um tem. Este capítulo representa a parte final do projeto prático e aglomera todo o trabalho desenvolvido durante esta dissertação. O sexto e último capítulo apresenta as conclusões a retirar do trabalho realizado seguindo-se das dificuldades e limitações apresentadas ao longo da dissertação e propõe o trabalho futuro associado ao tema em questão. 5 2. ESTADO DE ARTE Neste capítulo é apresentado os temas abordados ao longo do desenvolvimento da dissertação. O mesmo encontra-se dividido em três secções. Inicialmente, é abordada a estratégia de pesquisa utilizada, por forma a recolher o máximo de informação para a realização com sucesso deste tema. Seguidamente, são abordadas e descritas as temáticas de metodologias de desenvolvimento de software, mais concretamente, Waterfall e Agile. Na última secção deste capítulo são apresentadas as plataformas de visualização de informação. 2.1 Estratégia de Pesquisa Para a realização do estado da arte desenvolvido nesta dissertação, foi utilizada uma revisão narrativa, também conhecida como revisão assistemática. O seu objetivo consiste em reunir o máximo de informação útil para descrever os temas abordados, através da leitura de artigos, teses, dissertações e livros. Esta revisão não utiliza critérios especializados nem pesquisas sofisticadas e exaustivas. Contrariamente a uma pesquisa sistemática, é possível a existência de um foco alargado durante a pesquisa que permite a existência do início da pesquisa num ponto de partida simples e acabar em vários conceitos relevantes. Nesta dissertação será avaliada a performance de equipas Agile comparativamente a equipas Waterfall, assim sendo foram priorizados dois tópicos de pesquisa numa fase inicial. O ponto de partida foi a pesquisa sobre os conceitos de metodologia Waterfall e metodologia Agile, abordando temas como o seu surgimento, como funciona cada uma delas. É ainda realizada a comparação entre ambas para perceber quais as vantagens e desvantagens de cada uma e por fim e por fim, que tipo de metodologias são utilizadas atualmente nas empresas. Numa segunda fase da pesquisa foram abordados temas mais técnicos, o foco foi dirigido para Data analysis , visualização de informação e ferramentas para visualização de informação. 6 2.2 Metodologias de Desenvolvimento de Software 2.2.1 Introdução Atualmente, existem várias metodologias para o ciclo de vida do desenvolvimento de software, sendo as mais utilizadas, Waterfall e Agile. Recentemente, a mistura e/ou a opção entre as duas tornouse muito importante (Gabriela et al., 2018). A metodologia de desenvolvimento Waterfall foi a primeira a ser implementada, enquanto a Agile apenas surge passado uns anos, durante a década de 90. Ambas foram criadas com um objetivo claro, o de auxiliar a gestão do desenvolvimento de um software, definindo assim uma linha de prioridades, fases e prazos que devem servir de orientação durante todo o seu desenvolvimento. A implementação destas metodologias tiveram um impacto enorme na planificação de cada projeto, verificando-se um aumento do seu sucesso, (Khoza & Marnewick, 2020), cumprimento dos requisitos definidos e redução dos custos. O sucesso de um projeto depende de inúmeros fatores, sendo necessário existir uma gestão competente dos mesmos para atingir os fins pretendidos. Desta forma, para garantir que os objetivos propostos são atingidos é também necessário existir um alto conhecimento da metodologia de desenvolvimento que irá ser utilizada por parte do gestor de projeto. 2.2.2 Metodologia Waterfall A primeira publicação sobre a metodologia Waterfall, é creditada pelo artigo de Walter Royce em 1970, e consiste num modelo defeituoso e não funcional (Eason, 2016). Esta metodologia é um processo de desenvolvimento de software sequencial em que o progresso é considerado como um fluxo descendente (semelhante a uma cascata), através de uma lista de fases que têm de ser executadas em prol do sucesso do projeto (Bassil, 2012). Na figura 1, é possível visualizar o formato de cascata que esta metodologia apresenta e as respetivas fases. 7 Figura 1The Waterfall model, adaptado de (Bassil, 2012) Este modelo, é um dos primeiros modelos SDLC, Software Development Life Cycle, e compreende cinco fases consecutivas, sendo elas: Análise de negócio, design , implementação, testes e por último manutenção (Bassil, 2012). Estas fases são sequenciais, procedendo-se sem qualquer sobreposição (Www et al., 2008). A primeira fase em metodologias tradicionais de desenvolvimento de software foca-se no levantamento dos requisitos do sistema, pois estes são cruciais para o desenvolvimento e bom funcionamento do projeto. Os requisitos têm de ser claros e muito bem definidos antes de se poder iniciar a fase seguinte, uma vez que, a sua alteração numa fase mais avançada do projeto pode-se tornar bastante dispendiosa, e, em alguns casos, nem pode nem ser considerada como opção(Eason, 2016). A fase de design é iniciada logo após o térmico da primeira fase e detalha a identificação da solução do sistema. É neste processo que se define a estética do projeto e as funcionalidades a nível visual que este possuíra. O documento das especificações do design serve de input para a fase de construção e programação de software (Mitra Pedersen, 2013). A terceira fase, refere-se à implementação dos requisitos do negócio e as especificações do design num programa executável concreto, base de dados, website, ou num componente de software através de programação e desenvolvimento. É nesta fase que é desenvolvido e compilado o algoritmo numa aplicação operacional, onde a base de dados e os ficheiros de texto são criados (Bassil, 2012). A fase de teste é um processo de controlo em que se verifica se a solução de software realiza o propósito pretendido de acordo com os requisitos e especificações originais. Primeiramente, é realizado o debugging ao sistema de maneira a encontrar e resolver todos os seus problemas. Após isso, é 8 realizada uma verificação no qual esta componente é um processo de avaliação do software para determinar se os produtos de uma determinada fase de desenvolvimento satisfazem as condições impostas no início dessa fase. (Bassil, 2012). É ainda nesta fase, que se inclui o cliente de maneira a obter o seu feedback relativo a uma primeira abordagem da solução implementada (Eason, 2016). A última fase, é a etapa de operações e manutenções, na qual é prestado auxílio ao cliente sempre que necessário. Esta fase não tem término uma vez que, as manutenções deverão ocorrer indefinidamente.(Mitra Pedersen, 2013). A principal característica da utilização desta metodologia de desenvolvimento é ser sequencial pois, desta forma, permite ser facilmente implementado. Outras vantagens presentes neste modelo são, serem apenas necessário mínimos recursos para a sua utilização, não existir sobreposição de fases e a sua facilidade de uso pois é um modelo bastante conhecido entre os programadores de software (Murugaiyan, 2012) (Mitra Pedersen, 2013). No entanto, o modelo Waterfall também tem as suas desvantagens. Uma vez que, a fase de testes é apenas realizada na parte final do processo, alterações profundas derivadas a problemas encontrados serão muito mais moradas e dispendiosas. Isto vai resultar em atrasos nas entregas previstas (Abramowicz et al., 2012). Outra desvantagem, passa pela impossibilidade de alteração dos requerimentos do projeto por parte do cliente numa fase mais adiantada. Caso seja indispensável essa alteração, implica um recomeço de todos os processos até aí já realizados. 2.2.3 Metodologia Agile A necessidade de maior flexibilidade durante o desenvolvimento de um software fez com que os programadores começassem a afastar-se de modelos mais tradicionais como é o Waterfall. Desta forma, surgiu durante a década de 90, a metodologia Agile, ver figura 2 (Mitra Pedersen, 2013). Este modelo foi criado para contrariar um dos maiores problemas da metodologia Waterfall, sendo este a difícil adaptação a alterações nos requisitos. A metodologia Agile foi desenhada para proporcionar uma resposta efetiva à mudança, baseando-se num desenvolvimento interativo. O modelo divide os projetos em sprints , isto é, mini projetos ou iterações que possuem os seus próprios objetivos. 9 Figura 2Agile Process model (Fernando & De Freitas, 2015) Cada iteração precisa de percorrer todas as fases da metodologia e no final de cada miniciclo é necessário apresentar resultados que satisfaçam o cliente. No caso de o cliente não estar satisfeito ou pretender mudanças, estas devem ser realizadas antes de avançar para o próximo sprint (Fernando & De Freitas, 2015; Eason, 2016). Esta metodologia é cada vez mais utilizada pela sua simples compreensão e implementação, proporcionando uma maior visibilidade, previsibilidade e flexibilidade encorajando as equipas a desenvolver com alto desempenho (Rover et al., 2014). É possível afirmar que o Agile melhora a qualidade do projeto, otimiza o tempo e é bastante responsivo à constante necessidade do cliente, o que leva a uma maior satisfação do mesmo. Outras vantagens presentes neste modelo é o facto de aceitar e prever mudanças, realizando-as facilmente. A realização de sprints permite a existência de um maior controlo do tempo estimado para cada iteração, levando ao cumprimento do tempo regulamentado para o projeto. Apesar destes pontos positivos referidos, esta metodologia também lida com problemas. Os membros da equipa são essenciais para o sucesso do projeto, é necessário um empenho total dos mesmos, caso isto não aconteça o mesmo irá falhar. Outro problema presente no modelo é a falta de documentação no inicio do projeto, contrariamente à metodologia Waterfall, esta é realizada durante o 16 anteriormente referidos, foi escolhida a ferramenta SAS Visual Analytics para a construção da dashboard do projeto. 17 3. ANÁLISE DO PROBLEMA Neste capítulo será abordado o problema que originou este projeto, procedendo à sua identificação e avaliação para ser possível determinar os KPI’s para a criação dos dashboards . 3.1 Identificação do Problema A empresa com que este projeto está a ser realizado tem adotado a metodologia Agile em diversos projetos que está a realizar. Detetou-se um problema quando a equipa PMO (Project Management Office) necessitava de realizar análises diárias de indicadores como a performance das equipas em projetos, as entregas realizadas pelas equipas de projeto, etc. A equipa vê estas análises como uma mais-valia de forma a realizarem uma gestão eficiente dos recursos e projetos. Este problema alarga-se também à metodologia Waterfall, sendo que também existe carência de analises. Desta forma, a equipa PMO quer monitorizar as análises através da criação de dashboards que permitam o acompanhamento destes temas. 3.2 Avaliação do Problema De forma a ir de encontro aos problemas reais e perceber qual era o objetivo do projeto foi necessário realizar várias reuniões com a equipa PMO . Através destas reuniões foram cedidas várias fontes de dados com informações relevantes tanto de projetos Waterfall como Agile e também, determinadas várias métricas iniciais que necessitavam de ser abordadas, tais como: • Visão mensal dos projetos que são começados, dos projetos em progresso e dos terminados; • Média de entregas mensais por épico para o negócio e para os end-users; • Evolução das entregas nos épicos ao longo dos meses; • FTE (full time equivalent) = 𝑛𝑟 𝑑𝑒 ℎ𝑜𝑟𝑎𝑠 𝑡𝑟𝑎𝑏𝑎𝑙ℎ𝑎𝑑𝑎𝑠 𝑛𝑟 𝑑𝑒 ℎ𝑜𝑟𝑎𝑠 𝑢𝑡𝑒𝑖𝑠 𝑎𝑙𝑜𝑐𝑎𝑑𝑎𝑠 𝑎𝑜 𝑝𝑟𝑜𝑗𝑒𝑡𝑜; • Preferência dos elementos sobre o tipo de projeto; • Satisfação em relação a diferentes características dos projetos Agile; Estas métricas foram recolhidas ainda numa fase inicial com o propósito de as analisar e, em conjunto, com as fontes de dados determinar quais os KPI’s relevantes para a análise pretendida. 18 3.3 Determinação de KPI’s Um Key performance indicator (KPI) é um valor mesurável que demonstra eficazmente se uma empresa/equipa está a alcançar os objetivos definidos. O processo de construção de KPI’s tem de ter em atenção diversos fatores sendo um deles o discernimento que apenas um número limitado de KPI’s é sustentável para uma gestão eficaz destes. A existência de um grande número dos mesmos ou indicadores demasiado complexos podem levar à saturação de recursos e ocupar demasiado tempo. Para a medida da performance de um KPI ser eficaz, as medidas devem ser compreendidas e aceites pela pessoa ou departamento responsável pelo projeto. Após esta aceitação é necessário ter consciência que os KPI’s necessitam de evoluir e de mudança de forma a acompanhar os objetivos. (Chan & Chan, 2004) A forma mais linear e simples de medir a performance de um KPI é através do método SMART . • Specific , o KPI é elucidativo e específico na definição do objetivo do mesmo; • Measurable , é possível medir o KPI através de um valor objetivo; • Attainable , definir metas atingíveis e realísticas; • Relevant , o KPI deve ser relevante e importante para os objetivos do projeto; • Time - bound , deve ser definido um prazo para cumprir o KPI. Após uma análise mais teórica sobre KPI’s foi necessário elaborar os mesmos, com base nas métricas referidas no subcapítulo anterior. A conceção destes nunca é linear, é necessário uma discussão e entreajuda, neste caso, com a equipa de PMO . Assim sendo, foi elaborado um esboço de KPI’s para serem apresentados em reunião. Na reunião, em conjunto com a equipa de PMO , foram melhorados os KPI’s obtendo estes três finais. • Obter uma satisfação da metodologia Agile implementada acima dos 75% • Aumento das entregas mensais em ambas metodologias • Diminuir o número de projeto em que cada elemento está alocado ao mesmo tempo. O primeiro KPI será avaliado através de um questionário realizado a diversas equipas Agile que integram elementos que pertencem ou já pertenceram a projetos Waterfall. O segundo, é o resultado de diversos indicadores de análise, tais como: • Realizar uma comparação da quantidade de projetos Waterfall e Agile que são alocados às equipas; 19 • Obter uma visão mensal dos projetos que são começados, dos projetos em progresso e dos terminados; • Média de entregas mensais por épico para o negócio e para os end-users ; • Evolução das entregas nos épicos ao longo dos meses Por último, foi concebido um KPI para avaliar os elementos individualmente para perceber a quantidade de projetos que estes estavam incluídos ao mesmo tempo, sendo que através desta perceção pretende-se que os elementos comecem a focar apenas em projetos Agile ou Waterfall e não realizar uma mistura de ambos. Com isto, aumentar a produtividade e a velocidade de entrega de projetos. Os três KPI’s pertencem a subtemas diferentes pois o PMO pretende analisar estes através de diversos dashboards presentes em dois relatórios diferentes. Foi então necessário numa primeira fase determinar os três subtemas que iriam ser abordados no relatório. Posteriormente, a realização de um brainstorm foi fundamental para elaboração dos vários indicadores para análise que iriam resultar nos KPI’s finais. Esta fase foi imprescindível para a criação de uma base estável para sustentar a criação dos mesmos. A fase final desta criação baseou-se nos indicadores mais importantes que tinham sido criados e que poderiam conceder a melhor análise para o PMO. 20 4. COMPREENSÃO E ANÁLISE DOS DADOS Neste capítulo irá ser demonstrada a fase de ETL que originou as tabelas finais para os dashboards . As tabelas foram o resultado de várias fontes de dados recolhidas e devidamente analisadas, de forma a obter todos os dados necessários para esta análise. Será apresentada de forma individual o processo de criação de cada uma das tabelas que serão utilizadas nos dashboards . Para concluir este processo foram utilizadas três plataformas, sendo elas, SAS Data Integration Studio, para a extração, tratamento e carregamento dos dados. SAS Guide para desenvolver testes aos dados e perceber se todas as extrações e transformações foram efetuadas corretamente. Por último, MobaXterm para pesquisar os dados físicos das tabelas utilizados. 4.1 SAS Data Integration Studio O SAS DIS é o software utilizado na empresa com que foi desenvolvida esta dissertação para a fase de ETL de qualquer projeto. Este software tem uma organização por pastas já delineada pela organização, ver figura 4. Os acessos para a criação de pastas neste software são bastante restritos por parte da organização. Desta forma, para iniciar esta fase foi necessário fazer um pedido à equipa do informacional (Equipa responsável por atribuir acessos à edição livre do software e também responsável pela criação de pastas) para realizar a criação de uma pasta para os jobs e tabelas dentro da pasta PMO. Figura 4Página inicial SAS DIS 21 Todos os dados presentes neste software são dados metadata, isto é, todas as tabelas que se encontram no software apenas têm gravado os nomes dos campos da mesma, o seu nome metadata, o nome físico (Nome utilizado para aceder na base de dados) e a biblioteca associada (Todos os projetos têm a sua própria biblioteca, que funciona como um espaço físico na base de dados onde são guardados os dados das tabelas referentes a cada projeto). Os dados encontram-se gravados em bases de dados SAS e para aceder a estes é necessário realizar vários passos. 1. É necessário ver a biblioteca a que a tabela está associada; 2. Abrir o programa MobaXterm e pesquisar o caminho físico em que a biblioteca se encontra na base de dados; 3. Abrir o software SAS Guide, pesquisar pelo caminho da biblioteca e abrir a tabela. Após perceber todo este processo foi necessário conceber os vários process flows para a criação das tabelas necessárias para a construção dos dashboards . 4.2 SAS Guide Esta ferramenta tem funcionalidades de ETL, tal como a ferramenta anteriormente referida, mas neste projeto apenas foi utilizada para a realização de testes. A diferença entre o SAS DIS e o SAS Guide é que esta ferramenta trabalha com os dados físicos das tabelas, isto é, neste software é possível aceder e visualizar aos dados completos de todas as tabelas da organização. Para isto acontecer existem duas formas, a primeira é necessário realizar os passos descritos no final do subcapítulo anterior e posteriormente abrir a tabela manualmente como podemos verificar nas figuras 5 e 6. A segunda forma de visualizar os dados neste software foi o método utilizado neste projeto, através de testes. Numa primeira fase é necessário copiar o código de cada job criado no SAS DIS, este código é criado automaticamente e impossível de alterar por parte do utilizador. Após este procedimento, no SAS Guide é criado um programa onde se efetua uma copia do código de cada job num programa diferente, correndo os mesmos pela ordem de criação destes no SAS DIS. Após correr estes programas são originadas todas as tabelas que são criadas na fase de ETL dos respetivos jobs . É possível visualizar na figura 7, o programa com o código copiado. Na figura 8, podemos visualizar o resultado da última tabela do job que foi executado e por fim, o esquema do programa e todas as tabelas correspondentes à exploração, na figura 9. 22 Figura 5SAS Guide: Program Figura 6SAS Guide: Libraries 23 Figura 7SAS Guide: Código Figura 8SAS Guide: Tabela 24 Figura 9SAS Guide: Process Flow 4.3 MobaXterm O programa MobaXterm é muito semelhante à linha de comandos existente em todos os computadores. Nesta organização é utilizado para aceder e alterar todos os ficheiros da base de dados. Neste projeto foi utilizado apenas para pesquisar o caminho físico das tabelas que foram utilizadas no SAS DIS para realizar testes no SAS Guide, para isto foi necessário copiar o código da biblioteca de cada tabela e fazer a pesquisa demonstrada na figura 10. 25 Figura 10MobaXterm 4.4 ETL A fase de ETL foi bastante importante e trabalhosa para o desfecho deste projeto, o resultado ditou os dados que seriam utilizados para a construção dos dashboards . As ferramentas utilizadas no desenrolar desta etapa foram mencionadas nos três subcapítulos anteriores. Para iniciar a fase de ETL foi necessário realizar os passos de criação de pastas descrito no subcapítulo 4.1. De forma a criar uma organização eficiente e que satisfizesse os requisitos do PMO foram criadas duas pastas para a criação das tabelas e jobs . Uma pasta referente ao Planview , programa utilizado pela empresa para diversos assuntos, tais como: • Alocar o número de horas diárias que cada trabalhador prestou em cada projeto que está inserido; • Inserir todos os projetos iniciados no departamento de informação e tecnologia; • Inserir a duração de cada sprint, entregas e tempo total de cada projeto; • Inserir avaliações atribuídas aos projetos. A maioria dos dados necessários para completar os requisitos dos KPI’s foram retirados deste programa. A segunda pasta criada é referente ao questionário que foi realizado aos trabalhadores sobre a satisfação nos projetos Agile e Waterfall. Nestas pastas existe uma divisão para separar as tabelas que 32 equipa de PMO, sendo estas “4. Ready to go-live ” que se refere ao final do desenvolvimento do software por parte dos developers e é entregue em ambiente de desenvolvimento. Após esta entrega é necessário que outra equipa da empresa disponibilize este software em produção e disponível para o cliente utilizar, esta fase de disponibilização ao cliente é a fase “5. Turn-key moment ”. Nesta visão global é possível perceber a grande diferença existente entre ambas as metodologias na frequência de entregas por épico, sendo esta mais significativa na primeira fase de entregas, na qual Agile tem maior percentagem comparativamente à fase de entregas ao cliente. 5.1.2 Delivery Frequency by Month Na figura 18, está representada a segunda secção relacionada com uma análise mais detalhadamente dos dados realizando uma análise mensal das entregas nas diferentes fases por o tipo de metodologia. Na metade de cima foram escolhidos três gráficos borboleta, os primeiros dois retratam a diferença, ao longo dos meses, do número exato de entregas na metodologia Agile e Waterfall, distinguindo-se os dois pela fase em que essas entregas foram realizadas, 4. Ready to go-live e 5. Turnkey moment . O terceiro gráfico representa o número de épicos que existiram em cada mês nas diferentes metodologias. Os três gráficos ficaram ordenados cronologicamente para facilitar a interpretação dos utilizadores. Na segunda metade da secção, nos primeiros dois gráficos, 4. Ready to go-live per Month per Epic e 5. Turnk-key moment per Month per Epic respetivamente, é possível visualizar a relação entre o número de entregas pelo número de épicos. Isto permite perceber média de entregas que existe num épico em cada mês e tal como nos outros gráficos podemos observar uma comparação entre metodologias. Após analisar estes podemos observar que apesar de ambas metodologias possuírem um número de entregas sem grandes discrepâncias a média de entregas por épico é bastante inferior em Waterfall. Isto deve-se pelo número superior de épicos existentes nesta metodologia. O gráfico Ratio Type 4 and 5 for Agile vs Waterfall demonstra o rácio da média de entregas por mês e por épico entre as duas metodologias. Neste gráfico é possível fazer uma comparação mais facilitada entre as fases tipo 4 e tipo 5 mensalmente. Ao contrário dos outros gráficos que existia regularidade na superioridade de uma das linhas, neste encontra-se maior irregularidade e semelhança de valores pois a diferença do rácio de entregas entre metodologias é bastante semelhante em ambas as fases. 33 Este gráfico possui cores diferentes para as linhas pois, desta forma é possível dar a entender ao utilizador que os dados retratados nas linhas do terceiro gráfico são diferentes dos restantes gráficos desta secção que se usou o vermelho e o cinzento para se referir ao Agile e Waterfall, respetivamente. Nesta metade de baixo, foi escolhido demonstrar os dados em gráficos de linhas por ser visualmente mais apelativo para o utilizador diferir dos gráficos da metade de cima. Após decidir que necessitava de um tipo de gráfico diferente, o gráfico de linhas foi o que mais se adequava para representar a evolução dos valores no decorrer dos meses. Figura 18Dashboard PMO DFS, Secção Delivery Frequency by Month Esta secção é mais complexa e completa do que é visível na primeira impressão. Se o utilizador quiser ver o detalhe das entregas que foram realizadas num determinado mês ou que épicos existiram com a filtragem que o utilizador optou, é possível através de um duplo clique nas barras que queremos explorar. Como é possível visualizar na figura 19, é aberto um pop-up com uma tabela detalhada da entrega/épico em questão e três filtros para auxiliar essa pesquisa. Neste caso está representada a tabela de detalhe do gráfico 4. Ready to go-live . Todos os gráficos da metade de cima da secção têm a tabela de detalhe e estão demonstrados nos Anexos. É possível descarregar estas tabelas em formato csv, sendo uma funcionalidade bastante útil para guardar dados mais específicos. 34 Figura 19Detalhe do gráfico 4. Ready to go-live 5.1.3 Delivery Frequency – Table Esta secção, tal como o nome indica, é uma tabela e não possui gráficos. Isto acontece de forma, a cumprir todos os requisitos e agradar a equipa de PMO. É algo comum, nesta empresa, os clientes (neste caso a equipa de PMO funciona como um cliente interno que requisitou um projeto) além das habituais páginas com gráficos e indicadores, querem uma secção com apenas tabelas para poderem visualizar métricas e valores absolutos. Numa reunião com a equipa foram decididas as medidas que queriam pôr na tabela. Ao contrário dos gráficos apresentados na secção anterior esta tabela não tem a funcionalidade de abrir um pop-up pois apenas contem dados numéricos não associados a dados alfabéticos, ver figura 20. 35 Figura 20Dashboard PMO DFS, Secção Delivery Frequency - Table 5.1.4 Delivery Frequency Timeline A última secção deste dashboard é a Delivery Frequency Timeline , na qual foi realizada uma análise mais detalhada apenas às equipas Agile, sendo que estas podem ter épicos Waterfall associados. Este foi mais um dos requisitos da equipa de PMO para controlarem e estarem a par do desenvolvimento de todos os projetos Agile específicos. Esta secção tem uma diferença comparativamente às restantes, além dos filtros de relatório que afetam todas as secções foram colocados quatro filtros para auxiliar a pesquisar na tabela. Destes filtros, três são de escrita para realizar uma pesquisa pelo nome da equipa, o seu código de trabalho ou pelo nome do épico e no quarto filtro foi criado uma lista para selecionar se pretendemos analisar épicos Agile ou Waterfall. Foi utilizada uma tabela cruzada para fazer uma análise conjunta das equipas Agile e os épicos que criaram com o tipo de entrega que realizaram e a data correspondente. O resultado encontra-se na figura 21, em que a cinza é o tempo em que o épico esteve aberto sem entregas e a vermelho e verde a fase final de desenvolvimento e a entrega do software ao cliente ou ambas, respetivamente. Nesta tabela podemos observar várias situações como realizar entregas e o épico continuar, o épico terminar com uma entrega independentemente do tipo, mas algo que é comum em todas as situações é o facto de um épico apenas começar quando o anterior termina. Quando aparece uma situação em que existe 2 épicos na mesma semana significa que existiu uma revisão do épico anterior antes de começar o novo. Na figura 22, encontra-se uma análise dos épicos Waterfall, esta tabela representa adequadamente a diferença entre as metodologias para qualquer utilizador que esteja a 36 analisar. Estes épicos diferenciam-se dos anteriormente referidos pelo facto de ser bastante mais extensos e existirem períodos mais longos sem nenhuma entrega ou, o contrário e existir três semanas seguidas com entregas, estes épicos não são tão lineares. A diferença principal entre os dois que é possível visualizar é o facto de em Waterfall as equipas estarem com vários épicos ao mesmo tempo, tendo de distribuir as horas de trabalho por ambos, os épicos Agile têm o foco completo das equipas. Figura 21Dashboad PMO DFS, Secção Delivery Frequency Timeline (Agile) Figura 22Dashboad PMO DFS, Secção Delivery Frequency Timeline (Waterfall) Ao contrário da secção anterior, esta tabela cruzada possui um pop-up de detalhe, ver figura 23, em que é possível ver mais informação sobre o épico além do nome da equipa e código. Um ponto vantajoso desta tabela ter detalhe para além de mais informação, é o facto de caso se faça um duplo clique num dos quadrados verdes, este mostra uma linha caso apenas exista uma entrega do tipo 5 ou duas linhas de informação com a entrega da fase de desenvolvimento e entrega ao cliente, como é possível visualizar no exemplo em baixo apresentado. 37 Figura 23Detalhe da tabela Delivery Frequency Timeline 5.2 PMO Employee Satisfaction Grande parte dos trabalhadores da empresa com a qual a dissertação está a ser realizada trabalham há vários anos na mesma e a metodologia Agile começou a ser implementada nos projetos nos últimos anos. Desta forma, além de analisar as métricas de sucesso dos projetos Agile, a equipa de PMO pretende saber qual é a opinião dos trabalhadores a usarem esta metodologia, acreditando que o primeiro passo para o sucesso é a satisfação dos trabalhadores. O dashboard PMO Employee Satisfaction foi construído para responder a esta necessidade e apresenta tanto avaliações gerais e perguntas genéricas como avaliações de fases e pontos mais específicos. Na construção foi decidido que este seria dividido em três secções, a primeira para dar uma visão global dos resultados e as outras duas para análises mais especificas aos questionários e à função dos elementos nas equipas. Este relatório apenas contém dois filtros pois a informação contida nos dados é bastante concisa. O primeiro filtro “ Role ” corresponde ao papel da pessoa na equipa Agile que respondeu ao questionário. O filtro “ Survey ” representa a data em que foi respondido o questionário, sendo que existiu sete datas diferentes em que foram realizados estes questionários com 2 anos e meio de diferença entre a primeira e a última. É possível visualizar os filtros no capítulo anexos. 38 Neste dashboard , existiu uma adição de cor predominante comparativamente ao PMO Frequency Delivery . Além do vermelho e cinzento, cores da empresa, foi adicionada a cor verde para representar as respostas positivas em relação à satisfação, variando o tom da cor para diferenciar os níveis da mesma. 5.2.1 Overall Nesta secção é representada uma visão de valores globais da satisfação das pessoas a trabalhar com Agile, ver figura 24. Esta foi desenhada a pensar em dois tipos de utilizadores, os que apenas dão uma vista rápida ao dashboard e pretendem em poucos segundos perceber os valores gerais que importam. Assim sendo, foi criado um título com os valores da preferência da metodologia e recomendação da mesma. Para acrescentar, na parte esquerda da secção foi incluído três valores de avaliações, bem destacados, essenciais para a equipa de PMO. O outro tipo de utilizador é aquele que gosta de avaliar todos os pormenores, por conseguinte foi acrescentado mais três gráficos de valores globais mais pormenorizados. Figura 24Dashboard PMO ES, Secção Overall O gráfico mais saliente desta secção descreve a satisfação dos trabalhadores em cinco situações distintas que existem durante um projeto. Este é apresentado através de um gráfico de barras em forma de percentagem em vez do habitual gráfico com barras de diferentes tamanhos e valores absolutos. Esta forma permite uma leitura mais concisa e percetível em relação aos objetivos do dashboard . Este demonstra a clara superioridade de satisfação da metodologia Agile comparativamente a Waterfall, sendo 39 a velocidade das entregas o ponto com menos destaque em Agile, causando uma insatisfação acima da média das restantes situações. O gráfico em donut presente nesta secção representa a percentagem de preferência de metodologia, no qual percebe-se que as pessoas que preferem Waterfall é bastante reduzida até comparativamente às pessoas que não têm preferência. Além desta informação apresenta no meio o número de questionários respondidos. Por último, é apresentado um gráfico de barras com o número de respostas por tipo de papel do elemento da equipa. Este gráfico poderá parecer confuso, no entanto é de fácil perceção uma vez que através da figura 25 percebe-se que à medida que o rato se encontra por cima de uma das cores, este apresenta a respetiva caixa de informação em que o “código Período Inquérito” correspondente à data de realização do questionário, sendo o 1 o mês mais antigo e o 5 o mais recente. Figura 25Caixa de informação do gráfico Responses per Role 5.2.2 Analysis by Survey A secção apresentada na figura 26, demonstra uma comparação entre as respostas de todos os questionários, sendo que este estão identificados pelo mês e ano em que foi realizado. As métricas analisadas são as mesmas que na primeira secção devido aos dados que existem neste dataset , mas com a diferença de especificar os valores de todos os questionários. O gráfico Methodology type preferred necessitou de uma alteração para gráfico de barras comparativamente ao da secção anterior, uma vez 40 que estão a ser analisadas 3 variáveis diferentes, o tipo de resposta, o valor percentual e a data do questionário. Após analisar esta secção é possível perceber que a recomendação e satisfação de Agile é bastante positiva com pouca variação de opinião ao longo dos anos. Contrariamente, a opinião sobre Agile remote obteve um crescimento significativo ao longo dos anos. Esta resposta demonstra a clara inexperiência das equipas em 2020 em relação ao trabalho remoto devido ao início da pandemia, mas o aumento dos valores comprova que existiu boa adaptação e melhoria continua. No gráfico Agile Opinion – Different dimensions verica-se que apesar da alta satisfação os pontos mais negativos ao longos dos anos é a qualidade e velocidade de entrega. Figura 26Dashboard ES, Secção Employee Satisfaction 5.2.3 Analysis by Role A secção Analysis by Role é a última secção deste dashboard , ver figura 27, apresenta uma análise às questões respondidas por tipo de função de elementos na equipa, sendo estas análises as mesmas realizadas nas secções anteriores. As equipas são compostas por oito tipo de papéis diferentes, sendo o mais fora do comum o “Convidado”. Este é um elemento de equipas Waterfall que é inserido em equipas Agile apenas para realizar certas tarefas em determinados sprints e épicos. O facto de este não acompanhar todo o projeto e entrar e sair num curto espaço de tempo, sem muitas vezes perceber o conceito do projeto e da metodologia Agile justifica a avaliação tao baixa comparativamente aos restantes. 41 A análise individual das funções que desenvolvem os softwares como Developer , Tester e convidado são os únicos que têm respostas pela preferência única de Waterfall. Os restantes papéis são funções mais especificas de equipas Agile na qual é necessária formação para desempenhar esse papel, isto originou um nulo de resposta da preferência única da metodologia Waterfall. Por último, na opinião sobre diferentes situações de projetos Agile, existe um destacamento da insatisfação do Scrum Master, isto acontece por existir um maior conhecimento da metodologia Agile por parte destes elementos e as suas expectativas serem elevadas comparativamente aos restantes elementos. Figura 27Dashboard PMO ES, Seção Analysis by Role 5.3 Impacto na Equipa PMO Para finalizar este projeto foi realizada uma reunião com a equipa de PMO para apresentar os dashboards e explicar todas as funcionalidades do mesmo. O feedback por parte da equipa durante todo o processo foi positivo, uma vez que não existia nenhuma forma de a equipa de PMO controlar os projetos, dessa forma os dashboards tiveram um impacto muito positivo na equipa. A partir deste momento eles podem acompanhar a evolução dos KPI’s que foram delineados anteriormente, sendo que já confirmaram o cumprimento do KPI referente à obtenção de uma satisfação da metodologia Agile acima dos 75%. 48 Figura 30Objects 49 Figura 31Data a.2 Jobs e Tabelas a.2.1 Ratio Deliveries Figura 32DIV_PLANVIEW_PMO_DELIVERIES_RT_20_10_EXT_ONGOING_PROJECTS 50 Figura 33DIV_PLANVIEW_PMO_DELIVERIES_RT_20_20_EXT_COMPLETED_PROJECTS Figura 34DIV_PLANVIEW_PMO_DELIVERIES_RT_20_30_EXTRACT_DELIVERIES Figura 35DIV_PLANVIEW_PMO_DELIVERIES_RT_30_10_APPEND 51 Figura 36DIV_PLANVIEW_PMO_DELIVERIES_RT_30_20_TRANSFORM_FLAG_LAST_ROW Figura 37PUBL_MONTHLY_DTM_PMO_PLANVIEW_DATE_ANALYSIS Figura 38PUBL_MONTHLY_DTM_PMO_PLANVIEW_DELIVERY_RATIO_IND 52 a.2.2 Deliveries Frequency Figura 39DIV_PLANVIEW_PMO_DELIVERIES_FREQ_20_10_EXT_PROJECT_CATEGORY Figura 40DIV_PLANVIEW_PMO_DELIVERIES_FREQ_20_20_EXT_DELIVERIES(1) Figura 41DIV_PLANVIEW_PMO_DELIVERIES_FREQ_20_20_EXT_DELIVERIES(2) 53 Figura 42DIV_PLANVIEW_PMO_DELIVERIES_FREQ_30_10_TRANSFORM Figura 43PUBL_MONTHLY_DTM_PMO_PLANVIEW_DELIVERIES_FREQUENCY_IND a.2.3 Timeline Deliveries Figura 44DIV_PLANVIEW_PMO_DELIVERIES_TML_20_10_EXTRACT_PROJECTS 54 Figura 45DIV_PLANVIEW_PMO_DELIVERIES_TML_20_20_EXT_DELIVERY_TYPES Figura 46DIV_PLANVIEW_PMO_DELIVERIES_TML_30_10_TRANSFORM Figura 47PUBL_MONTHLY_DTM_PMO_PLANVIEW_DELIVERIES_TIMELINE a.2.4 Employee Satisfaction 55 Figura 48DTM_AGILE_METRICS_EMPLOYEE_SAT_20_10_EXT_LAST_POSITION Figura 49DTM_AGILE_METRICS_EMPLOYEE_SAT_30_10_TRF_CONTEXT_INFO Figura 50DTM_AGILE_METRICS_EMPLOYEE_SAT_30_20_TRF_TRANSPOSE Figura 51DTM_AGILE_METRICS_EMPLOYEE_SAT_30_30_TRF_JOIN_CONTEXT 56 Figura 52PUBL_MONTHLY_DTM_PMO_SM_EMPLOYEE_SATISFACTION a.3 Dashboards a.3.1 PMO Frequency Delivery Figura 53Filtro Vertical Line of Business Figura 54Filtro Business Cluster 57 Figura 55Filtro Approval Comittee / Managment Team Figura 56Filtro Methodology Type