2017.3.4, 深圳, Ken Fang
前言:
產品開發最危險的一件事便是: 開發人員往往是在無知的情況下, 寫代碼。
產品開發最不可思議的一件事便是: 開發人員開發汽車; 測試人員測試飛機 。
產品開發最悲催的一件事便是: 天天熬夜加班, 最終發佈的版本, 卻對客戶、對用戶, 產生不了任何正面的影響。
產品開發中最鬱悶的一件事便是: 來了團隊兩、三年, 還是沒法成爲能獨當一面的大牛。
產品級敏捷經由團隊的高度協作與自主, 建立起一講求個人價值與責任, 逐步的形成一高效的產品開發生態系統。 在這生態系統中, 團隊成員不僅能高效的完成版本開發, 更重要的是能發揮 “集體的智慧” 做出最佳的決策◦ 而使每一輪版本的發佈, 都能以最少的產出, 卻能對客戶、對使用者, 產生最大的影響。
本文:
產品級敏捷是我在 2014年所獨立創建的; 是當今在業界唯一能將精益敏捷開發與軟件工程, 無縫結合的端到端的產品開發模式。
產品級敏捷:
有著精益敏捷開發的輕量級、可視化、即時發現問題等的特點。
也有著軟件工程的系統化與規範化。
更重要且獨特的是, 產品級敏捷中的各核心工程實踐, 均可根據團隊所要開發的需求 (特性) 的不同, 而可任意的 “組合” 成團隊所需的工程實踐; 使得團隊可真正的擁有適合自身的產品開發的工程實踐與工作模式, 使得團隊不僅是能高效的開發產品, 更能保證產品發佈的質量; 對客戶、對使用者, 產生最大的影響。
產品級敏捷共有五大核心工程實踐:
Slice Board (切片板) : 使得每一輪版本的發佈, 都能以最少的產出, 卻能對客戶產生最大的影響。
Architecture Map (架構地圖): 輕量級的設計每一輪版本的架構設計, 並識別每一輪版本在架構上的風險。
Story Wall (故事牆): 使得開發人員與測試人員, 認同 User Story 的價值, 並從產品外部的視角, 清楚的明白: User Story完成的定義或標準爲何?
Scenario Tree (場景樹): 輕量級且可視化的Story的設計與定義完成。
Feature API (特性API): 從外部的視角, 使得特性對外所提供的 API, 均能代表ㄧ有價值的 “業務概念”。
I. Slice Board (切片板):
任何的產品; 不論是與使用者會直接發生互動的應用系統, 或是提供給衆多產品使用的平臺; 都應該要先有一個完整的產品特性樹。
產品特性樹將使得我們可以很清楚的知道, 從外部使用者或外部產品的視角, 產品的架構, 最終應提供哪些有價值的服務?
而團隊中針對產品特性樹中的每一個特性, 都應該要有一個主要的特性負責人; 每一個特性都會有一個主要的特性負責人負責, 每一個特性負責人, 都將負責多個特性。
在產品級敏捷中, 特性負責人的主要責任便是: 經由與團隊中各不同領域的成員; 架構師, 開發骨幹人員, 測試經理, 資深測試人員; 共同具體分析出每個特性的業務場景。
特性負責人與團隊成員協作, 分析每個特性業務場景的主要步驟如下:
步驟-1: 特性負責人, 分析特性是由哪些業務活動所構成的?
步驟-2: 特性負責人, 針對特性中的某個業務活動, 分析出此業務活動的基本流。
步驟-3: 團隊成員, 以特性負責人所分析出的基本流爲基礎, 分析出相關的 擴展流與異常流。
步驟-4: 特性負責人, 決定團隊成員所分析出的擴展流與異常流, 哪些是需在這個版本中, 置入到產品的架構中, 來進行開發的。
步驟-5: 特性負責人, 再選取特性中的其他業務活動, 並重復步驟二至步驟五。直到特性中的所有業務活動均已分析完畢爲止。
當特性負責人, 將特性的所有業務活動均分析出, 其各自的基本流, 擴展流與異常流之後, 特性負責人便可經由組合基本流, 擴展流與異常流, 而分析出從外部使用者或外部產品的視角, 有價值的端到端的業務場景切片。
特性負責人經由與團隊成員的協作:
團隊成員, 分析出擴展流與異常流; 團隊成員作加法。
特性負責人, 從團隊成員所分析出擴展流與異常流中, 刪除不需要置
入產品的架構中, 去進行開發的擴展流與異常流; 特性負責人作減
法。
團隊成員作加法, 特性負責人作減法; 此種團隊協作的方式, 不僅使團隊成員間, 能對需開發的特性場景 (需求), 迅速的達成一致的共識, 並且能使得每個特性, 都能以最少的場景 (需求), 卻能對外部使用者或外部產品, 產生最大的正面影響。
[圖一：Slice Board使得特性負責人與團隊成員協作; 分析對客戶、對使用者能產生最大正面影響的業務場景切片]
II. Architecture Map (架構地圖):
當特性負責人與架構師, 開發骨幹人員, 測試經理, 資深測試人員協作, 而可分析出特性下的所有業務場景切片時, 特性負責人與架構師, 開發骨幹人員, 測試經理, 資深測試人員應再持續的協作, 根據由分析特性業務場景切片時, 所獲得的知識, 繼續分析出特性在架構上的依賴。
這些架構上的依賴, 包括:
特性依賴產品外部的哪些產品? 設備?
特性依賴外部這些產品或設備的哪些接口? 端口? 數據庫?
特性依賴自身產品內部的哪些子系統?
特性依賴自身產品內部的這些子系統的哪些接口? 數據庫?
當特性負責人與架構師, 開發骨幹人員, 測試經理, 資深測試人員分析出特性在架構上的依賴後, 特性負責人便以 “Architecture Map”, 去承載這些特性在架構上的依賴。
特性負責人與架構師, 開發骨幹人員, 測試經理, 資深測試人員便可根據特性的 Architecture Map 中, 所體現出的各特性在架構上的依賴, 而識別出:
哪些依賴會存在著風險, 而使特性無法進行集成測試?
或者哪些依賴所造成的風險, 會使特性無法進行獨立發佈、獨立部
署?
特性負責人必需與架構師, 開發骨幹人員, 測試經理, 資深測試人員協作, 認真的分析因架構上的依賴, 對特性在執行集成測試或獨立發佈、獨立部署上, 所可能帶來的風險爲何? 並深度的思考, 應該有怎樣的A計劃? B計劃? 才能消除或降低因爲架構上的依賴, 所導致的風險; 這一步真的很關鍵, 往往會決定產品開發的成功或失敗…
[圖二: Architecture Map; Payroll 與 Finance 由不同的團隊開發, 並且Payroll 依賴著 Finance。Payroll 與 HR 是經由數據庫整合; Payroll 與 HR 共用 Employee 數據表。HR 會調用 Recruitment 的 REST API]
III. Story Wall (故事牆):
特性負責人與架構師, 開發骨幹人員, 測試人員, 資深測試人員, 經由協作, 完成了:
1. 特性業務場景切片的分析。
2. 特性架構上的依賴分析。
所以, 接下來特性負責人便可:
將特性內部的業務場景切片, 依場景或功能點, 拆分成一個或多個 User Stories。
將特性會與其他特性產生交互的場景, 拆分成一個或多個 User Stories。
特性負責人, 需針對每一個 User Stories, 提供以下的信息給開發人員與測試人員:
會與 User Story 直接產生交互的外部使用者、系統、設備或事件。
外部使用者、系統、設備或事件, 和 User Story 直接產生交互的目的。
外部使用者、系統、設備或事件, 和 User Story 直接產生交互的主要場景。
User Story 完成標準 (驗收條件):
• 使用性: 外部使用者、系統、設備或事件是經由何種方式; 瀏覽器, 手機, 接口, 端口或某事件類型; 與 User Story 直接產生交互。
• 性能
• 可靠性
• 安全性
在產品級敏捷中, 特性負責人, 不應只是傳遞特性的需求, 而應該是:
要能說服開發與測試人員, 能認同 User Story 的價值。 並使開發與測試人員能從產品外部的視角, 清楚明白: 外部使用者、系統、設備或事件所期望 User Story 完成的定義或標準爲何?
對於沒被我們說服的這些開發、測試人員，我們怎能相信這些開發、測試人員，能爲我們產出高質量的特性？
假如，我們自己都不把說服開發、測試人員，這麼重要的事，當成是一回事，那隻能再度的證明：我們自己也都是抱着一種做事的心態；只要開發、測試人員聽我的命令在做事就行了。
做產品和做事最大的差別，不在於做事的內容，而在於心態與文化；一種懂得尊重他人，說服他人能交心，又能嚴守原則與是非的心態與文化。
產品的特性負責人，對於自己所負責的特性，都無法從外部的視角，明確且清楚的定義出，什麼是特性開發完成的條件時，這樣的特性負責人，除了只會使團隊交付永遠沒有市場競爭力、永遠無法使客戶滿意的產品外，其他什麼事也沒法做…
[圖三: Story Wall]
IV. Scenario Tree (場景樹):
特性負責人, 說服開發與測試人員, 能認同特性中的 User Story 的價值, 並使開發與測試人員能從產品外部的視角, 清楚的明白: 外部使用者、系統、設備或事件所期望的特性中的 User Story 完成的定義或標準爲何後, 開發人員與測試人員便必需協作, 藉由 “Scenario Tree”, 針對特性中的每個 User Stories, 共同的完成:
從產品外部的視角, 分析出 User Story 最佳的易用性業務流活動步驟。
分析出 User Story 每個業務流的活動步驟, 對外依賴的接口, 數據庫或端口。
分析出 User Story 每個業務流活動步驟完成後, 其所產出的實體。
設計出每個實體的關鍵的緯度, 經由這些關鍵的緯度, 便能校驗出 User Story 每個業務流活動步驟完成後, 其所產出的實體是正確、不正確、合法或不合法。
由每個實體的關鍵緯度, 設計出 User Story 每個業務流活動步驟的表格式測試用例; 經由此表格式測試用例, 便可定義出:
• User Story 每個業務流活動步驟, 其 ”開發完成” 的定義。
開發人員, 架構師, UX 工程師與 Product Owner, 也必需協作, 藉由 “Scenario Tree” , 針對特性中的每個 User Stories, 共同的完成下列的設計:
User Story 是屬於哪一個版本的特性? 或是屬於新產生的特性?
User Story 將開發在那個模塊? 那個類或文件內?
User Story 所需的數據表結構。
User Story 所需的使用者介面。
更重要的是: Product Owner 可藉由 “Scenario Tree”, 確認開發人員已清楚的知道:
• User Story 開發完成的定義爲何?
• User Story 該如何進行開發者測試?
• User Story 最佳易用性的行爲爲何?
Product Owner 應堅持:
確認開發人員能經由 “Scenario Tree”, 清楚的知道, 上述的三件事後, 才允許開發人員, 進行 User Story 的開發。
因爲, 唯有如此, 才能確保特性交付時的質量與易用性。
假如，某個開發人員沒辦法清楚且具體的定義出，自己所負責開發的 User Story，什麼是完成？那可以預見的是，這個開發人員，便只是會在我們的產品中，不斷的製造問題單罷了…
[圖四: Scenario Tree: 業務流活動步驟: 獲取客戶租 CD 數據, 將會調用一 REST API, 併產生一實體: 客戶租 CD 數據。驗證實體: 客戶租 CD 數據, 是, 否正確的關鍵緯度是: Customer ID, CD 數, CD ID, Rental Date]
V. Feature API (特性 API)
每個特性依照場景或功能點, 分解成一到多個的 User Stories。每個 User Story 經過開發人員與測試人員的協作, 藉由“Scenario Tree”, 分析出特性中包含哪些“實體” ?
每一個特性中的實體應能只明確代表特性中的某個單一的業務概念; 同樣的, 特性中的某個業務概念應也只能由特性中某個單一的實體所代表。
所以, 在特性中的 Scenario Tree 中, 假如, 識別出有一個以上的實體; 名稱不同, 但這些實體所代表的業務概念, 卻是同一個的業務概念; 則開發人員與測試人員, 便應該將這些代表相同業務概念的實體, 合併爲單一的實體。
當開發人員與測試人員可從特性中的 Scenario Tree 中, 將特性中的實體都能明確的對映到某個單一的業務概念後, 開發人員與測試人員便可輕鬆的從 Scenario Tree 中, 依照實體所對映的活動, 而分析出每個實體對外需提供的方法 (API)。
[圖五: Orders 與 Order Status 雖是不同的實體, 但, 卻代表著同一個業務概念; Orders。所以, 將 實體Orders 與實體 Order Status 合併]
VI. 組合團隊自身所需的核心工程實踐:
團隊往往面對不同類型的需求 (特性) 開發; 只需演示的需求 (特性), 在既有架構上, 需快速交付的需求 (特性), 新的需求 (特性) 的開發…等等。
團隊針對這些不同類型需求 (特性) 的開發, 應該有不同的核心工程實踐的組合。
例如: 只需演示的需求 (特性), 建議: 只需 Slice Board, Story Wall, Scenario Tree 的組合; 便可快速的產出最少的場景, 卻能吸引客戶最多的關注。
[圖六: 產品級敏捷的工程實踐, 可針對不同類型需求 (特性) 的開發, 而可任意的組合]
結論：
產品級敏捷使得市場行銷、產品管理與研發團隊之間, 有了共通的語言, 而
可共同的面向外部的客戶與市場; 以最少的產出, 對客戶產生最大的影響。
更重要的是, 藉由產品級敏捷, 企業將能打造一以人爲本, 內聚力強, 強調協作互助, 完全自主當責的全功能幸福團隊。
產品級敏捷期待著你的參與!
