Utilização da Ferramenta Redmine para Auxiliar na Obtenção da Certificação MPS-BR Nível F

Boa tarde caros Lemafianos,

Gostaria de vir aqui hoje dividir uma experiência interessante com vocês.

Como muitos de vocês já sabem, em 2016 a GT4W, empresa parceira do LEMAF, obteve a certificação MPS-BR nível F. Essa certificação foi fruto de bastante empenho dos responsáveis pela GT4W e os demais envolvidos no processo. Cerca de dois meses atrás (e quase um ano após a certificação), escrevi um artigo científico relatando a experiência da ferramenta que utilizamos no processo (o Redmine) e submeti ao XVI Simpósio Brasileiro de Qualidade de Software como um relato de experiência. Para minha surpresa o artigo foi aceito e publicado! Apresentei o trabalho no evento e o feedback foi bastante positivo, principalmente pela falta de artigos com experiências práticas na literatura. Com isso, compartilho com vocês um resumo do artigo, detalhando como definimos e utilizamos a ferramenta para auxiliar na implementação de alguns dos processos necessários e como foi o desempenho da ferramenta na prática.

Modelos de maturidade e o MPS-BR

Primeiramente vamos falar um pouco de modelos de maturidade. Os modelos de maturidade oferecem informações estratégicas para avaliar o desempenho dos processos organizacionais como uma forma de auxiliar a gestão dos projetos na empresa. Os modelos de maturidade em gestão de projetos consistem em um arquétipo de crescimento que estabelece estágios pré-definidos, permitindo autoavaliações e aperfeiçoamentos [Prado, 2008]. São exemplos de modelos de maturidade Capability Maturity Model Integration (CMMI), Project Management Maturity Model (PMMM), Organizational Project Management Maturity Model (OPM3) e o nosso tão falado Melhoria de Processo de Software Brasileiro (MPS-BR), sendo este um programa criado pela SOFTEX com o apoio do Ministério da Ciência e Tecnologia, Inovações e Comunicações (MCTIC) cujo objetivo é melhorar a capacidade de desenvolvimento de software, serviços e práticas de gestão na indústria de Tecnologia da Informação (SOFTEX, 2016). Mais informações sobre o MPS-BR neste link ou nas referências ao fim deste post.

Para acompanhar o andamento do processo na GT4W, uma instituição implementadora foi contratada, e esta constatou que a empresa já possuía certa organização e padronização em seus processos, sendo aconselhada a buscar o Nível F, implantando os processos referentes aos níveis G e F do MPS-BR. O nível G (Parcialmente Gerenciado) possui dois processos: i) Gerência de Requisitos (GRE); e ii) Gerência de Projetos (GPR). O nível F (Gerenciado) possui cinco processos: i) Aquisição (AQU); ii) Gerência da Configuração (GCO); iii) Garantia da Qualidade (GQA); iv) Gerência de Portfolio de Projetos (GPP); e v) Medição (MED). O processo de Aquisição não foi considerado no escopo da avaliação, pois a GT4W se enquadra como uma fábrica de software.

Ok, e onde entra a ferramenta?

Com o advento da necessidade de implantar o MPS-BR na empresa e a definição do nível F como objetivo primário, foi recomendada pelo consultor responsável da instituição implementadora, a utilização de uma ferramenta para ajudar a controlar os projetos para atendimento a algumas exigências da implantação, por exemplo, a rastreabilidade bidirecional entre requisitos e atividades. O controle era integralmente realizado utilizando planilhas personalizadas para cada equipe sem alguma padronização.

Diante dessa necessidade, a comissão formada pelos gestores responsáveis e a instituição implementadora estabeleceram, baseados na experiência prévia da instituição implementadora em certificações anteriores, um conjunto de nove critérios categorizados de acordo com a necessidade para a implantação da certificação que a ferramenta deveria atender, sendo eles:

  • Integração com o Git: a empresa utiliza o Git para controle de versões e de releases dos sistemas desenvolvidos, sendo fundamental a integração com os repositórios de forma a ser possível acessar o código fonte gerado no projeto;
  • Open source: a ferramenta deve possuir código aberto para futuras customizações pela equipe de desenvolvimento;
  • Rastreabilidade bidirecional de requisitos: permitir identificar cada item desenvolvido presente no Documento de Visão do projeto (mais alto nível de abstração), as histórias de usuários do Product Backlog associadas ao item de visão, as tarefas associadas às histórias de usuários e os commits no repositório e vice-versa, possibilitando navegar entre os diversos níveis de atividades, fornecendo ampla visibilidade do projeto;
  • Possibilidade de trabalhar com Scrum: Scrum é utilizado pelas equipes de desenvolvimento;
  • Histórico de atualização de tarefas: manter um histórico que permitisse visualizar quem alterou o estado da atividade e quando foi realizada a alteração;
  • Controle da equipe: possibilidade de configurar a equipe, gerenciar membros de projetos e permissões de acesso, de forma a limitar o acesso a determinadas áreas do sistema para usuários;
  • Autenticação de usuários: login utilizando uma credencial para acesso ao sistema;
  • Gratuita: Por ser uma microempresa, optou-se por não investir em uma ferramenta proprietária;
  • Self-hosted: a ferramenta deveria ser implantada nos servidores locais da empresa, não dependendo de serviços em nuvem para seu funcionamento. Essa não dependência é explícita em alguns contratos com clientes.

Esses critérios foram categorizados de acordo com seu grau de relevância para a certificação (Tabela 1), sendo: i) 1: pouco relevante; ii) 2: relevante; e iii) 3: muito relevante. O grau de relevância “pouco relevante” é considerado pouco importante, não inviabilizando a utilização da ferramenta, caso não seja atendido. O grau de relevância “relevante” é de relevância média, considerado importante, mas não chega a inviabilizar o uso da ferramenta, caso não seja atendido. O grau de relevância “muito relevante” é considerado muito importante, que inviabiliza o uso da ferramenta, caso não seja atendido. Assim, os critérios Integração com o Git, Rastreabilidade bidirecional de requisitos, Possibilidade de trabalhar com Scrum, Gratuita e Self-hosted são considerados muito relevantes. Por outro lado, o critério Open source e Histórico de atualização de tarefas são considerados pouco relevantes. Os dois critérios restantes, Controle da equipe e Autenticação de usuários, são considerados relevantes.

Uma vez definida a lista de critérios, foi feita uma pesquisa para identificar possíveis ferramentas computacionais candidatas a serem utilizadas para apoiar no processo de certificação baseada nessa lista. As ferramentas encontradas foram:

  • JIRA: descartada pelo fato de não atender o critério 8 (Gratuita) e inclusive possui alto custo para implantação e customização;
  • Open Project: descartada pelos envolvidos não possuírem contato prévio com ela, ocasionando na necessidade de esforço (tempo) para estudo do seu comportamento prático. Dessa forma, a sua utilização tornou-se inviável por conta do curto tempo entre a implantação da ferramenta nos projetos e a avaliação final da certificação;
  • Trello: descartada pelo fato da Rastreabilidade bidirecional de requisitos (critério 3) não se mostrar ineficiente, apesar dos plug-ins existentes para a ferramenta. Além disso, Trello não é Self-hosted (critério 9);
  • Redmine: Com as pesquisas realizadas na Internet e em fóruns de discussão, essa ferramenta apresentou bons resultados baseados nos critérios e nos graus de relevância definidos. O principal ponto que contribuiu para a sua escolha foi a indicação da instituição implementadora que acompanhava a implantação dos processos, pois o consultor responsável havia tido contato com a ferramenta em processos de certificação anteriores, atingindo seu o objetivo.
Utilização do Redmine

Para a certificação MPS-BR Nível F, a empresa precisava apresentar quatro projetos candidatos à avaliação, dois finalizados e dois em andamento. Os projetos seriam avaliados quanto ao escopo da avaliação do Nível F: i) Gerência de Projetos; ii) Gerência de Requisitos; iii) Gerência da Configuração; iv) Garantia da Qualidade; v) Gerência de Portfolio de Projetos; e vi) Medição. A Redmine foi selecionada para auxiliar na Gerência de Projetos e na Gerência de Requisitos.

Uma vez definidas as equipes e os projetos que articipariam da experiência com a Redmine, foram realizadas reuniões com a instituição implementadora para definir como seria a estrutura da Redmine. Nessas reuniões, foram discutidos diversos aspectos de como a ferramenta seria utilizada para atender aos requisitos do MPS-BR. Dentre os vários pontos, os mais importantes foram a estruturação dos requisitos de projeto, a rastreabilidade bidirecional de requisitos e o acesso ao repositório Git. Para adaptar-se ao contexto da organização, foi necessário inserir uma extensão na Redmine que permitia trabalhar com metodologias ágeis. Essa extensão permitia a utilização do Kanban e as demais características do Scrum, como a criação de Product Backlog e Sprints. Além disso, o Redmine precisou ser configurado para se adaptar ao contexto da organização, sendo configurada conforme a figura a seguir.

As equipes envolvidas foram treinadas pela equipe de qualidade e pelo Gerente de Projetos antes de iniciar de fato a utilização da Redmine. O treinamento consistiu em uma apresentação da ferramenta juntamente com sua política de uso e os padrões de nomenclaturas e de projeto. Ainda nesse treinamento, os desenvolvedores foram orientados a identificar a atividade sendo trabalhada utilizando comentários nos commits realizados ao finalizar determinada atividade. Para fins de identificação de tarefas no Git, a Redmine exige informação do caractere “#” seguido do código identificador (id) da atividade trabalhada no comentário do commit, estabelecendo um vínculo entre a tarefa e o commit no repositório. Dessa forma, o critério Rastreabilidade bidirecional de requisitos é atendido.

Após o treinamento, as equipes foram capazes de iniciar a utilização da ferramenta Redmine em seus projetos. Foi aconselhado manter o uso das planilhas em paralelo a essa ferramenta no primeiro momento, de forma que o impacto nas equipes fosse mitigado, visto que as planilhas eram utilizadas desde os primeiros projetos da empresa, sendo a primeira vez que uma ferramenta estava sendo implantada para controle dos projetos. O fluxo realizado para a implantação da Redmine para ser utilizada pelas equipes é apresentado na figura a seguir.

Ao longo do processo de certificação, cada projeto teve a duração média de três iterações. Alguns projetos foram finalizados após a instituição avaliadora auditar os projetos, sendo considerados (auditados) como projetos em andamento.

Resultados

Durante a utilização da Redmine pelas equipes envolvidas no processo de implantação da qualidade, foi possível ter uma visão mais ampla dos projetos em execução, algo que se tornava ineficiente quando as planilhas eram a principal forma de controle utilizada. O desempenho dessa ferramenta foi medido com base nos critérios descritos anteriormente, os quais foram analisados quanto à sua efetividade no processo, atendendo, não atendendo ou atendendo parcialmente o critério em questão.

O critério 1 (Integração com o Git) foi considerado de alto grau de relevância para a obtenção da certificação, o qual a Redmine atendeu parcialmente, de forma a conseguir ser efetiva para a instituição avaliadora quanto ao acesso ao repositório, mas, do ponto de vista de infraestrutura, mostrou-se tecnicamente inviável. Isso ocorreu, pois a Redmine exige que os repositórios Git sejam clonados e inseridos em seu diretório para serem acessados, sendo necessário ter um espaço cada vez maior no storage, à medida que novos projetos são criados. Além disso, foi necessário criar uma rotina de atualização para realizar a cópia do repositório diariamente na Redmine, dependendo constantemente da intervenção da equipe de infraestrutura para dar suporte à ferramenta. Isso tornava um procedimento de alto custo para a empresa, que conta apenas com dois analistas de infraestrutura e uma alta quantidade de projetos, além do risco de informações sensíveis se perderem por causa do espaço limitado nos storages disponíveis. O modelo ideal seria a ferramenta ter uma referência para os repositórios dos projetos, de forma a não ser necessário criar cópias adicionais ou rotinas para substituir os repositórios por versões mais atualizadas.

O critério 2 (Open source), de baixa relevância, está relacionado à licença da ferramenta, que preferencialmente deveria ser de código aberto, para que melhorias futuras pudessem ser propostas pelas equipes de desenvolvimento e pela equipe de infraestrutura. A Redmine atendeu esse critério por ser de código aberto, escrita utilizando o framework Ruby on Rails publicada sob a licença GPL3. É importante frisar que, no período da certificação, não havia desenvolvedores na empresa com conhecimento pleno em Ruby on Rails, mas poderia ser cogitada a contratação de alguém com o perfil para melhorar a ferramenta.

O critério 3 (Rastreabilidade bidirecional de requisitos) é um dos critérios de maior grau de relevância para o processo de certificação, sendo considerado crítico pela instituição implementadora e profundamente analisado durante a auditoria da instituição avaliadora. Com esse critério atendido, para o MPS-BR Nível F, pode-se identificar cada item desenvolvido no projeto, desde seu nível mais abstrato até a atividade concluída pelo desenvolvedor na Sprint e vice-versa. Em linhas gerais, acessando um item de visão, deveria ser possível acessar cada história de usuário associada àquele item. Acessando uma história de usuário, deveria ser possível acessar cada tarefa associada àquela história de usuário e, em cada tarefa, deveria ser possível acessar o commit realizado pelo desenvolvedor relacionado àquela tarefa e vice-versa, conforme é possível ver na figura a seguir. Esse critério foi atendido parcialmente, pois a Redmine não faz a vinculação do código gerado pelo commit dos desenvolvedores armazenado nos repositórios do projeto no Gitlab da empresa e o projeto da Redmine. Para atender esse critério, o Product Owner adicionava aos comentários de cada atividade os comentários dos commits realizados pelos desenvolvedores e cabia ao gerente de projetos gerar relatórios periódicos baseados nesses comentários dos commits. Isso permitia criar um mapeamento que associava a atividade realizada a seu respectivo commit por meio do código identificador da atividade da Redmine no comentário realizado, conforme orientado no treinamento realizado.

O Scrum é adotado pela GT4W no desenvolvimento de software, então o critério 4 (Possibilidade de trabalhar com Scrum) foi elencado pelos envolvidos e atribuído alto grau de relevância. Assim, a Redmine atendeu esse critério, pois apesar de não possuir o framework Scrum como padrão, existem extensões criadas pela comunidade que permitem a utilização de Scrum. No processo para obtenção da certificação, foi utilizado o plug-in Redmine Plugin Scrum que permitiu adaptar a Redmine ao Scrum. Mesmo com a utilização desse plug-in, foi necessário configurar a ferramenta por causa da customização do Scrum empregado pela empresa, sendo necessário criar alguns papéis adicionais. Um feedback negativo das equipes quanto a esse critério foi a impossibilidade de utilizar estimativa por pontos de complexidade nas histórias de usuários, sendo a Redmine restrita à estimativa por horas de desenvolvimento.

O critério 5 (Histórico de atualização de tarefas) possui baixo grau de relevância, não inviabilizando a utilização da ferramenta. Esse critério foi atendido pela Redmine pois mantém a informação de quem moveu a atividade no kanban, bem como a data e o horário que seu estado foi alterado. Isso permitiu saber exatamente quais membros da equipe trabalharam em quais atividades.

O critério 6 (Controle da equipe) também foi levantado pelos envolvidos com médio grau de relevância. Esse critério consiste no controle da equipe do projeto, como o cadastro dos usuários e a atribuição de perfis e de permissões. A Redmine atendeu, pois possui configurações de perfis (que apresentavam com os perfis padrão de Scrum diante da instalação do plug-in) e de permissões de acesso que podem limitar ou conceder o acesso a determinada ação mediante à permissão relacionada. No processo de obtenção
da certificação foi importante o cadastro de novos perfis para membros da equipe, tal como o Líder Técnico e o Tester, bem como as permissões relacionadas.

O critério 7 (Autenticação de usuários), de média relevância, foi atendido pela Redmine por fornecer login e senha para cada usuário que utilizar a ferramenta. Dessa forma, a Redmine “exigia” do membro da equipe ou gerente de projetos sua respectiva credencial, formada pelo e-mail corporativo e uma senha de acesso, criada no momento do cadastro.

O critério 8 (Gratuita) foi atendido por a Redmine ser gratuita. O fato de ser gratuita foi levantado por ser uma ferramenta piloto na organização, podendo adequar ou não ao processo. Assim, para evitar custos com ferramentas que poderiam ser descartadas, optou-se pela utilização de ferramentas gratuitas.

O critério 9 (Self-hosted) foi considerado de alto grau de relevância, sendo necessária a hospedagem internamente na empresa. Esse critério exige que a ferramenta esteja alocada nos servidores internos da empresa, sem a necessidade da utilização de nuvem para acessar o conteúdo dos projetos. Esse critério foi definido por questões de
segurança e disponibilidade, uma vez que o acesso à Internet não é 100% estável no ambiente organizacional. A Redmine foi hospedada em um servidor interno dedicado na rede interna da organização, atendendo esse critério.

Um resumo dos critérios elaborados e se eles foram atendidos, não atendidos ou atendidos parcialmente pela ferramenta Redmine é apresentado na tabela 2.

Como descrito neste trabalho, o Redmine não atendeu a todos os critérios, mas para os pontos que não atendeu com eficácia, foram criados mecanismos que permitiram sua utilização durante o processo de certificação, atingindo desempenho satisfatório no processo de obtenção da certificação.

Considerações finais

O artigo em questão explorou o desempenho do Redmne durante o processo da implantação do processos do nível F do MPS-BR.

No que concerne à utilização do Scrum, a ferramenta mostrou-se eficiente durante a implantação, mas em seguida, foi identificada a necessidade de trabalhar com múltiplos projetos em uma mesma Sprint na equipe, sendo uma característica que ainda não existe na Redmine. Isso inviabilizou a empresa a manter a utilização da ferramenta como fonte única de controle dos projetos. Outro ponto que contribuiu para a decisão de descontinuar a utilização de Redmine na empresa foi a integração com o Git, uma vez que a integração exige fazer uma cópia dos repositórios no diretório da Redmine para serem referenciados no projeto. Assim, há a necessidade de cada vez mais ter um espaço maior no storage à medida que novos projetos são criados, tornando inviável do ponto de vista de infraestrutura ao longo do tempo, uma vez que os repositórios são alocados localmente.

De modo geral, o processo de implantação do MPS-BR Nível F na GT4W foi um êxito e a Redmine permitiu a automatização de alguns processos da gestão dos projetos, que dependia integralmente de planilhas de controle, promovendo, com a utilização da Redmine, mais agilidade, flexibilidade, disponibilidade e a rastreabilidade necessárias do foi realizado nos projetos. Ainda existem algumas limitações relacionadas à ferramenta a serem tratadas, mas apesar de não atender 100% de todos os critérios, a Redmine não deve ser descartada como uma opção viável para controle dos projetos, sobretudo em processos de certificação MPS-BR.

Este post trouxe um resumo do artigo publicado, e sua versão completa está disponível neste link. Os demais artigos do evento estão nos anais do SBQS 2017, disponível para download neste link.

Como vocês sabem, atualmente estamos utilizando o taiga no LEMAF para controle dos projetos. Espero em um futuro próximo escrever um artigo medindo o seu desempenho comparando-o ao Redmine nos aspectos observados.

Qualquer consideração estou à disposição.

Grande abraço!

Referências

Catunda, E.; Nascimento, C.; Cerdeiral, C.; Santos, G.; Nunes, E.; Schots, N. C. L.;

Schots, M.; Rocha, A. R. "Implementação do Nível F do MR-MPS com Práticas Ágeis do Scrum em uma Fábrica de Software." X Simpósio Brasileiro de Qualidade de Software (SBQS’11), Curitiba–Brasil (2011).

França, B. B. N. de; Sales, E. de O.; Reis, C. A. L.; Reis, R. Q. Utilização do Ambiente WebAPSEE na implantação do nível G do MPS. BR no CTIC-UFPA. 2009. VIII Simpósio Brasileiro de Qualidade de Software. pp 310- 317

Ibbs, C. W.; Kwak, Y. H. (2002). “Assessing Project Management Maturity”. Project Management Journal 31.1. pp 32-43.

Koscianski, A.; Soares, M. dos S. Qualidade de Software. 1ª edição. Editora Novatec. 2007.

Oliveira, S. R. B., et al. "SPIDER-Um Suite de Ferramentas de Software Livre de Apoio à Implementação do modelo MPS. BR." Anais do VIII Encontro Anual de Computação–ENACOMP (2010).

Prado, Darci. "Maturidade em gerenciamento de projetos." Nova Lima: INDG Tecnologia e Serviços Ltda 7 (2008).

Schwaber, K.; Sutherland, J. The Scrum Guide. Disponível em: <http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide- US.pdf#zoom=100> Acesso em 19 abr de 2016

SOFTEX, 2016. Disponível em: http://www.softex.br/mpsbr/#>. Acesso em: 18 abr 2016.

SOFTEX. Guia Geral do Software, 2016. Disponível em: <http://www.softex.br/wpcontent/uploads/2016/04/MPS.BR_Guia_Geral_Software_2016-com- ISBN.pdf?x15632>. Acesso em: 18 abr 2016.