Gestão de Projetos com Metodologias Ágeis no RedMine

O Redmine é um sistema completo de código fonte aberto, escrito na plataforma Ruby on Rails para gerenciamento de projetos a partir de recursos como: wiki, fóruns, gestão de arquivos, gráficos, acompanhamento de solicitações, equipes e inúmeros outros recursos.

O que não se pode negar é que atualmente muitos desenvolvedores/gerentes de projeto estão optando por utilizar alguma metodologia ágil para gerenciamento e desenvolvimento de sistemas, claro que, respeitando as limitações e indicações de aplicação de tais metodologias.

Ao buscar por algumas ferramentas de gerenciamento de projetos apoiadas em metodologias ágeis, mais especificamente Scrum, para um projeto de um pequeno sistema de leitura e cálculos de um equipamento de medição de ruídos, foi possível encontrar certa quantidade de ferramentas para tal finalidade, tais como Scrumwise, Targetprocess, Agile Agenda e Agile Zen (vide seção Links). Contudo, ainda que possuidoras de características únicas que lhe conferem grande valor, elas não eram suficientes para a situação em questão, pois além de serem pagas, elas também não se adaptam e não permitem hierarquização das funções/atividades, além de não oferecerem gráficos em diversos formatos e nem o aparato para gestão de projetos que vimos no artigo Gestão de Projetos: Primeiros passos com o RedMine. As ferramentas citadas são específicas para o controle e apresentação dos processos no modelo Kanban, mas não para gestão completa de um projeto.

Já o Redmine possui enorme capacidade de gerenciamento: seus recursos e sua capacidade de adaptação mostraram-se fatores determinantes para a escolha desta como ferramenta a ser adaptada para o gerenciamento de projetos utilizando a metodologia ágil Scrum. Por isso, veremos a seguir como adaptar essa ferramenta.

Adaptando o RedMine - Requisitos

Caso ainda não tenha o Redmine instalado, acompanhe a seguir os passos para a instalação:

1. Certifique-se que tenha o ruby instalado na sua máquina. Para isso, use o seguinte código:
   

   ruby --version

   
   A versão instalada deve ser a partir da 1.9.3. Caso não tenha instalado, acompanhe no artigo de Instalação os passos.
   
2. Vá até a página de instalação (seção Links) e escolha a versão apropriada para o seu sistema operacional.
   
3. Adquira o Subversion (seção Links) para prosseguir com a instalação;
4. Faça o checkout do projeto direto do site usando os seguintes códigos:
   

   
   # cd /opt
   # svn checkout http://redmine.rubyforge.org/svn/trunkredmine

Antes de iniciar a adaptação da ferramenta alguns plug-ins são fundamentais. A lista a seguir pode ser encontrada para download na seção Links.

1. Advanced Roadmap – serve para exibir o roteiro, como um status do projeto, versões, estimativas de tempo, etc.
2. Redmine Charts – serve para exibir gráficos em geral;
3. Redmine Graphs –serve para exibir gráficos adicionais como versão conclusão (que mostra questões totais e fechadas ao longo do tempo), questões por data, etc.;
4. Issue Due Date – serve para trabalhar com datas de versões e entregas finais;
5. Issue History Tab – serve para trabalhar com o histórico, separando por abas para melhorar a comunicação;
6. Partking Lot Chart – serve para trabalhar com o Kaban;
7. Redmine Task Board – serve para trabalhar com taskboardsKaban.

Para instala-los basta copiar a pasta de plug-ins para#{RAILS_ROOT}/plugins e reinicie o Redmine. Você deve ser capaz de ver a lista de pluginsemAdministração-> Plugins.

Não se pode deixar de informar que dentre seus diversos plug-ins, o Redmine oferece também um plug-in para o Scrum, mas no decorrer deste artigo veremos que os resultados são completamente diferentes, já que ele não se adapta a todas as necessidades do projeto.

Uma das grandes vantagens apresentadas pela ferramenta é seu poder de personalização, permitindo assim que programadores a adaptem para atender às suas necessidades. Logo, para que a ferramenta possa apresentar características que se ajustem ao estilo de execução de um projeto baseado na metodologia Scrum por completo, uma série de caraterísticas devem ser alteradas e é o que veremos nos próximos tópicos.

Adaptando o Grupo de Membros

O primeiro passo é personalizar o papel dos usuários do sistema, dessa forma, podemos aproximar a representação de cada um ao que é realmente aplicado em um típico processo ágil.

Para iniciarmos essa parte pedimos que o leitor acompanhe antes a criação de membros apresentada no artigo com os Primeiros passos com o RedMine.

Com a ferramenta aberta, na aba membros, crie alguns grupos, conforme mostra a Figura 1. Nela vemos a adaptação que pode ser feita sem muitas dificuldades, incluindo o nome dos grupos que estão presentes na metodologia Scrum, como Developer, Product Owner, Scrum Master e tester.

Figura 1. Redefinição dos Papeis dos Membros do Projeto

Adaptando as Tarefas

Outra adaptação importante a ser realizada refere-se às tarefas. Em se tratando de desenvolvimento ágil com Scrum, algumas tarefas são bem particulares. Logo, para que o projeto possa se manter conciso é preciso que todos os envolvidos saibam exatamente o que está acontecendo e quando. Não podemos conduzir um projeto pedindo para que estes entendam que uma nomenclatura x significa y. Por isso precisamos alterar e incluir novas nomenclaturas para as tarefas a serem realizadas em um projeto.

Na aba Trackers (tarefas), clique no botão “New tracker” e criar as tarefas a seguir:

1. Bug: Diz respeito a erros ou defeitos;
2. Feature: Trata-se de uma característica da aplicação;
3. Clarification: Trata dos esclarecimentos e dúvidas que a equipe pode ter. É importante manter o alinhamento no pensamento de todos;
4. Task: Uma tarefa propriamente dita, algo que precisa ser feito;
5. Tech Need: Uma necessidade tecnológica ou uma característica técnica que precisa ser implementada para que o projeto transcorra de forma clara, segura e transparente.

O resultado pode ser observado na Figura 2.

Figura 2. Adaptando as Tarefas para o Scrum

Adaptando o Estado das Atividades

Assim como ocorre nas tarefas e com os membros do projeto, o Scrum requer que outras características básicas do conteúdo de um projeto padrão sejam adaptadas. Neste tópico realizaremos algumas adaptações nos possíveis estados das atividades relacionadas ao projeto. Assim, será possível contemplar todos os possíveis estágios de uma atividade baseada nesta metodologia. Teremos então um total de oito possíveis estados para as atividades:

1. New: relacionado a atividade nova ou estado inicial;
2. Open: relacionado a uma atividade que acabou de ser aberta para realização;
3. Re-Open: relacionado a uma atividade reaberta, geralmente pela necessidade de alguma adaptação ou correção da mesma. Isto pode ser importante para indicar retrabalhos;
4. In Progress: relacionado as atividades estão sendo em progresso, ou seja, realizadas em um determinado momento, sem que seja necessário recorrer a detalhes da mesma;
5. Closed: o gestor ou responsável verifica a atividade e se entender que esta foi concluída com sucesso, marca-a como fechada ou simplesmente encerrada;
6. Rejected: referente as atividades que apresentaram algum problema, inconsistência, defeitos ou semelhante. Não se deve pensar em corrigir a mesma, já que esta atividade deve ser rejeitada e posteriormente uma nova atividade será criada;
7. Wont Fix: são questões que precisam ser resolvidas, ou seja, problemas que não tiveram ainda uma solução ou cuja solução realizada não foi satisfatória;
8. Blocked: são as atividades bloqueadas, ou seja, até que mude, esta atividade não deve ser realizada.

Assim, teremos ao final desta adaptação um quadro semelhante ao apresentado na Figura 3.

Figura 3. Adaptação dos Estados das Atividades

Quando aberta, toda atividade terá, por padrão, seu estado marcado como new (novo) automaticamente: isto pode ser observado no campo Default Value (valor padrão). O mesmo raciocínio é utilizado quando se termina/fecha uma atividade, onde o valor padrão para toda atividade terminada é closed (fechada). Estas configurações reduzem a possibilidade de erro no gerenciamento do projeto.

Fluxo de Trabalho - Atividades

Não se refere especificamente a uma adaptação a ser realizada na ferramenta Redmine, mas sim no modelo de se trabalhar. Para garantir que as questões pertinentes ao desenvolvimento e gerenciamento de um projeto, com base em uma metodologia ágil estejam ocorrendo corretamente é necessária uma adaptação e bom entendimento do fluxo de trabalho. A Figura 4 apresenta uma proposta de como isso deve ocorrer.

Figura 4. Fluxo de Trabalho Sugerido pelo Scrum

Seguindo o proposto, as chances de sucesso na gestão de um projeto baseado nesta metodologia aumentam.

Permissões

As permissões devem ser aplicadas de acordo com o entendimento do gestor do projeto, ou com a estrutura e definições da organização que responde pelo projeto. Logo, neste tópico não serão realizadas grandes discussões.

Por exemplo: desenvolvedores não precisam ter acesso a toda estrutura do projeto: é de interesse da equipe de desenvolvimento somente as atividades pertinentes ao desenvolvimento. Algumas regras referentes ao negócio, bem como andamento das atividades associadas a outras equipes não precisam (nem devem) ser acessíveis aos desenvolvedores.

A priori, o único que deve ter acesso a todo conteúdo (operacional) do projeto é seu gestor, reduzindo de uma visão macro para uma visão micro do mesmo na medida em que se desce na cadeia hierárquica dos membros. Entretanto, questões como, metas, objetivos, expectativas e demais questões relacionadas ao contexto geral do projeto podem e devem ser compartilhadas, permitindo assim que toda a equipe caminhe num mesmo sentido.

Adaptação das Prioridades das Atividades

No tocante aos defeitos, o grau de suas prioridades ficará classificado da seguinte forma:

1. Low: Não necessitam de tanta atenção no momento;
2. Normal: Requerem atenção, mas moderada;
3. High: Requerem muita atenção;
4. Urgent: Atenção e urgência em sua resolução.

Referente às características do projeto, ou seja, quando a atividade em questão estiver relacionada a alguma característica do projeto em desenvolvimento, as prioridades ficam assim descritas:

1. Immediate: são características e funcionalidades que devem ser providas imediatamente;
2. Must have: são características e funcionalidades importantes e é muito bom que sejam realizadas;
3. Should have: tratam de questões relacionadas ao projeto que devem ser realizadas;
4. Nice to have: tratam de características que na sua falta não comprometem o projeto, mas que, no entanto, é bom que sejam realizadas/implementadas.

A Figura 5 mostra o quadro resultante destas adaptações.

Figura 5. Adaptação do Grau de Prioridade das Atividades

Campos Adaptados

Entendendo também que é muito importante que sejam registradas as datas de início e término de uma versão do projeto, sugere-se a criação de campos personalizados para o controle de versões.

Por padrão, a data de início de uma versão é sempre a data em que o evento foi registrado, contudo, isso não expressa uma verdade absoluta, pois uma nova versão pode ter sido iniciada em qualquer momento e só foi registrada (por diversos motivos) naquele exato momento. Sugere-se então que, ao criar uma nova versão do projeto no RedMine, seja também alterado o campo Date (data de início), preenchendo-o com a data em que efetivamente a nova versão do projeto foi iniciada e não a data em que a mesma foi incluída no sistema, como pode ser observado na Figura 6.

Figura 6. Configurando o campo Date

Adaptando os Plugins

Alguns dos plug-ins sugeridos neste trabalho também deverão passar por um processo de adaptação, permitindo que os mesmos atendam com maior presteza os requisitos do Scrum.

Iniciaremos com adaptação dos plug-ins gráficos: propõe-se a personalização de um plug-in gráfico para a criação de um gráfico do tipo burndown, que serve para representar o progresso do trabalho.

Anteriormente foi sugerido a criação de um campo chamado Data de Início, bom, agora faremos uso deste campo para adaptar nosso gráfico. Para que o processo possa ser realizado corretamente siga os passos a seguir:

1. Entre no sistema como administrador e crie o campo indicado;
2. Selecione o projeto desejado e vá na opção modificar a versão, como mostra a Figura 7. Clique na versão e logo em seguida em editar:
   
   Figura 7. Alterando versão do projeto.
3. Defina a data de início da versão para a data desejada.

Além disso, precisamos alterar o arquivo charts_burndown2_controller.rb inserindo o código da Listagem 1. Lembre-se que o caminho desse arquivo é $REDMINE_ROOT/vendor/plugins/redmine_charts/app/controller/charts_burndown2_controller.rb

Listagem 1. Alteração no arquivo charts_burndown2_controller.rb

  1. # start_date = version.created_on.to_date
  2. c_value = CustomValue.find_by_sql(["SELECT value from custom_values WHERE customized_type = 'Version' AND customized_id = ? LIMIT 1", version.id])
  3. s_date = c_value.empty? ? nil : c_value.first.value
  4. s_date = (s_date.nil?  ||  s_date.empty?) ? nil : s_date.to_date
  5. start_date = s_date==nil ? version.created_on.to_date : s_date
   
  6. # daily_velocity = total_estimated.to_f/@range[:keys].size
  7. daily_velocity = total_estimated.to_f/(@range[:keys].size – 1

Lembre-se que as linhas com # tratam-se de comentários.

A linha 2 realiza uma pesquisa na base de dados procurando por valores padrões para a versão, ou seja, valores que foram inseridos pelo usuário ao criar a versão do projeto. Na linha 3 é realizada uma verificação com um operador ternário procurando por algum valor definido em c_value: se o objeto não estiver vazio, então seu valor será adicionado a variável s_date (de start date), caso contrário, esta variável será preenchida com nil.

A linha 4 realiza uma nova verificação: não estando a variável s_date vazia, então a data definida pelo usuário é inserida na variável, caso contrário, ela é marcada como nil. Na linha 5 novamente é utilizado um operador ternário para verificar o valor de s_date, que não sendo vazio, é inserido em start_date, caso contrário, insere a data padrão sugerida pelo Redmine. Por fim, na linha 7 define-se o valor da variável daily_velocity (velocidade diária) como sendo resultado da operação indicada a frente. Este é um valor padrão para cálculo desta estimativa.

O propósito de toda esta atividade é, primeiro inserir no gráfico a data de início da versão, substituindo assim a data padrão utilizada pela ferramenta. Em seguida alteramos a permissão para criar uma linha de estimativa de tempo e recursos, que acompanha a realidade do andamento do projeto.

Ao final destas alterações o gráfico esperado para demonstrar o ciclo de vida evolutivo das versões do produto deve apresentar-se semelhante ao da Figura 8.

Figura 8. Gráfico Burndown Adaptado

Em seguida vamos personalizar os plug-ins de roteiros, ou roadmaps, que são responsáveis por incrementar os detalhes de uma atividade ou até mesmo do projeto, apresentando o andamento geral do mesmo. Esta adaptação garantirá que tenhamos uma melhor visualização do andamento do projeto.

Para isto, altere o arquivo $REDMINE_ROOT/vendor/plugins/advanced_roadmap/app/views/versions/_info.html.erb e adicione as variáveis begin_bold/end_bold e as inicialize conforme demonstrado na Listagem 2.

Listagem 2. Alteração no arquivo _info.html.erb.

  if issue.status.name == 'Blocked'
    begin_bold = '<b>'
    end_bold   = '</b>'
    color      = 'red'
  end

Na linha 1 inserimos no código do arquivo informado uma verificação para que saibamos o estado desta atividade/versão. Caso o resultado seja verdadeiro, na linha 2 adicionamos a tag html <b> na variável begin_bold e na linha 3 a tag html </b> na variável end_bold. Estas variáveis serão utilizadas posteriormente. Na linha 4 finalizamos inserindo o valor red na variável color.

Agora basta, para cada tag begin_strike/end_strike, adicionar, logo após estas, as seguintes tags: BEGIN_BOLD/END_BOLD. O resultado esperado após a realização de tais alterações é semelhante ao apresentado na Figura 9.

Figura 9. Mapa de Atividades Adaptado.

Assim, as atividades que se encontram bloqueadas aparecerão em destaque para o gestor do projeto, facilitando sua identificação.

Adaptação da gestão de tarefas

Agora realizaremos a adaptação do módulo de gestão de tarefas para deixar este recurso baseado no modelo Kanban, permitindo assim uma visualização mais dinâmica do estado de cada tarefa.

A personalização indicada realizará as seguintes alterações neste módulo:

1. Adicionar coluna para tarefas bloqueadas;
2. Manter uma categorização desta página, permitindo abertura e fechamento de versões; e
3. Mostrar todas as questões com diferentes estados de forma correta no quadro de tarefas.

Para que isso seja possível, uma série de alterações são necessárias no código do Redmine e seus plug-ins. A seguir temos o passo a passo o que deve ser feito.

Passo 1: Arquivo show.html.erb

Edite o arquivo $REDMINE_ROOT/vendor/plugin/redmine_task_board/app/view/task_boards/ show.html.erbcom o código da Listagem 3 para redefinirmos as colunas desta página.

Listagem 3. Colunas

  <div id="task-columns">
   <%= render :partial => 'task_column', 
      :locals => {:title => 'To Do', :issues => @issues_to_do} %>
   <%= render :partial => 'task_column', 
      :locals => {:title => 'In Progress', :issues => @issues_in_progress} %>
   <%= render :partial => 'task_column', 
      :locals => {:title => 'Blocked', :issues => @issues_blocked} %>
   <%= render :partial => 'task_column', 
      :locals => {:title => 'Verify', :issues => @issues_to_verify} %>
   <%= render :partial => 'task_column', 
      :locals => {:title => 'Closed', :issues => @issues_closed} %>
  </div>

Na linha 1 temos a criação de uma div que armazenará as colunas que apresentarão as atividades em seus devidos estados. Já na linha 2 cria-se a coluna intitulada “To Do” (a fazer), onde são impressas todas as tarefas da fila de execução, ou seja, que estão para serem realizadas. Até a linha 6 mantem-se o mesmo, exceto pelo fato de estarmos alterando o título das colunas e os valores recuperados.

Passo 2: Arquivo _task_column.html.erb

Agora altere o arquivo $REDMINE_ROOT/vendor/plugin/redmine_task_board/app/view/task_boards/_task_column.html.erb para modificar as cores dos títulos das colunas, conforme mostra a Listagem 4.

Listagem 4. Código que dará coloração diferenciada às colunas da página.

  <%- 
     color = ''
     if title == 'To Do'
        color = 'style="background:#f8f8f8"'
     elsif title == 'In Progress'
        color = 'style="background:#66ff99"'
     elsif title == 'Blocked'
        color = 'style="background:#ff0000"'
     elsif title == 'Verify'
        color = 'style="background:#6699ff"'
     elsif title == 'Closed'
        color = 'style="background:#009966"'
     end
  -%>
  <div class="task-column">
      <h3 <%= color %> ><center><%= title %></center></h3>
      <% issues.each do |issue| %>
          <div class="issue">
              <a href="/issues/<%= issue.id %>">
              #<%= issue.id %> - <%= issue.tracker %> :
              <%= issue.subject %>
              </a>
          </div>
      <% end %>
  </div>

Da linha 3 até a 12 são realizadas verificações quanto ao título da coluna em questão. Para cada uma é definida uma coloração diferente de seu fundo. Por exemplo, usamos na linha 3 “color = ‘style=”background:#f8f8f8”’”. Na linha 15 é criada uma nova div que recebe as características da classe task-column e na linha 16 são utilizadas uma série de tags HTML associadas a tags Ruby que permitem definir de forma dinâmica a cor de fundo e o título de cada bloco. Na linha 17 é inicializado um laço de repetição que buscará todas as atividades pertencentes a cada um dos grupos To Do, In Progress, Blocked, Verify e Closed.

Passo 3: Arquivo index.html.erb

O terceiro passo da adaptação consiste em permitir a apresentação das atividades abertas e fechadas de forma personalizada. Para isso, execute no arquivo $REDMINE_ROOT/vendor/plugin/redmine_task_board/app/view/task_boards/index.html.erb as alterações indicadas na Listagem 5.

Listagem 5. Personalização da funcionalidade de escolha de Sprint’s

  <h2>Choose a Sprint</h2>
   
  <h4>Open</h4>
  <ul id="version-choice">
  <% @project.versions.each do |version| %>
      <% if version.open? %>
         <li><%= link_to version.name, '/task_boards/show/' + version.id.to_s + '?project_identifier=' + version.project.identifier.to_s %></li>
      <% end %>
  <% end %>
  </ul>
  <h4>Closed</h4>
  <ul id="version-choice">
  <% @project.versions.each do |version| %>
      <% if version.closed? %>
         <li><%= link_to version.name, '/task_boards/show/' + version.id.to_s + '?project_identifier=' + version.project.identifier.to_s %></li>
      <% end %>
  <% end %>
  </ul>

Na linha 4 é realizado um laço por todas as versões do projeto; na linha 5 é verificado se a versão está aberta e se estiver, na linha 6 é criado um link para a página de configuração da versão. A linha 8 fecha o laço

A linha 12 inicia outro laço verificando se o estado do projeto está fechado: se sim, é criado um link para a página de detalhamento do projeto.

Passo 4: Arquivo task_boards_controller.rb

Continuando o processo de adaptação do código responsável por apresentar dinamicamente as atividades abertas e fechadas, deve-se agora realizar as alterações sugeridas na Listagem 6 no arquivo $REDMINE_ROOT/vendor/plugin/redmine_task_board/app/controllers/task_boards_controller.rb

Listagem 6. Linkagem das operações indicadas na Listagem 5

  def show
    @version = Version.find(params[:id])
    @project = @version.project
       
    @issues_to_do = Issue.find_by_version_id_and_status_names
                    (@version.id, ['New', 'Open', 'Re Open'])
    @issues_in_progress = Issue.find_by_version_id_and_status_names
                          (@version.id, ['In Progress'])    
    @issues_blocked = Issue.find_by_version_id_and_status_names
                      (@version.id, ['Blocked'])    
    @issues_to_verify = Issue.find_by_version_id_and_status_names
                        (@version.id, ['Done', 'Rejected', "Won't Fix"])
    @issues_closed = Issue.find_by_version_id_and_status_names
                     (@version.id, ['Rejected', 'Closed'])
  end

Das linhas 3 a 13 temos a criação de objetos para cada um dos estados da atividade. Desta forma pode-se armazenar diversas informações estruturadas dentro de cada um dos objetos citados, permitindo sua posterior apresentação.

Passo 5: Arquivo task_board.css

Por fim, deve-se realizar no arquivo $REDMINE_ROOT/vendor/plugin/redmine_task_board/asset/stylesheets/task_board.css as alterações indicadas na Listagem 7.

Listagem 7. Adição de comandos CSS para apresentação das alterações na página.

  .task-column {
      width: 18%;
      height: 100%;
      float: left; 
      margin-right: 1em;
  }

Assim, finaliza-se as alterações que permitem a visualização das atividades relacionadas ao projeto no modelo Kanban. Um exemplo do resultado pode ser observado na Figura 10.

Figura 10. Apresentação das Tarefas no Modelo Kanban

Desta forma, tem-se no ambiente digital uma visualização com alto grau de aproximação do que é realizado em processos manuais.

Caso o gestor prefira, o Redmine oferece também seu próprio plug-in para adaptação desta etapa, procurando apresentar um modelo que também se assemelha ao Kanban.(vide seção Links).

Contudo, os resultados apresentados não são tão bons quanto os da adaptação realizada manualmente, assim como aconteceu com as demais ferramentas verificadas para então a escolha do RedMine. Na seção Links você encontra dois caminhos para buscar outras ferramentas ágeis.

Alguns recursos referentes ao Scrum ainda não podem ser implementados no Redmine, por isso é muito importante algumas adaptações no próprio processo de trabalho da equipe (como a realização das breves reuniões diárias). Recomenda-se também que as características relacionadas ao negócio (regras de negócio, necessidades de novas funcionalidades, características do projeto, etc.) sejam registradas nos recursos de tracker, e que os requisitos técnicos (padrão a ser utilizado, tecnologias necessárias, etc.) registrados nas necessidades tecnológicas, assim como as tarefas relacionadas ao desenvolvimento (correção de erros, desenvolvimento de novas funcionalidades, criação de classes de conexão com banco de dados, etc.) sejam registradas como subtarefa de um recurso.

Links

Advanced Roadmap v2
https://www.redmine.org/plugins/advanced_roadmap_v2

Redmine Charts
https://www.redmine.org/plugins/redmine_charts2

Redmine Graphs
http://www.redmine.org/projects/redmine/wiki/PluginGraphs

Issue Due Date
http://www.redmine.org/projects/redmine/wiki/PluginIssueDueDate

Issue History Tab
https://www.redmine.org/plugins/issue_tabs

Partking Lot Chart
https://www.redmine.org/plugins/parking-lot-chart

Redmine Task Board
https://github.com/netaustin/redmine_task_board

Plugin Scrum
http://www.redmine.org/plugins/scrum-plugin