Bonnes pratiques Redmine [fermé]

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

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

Laissez-vous les problèmes et les mises à jour être envoyés par e-mail dans 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'essaye de traîner notre département. dans un PM basé sur le Web au lieu de documents Word envoyés par courrier électronique contenant des exigences vagues, suivis de documents Word expliquant comment effectuer un contrôle qualité et un déploiement qui se perdent tous dans une pile de mises à jour et de projets concurrents, de sorte qu'au moment où je dois réparer quelque chose, personne ne peut trouver toute documentation sur son fonctionnement.

Je développe et gère 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. Au pire de la récession, les exigences de mon projet ont explosé. En tant que tel, mon arriéré de projets ET de problèmes est assez lourd. 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, éviter trop de mainmise de nouveau personnel à l'avenir.

• J'utilise Subversion pour le contrôle de code source, avec TortoiseSVN et le plugin Tortoise-Redmine bien nommé . L'actualisation du référentiel sur le projet Redmine après une validation lie le problème, qui montre 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 qui reste sur le buffet que je regarde de loin.
• J'utilise des noms de rôle spécifiques pour mes ensembles 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, Overlord (pour mes patrons ... à la fois amusant et indéniablement correct)
• J'utilise le wiki et les documents pour la documentation, selon ce que je pense être approprié.
• Les versions sont à peu près inutiles pour moi, donc au lieu de les utiliser pour les versions planifiées, je les utilise pour regrouper les problèmes connexes en sprints.
• J'utilise le fabuleux plugin Stuff-To-Do d'Eric Davis pour organiser / réorganiser les sprints susmentionnés avant d'éditer 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 hiérarchisé 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 Redmine.
• Construire une bibliothèque de code pour coupler vaguement mon application avec son projet Redmine: automatiser la soumission des bogues, alerter les parties prenantes qui s'abonnent à 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?)

Je suis un développeur web indépendant Ruby et Redmine qui dirige une entreprise de développement d'un (moi). Mon Redmine est donc configuré pour être assez léger et axé sur le client. My Redmine a également une double fonction d'hébergement de mes projets Open Source.

J'autorise l'envoi de nouveaux problèmes et mises à jour par e-mail et cela fonctionne très bien pour les utilisateurs connectés par e-mail (ou ceux qui sont toujours sur leur iPhone).

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

J'ai trouvé que les forums sont sous-utilisés. Je pense que s'il y avait une intégration de courrier électronique, elles seraient plus utiles.

Nous avons trouvé utiles les pratiques suivantes:

1) Cacher le tracker "Problème" et "Support", et tout classer comme un bogue :

• gain de temps pour les développeurs, les testeurs, la direction;
• si certaines activités doivent être facturées comme «extra» ou «nouvelle fonctionnalité» ou quoi que ce soit d'autre, des réunions rapides sont organisées pour les évaluer.

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

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

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

Nous utilisons Redmine largement sur notre système. Nous avons même mis en place un projet «Ventes» pour notre équipe commerciale à utiliser 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 serveur est divisé en sous-modules, en fonction de la manière dont j'ai structuré le système et les sous-référentiels, puisque Redmine aime un dépôt séparé par projet.

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

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

Pour essayer d'utiliser le plugin Redmine Time Tracker pour suivre le temps, mais j'oublie toujours de cliquer sur début ou fin. Nous recevons quotidiennement des e-mails 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 proche avenir (rappel avancé).

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

Ce 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, pour que nous puissions générer une nouvelle entreprise à partir d'un ticket de vente au point pertinent. Cela m'oblige simplement à faire du travail.
• Avoir une relation entre notre logiciel de suivi des erreurs (sentinelle) et redmine, de sorte que les erreurs du serveur génèrent un ticket redmine. Encore une fois, résoluble avec la technologie actuelle.
• Avoir un client de bureau à redminer. Le serveur se trouve dans notre réseau local, mais être en mesure d'avoir un moyen plus flexible d'accéder aux données autres que la page Web serait génial. Ce n'est pas qu'il y a quelque chose que je ne peux pas vraiment faire dans l'interface Web de Redmine, mais quelque chose comme Things.app est tellement plus agréable à travailler.
• Ayez toute notre documentation de support dans redmine, puis générée 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.

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

• L'installation / la maintenance via SVN a été un jeu d'enfant (je nous ai migrés de 1.1 à 1.2 à 1.3 à 1.4 via l'utilisation de svn switch https//.../branches/1.3-stable .commandes suivies des rake migratecommandes avec seulement des 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 en une ligne
• Nous adorons les plugins Time Tracker et Spent Time . Je tuerais pour un client lourd 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 utilisons fortement l'activité et la feuille de route. Lier des problèmes à des versions spécifiques est une aubaine.
• Nous avons également des distinctions Client / Serveur, mais nous utilisons la version cible pour lier les tickets afin de spécifier qui va où (et nous avons ouvert la prochaine LIBÉRATION CLIENT / PROCHAINE LIBÉRATION DU SERVEUR) afin de faire la distinction entre tout en travaillant.
• Nous mélangons des métaphores pour les statuts - nous utilisons nos listes d'abord groupées par ces derniers ("Immédiat", "Rejeté", "Bloqué", "En cours de fonctionnement", "Sur le pont" "La liste", "En attente de construction", "Sortie pour tester "," Vérifié "," Mis en production "," Fermé "," Annulé).
• Ensuite, dans chaque groupe ci-dessus, nous avons cette liste triée de priorités: ("Immédiate", "Priorité à moi", "Concevoir et me dimensionner", "P1"… "P5", "P-Watch List"). Ceci, ajouté à ce qui précède, permet 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 parente", puis "Date de mise à jour" - nous avons besoin de celle du milieu pour que Redmine se rétracte correctement s'il y a 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 faisons en sorte que le problème soit déplacé vers "En attente de compilation" (auparavant, "Résolu", mais j'en ai eu assez d'expliquer que "Résolu" ne signifiait pas que quelqu'un pouvait attendez-vous à le voir encore publié).

Je pense cependant que je vais devoir aller étudier le plugin Redmine-stuff-to-do. +1 question.

Mon entreprise travaille avec des développeurs de logiciels et de matériel d'origine internationale. Avant de rejoindre l'entreprise, 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 de suivre et de maintenir tout type de processus. J'ai implémenté RedMine pour 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 Sipmlified et les commentaires ont montré que c'était OK pour 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 qu'ils y travaillent, ils changent le statut en "En cours". Ils peuvent utiliser le% terminé s'ils le souhaitent entre 0 et 50. Je leur demande de régler% 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 le% terminé à 100%. Cela me permet de filtrer les problèmes <ou égaux à 50% pour trouver les problèmes qui sont toujours ouverts.

Priorité - Faible, normale, élevée, urgente, immédiate tout se traduit bien en chinois.

Date d'échéance - Je l'utilise pour me dire quand le correctif a été initialement téléchargé par mes développeurs de logiciels. Cela peut me prendre 4 à 6 jours pour tester quelque chose et résoudre le problème. J'aime que mon diagramme de 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 le plus de bogues et pour m'assurer que les nouvelles versions du logiciel ne souffrent pas de régression.

J'ai tout le monde inclus sur la liste des observateurs RedMine pour tous les bogues. L'e-mail apparaît comme (Nouveau), (Résolu) ou (En cours) afin que mes superviseurs, ainsi que les superviseurs et les 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 e-mails servent parfaitement à donner des mises à jour instantanées à tous ceux dont le seul souci est de savoir si des progrès sont réalisés ou non.

Comme vous avez mentionné l'envoi de documents Word d'avant en arrière avec votre assurance qualité - je connais ce sentiment, j'étais là, je l'ai fait. Le principal problème pour moi était le suivant: les personnes chargées du contrôle qualité n'aiment pas ajouter de problèmes dans aucun outil de suivi de bogues, ils les notent dans un éditeur à côté d'eux pendant les tests.

Nous utilisons maintenant Redmine avec un joli addon - Usersnap (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.

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

• Bugs
• 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 `` annoncer '' est utilisée pour définir les principales dates de jalon / de sortie utilisées dans la feuille de route)

En plus des autres commentaires, je recommande l'utilisation du plug-in "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

Nous utilisons les versions comme moyen de définir des sprints, donc chaque version est un sprint avec la vue Roadmap donnant une illustration claire de la progression. Les problèmes dans les sprints sont marqués comme «prêts pour la révision» 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.

Nous utilisons Redmine depuis environ un an maintenant et il a évolué de lui-même à bien des égards. 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 flux de travail de nouveau> en cours> résolu. Ensuite, le testeur fermera le problème lorsqu'il sera satisfait.

Nous serions ravis de mettre à jour la façon dont nous utilisons Redmine, il semble y avoir tellement de bons 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.