2009-06-08 22 views
10

Einige meiner Mitarbeiter haben sich zu einer Gruppe zusammengefunden, deren Ziel es ist, die Vorteile der Implementierung einiger agiler Softwareentwicklungs-/Projektmanagement-Prinzipien zu analysieren.Wie soll ich User Stories in Bugzilla implementieren?

Als Entwickler sehe ich großen Nutzen in User Stories. Wir suchen nach einem Informationsradiator, der für die Überwachung der Phasen der aktuellen Version und die Planung zukünftiger Releases verwendet werden kann. Ich möchte User Storys für diesen Prozess verwenden.

Momentan verwenden wir Bugzilla zur Problemverfolgung. Die meisten Release-Planungen werden mit Fehlern aus diesem System durchgeführt. Die Verwendung von Bugzilla wird sich wahrscheinlich nicht ändern. Es bietet das meiste von dem, was wir brauchen, zu den richtigen Kosten ($ 0).

Ein Problem ist die Zuordnung von User Storys zu Bugs. Das Versionsmanagement erfolgt derzeit mit Hilfe von Fehlernummern. Das Problem ist, dass eine User Story drei Bugs enthalten könnte oder umgekehrt.

In dem Szenario mit mehreren gemeldeten Fehlern für eine einzelne User Story ist eine Idee, einen User Story Bug zu haben, der die Geschichte buchstabiert und Abhängigkeiten von Kind Bugs festlegt, die diese Geschichte ausmachen. Ich befürchte, dass dies zu komplex sein und Verwirrung zwischen den Beteiligten, der Entwicklung und der Qualitätssicherung schaffen könnte. Außerdem wird es Bugzilla ziemlich durcheinander bringen.

Hat schon jemand diesen Weg genommen? Wenn ja, was hast du getan? Soll ich die Idee von User Stories in Bugzilla aufgeben? Gibt es eine einfachere Lösung?

Alle Gedanken würden geschätzt werden.

Antwort

3

Ich habe ähnliche Sachen vorher in Bugzilla gemacht, und die Lösung, die ich fand, war nicht, hierarchische "Story Bugs" oder ähnliches zu implementieren; Wir haben auch entschieden, dass das Verwirrung stiften würde und einfach zu kompliziert für das war, was wir wollten. Die Lösung, die ich vorher verwendet habe, war einfach die User Story Nummer in die Beschreibung des Fehlers zu schreiben; Sie können dort auch einen Link einfügen, um die Dereferenzierung zu erleichtern. Es ist ein bisschen patchworkish, aber es funktioniert ziemlich gut.

2

Ich würde sagen, dass, wenn Ihre User Stories mehr als einen Bug Case benötigen - sie sind zu groß. Mit einer guten Abstraktion der erforderlichen Funktionalität können Sie Ihre User Stories in kleinere aufteilen, die nur einen Fall pro Story erfordern, und dann planen und fortfahren.

Wir haben versucht, den Ansatz @McWafflestix beschreibt, mit Links aus den Fällen zu den offiziellen (Wiki) Dokument der User Story, aber nach einiger Zeit fanden wir, dass die Schaffung kleiner User Stories ist besser - es führt auch zu ein besseres Anwendungsdesign, da jede User Story so abstrakt wie möglich implementiert wird, was eine bessere Testbarkeit und Wartbarkeit des Codes bietet.

+0

Ich stimme einigermaßen mit Ihrem Punkt überein, aber ich denke, dass das Problem, die User Stories in kleinere User Stories zu zerlegen, die zusätzliche Ebene der Indirection hinzufügt, die ein "User Story Bug" in Bugzilla würde; Es wird nur die Umleitung zum User Stories-Tool anstelle von Bugzilla verschoben. nicht, dass das falsch ist; Es hängt wirklich vom Unternehmen ab, was am besten funktioniert. Aber wenn Sie versuchen, die Komplexität und Tiefe zu minimieren, erkennen Sie, dass dies die Komplexität an anderer Stelle verschiebt. Wie ich schon sagte, nichts falsch daran, wenn das ist, was Ihre Organisation findet, das funktioniert. –

+0

Ja, wie gesagt, der andere Ansatz hat bei uns nicht sehr gut funktioniert, aber für viele ist er immer noch eine gute Lösung. –

+0

Danke für Ihren Rat. Ein Problem, das ich damit sehe, ist ein umgekehrtes Szenario, bei dem ein einzelner Fehler mehrere Geschichten benötigt. Unsere Kunden sind intern. Ein Grund, warum wir Bugzilla verwenden, ist, dass jeder Benutzer einen Bug ohne zusätzliche Lizenzkosten einreichen kann. Wir werden Fälle erhalten, in denen ein von einem Benutzer eingereichter Fehler mehreren Benutzergeschichten zugeordnet wird. Wir könnten einfach mehrere Story-Bugs erstellen und das ursprüngliche Problem schließen, aber dies fügt noch eine Ebene der Komplexität hinzu, die ich vermeiden möchte. –

2

Ob die Verwendung von Abhängigkeitslinks in Bugzilla für das Story-Tracking verwendet wird, ich empfehle dringend, ein Keyword für Ihre Storys zu verwenden. Wir benutzen 'Geschichte'. Die Verwendung eines Schlüsselworts ermöglicht die einfache Verfolgung von Stories und Bugs in Produktbäumen. Ich würde auch die Verwendung der Zeiterfassung in der Bugzilla-Installation empfehlen; auch wenn die Zeit nur auf Geschichten verfolgt wird.