2016.9.12, 深圳, Ken Fang

特性負責人, 說服開發與測試人員, 能認同微服務中的 User Story 的價值, 並使開發與測試人員能從產品外部的視角, 清楚的明白: 外部使用者、系統、裝置或事件所期望的微服務中的 User Story 完成的定義或標準為何後…

I.       開發人員與測試人員便必需協作, 藉由 “Story 場景樹”, 針對微服務中的每個 User Stories, 共同的完成:

         1. 從產品外部的視角, 分析出 User Story 最佳的易用性業務流活動步驟。

         2. 分析出 User Story 每個業務流的活動步驟, 對外依賴的介面, 資料庫或埠。

         3. 分析出 User Story 每個業務流活動步驟完成後, 其所產出的實體。

         4. 設計出關鍵的緯度, 經由這些關鍵的緯度, 便能校驗出 User Story 每個業務流活動步驟完成後, 其所產出的實體是正確、不正確、合法或不合法。

         5. 由步驟三, 所設計出的關鍵的緯度, 設計出 User Story 每個業務流活動步驟的表格式測試用例; 經由此表格式測試用例, 便可定義出: User Story 每個業務流活動步驟, 其 “開發完成” 的定義。

II.      開發人員, 架構師, UX工程師與 Product Owner, 也必需協作, 藉由 “Story 場景樹”, 針對微服務中的每個 User Stories, 共同的完成下列的設計:

         1. User Story 是屬於哪一個版本的微服務? 或是屬於新產生的微服務?

         2. User Story 將開發在那個模組? 那個類或檔案內?

         3. User Story 所需的資料表結構。

         4. User Story 所需的使用者介面。

更重要的是: Product Owner 可藉由 “Story 場景樹”, 確認開發人員已清楚的知道:

1. User Story 開發完成的定義為何?

2. User Story 該如何進行開發者測試?

3. User Story 最佳易用性的行為為何?

Product Owner 應堅持: 確認開發人員能經由 “Story 場景樹”, 清楚的知道, 上述的三件事後, 才允許開發人員, 進行開發 User Story。

因為, 唯有如此, 才能確保微服務交付時的質量與易用性。

假如，某個開發人員沒辦法清楚且具體的定義出，自己所負責開發的 Story，什麼是完成？那可以預見的是，這個開發人員，便只是會在我們微服務的產品中，不斷的製造問題單罷了…