Stellen Sie sich vor, ich stelle jede Anforderung als eine Funktion auf meinem Bugtracker. Wäre es eine nette Idee? Gibt es bessere Werkzeuge?Würden Sie den Bugtracker verwenden, um die Entwicklung der anfänglichen Anforderungen zu verfolgen?
Ich würde sagen, es ist definitiv eine gute Idee, weil Sie später leicht nachvollziehen können, wie die Anforderungen und Ideen zusammengingen. Sie können auch leicht Ihren Fortschritt, Zeitschätzungen, verbrachte Zeit usw. verfolgen.
Das ist es, was ich und viele andere tun. Fügen Sie die Spezifikationen als Fehler hinzu und beheben Sie die Fehler, wenn sie vollständig sind.
Es ist eine großartige Möglichkeit, die relative Priorität der Fehlerbeseitigung gegenüber dem Hinzufügen neuer Funktionen zu bewerten. In gewisser Weise hat ein leeres Projekt viele Bugs, weil es nicht irgendetwas tut!
Bugtracking ist alles über das Schließen von Einträgen. Beim Produkt-/Anforderungsmanagement geht es darum, sie am Leben zu erhalten.
BTW - einige Bug-Tracking-Systeme unterstützen Anforderungsmanagement, aber das ist nicht das Gleiche.
Im Allgemeinen denke ich, dass die Verwendung eines Tracking-Systems wie dieses für die Verwaltung eines Projekts sehr gut funktioniert.
Der wichtige Teil ist, dass Sie umsetzbare Elemente in Ihre Datenbank einfügen möchten - nur die Anforderungen auflisten wird nicht helfen, wenn diese Anforderung nicht direkt in den Code/High-Level-Design übersetzt werden, die Sie implementiert werden möchten. Für eine Anforderung könnte ich also ein Problem eingeben, um die Anforderung in Features zu zerlegen und neue Datensätze zur Implementierung der Features zu erzeugen.
Wir tun dies - Wir übertragen die Work Breakdown Structure (WBS) entwickelt aus der in den Bug-Tracker. Wir sind dann in der Lage, den Fortschritt einzelner Arbeitsschritte zu verfolgen/zu überwachen. Der Nachteil ist, dass Sie potentiell die Anforderungsdefinitionen an zwei Stellen haben, aber für ein kleines Team wie unseres war es kein Problem.
Wir haben einmal versucht, nur Bug-Tracker zu verfolgen, aber wir fanden es schwierig, das komplette Dokument wiederherzustellen, wenn wir es externen Benutzern und nicht-technischen Benutzern übergeben mussten.
Nur für diejenigen, die nicht wissen: WBS ist http: // en.wikipedia.org/wiki/Work_breakdown_structure und MRD ist http://en.wikipedia.org/wiki/Marketing_Requirements_Document –
yeah. mein Fehler. Ich werde aktualisieren und beheben. – MikeJ
Es hängt davon ab, wie komplex Ihre Anforderungen für das Verfolgen von Anforderungen wahrscheinlich sind. Ein vollständiges System zur Nachverfolgung von Anforderungen unterstützt Unteranforderungen auf vielen Ebenen und die mögliche Integration mit anderen Projektmanagement-Tools. Wenn das Projekt einfach ist und Ihre Bedürfnisse weniger komplex sind, könnten Sie stattdessen einfach einen Bug Tracker verwenden.
Bug Tracker ist für Defekte, einschließlich Dokumenten. Das Tracking von Defekten in Ihren Anforderungsdokumenten ist genauso wichtig, wenn nicht sogar wichtiger für das Tracking von Defekten in der Software. Je früher Sie die Mängel finden, desto billiger ist es.
Für erste funktionale Anforderungen, würde ich nur einen separaten Tracker wie eine Einkaufsliste generieren. Wenn sie in der Liste enthalten sind, markieren Sie das Element.
Ich entschuldige mich für die erste Soapbox, aber eine Menge Leute vergessen Dokumente können auch Defekte haben, nicht nur Software.
Sie könnten es als Issue-Management sehen, in denen Sie diejenigen in (Defekte, neue Funktionen, Verbesserungen, Aufgaben, etc) trennt. All diese Dinge enden schließlich in einem Produkt mit einer bestimmten Version. Die Idee ist also trotzdem gut! (Auch Sie können dann die Neuentwicklung mit der Issue-ID festschreiben) – Verhagen
Wenn Sie das tun, wird das Erstellen der Release-Notes auch einfach. – Verhagen