Práticas recomendadas do Redmine [fechado]

Que dicas e "padrões" você usa no processo de gerenciamento de projetos do Redmine?

Você tem um modelo de inserção de wiki padrão que possa compartilhar ou uma maneira padrão de trabalhar um projeto usando tarefas de recursos de bugs e problemas de suporte?

Você permite que problemas e atualizações sejam enviados por e-mail para o Redmine? Você usa os fóruns? Você usa o repositório SVN? Você usa o Mylyn no Eclipse para trabalhar as listas de tarefas?

Estou tentando arrastar nosso departamento. em algum PM baseado na web, em vez de documentos do Word enviados por e-mail com requisitos vagos, seguidos por documentos do Word explicando como fazer o controle de qualidade e implantar para que todos se percam em uma pilha de atualizações e projetos concorrentes para que, quando eu tiver que consertar algo, ninguém possa encontrar qualquer documentação sobre como funciona.

Eu desenvolvo e mantenho aplicativos internos para uma família de empresas de manufatura. Até o momento deste comentário, sou o único desenvolvedor / analista da equipe de TI. Durante o pior da recessão, minhas demandas de projetos explodiram. Como tal, minha lista de pendências de projeto E problema é bastante complicada. No momento, estamos em processo de reestruturação para ampliar a equipe.

É assim que eu uso o Redmine para manter minha cabeça reta (na medida do possível), meus usuários afastados e, espero, evitar que a nova equipe segure muito no futuro.

• Eu uso o Subversion para controle de código-fonte, com TortoiseSVN e o plugin apropriadamente chamado de Tortoise-Redmine . Atualizar o repositório no projeto Redmine após um commit vincula o problema, que mostra a revisão sobre o problema e atualiza minhas partes interessadas por meio de notificação por email.
• Eu trato a descrição do projeto como um meio de comunicar o propósito, o escopo e o estágio do ciclo de vida do projeto para aqueles que não estão envolvidos. Dessa forma, meus usuários sabem o que tenho em mãos e o que ainda está no buffet que estou observando à distância.
• Eu uso nomes de funções específicos para meus conjuntos de permissões que indicam mais do que um conjunto de permissões - novamente, como um meio de documentação. Minhas funções incluem o seguinte: Gerente de Projeto, Membro da Equipe do Projeto, Proprietário, Usuário Principal, Usuário Secundário, Observador, Overlord (para meus chefes ... divertido e inegavelmente correto).
• Eu uso o Wiki e os Documentos para documentação, dependendo do que eu achar apropriado.
• Versões são praticamente inúteis para mim, então, em vez de usá-las para lançamentos planejados, eu as uso para agrupar questões relacionadas em sprints.
• Eu uso o fabuloso plug-in Stuff-To-Do de Eric Davis para organizar / reorganizar os sprints mencionados antes da edição em massa das Versões Alvo em meus problemas. Isso também permite que meus stakeholders saibam no que estou trabalhando e como priorizei seus interesses (para melhor ou pior).
• Para incentivar a interação do usuário, adicionei links para o projeto Redmine aos menus de Ajuda dos meus aplicativos. A caixa "Sobre" também contém um link para o projeto Redmine.

Planos futuros

• Espero em algum momento terminar minha extensão do Visual Studio para integração com o Redmine.
• Construir uma biblioteca de código para acoplar livremente meu aplicativo com seu projeto Redmine: automatizar o envio de bugs, alertar as partes interessadas inscritas na bandeja do sistema, menu de Ajuda interativo reutilizável conduzido pela API REST do Redmine, etc. (Talvez automatizar partes da documentação com o Wiki?)

Sou um desenvolvedor web freelance em Ruby e Redmine que administra um negócio de desenvolvimento de um (eu). Portanto, meu Redmine está configurado para ser bem leve e focado no cliente. Meu Redmine também serve em dobro para hospedar meus projetos de código aberto.

Eu permito que novos problemas e atualizações sejam enviados por e-mail e funciona muito bem para usuários conectados por e-mail (ou aqueles que estão sempre em seus iPhones).

Tenho usado a visualização do repositório com repositórios git e está funcionando muito bem. A cada check-in, faço referência ao problema com #nnn, de modo que a página do problema real mostrará todos os commits para implementar o recurso.

Eu descobri que os fóruns são subutilizados. Acho que se houvesse alguma integração de e-mail, eles seriam mais úteis.

Consideramos úteis as seguintes práticas:

1) Oculte o rastreador de "Problema" e "Suporte" e arquive tudo como um bug :

• economizador de tempo para desenvolvedores, testadores, gerenciamento;
• se algumas atividades forem cobradas como "extras", "novos recursos" ou qualquer outra coisa, reuniões rápidas são organizadas para avaliá-las.

2) marcos e versões Adoro isso, você pode facilmente rastrear o status de cada lançamento e a qualquer momento você pode baixar um pacote mais antigo, ou seja, para testar um bug apresentado pelo cliente.

3) Função "salvar" na guia "problemas": outra grande economia de tempo, tenho diferentes consultas salvas para muitas tarefas de relatórios do dia-a-dia e isso é tudo que preciso.

4) integração de controle de versão, ou seja, usar "# 123" nos comentários cria um link para o problema correspondente: simplesmente inteligente!

Usamos o Redmine extensivamente em nosso sistema. Até montamos um projeto de "Vendas" para nossa equipe de vendas usar como um CRM. Temos um monte de campos personalizados neste projeto e ele substitui o SugarCRM que estávamos usando antes.

Dentro do nosso sistema, temos projetos para software Servidor e Cliente. O projeto do servidor é dividido em submódulos, com base em como estruturei o sistema e os sub-repositórios, já que o Redmine gosta de um repositório separado por projeto.

Usamos, como outros observam, códigos #nnn em mensagens de confirmação para fazer referência a tickets. O legal é que não precisa ser um ticket no mesmo projeto. Assim, um tíquete de venda pode ser bloqueado por um problema de bug ou uma solicitação de suporte.

Acabamos de começar a usar Documentos para agenda / atas de reuniões. Usamos versões para agrupar em lançamentos, tanto no cliente quanto no servidor.

Para tentar usar o plugin Redmine Time Tracker para controlar o tempo, mas sempre esqueço de clicar em iniciar ou terminar. Recebemos e-mails diários sobre questões que não são abordadas há algum tempo (Redmine Whining, eu acho), e que têm datas de vencimento no passado ou em um futuro próximo (Lembrete avançado).

Os e-mails de suporte vão diretamente para o nosso projeto de suporte, e se a importação de e-mail fosse um pouco mais robusta (às vezes não cria novos tickets corretamente se a linha Projeto: estiver incluída no e-mail), teríamos consultas do site para gerar tickets de vendas automaticamente . Do jeito que está, só precisamos monitorar os tíquetes de suporte e movê-los para Vendas, se aplicável.

Coisas que eu gostaria de ser capaz de fazer:

• Tenha relacionamento entre nosso sistema e o redmine, para que os tickets possam ser associados a um usuário ou empresa em nosso sistema. Além disso, para que possamos gerar uma nova empresa a partir de um ticket de venda no ponto em questão. Isso só requer que eu faça algum trabalho.
• Tenha um relacionamento entre nosso software de rastreamento de erros (sentry) e o redmine, para que os erros do servidor gerem um tíquete do redmine. Novamente, solucionável com a tecnologia atual.
• Tenha um cliente de desktop para redmine. O servidor está dentro da nossa LAN, mas poder ter uma forma mais flexível de acessar os dados além da página da web seria ótimo. Não é que há algo que eu realmente não pode fazer na interface web redmine, mas algo como Things.app é por isso muito mais agradável para trabalhar.
• Tenha nossa documentação de suporte toda dentro do redmine, e então gerada em um servidor público. Dessa forma, nossa equipe de suporte pode manter a documentação, editar de uma maneira agradável e implantar as alterações no servidor de documentos.

O Redmine tem sido fantástico para nós até agora. Nós o usamos como uma fila multi-tenant de tíquetes / priorização ágil e também o vinculamos ao SVN. Em particular:

• Instalar / manter via SVN foi muito fácil (eu migrei de 1.1 para 1.2 para 1.3 para 1.4 por meio do uso de svn switch https//.../branches/1.3-stable .comandos seguidos pelos rake migratecomandos com apenas instalações ocasionais de gem necessárias entre eles).
• Backups do banco de dados e arquivos armazenados são uma execução de script de uma linha
• Adoramos os plug-ins Time Tracker e Spent Time . Eu mataria por um cliente gordo de rastreamento de tempo do Mac OS X para alguns de nossos usuários de escritório, mas isso não vem ao caso :)
• Não usamos muito os Fóruns, mas usamos muito Activity e Roadmap. Vincular questões a versões específicas é uma dádiva de Deus.
• Também temos distinções de cliente / servidor, mas usamos a versão de destino para amarrar os tíquetes para especificar quem vai para onde (e abrimos o PRÓXIMO CLIENTE RELEASE / PRÓXIMO SERVER RELEASE) de modo a distinguir enquanto está sendo trabalhado.
• Misturamos metáforas para status - usamos nossas listas primeiro agrupadas por estes ("Imediato", "Rejeitado", "Bloqueado", "Funcionando", "No deck" "A Lista", "Esperando pela Construção", "Liberado para Teste "," Verificado "," Liberado para produção "," Fechado "," Cancelado).
• Então, dentro de cada grupo acima, temos esta lista classificada de Prioridades: ("Imediato", "Priorize-me", "Projete e dimensione-me", "P1" ... "P5", "Lista P-Watch"). Isso mais o acima permite um fluxo de trabalho fácil de todas as áreas de problemas.
• Para a lista de problemas básicos, classificamos por "Prioridade", "Tarefa pai" e depois "Data de atualização" - é necessário aquele do meio para que o Redmine indente bem se houver uma tarefa filho no mesmo agrupamento.
• Usamos confirmações de check-in para vincular confirmações a problemas (ou seja, svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns.") - e movemos esse problema para "Aguardando construção" (costumava ser "Resolvido", mas cansei de explicar que "Resolvido" não significava que alguém pudesse espere vê-lo lançado ainda).

Acho que terei que investigar o plug-in Redmine-stuff-to-do embora. +1 pergunta.

Minha empresa trabalha com desenvolvedores de software e hardware de origem internacional. Antes de entrar na empresa, o e-mail era usado com documentos do MS Word para relatar nossos problemas e bugs com software ou hardware para solicitar uma correção. Este processo era impossível de rastrear e manter qualquer tipo de processo. Implementei o RedMine como um meio de rastrear os bugs de software e hardware e está funcionando muito bem desde então. Existe uma grande barreira de idioma com a minha situação. Felizmente, o RedMine pode ser exibido no idioma chinês Sipmlified e o feedback mostrou que isso está OK até agora para meus desenvolvedores.

Status - Quando encontro um problema de software ou hardware, o Status é "Novo" - Quando meus desenvolvedores de software / hardware viram esse problema e estão trabalhando nele, eles mudam o status para "Em andamento". Eles podem usar a% concluída, se desejarem, de 0 a 50. Eu os defini como% Concluída para 50 quando acharem que resolveram o problema. - Eu determino se o problema foi corrigido e altero o Status para "Resolvido" e% concluído para 100%. Isso me permite filtrar problemas <ou igual a 50% para encontrar problemas que ainda estão em aberto.

Prioridade - Baixa, Normal, Alta, Urgente, Imediata tudo se traduz bem em chinês.

Data de vencimento - eu uso isso para me dizer quando a correção foi carregada originalmente pelos meus desenvolvedores de software. Pode levar de 4 a 6 dias para testar algo e resolver o problema. Gosto que meu gráfico de Gannt reflita a capacidade de resposta de minha equipe de software, não quanto tempo levei para aprovar a correção.

Categoria - Isso sempre reflete a versão do software ou hardware onde encontrei o problema. Eu uso isso para ver qual versão do software tinha a maior quantidade de bugs e para garantir que as versões mais novas do software não sofram regressão.

Todos estão incluídos na lista de observadores do RedMine para todos os bugs. O e-mail aparece como (Novo), (Resolvido) ou (Em andamento) para que meus supervisores e os supervisores e engenheiros-chefe das equipes envolvidas possam ver o e-mail e ler rapidamente o progresso que está sendo feito no momento. A maioria das outras pessoas envolvidas nunca faz login no RedMine, normalmente sou a única. Os e-mails servem perfeitamente para dar atualizações instantâneas a todos cuja única preocupação é se o progresso está sendo feito ou não.

Como você mencionou, enviar e encaminhar documentos do Word com seu controle de qualidade - eu conheço essa sensação, já estive lá, fiz isso. O principal problema para mim foi: as pessoas do controle de qualidade não gostam de adicionar problemas em qualquer bug tracker, eles os anotam em um editor próximo a eles durante o teste.

Estamos usando o Redmine agora com um bom addon - Usersnap (Disclaimer: Nós construímos a ferramenta para resolver este problema por nós mesmos.

Usersnap é ótimo para desenvolvedores web - adicione-o ao seu projeto web e você obterá capturas de tela diretamente anexadas aos tíquetes do Redmine - incluindo meta informações sobre o navegador usado, sistema operacional e assim por diante.

Nossos QAs / clientes podem inserir bugs agora diretamente no aplicativo da web e os desenvolvedores ficam mais fáceis de reproduzir relatórios de bug no Redmine.

Estamos usando a seção Roteiro como uma maneira clara de exibir:

• insetos
• recursos (que seriam referências ao seu documento do Word, ou link para páginas de requisitos html)
• reconciliações (diferenças entre os valores de produção e os valores de teste)
• e assim por diante...

Esse é o principal ponto de consolidação para nós. O resto é usado em relação a isso (por exemplo, a seção 'anunciar' é usada para definir o marco principal / datas de lançamento usadas no roteiro)

Além dos outros comentários, recomendo o uso do plug-in "Coisas para fazer" (escrito por Eric Davis, acho :) O uso desse plug-in permite arrastar e soltar a ordem dos problemas em vários projetos.

https://projects.littlestreamsoftware.com/projects/show/redmine-stuff-to-do

Usamos Versões como uma forma de definir sprints, de modo que cada Versão é uma sprint com a visualização Roadmap, dando uma ilustração clara do progresso. Os problemas nos sprints são marcados como 'prontos para revisão' quando concluídos e, em seguida, fechados quando o controle de qualidade é verificado.

Usamos uma versão como um backlog para quaisquer questões que saiam do escopo ou perdem sua prioridade, etc.

Estamos usando o Redmine há cerca de um ano e ele evoluiu sozinho de várias maneiras. Usamos versões para agrupar questões para um lançamento e categorias para agrupar questões por disciplina.

Cada problema passa por um fluxo de trabalho de novo> em andamento> resolvido. Em seguida, o testador fechará o problema quando estiver satisfeito.

Adoraríamos atualizar a forma como usamos o Redmine. Parece que há tantos plug-ins ótimos, mas descobrimos que muitos deles estão corrompidos ou não serão instalados.

Usamos o wiki de forma abrangente para a documentação do desenvolvedor.