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

新的故事

1，系統(tǒng)故事 System Story
2，賦能故事 Enabler Story，也稱推動者故事，或者使能故事

為什么不用技術(shù)故事

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

重構(gòu)某個故事；

非人類的系統(tǒng)擔當交互對象；

建設技術(shù)債務觀測工具；

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

系統(tǒng)故事

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

賦能故事

賦能故事，不是用來描述系統(tǒng)功能的，而是用來建設更好的開發(fā)測試方法、環(huán)境、架構(gòu)、基礎設施等等。
其小類有：

• 改進故事
• 環(huán)境建設故事
• 測試準備故事
• 設計架構(gòu)故事
• 其它

識別多種類型故事的原因

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

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

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

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

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

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

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

參考

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。