微服務架構設計 第五步: 微服務的 User Stories 的拆分與澄清
2016.9.11, 深圳, Ken Fang
特性負責人與架構師, 開發骨幹人員, 測試經理, 資深測試人員, 經由協作, 完成了:
1. 微服務邊界上下文 (Bounded Context) 的界定。
2. 微服務架構設計; 架構方案的選定。
3. 微服務架構上的依賴分析。
所以, 接下來特性負責人便可:
1. 將微服務內部的業務場景切片, 依場景或功能點, 拆分成一個或多個 User Stories。
2. 將微服務會與其他微服務產生互動的場景, 拆分成一個或多個 User Stories。
特性負責人, 需針對每一個 User Stories, 提供以下的資訊給開發人員與測試人員:
1. 會與 User Story 直接產生互動的外部使用者、系統、裝置或事件。
2. 外部使用者、系統、裝置或事件, 和 User Story 直接產生互動的目的。
3. 外部使用者、系統、裝置或事件, 和 User Story 直接產生互動的主要場景。
4. User Story 完成標準 (驗收條件):
a. 使用性: 外部使用者、系統、裝置或事件是經由何種方式; 瀏覽器, 手機, 介面, 埠或某事件型別; 與 User Story 直接產生互動。
b. 效能
c. 可靠性
d. 安全性
在微服務產品級敏捷中, 特性負責人, 不應只是傳遞微服務的需求, 而應該是要能說服開發與測試人員, 能認同 User Story 的價值
對於沒被我們說服的這些開發、測試人員,我們怎能相信這些開發、測試人員,能為我們產出高質量的微服務?假如,我們自己都不把說服開發、測試人員,這麼重要的事,當成是一回事,那隻能再度的證明:我們自己也都是抱著一種做事的心態;只要開發、測試人員聽我的命令在做事就行了。做產品和做事最大的差別,不在於做事的內容,而在於心態與文化;一種懂得尊重他人,說服他人能交心,又能嚴守原則與是非的心態與文化。
產品的特性負責人,對於自己所負責的特性,都無法從外部的視角,明確且清楚的定義出,什麼是微服務開發完成的條件時,這樣的特性負責人,除了只會使團隊交付永