0 0
Read Time:3 Minute, 33 Second

前言:

產品開發最危險的一件事便是: 開發人員往往是在無知的情況下, 寫代碼。

產品開發最沒效率的一件事便是: 架構師進行笨重的軟體設計, 輸出對開發人員毫無幫助的設計文檔。

產品開發最不可思議的一件事便是: 開發人員開發汽車; 測試人員測試飛機 。

產品開發最悲催的一件事便是: 天天熬夜加班, 最終發布的版本, 卻對客戶、對用戶, 產生不了任何正面的影響。

產品開發中最鬱悶的一件事便是: 來了團隊兩、三年, 還是沒法成為能獨當一面的大牛。

產品級敏捷經由團隊的高度協作與自主, 建立起一講求個人價值與責任, 逐步的形成一高效的產品開發生態系統。在這生態系統中, 團隊成員不僅能高效的完成版本開發, 更重要的是能發揮 「集體的智慧」 做出最佳的決策◦ 而使每一輪版本的發布, 都能以最少的產出, 卻能對客戶、對使用者, 產生最大的影響。

產品級敏捷:

產品級敏捷是我在 2014 年所獨立創建的; 是當今在業界唯一能將精益敏捷開發與軟體工程, 無縫結合的端到端的產品開發模式。

產品級敏捷:

  • 有著精益敏捷開發的輕量級、可視化、即時發現問題等的特點
  • 也有著軟體工程的系統化與規範化
  • 更重要且獨特的是, 產品級敏捷中的各核心工程實踐, 均可根據團隊所要開發的需求 (特性) 的不同, 而可任意的 「組合」 成團隊所需的工程實踐; 使得團隊可真正的擁有適合自身的產品開發的工程實踐與工作模式, 使得團隊不僅是能高效的開發產品, 更能保證產品發布的質量; 對客戶、對使用者, 產生最大的影響

產品級敏捷共有五大核心工程實踐:

  • Slice Board (切片板) : 使得每一輪版本的發布, 都能以最少的產出, 卻能對客戶產生最大的影響
  • Architecture Map (架構地圖): 輕量級的設計每一輪版本的架構設計, 並識別每一輪版本在架構上的風險
  • Story Wall (故事牆): 使得開發人員與測試人員, 認同 User Story 的價值, 並從產品外部的視角, 清楚的明白: User Story 完成的定義或標準為何?
  • Scenario Tree (場景樹): 輕量級且可視化的 Story 的設計與定義完成
  • Feature API (特性API): 從外部的視角, 使得特性對外所提供的 API, 均能代表ㄧ有價值的 “業務概念”

Slice Board (切片板):

任何的產品; 不論是與使用者會直接發生互動的應用系統, 或是提供給眾多產品使用的平台; 都應該要先有一個完整的產品特性樹。

產品特性樹將使得我們可以很清楚的知道, 從外部使用者或外部產品的視角, 產品的架構, 最終應提供哪些有價值的服務?

而團隊中針對產品特性樹中的每一個特性, 都應該要有一個主要的特性負責人; 每一個特性都會有一個主要的特性負責人負責, 每一個特性負責人, 都將負責多個特性。

在產品級敏捷中, 特性負責人的主要責任便是: 經由與團隊中各不同領域的成員; 架構師, 開發骨幹人員, 測試經理, 資深測試人員; 共同具體分析出每個特性的業務場景。

特性負責人與團隊成員協作, 分析每個特性業務場景的主要步驟如下:

步驟-1:     特性負責人, 分析特性是由哪些業務活動所構成的?

步驟-2:     特性負責人, 針對特性中的某個業務活動, 分析出此業務活動的基本流。

步驟-3:    團隊成員, 以特性負責人所分析出的基本流為基礎, 分析出相關的擴展流與異常流。

步驟-4:     特性負責人, 決定團隊成員所分析出的擴展流與異常流, 哪些是需在這個版本中, 置入到產品的架構中, 來進行開發的。

步驟-5:     特性負責人, 再選取特性中的其他業務活動, 並重複步驟二至步驟五。直到特性中的所有業務活動均已分析完畢為止。

當特性負責人, 將特性的所有業務活動均分析出, 其各自的基本流, 擴展流與異常流之後, 特性負責人便可經由組合基本流, 擴展流與異常流, 而分析出從外部使用者或外部產品的視角, 有價值的端到端的業務場景切片。

特性負責人經由與團隊成員的協作:

  • 團隊成員, 分析出擴展流與異常流; 團隊成員作加法。
  • 特性負責人, 從團隊成員所分析出擴展流與異常流中, 刪除不需要置入產品的架構中, 去進行開發的擴展流與異常流; 特性負責人作減法。

團隊成員作加法, 特性負責人作減法; 此種團隊協作的方式, 不僅使團隊成員間, 能對需開發的特性場景 (需求), 迅速的達成一致的共識, 並且能使得每個特性, 都能以最少的場景 (需求), 卻能對外部使用者或外部產品, 產生最大的正面影響。

圖一: Slice Board 使得特性負責人與團隊成員協作; 分析對客戶、對使用者能產生最大正面影響的業務場景切片。

Architecture Map (架構地圖):

當特性負責人與架構師, 開發骨幹人員, 測試經理, 資深測試人員協作, 而可分析出特性下的所有業務場景切片時, 特性負責人與架構師, 開發骨幹人員, 測試經理, 資深測試人員應再持續的協作, 根據由分析特性業務場景切片時, 所獲得的知識, 繼續分析出特性在架構上的依賴。

這些架構上的依賴, 包括:

  • 特性依賴產品外部的哪些產品? 設備?
  • 特性依賴外部這些產品或設備的哪些介面? 埠? 資料庫?
  • 特性依賴自身產品內部的哪些子系統?
  • 特性依賴自身產品內部的這些子系統的哪些介面? 資料庫?

當特性負責人與架構師, 開發骨幹人員, 測試經理, 資深測試人員分析出特性在架構上的依賴後, 特性負責人便以 「Architecture Map」, 去承載這些特性在架構上的依賴。

特性負責人與架構師, 開發骨幹人員, 測試經理, 資深測試人員便可根據特性的 Architecture Map 中, 所體現出的各特性在架構上的依賴, 而識別出:

  • 哪些依賴會存在著風險, 而使特性無法進行集成測試?
  • 或者哪些依賴所造成的風險, 會使特性無法進行獨立發布、獨立部署?

特性負責人必需與架構師, 開發骨幹人員, 測試經理, 資深測試人員協作, 認真的分析因架構上的依賴, 對特性在執行集成測試或獨立發布、獨立部署上, 所可能帶來的風險為何? 並深度的思考, 應該有怎樣的A計劃? B計劃? 才能消除或降低因為架構上的依賴, 所導致的風險; 這一步真的很關鍵, 往往會決定產品開發的成功或失敗…

圖二: Architecture Map: Payroll 與 Finance 由不同的團隊開發, 並且Payroll 依賴著 Finance。Payroll 與 HR 是經由資料庫整合; Payroll 與 HR 共用 Employee 數據表。HR 會調用Recruitment 的 REST API。

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

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

Feature API (特性API):

每個特性依照場景或功能點, 分解成一到多個的 User Stories。每個 User Story 經過開發人員與測試人員的協作, 藉由 「Scenario Tree」, 分析出特性中包含哪些 「實體」 ?

每一個特性中的實體應能只明確代表特性中的某個單一的業務概念; 同樣的, 特性中的某個業務概念應也只能由特性中某個單一的實體所代表。

所以, 在特性中的 Scenario Tree 中, 假如, 識別出有一個以上的實體; 名稱不同, 但這些實體所代表的業務概念, 卻是同一個的業務概念; 則開發人員與測試人員, 便應該將這些代表相同業務概念的實體, 合併為單一的實體。

當開發人員與測試人員可從特性中的 Scenario Tree 中, 將特性中的實體都能明確的對映到某個單一的業務概念後, 開發人員與測試人員便可輕鬆的從 Scenario Tree 中, 依照實體所對映的活動, 而分析出每個實體對外需提供的方法 (API)。

最後, 開發與測試人員再將所有實體對外需提供的方法 (API) 集成, 便成為特性對外需提供的方法 (API)。

圖五: Orders 與 Order Status 雖是不同的實體, 但, 卻代表著同一個業務概念; Orders。所以, 將 實體Orders 與實體 Order Status 合併。

組合團隊自身所需的核心工程實踐:

團隊往往面對不同類型的需求 (特性) 開發; 只需演示的需求 (特性), 在既有架構上, 需快速交付的需求 (特性), 新的需求 (特性) 的開發…等等。

團隊針對這些不同類型需求 (特性) 的開發, 應該有不同的核心工程實踐的組合

例如: 只需演示的需求 (特性), 建議: 只需 Slice Board, Story Wall, Scenario Tree 的組合; 便可快速的產出最少的場景, 卻能吸引客戶最多的關注。

 Slice Board Architecture MapStory WallScenario Tree Feature API
只需演示的需求 (特性)V VV 
在既有架構上, 需快速交付的需求 (特性)VVVV 
新的需求 (特性) 的開發VVVVV

結論:

產品級敏捷使得市場行銷、產品管理與研發團隊之間, 有了共通的語言, 而可共同的面向外部的客戶與市場; 以最少的產出, 對客戶產生最大的影響。

更重要的是, 藉由產品級敏捷, 企業將能打造一以人為本, 內聚力強, 強調協作互助, 完全自主當責的全功能幸福團隊。

產品級敏捷期待著你的參與!

About Post Author

方俊賢; Ken Fang

專利號: 201910652769.4; 一種深度學習的演算法, 預測微服務持續發布、持續部署後對產品整體質量的影響, 獲得國家知識財產局專利; 符合專利法實施細則第 44 條的規定。
Happy
Happy
0 %
Sad
Sad
0 %
Excited
Excited
0 %
Sleepy
Sleepy
0 %
Angry
Angry
0 %
Surprise
Surprise
0 %

Average Rating

5 Star
0%
4 Star
0%
3 Star
0%
2 Star
0%
1 Star
0%

發表評論

您的電子郵箱地址不會被公開。

此站點使用Akismet來減少垃圾評論。了解我們如何處理您的評論數據