用戶故事自最早1998年誕生以來，由于其突出的優點，到現在得到了廣泛的應用。從最開始的克萊斯勒C3項目，用戶故事當中的用戶一般是指軟件系統的人類用戶，這類用戶故事一般涉及人機交互界面。
而隨著用戶故事在多種場合擴展使用，慢慢衍生出另外兩類故事。本文試圖來整理下新的故事。

新的故事

1，系統故事 System Story
2，賦能故事 Enabler Story，也稱推動者故事，或者使能故事

為什么不用技術故事

技術故事，技術一詞，含義廣泛，因此技術故事有不同的理解。
常見的例子有：

重構某個故事；

非人類的系統擔當交互對象；

建設技術債務觀測工具；

對某關鍵模塊進行架構設計。
幾乎除了用戶故事之外的故事，都曾經被人稱為技術故事，所以技術故事成為了一個含義廣泛的詞語。

系統故事

系統故事是指系統或者組件之間發生的交互。另外一個角度可以理解為非人類用戶故事，與用例分析當中的非人類角色是相當的情況。
對于復雜組合大應用，中間系統往往并不與人類用戶直接交互，往往是與其它系統進行交互。而當前不少組織的分工是安裝系統或者模塊來劃分的，不少組織當中的團隊所處理的系統或者模塊無論位于何處，都有與其它系統或者模塊的交互。這時如果不能快速的重組團隊，也就是團隊所負責的范圍沒有變化的話，那么系統故事就是無奈的、必需的選擇。
一般的，系統故事所描述的仍然是系統的功能，當然有些情況下深入到系統內部的組件級別，這時描述的是系統內部的功能。

賦能故事

賦能故事，不是用來描述系統功能的，而是用來建設更好的開發測試方法、環境、架構、基礎設施等等。
其小類有：

• 改進故事
• 環境建設故事
• 測試準備故事
• 設計架構故事
• 其它

識別多種類型故事的原因

有不少人認為沒有必要識別其它類型故事，因為其它事務可以以任務的形態進入到迭代計劃。
那么原因就是在迭代計劃當中，主要有如下2點：

從思考的角度講，用戶故事和任務是兩個層次的事物，對于不同層次的事物對于工作量和優先級的思考是頗有麻煩的；

在電子工具使用的情況下，對于不同類型的條目難以混排在一起。當前流行的Rally和Jira缺省都是按故事來進入到迭代的backlog。

而識別了多種類型故事后，有如下好處：

開發測試系統本身的事物，以及輔助開發測試的事物，所有團隊需要處理的事物放在相同層面，同場競技，能夠更好的全面考慮各類事物的優先級和安排；

故事點估算可以跨越不同類型事物，通過故事點可能更好的計劃迭代，故事點超越了傳統的用例點、功能點等等的范圍；

絕大多數支持敏捷的電子工具都能管理單一層面的故事優先級排定。

參考

http://www.stephen-smith.co.uk/treat-technical-stories-as-user-stories/
http://ronjeffries.com/xprog/articles/technical-stories-we-dont-need-em/
http://stackoverflow.com/questions/1828057/system-stories-for-agile-architecture

總結

以上是生活随笔為你收集整理的用户故事的扩展-新的故事类别的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。