我應該如何在Bugzilla中實現用戶故事？

Question

我的工作中有幾個人聚集在一起形成一個團隊，其目標是分析實施一些敏捷軟件開發/項目管理原則的好處。

作爲一名開發人員，我在用戶故事中看到了很大的好處。我們正在尋找一種信息散熱器，可用於監測當前版本的各個階段並規劃未來版本。我想爲這個過程使用用戶故事。

現在，我們使用Bugzilla進行問題跟蹤。大多數發佈計劃是使用此係統中的錯誤完成的。 Bugzilla的使用可能不會改變。它以合適的成本（$ 0）提供我們所需的大部分。

一個問題是用戶故事到錯誤的映射。發佈管理目前使用bug數量完成。問題是一個用戶故事可能包含三個錯誤，反之亦然。

在單個用戶故事中存在多個報告錯誤的情況下，有一個想法是有一個用戶故事錯誤，說明故事並設置構成故事的子錯誤的依賴關係。我擔心這可能最終會變得太複雜，並在利益相關者，開發和QA之間造成混亂。另外，它會讓Bugzilla變得相當混亂。

有沒有人已經走過這條路？如果是這樣，你做了什麼？我應該推動放棄Bugzilla中的用戶故事的想法嗎？有一個更簡單的解決方案嗎？

任何想法將不勝感激。

Answer 1

我以前在Bugzilla做過類似的事情，我發現的解決方案並不是實現分層的「故事錯誤」等;我們也決定這會造成混亂，並且對於我們想要的而言太複雜了。我之前使用過的解決方案只是簡單地將用戶故事編號放入錯誤描述中;你也可以在那裏拋出一個鏈接，以便更容易取消引用。這有點拼湊，但它工作得很好。

Answer 2

我會說，如果你的用戶故事需要多個bug的話 - 它們太大了。通過對所需功能的良好抽象，您可以將用戶故事分爲較小的用戶故事，每個故事只需要一個案例，然後按照這種方式進行規劃和執行。

我們試圖使用@McWafflestix描述的方法，將案例鏈接到用戶故事的官方（wiki）文檔，但經過一段時間我們發現，創建更小的用戶故事更好 - 它也會導致一個更好的應用程序設計，因爲每個用戶故事都儘可能抽象地實現，從而提供更好的代碼可測試性和可維護性。

Answer 3

無論是否使用Bugzilla中的依賴關係鏈接進行故事跟蹤，我強烈建議在故事中使用關鍵字。我們使用'故事'。使用關鍵字可以靈活地輕鬆跟蹤故事與產品樹中的錯誤。我還建議在Bugzilla安裝中使用時間跟蹤;即使時間只在故事中被追蹤。