organisation de projets Redmine?

Question

Je suis le seul développeur à travailler sur quelques sites webapp. Je les ai dans subversion, mais je n'utilise pas un outil de gestion de projet.

Je me suis récemment mis au travail et je veux mettre en place les projets là-bas. Ce que je cherche, c'est une recommandation sur la façon de structurer ces deux projets dans Redmine. De ce que je peux glaner, la structure est Projet-> sous-projet. Donc j'essaye de mapper ceci à ma structure de liste de choses à faire. De ma liste de choses à faire, il y a trois types de tâches: les nouvelles fonctionnalités, les corrections de bogues et la maintenance (pas tout à fait des corrections de bogues mais des choses qui ont vraiment besoin d'être nettoyées). Dois-je faire de chaque application Web un projet de niveau supérieur, avec des fonctionnalités, des bogues et de la maintenance en tant que sous-projets? Quelles sont les autres façons d'organiser les projets? Par exemple, dans le manuel Subversion, ils recommandent d'avoir project/trunk, project/branches, project/testing, project/releases, etc. Existe-t-il des directives similaires pour travailler dans Redmine?

Answer 1

Comme d'habitude, lorsque vous configurez un système, vous devez le personnaliser autant que possible pour essayer de répondre à vos propres besoins. Personnellement, je ne connais pas de lignes directrices ou de recommandations pour Redmine en soi, mais je peux raconter ce que nous faisons ici et j'espère que cela vous aidera! :-)

Fonctionnalités/Bogues/Maintenance sont juste des moyens d'étiqueter vos tâches afin que vous puissiez les filtrer. Ce sont des étiquettes spécifiques connues sous le nom de "tracker" dans Redmine. Vous pouvez définir vos propres trackers pour d'autres types de tâches. Le projet et le sous-projet sont également un moyen d'étiqueter vos tâches, mais en les regroupant dans une catégorie plus large. Lorsque vous créez des «projets», vous affectez les suiveurs dont vous aurez besoin. Dans notre cas, nous créons une API, et avons des trackers distincts pour identifier les bogues, avec & modifications avec (effectivement) des noms de tracker dupliqués afin que nous puissions identifier si les tâches sont pour les programmeurs desktop ou dsp. Les sous-projets sont utilisés pour identifier les lignes de produits ou les personnalisations pour lesquelles nos clients ont besoin d'un support spécifique. Nous utilisons également des libellés de version pour identifier les versions spécifiques de chaque sous-projet, ce qui nous permet d'obtenir un bon aperçu de toutes les tâches que nous suivons. Nous avons plusieurs projets dans notre système Redmine, chacun configuré de la même manière, avec des tâches de projet liées entre projets comme des problèmes "liés" afin que nous puissions identifier les dépendances.

Ceci est juste une façon de configurer Redmine, mais c'est la plus simple que nous puissions gérer étant donné les relations complexes entre certains de nos projets. C'est la deuxième configuration que nous avons essayée et nous trouvons que cela fonctionne bien. FYI, la première configuration était sur un système de test pour nous permettre de déterminer ce dont nous avions besoin du système après la migration de Trac, il y a quelques années. La configuration actuelle est utilisée depuis environ 2 ans et semble bien convenir à nos besoins. Comme je l'ai déjà dit, vous devez décider ce dont vous avez besoin du système, mais l'approche la plus simple consiste à réfléchir à la façon dont vous visualisez un projet de haut en bas, configurez votre système pour qu'il corresponde à vos processus et ne modifiez pas votre processus pour correspondre à l'outil - toujours l'option plus «désastreuse» à mon humble avis. Je ne recommanderais pas de suivre les bogues et les fonctionnalités, etc., dans des projets distincts, car il est généralement plus difficile d'assembler vos feuilles de route et il est également plus difficile de visualiser la charge totale de tâches pour un projet donné. Même la division de types de tâches en sous-projets peut poser problème, car cela complique les choses si vous estimez que vous devez prendre en charge plusieurs cycles de lancement de produit, ce qui ajoute à votre charge de travail en termes de gestion de votre système Redmine.

C'est à peu près tout ce que je peux penser pour le moment.J'espère que cela vous aide. :-)

Answer 2

Le type de tâches que vous mentionnez semble être ce que Redmine appelle traqueur. Vous pouvez définir vos propres trackers. À mon avis, vous ne devriez pas avoir besoin d'un sous-projet pour chaque "genre de tâche", mais d'un tracker.