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 的價值, 並使開發與測試人員能從產品外部的視角, 清楚明白:外部使用者、系統、裝置或事件所期望 User Story 完成的定義或標準為何? 

對於沒被我們說服的這些開發、測試人員,我們怎能相信這些開發、測試人員,能為我們產出高質量的微服務?假如,我們自己都不把說服開發、測試人員,這麼重要的事,當成是一回事,那隻能再度的證明:我們自己也都是抱著一種做事的心態;只要開發、測試人員聽我的命令在做事就行了。做產品和做事最大的差別,不在於做事的內容,而在於心態與文化;一種懂得尊重他人,說服他人能交心,又能嚴守原則與是非的心態與文化。

產品的特性負責人,對於自己所負責的特性,都無法從外部的視角,明確且清楚的定義出,什麼是微服務開發完成的條件時,這樣的特性負責人,除了只會使團隊交付永遠沒有市場競爭力、永遠無法使客戶滿意的產品外,其他什麼事也沒法做…


SaveSaveSaveSaveSaveSaveSaveSave