Wie üblich, wenn Sie ein System konfigurieren, müssen Sie es so viel wie möglich anpassen, um zu versuchen und Ihre eigenen Bedürfnisse zu erfüllen. Ich persönlich kenne keine Richtlinien oder Empfehlungen für Redmine per se, aber ich kann erzählen, was wir hier machen und ich hoffe, dass dir das weiterhilft! :-)
Funktionen/Bugs/Wartung sind nur Möglichkeiten, Ihre Aufgaben zu kennzeichnen, so dass Sie sie filtern können. Dies ist ein spezielles Label, das in Redmine als "Tracker" bezeichnet wird. Sie können eigene Tracker für zusätzliche Aufgaben definieren.
Projekt und Unterprojekt sind auch eine effektive Möglichkeit, Ihre Aufgaben zu kennzeichnen, sie jedoch in eine breitere Kategorie einzuteilen. Wenn Sie "Projekte" erstellen, ordnen Sie die benötigten Tracker zu. In unserem Fall erstellen wir eine API und haben verschiedene Tracker, um Bugs zu identifizieren, Features & Änderungen mit (effektiv) doppelten Tracker-Namen, so dass wir erkennen können, ob die Aufgaben für Desktop- oder DSP-Programmierer sind. Die Teilprojekte werden verwendet, um Produktlinien oder Anpassungen zu identifizieren, für die unsere Kunden spezifische Unterstützung benötigen. Wir verwenden auch Versionsbezeichnungen, um bestimmte Releases in jedem Teilprojekt zu identifizieren, sodass wir eine gute Übersicht über alle Aufgaben erhalten, die wir verfolgen. Wir haben mehrere Projekte in unserem Redmine-System, die alle auf ähnliche Weise konfiguriert sind, wobei einige Projektaufgaben projektübergreifend als "verwandte" Probleme verknüpft sind, so dass wir Abhängigkeiten identifizieren können.
Dies ist nur eine Möglichkeit, Redmine zu konfigurieren, ist aber angesichts der komplexen Beziehungen zwischen einigen unserer Projekte die einfachste Lösung. Es ist die zweite Konfiguration, die wir ausprobiert haben, und wir finden, dass es gut funktioniert. Zu guter Letzt, die erste Konfiguration war auf einem Testsystem, um uns zu erlauben, herauszufinden, was wir vom System brauchten, nachdem wir vor ein paar Jahren von Trac migriert hatten. Die aktuelle Konfiguration wird seit ca. 2 Jahren verwendet und scheint unseren Bedürfnissen gerecht zu werden.
Wie ich bereits sagte, müssen Sie entscheiden, was Sie vom System benötigen, aber der einfachste Ansatz ist, darüber nachzudenken, wie Sie ein Projekt von oben nach unten sehen, Ihr System so konfigurieren, dass es Ihren Prozessen entspricht, und nicht ändern Prozesse, um das Werkzeug zu entsprechen - immer die "katastrophale" Option IMHO. Ich würde nicht empfehlen, Bugs und Features in separaten Projekten zu verfolgen, da das Zusammenstellen von Roadmaps normalerweise schwieriger ist und es außerdem schwieriger macht, die Gesamtlast für ein bestimmtes Projekt zu visualisieren. Auch die Aufspaltung von Aufgabentypen in Teilprojekte kann problematisch sein, da dies die Situation komplizierter macht, wenn Sie mehrere Produktfreigabezyklen unterstützen müssen, was zu Ihrer Arbeitslast bei der Verwaltung Ihres Redmine-Systems beiträgt.
Das ist alles, worüber ich im Moment nachdenken kann.Ich hoffe, das hilft dir. :-)
In Anbetracht des Alters der Frage könnte dies anderen Benutzern mehr nützen .. Aber Sie sollten hier notieren: Redmine-Unterprojekte listen keine Eltern in ihren URIs auf, sie benutzen jeweils einfach 'server: port//projects/ 'für direkten Zugriff auf Projektseite. Ich glaube, das gilt sowohl für das Web-UI als auch für das REST-konforme Back-End. –
ZaLiTHkA