End-to-end stories：鄉民要求篇

Sept. 18 16:53~17:53

幾天前有鄉民留言詢問end-to-end story的意義，其實這個概念是以前在OOAD課程學use case的時候聽到的概念，Teddy在《end-to-end stories：切蛋糕篇》有解釋過一次，不過留言的這位鄉民表示這塊蛋糕他「吞不下去」。既然打比方無法體會，那Teddy就用實際軟體的例子來說明一下好了。請看上圖，這是Teddy在《軟體架構也可逐步成長（3）：往下展開實例》中所使用到的例子，在此簡單說明一下。

這是一個保全監控軟體的例子，當客戶端發生異常時，可以把異常結果傳回監控中心。平常這個監控系統也可以把客戶端的影像或是環境資料（例如溫度、濕度）傳回監控中心。由於客戶端可被監控的類型很多（例如，窗戶是否被打開、溫度是否異常、監視器是否拍到可疑入侵畫面），因此下圖中以Client Type A、B、C、D來表示。不同的Client Type可能連接到後端不同的硬體設備（Device A、B、C、D等，實際受監控的裝置）。

假設鄉民們要幫這個系統寫story（寫需求），有一個需求如下。

使用者必須可以透過瀏覽器看到客戶端的所有受控裝置的及時與歷史狀態。例如，門窗是否有關好、溫度是否正常、紅外線入侵偵測器是否正常。

針對以上需求，如果需求細分寫成這個樣子：

• 看到畫面prototype以及操作流程。
• 把客戶端狀態存到資料庫。
• 把客戶端狀態顯示在畫面上。

上面這些需求的寫法，是屬於片段的寫法，只涵蓋了某個完整使用者可以使用功能的一部分，所以不能稱為end-to-end的需求。如果要寫成end-to-end story，則應該會長成這樣：

• 身為使用者，我可以看到客戶端所有設備的即時資料。這個story如果覺得太大，還可以細切成：
• 我可以看到客戶端門窗開啟狀態的即時資料。
• 我可以看到客戶端溫度的即時資料。
• 我可以看到客戶端紅外線入侵設備的即時資料。
• 身為使用者，我可以看到客戶端所有設備的30天歷史資料。
• 身為使用者，我可以看到客戶端所有設備的一年歷史資料。

寫完之後的end-to-end story會比較像下圖這樣子，每一個story涵蓋使用者可以操作的一個功能。這個功能可以不是100%的完整，例如使用者觀看所有設備即時資料的這個需求，如果無法在一個sprint裡面完成，則可以細切成多個小一點的story。但是這每一個細切的story也都是end-to-end story，個別來看都是對使用者有價值的story。

***

報告完畢，Teddy要準備去上課了。

***

友藏內心獨白：是不是應該考慮請個家教呢？XD。