Bonnes pratiques Redmine

Question

Quels conseils et "normes" utilisez-vous dans votre processus de gestion de projet Redmine?

Avez-vous un modèle d'insertion de wiki standard que vous pourriez partager ou une façon standard de travailler sur un projet en utilisant des tâches de fonctionnalités de bugs et des problèmes de support?

Laissez-vous les problèmes et les mises à jour être envoyés par e-mail à Redmine? Utilisez-vous les forums? Utilisez-vous le référentiel SVN? Utilisez-vous Mylyn dans Eclipse pour travailler les listes de tâches?

J'essaie de traîner notre département. dans certains sites Web PM au lieu de documents Word envoyés par e-mail d'exigences vagues suivis de documents Word expliquant comment procéder à l'AQ et au déploiement qui se perdent tous dans une pile de mises à jour et de projets concurrents afin qu'au moment où je avoir à réparer quelque chose, personne ne peut trouver de documentation sur la façon dont cela fonctionne.

Answer 1

Je développe et maintiens des applications internes pour une famille d'entreprises manufacturières. Au moment de ce commentaire, je suis le seul développeur/analyste de l'équipe informatique. Pendant le pire de la récession, mon projet a explosé. En tant que tel, mon projet ET mon carnet de commandes sont assez compliqués. Nous sommes actuellement en cours de restructuration pour agrandir l'équipe.

Voici comment j'utilise Redmine pour garder la tête droite (dans la mesure du possible), mes utilisateurs à distance et, espérons-le, empêcher trop de prise en main de nouveaux employés à l'avenir.

• J'utilise Subversion pour le contrôle des sources, avec TortoiseSVN et le bien nommé plugin Tortoise-Redmine . L'actualisation du référentiel sur le projet Redmine après une validation lie le problème, qui affiche la révision du problème et met à jour mes parties prenantes via une notification par courrier électronique.
• Je traite la description du projet comme un moyen de communiquer l'objectif, la portée et l'étape du cycle de vie du projet à ceux qui ne sont pas impliqués. De cette façon, mes utilisateurs savent ce que j'ai dans mon assiette et ce qu'il y a encore sur le buffet que je regarde de loin.
• J'utilise des noms de rôle spécifiques pour mes jeux d'autorisations qui indiquent plus qu'un ensemble d'autorisations - encore une fois, comme moyen de documentation. Mes rôles sont les suivants: chef de projet, membre de l'équipe de projet, propriétaire, utilisateur principal, utilisateur secondaire, observateur, suzerain (pour mes patrons ... à la fois amusant et indéniablement correct).
• J'utilise le wiki et les documents pour la documentation, selon ce qui me semble approprié.
• Les versions me sont pratiquement inutiles, donc au lieu de les utiliser pour les versions planifiées, je les utilise pour regrouper les problèmes liés en sprints.
• J'utilise le fabuleux plugin Stuff-To-Do d'Eric Davis pour organiser/réorganiser les sprints susmentionnés avant de modifier en masse les versions cibles sur mes problèmes. Cela permet également à mes parties prenantes de savoir sur quoi je travaille et comment j'ai priorisé leurs intérêts (pour le meilleur ou pour le pire).
• Pour encourager l'interaction des utilisateurs, j'ai ajouté des liens vers le projet Redmine dans les menus d'aide de mes applications. La boîte "À propos" contient également un lien vers le projet Redmine.

Plans futurs

• J'espère à un moment donné terminer mon extension Visual Studio pour l'intégration de Redmine.
• Construisez une bibliothèque de code pour coupler librement mon application avec son projet Redmine: automatiser la soumission des bogues, alerter les parties prenantes abonnées à partir de la barre d'état système, menu d'aide interactif réutilisable piloté par l'API REST de Redmine, etc. (Peut-être automatiser des parties de la documentation avec le wiki?)

Answer 2

Je suis un freelance Ruby et développeur Web Redmine qui dirige une entreprise de développement d'un (moi). Donc, mon Redmine est configuré pour être assez léger et axé sur le client. Mon Redmine sert également à double fonction pour héberger mes projets Open Source.

J'autorise les nouveaux problèmes et les mises à jour à être envoyés par e-mail et cela fonctionne très bien pour les utilisateurs connectés par e-mail (ou ceux qui sont toujours sur leurs iPhones).

J'ai utilisé la vue du référentiel avec les référentiels git et cela fonctionne très bien. À chaque enregistrement, je fais référence au problème avec #nnn afin que la page réelle du problème affiche tous les commits pour implémenter la fonctionnalité.

J'ai trouvé que les forums étaient sous-utilisés. Je pense que s'il y avait une intégration de messagerie, ils seraient plus utiles.

Answer 3

Nous avons trouvé utiles les pratiques suivantes:

1) Cacher le tracker "Issue" et "Support", et le fichier tout comme un bug:

• gain de temps pour les développeurs, testeurs, gestion;
• si certaines activités doivent être facturées comme "extra" ou "nouvelle fonctionnalité" ou autre, des réunions rapides sont organisées pour les évaluer.

2) jalons et versions J'adore cela, vous pouvez facilement suivre l'état de chaque version et à tout moment vous pouvez télécharger un package plus ancien, c'est-à-dire pour tester un bogue déposé par le client.

3) Fonction "enregistrer" sur l'onglet "problèmes": un autre gros gain de temps, j'ai différentes requêtes enregistrées pour de nombreuses tâches de rapport au jour le jour et c'est tout ce dont j'ai besoin.

4) l'intégration du versioning, c'est-à-dire que l'utilisation de "# 123" dans les commentaires crée un lien vers le problème correspondant: tout simplement intelligent!

Answer 4

Nous utilisons largement Redmine sur notre système. Nous avons même mis en place un projet "Ventes" à utiliser par notre équipe commerciale comme CRM. Nous avons un tas de champs personnalisés dans ce projet, et il remplace SugarCRM que nous utilisions auparavant.

Dans notre système, nous avons des projets pour les logiciels serveur et client. Le projet de serveur est divisé en sous-modules, en fonction de la façon dont j'ai structuré le système et les sous-référentiels, car Redmine aime un dépôt séparé par projet.

Comme d'autres le notent, nous utilisons des codes #nnn dans les messages de validation pour référencer les tickets. Ce qui est cool, c'est que ce n'est pas nécessairement un ticket dans le même projet. Ainsi, un ticket de vente peut être bloqué par un problème de bogue ou une demande d'assistance.

Nous venons de commencer à utiliser les documents pour l'ordre du jour/les procès-verbaux des réunions. Nous utilisons des versions pour regrouper en versions, à la fois sur le client et sur le serveur.

Pour essayer d'utiliser le plugin Redmine Time Tracker pour suivre le temps, mais j'oublie toujours de cliquer sur le début ou la fin. Nous recevons quotidiennement des courriels sur des problèmes qui n'ont pas été abordés depuis un certain temps (Redmine Whining, je pense) et qui ont des dates d'échéance dans le passé ou dans un avenir proche (rappel avancé).

Les e-mails d'assistance vont directement dans notre projet d'assistance, et si l'importation des e-mails était un peu plus robuste (parfois, elle ne crée pas correctement de nouveaux tickets si la ligne Project: est incluse dans l'e-mail), nous aurions des requêtes sur le site Web générant automatiquement des tickets de vente. . En l'état, il nous suffit de surveiller les tickets de support et de les déplacer vers les ventes, le cas échéant.

Choses que j'aimerais pouvoir faire:

• Avoir des relations entre notre système et redmine, afin que les tickets puissent être associés à un utilisateur ou une entreprise dans notre système. Aussi, afin que nous puissions générer une nouvelle entreprise à partir d'un ticket de vente au point pertinent. Cela me demande juste de faire un peu de travail.
• Avoir une relation entre notre logiciel de suivi des erreurs (sentinelle) et redmine, de sorte que les erreurs de serveur génèrent un ticket redmine. Encore une fois, résoluble avec la technologie actuelle.
• Avoir un client de bureau à redéfinir. Le serveur est dans notre réseau local, mais avoir un moyen plus flexible d'accéder aux données autres que la page Web serait formidable. Ce n'est pas qu'il y ait quelque chose que je ne puisse pas vraiment faire dans l'interface Web de Redmine, mais quelque chose comme Things.app est donc beaucoup plus agréable à travailler.
• Disposez de notre documentation de support dans Redmine, puis générez-la sur un serveur public. De cette façon, notre personnel de support peut maintenir la documentation, éditer de manière agréable et déployer les modifications sur doc-server.

Answer 5

Redmine a été fantastique pour nous jusqu'à présent. Nous l'utilisons comme file d'attente de ticketing/priorisation agile multi-locataire, et l'avons également lié à SVN. En particulier:

• L'installation/la maintenance via SVN a été un jeu d'enfant (je nous ai fait migrer de 1.1 à 1.2 à 1.3 à 1.4 via l'utilisation de svn switch https//.../branches/1.3-stable . commandes suivies de rake migrate commandes avec seulement quelques installations de gemmes occasionnelles nécessaires entre les deux).
• Les sauvegardes de la base de données et des fichiers stockés sont une exécution de script sur une ligne
• Nous aimons les plugins Time Tracker et Spent Time . Je tuerais pour un gros client de suivi du temps Mac OS X pour certains de nos utilisateurs de bureau, mais ce n'est pas la question :)
• Nous n'utilisons pas beaucoup les forums, mais nous utilisons beaucoup l'activité et la feuille de route. Lier les problèmes à des versions spécifiques est une aubaine.
• Nous avons également des distinctions client/serveur, mais utilisez la version cible pour lier les tickets afin de spécifier ce qui va où (et avoir une version ouverte NEXT CLIENT RELEASE/NEXT SERVER RELEASE) afin de faire la distinction entre les travaux.
• Nous mélangeons les métaphores pour les statuts - nous utilisons nos listes d'abord groupées par ceux-ci ("Immédiat", "Rejeté", "Bloqué", "Travail", "Sur le pont" "La Liste", "En attente de construction", "Publié pour tester" "," Vérifié "," Mis en production "," Fermé "," Annulé).
• Ensuite, au sein de chaque groupe ci-dessus, nous avons cette liste triée de priorités: ("Immédiat", "Me prioriser", "Me concevoir et me dimensionner", "P1"… "P5", "P-Watch List"). Cela, ainsi que les éléments ci-dessus, permettent un flux de travail facile depuis la zone des problèmes.
• Pour la liste des problèmes de base, nous trions par "Priorité", "Tâche parent", puis "Date de mise à jour" - nous avons besoin de celle du milieu pour que Redmine soit bien en retrait s'il devrait y avoir une tâche enfant dans le même groupe.
• Nous utilisons les validations d'enregistrement pour lier les validations aux problèmes (c'est-à-dire svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns.") - et faites déplacer ce problème vers "Waiting For Build" (qui était "Resolved", mais je me suis fatigué d'expliquer que "Resolved" ne signifiait pas que quelqu'un pouvait s'attendre à le voir publié pour le moment).

Je pense que je vais devoir aller enquêter sur le plugin Redmine-stuff-to-do. +1 question.

Answer 6

Mon entreprise travaille avec des développeurs de logiciels et de matériel d'origine internationale. Avant de rejoindre la société, le courrier électronique était utilisé avec des documents MS Word pour relayer nos problèmes et bogues avec des logiciels ou du matériel pour demander une correction. Ce processus était impossible à suivre et à maintenir tout type de processus. J'ai implémenté RedMine comme un moyen de suivre les bogues logiciels et matériels et cela fonctionne très bien depuis. Il y a une barrière linguistique majeure avec ma situation. Heureusement, RedMine peut s'afficher en chinois sipmlifié et les commentaires ont montré que cela est bien loin de mes développeurs.

Statut - Lorsque je trouve un problème logiciel ou matériel, le statut est "Nouveau" - Lorsque mes développeurs logiciels/matériels ont vu ce problème et y travaillent, ils changent de statut en "En cours". Ils peuvent utiliser le% fait s'ils le souhaitent de 0 à 50. Je leur ai défini% Terminé à 50 lorsqu'ils estiment avoir résolu le problème. - Je détermine si le problème est résolu et je change le statut en "Résolu" et% fait à 100%. Cela me permet de filtrer les problèmes <ou égal à 50% pour trouver les problèmes qui sont toujours ouverts.

Priorité - Faible, Normal, Élevé, Urgent, Immédiat tout se traduit bien en chinois.

Date d'échéance - J'utilise ceci pour me dire quand le correctif a été initialement téléchargé par mes développeurs de logiciels. Cela peut prendre entre 4 et 6 jours pour tester quelque chose et résoudre le problème. J'aime que mon graphique Gannt reflète la réactivité de mon équipe logicielle, pas le temps qu'il m'a fallu pour approuver le correctif.

Catégorie - Cela reflète toujours la version du logiciel ou du matériel où j'ai trouvé le problème. J'utilise ceci pour voir quelle version du logiciel a eu le plus de bogues et pour m'assurer que les versions plus récentes du logiciel ne souffrent pas de régression.

J'ai tout le monde inclus sur la liste des observateurs RedMine pour tous les bugs. L'e-mail apparaît sous la forme (Nouveau), (Résolu) ou (En cours) afin que mes superviseurs et les superviseurs et ingénieurs en chef des équipes impliquées puissent tous voir l'e-mail et lire rapidement les progrès en cours. La plupart des autres personnes impliquées ne se connectent jamais à RedMine, je suis généralement le seul. Les courriels servent parfaitement à fournir des mises à jour instantanées à tous ceux dont la seule préoccupation est de savoir si des progrès sont en cours ou non.

Answer 7

Comme vous avez mentionné l'envoi de documents Word d'avant en arrière avec votre AQ - je sais que ce sentiment, là-bas, l'a fait. Le problème principal pour moi était: les gens d'AQ n'aiment pas ajouter de problèmes dans un outil de suivi des bogues, ils les notent dans un éditeur à côté d'eux pendant les tests.

Nous utilisons Redmine maintenant avec un addon Nice - sersnap (Avertissement: Nous avons construit l'outil pour résoudre ce problème par nous-mêmes.

Usersnap est idéal pour les développeurs Web - ajoutez-le à votre projet Web et vous obtiendrez des captures d'écran directement attachées aux tickets Redmine - y compris des méta-informations sur le navigateur utilisé, le système d'exploitation, etc.

Nos QA/clients peuvent maintenant saisir des bogues directement dans l'application Web et les développeurs peuvent plus facilement reproduire les rapports de bogues dans Redmine.

Answer 8

En plus des autres commentaires, je recommande l'utilisation du plugin "Stuff To Do" (écrit par Eric Davis je pense :) L'utilisation de ce plugin vous permet de trier par glisser-déposer l'ordre des problèmes sur plusieurs projets.

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

Answer 9

Nous utilisons la section Feuille de route comme un moyen clair d'afficher:

• bogues
• fonctionnalités (qui seraient des références à votre document Word ou un lien vers des pages d'exigences html)
• rapprochements (différences entre les valeurs de production et les valeurs de test)
• etc...

C'est le principal point de consolidation pour nous. Le reste est utilisé en relation avec cela (par exemple, la section 'annonce' est utilisée pour définir les principales étapes/dates de sortie utilisées dans la feuille de route)

Answer 10

Nous utilisons les versions comme un moyen de définir des sprints, donc chaque version est un sprint avec la vue Feuille de route donnant une illustration claire des progrès. Les problèmes dans les sprints sont marqués comme "prêts à être examinés" une fois terminés, puis fermés lorsque le contrôle qualité a été vérifié.

Nous utilisons une version comme backlog pour tous les problèmes qui tombent hors de portée ou perdent leur priorité, etc.

Answer 11

Nous utilisons Redmine depuis environ un an maintenant et il a évolué de plusieurs façons. Nous utilisons des versions pour regrouper les problèmes pour une version, et des catégories pour regrouper les problèmes par discipline.

Chaque problème passe par un workflow de nouveau> en cours> résolu. Ensuite, le testeur fermera le problème lorsqu'il sera satisfait.

Nous aimerions mettre à jour la façon dont nous utilisons Redmine, il semble y avoir tellement d'excellents plugins, mais nous constatons que beaucoup d'entre eux sont cassés ou ne s'installent pas.

Nous utilisons le wiki de manière exhaustive pour la documentation des développeurs.