??用戶故事自最早1998年誕生以來，由于其突出的優點，到現在得到了廣泛的應用。一般而言，用戶故事里面的用戶是人類用戶，用戶故事在表達人類用戶與系統的交互方面已經證明了其有效性。

??那么當處理系統之間交互時，我們能不能參照用戶故事來說明系統交互的需求？ 讓系統來講講故事？
這樣的故事不妨稱之為系統故事。
微博上有朋友形象的說這是瓦力和伊娃之間的故事。

在另外一篇文章中已經分析了用戶故事的新擴展，見此鏈接，答案是肯定的。本文具體來說明系統故事。

??下面是按照故事經典句型給出的2個例子。
* 作為ATM系統，我要發送客戶卡號給銀行中央系統，這樣可以獲得客戶的余額。
* 作為ATM系統，我要把客戶取款成功的信息送給銀行中央系統，這樣可以記賬

什么情況下需要識別系統故事？

??最典型的情況是兩個系統分屬不同部門或者團隊在開發維護。采用故事的表達方式有利于跨部門或者團隊來快速溝通。

??另外的情況是不同組件（或者叫子系統）之間的交互。利用系統故事來更清晰的說明，某種程度而言，這算屬于設計的范疇。當然，這是為了讓編程者更快的工作，屬于什么范疇并不重要。

誰來識別系統故事？

?? 對于用戶故事，一般是PO或者PO的助手來識別用戶故事。而對于系統故事，也是相同道理，對于擔當中間系統的PO來說，可以假設PO是知道系統之間業務意義上的交互的，了解系統交互是應當的。 當然了解系統交互的其他工程師同樣可以擔當系統故事的識別。而如果系統多數交互是與人類用戶交互，而只有少數是與后臺系統交互，那么PO可能并不了解與后臺的交互，那么應當有其他了解后臺交互的工程師來協助。

如何識別系統故事？

??從系統交互中識別系統故事，提議將有業務意義的最少交互可以識別為一個系統故事。
比如：
* 兩個系統的時鐘同步只是技術意義上的交互，不是系統故事
* 但凡傳遞業務信息，那么屬于系統故事，比如ATM機向銀行中央系統提交銀行卡卡號和密碼來簽權

在這么多表示系統交互的圖形中，推薦使用泳道圖來繪制交互，在穿越泳道的地方來識別系統故事。

試圖利用Wiki的表格來繪制泳道圖，由于無法繪制箭頭，活動順序是在表格中從左到右，再從上到下。
分析對象是ATM機，大場景是取款。

儲戶ATM銀行中央系統銀聯系統

插卡登錄	登錄儲戶卡	校驗用戶身份，如果非本行用戶，提交銀聯校驗	校驗用戶身份
	顯示登錄成功歡迎頁
取款	核對儲戶余額	[[查詢用戶余額]]，如果非本行用戶，提交銀聯校驗	用戶余額
	吐錢
獲得現鈔	校驗取款結果	記賬，非本行用戶，提交銀聯記賬	記賬

銀聯系統放在上表中只為擴充理解。

系統故事有哪些好處？

• 以故事形態進入的Backlog，與其它形態故事放在一起，可視化效果好
• 容易讓編程者理解，方便配套驗收條件和自動化測試
• 以故事的方式來進行接口設計，幫助進行架構演進

系統故事識別的優先級？

?? 如果能夠識別覆蓋系統故事的用戶故事，并且該用戶故事也方便進入迭代處理，那么優先識別用戶故事，不必識別系統故事。
?? 雖然站在編程者角度的賦能故事（enabler story）也能表達系統故事的內容，但是系統故事的識別優先級高于賦能故事，因為系統故事對比賦能故事有更好的表現力，系統故事本身著眼于描述系統行為。
在用戶故事、系統故事和賦能故事中，賦能故事的識別優先級最低，因為賦能故事描述的是賦能者（包括編程者、測試者）的行為，靈活多變，并不是描述系統的行為。

而一旦識別了系統故事，那么實現系統故事的編程者行為就不必再識別為賦能故事。

這與用戶故事是一樣的道理，沒有必要把實現用戶故事的行為作為賦能故事另外再識別出來。

如何描述系統故事？

?? 如同用戶故事一樣，采用講故事的方式來描述系統故事。 如下推薦一種參考自用例規約的寫法。
??首先給系統故事起標題，由于考慮到直觀顯示到看板，因此要盡量縮短標題，又能保持意思。
??其次概述這個故事，推薦采用故事描述經典句型：作為XX角色，我要做XXXXX，這樣可以XXXXXX
??故事主體采用情景描述方法，先描述成功情景，也有基本流、主成功場景等另外的說法，再補充描述異常/失敗情景，也有異常流、擴展場景等另外的說法。
??最后說明驗收條件，設定類內容可以寫在驗收條件里面。由于以上的情景描述本身就是驗收要點，因此有時候驗收條件可以不用寫。 比如如下例子中的條件如果已經寫在了總體驗收條件中，那么沒有必要在故事內再重復說明。

如果有必要可以添加其它說明。

如下是示例：

標題：ATM查詢客戶人民幣余額
概述：作為ATM系統，我要發送客戶卡號給銀行中央系統，這樣可以獲得客戶的人民幣余額。
成功情景：
1. ATM發送客戶卡號到銀行中央系統
2. 銀行中央系統返回該卡的人民幣余額

異常情景：
* 2a 無法鏈接到銀行中央系統
* 2b 該卡不在可處理范圍之內
* 2c 該卡已經被凍結
* 2d 該卡余額超出可處理范圍

驗收條件：
1. 響應時間小于10秒
2. 銀行卡可處理范圍是中國銀聯支持的銀行卡
3. ATM可處理余額最大范圍是99999999元

為系統故事添加測試

??根據系統故事的描述，配套編寫相應的自動化測試。成功情景與異常情景幾乎與測試用例等價類劃分直接對應，從中設計測試用例相對容易。

小結

• 采用講故事的方式來說明系統之間交互是完全可行的，而且容易讓編程者理解，而且也能更好的關聯到需求和業務。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的系统故事 --- 让系统讲故事的全部內容，希望文章能夠幫你解決所遇到的問題。

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