從領域到價值流 - Nick

價值流
多年來，價值流的概念已被不同社群採納。我相信它起源於 70 年代或 80 年代的精益製造。從那時起，它就被六西格碼、企業/業務架構以及最近的敏捷和 DevOps 社群所採用。
由於價值流應用於不同的環境，它們有不同的風格和不同的服裝。有時最好具體說明您所指的價值流型別。
在本文中，價值流被定義為端到端的業務流程以及組織為交付客戶價值而採取的相關步驟。也可以將其理解為向客戶提供價值（通常是產品或服務）的業務線。對於傳統的以專案為中心的方式中，真正的價值往往被以專案為中心的指標（如按時和按預算）所掩蓋。價值流由長期存在的跨職能團隊組成，而不是圍繞特定專案臨時組織的臨時團隊；由於團隊持續運作，因此他們能夠進行持續改進。
價值流兩種：

• 開發價值流：這些是將想法轉化為新產品和能力增強的價值流。
• 還有運營價值流，它們是向客戶提供產品或服務所需的一系列活動。

授權的產品模式團隊
獲得授權的產品模式團隊負責在特定業務領域中發現和交付價值。他們可能負責產品面向使用者的部分，例如移動應用程式或面向內部的 API。在任何情況下，團隊都必須發現客戶未滿足的需求，並提供產品改進以滿足這些需求。
一個團隊負責的業務領域是一個域。團隊為發現其領域中的潛在價值並以新/改進產品增強的形式交付價值所經歷的步驟就是他們的價值流。
領域和價值流之間的關係是雙向的。在理想的世界中，從空白畫布開始，首先定義每個團隊將負責的域是合乎邏輯的（DDD 可以提供幫助）。
即使建立了領域和價值流，也需要不斷髮展。領域和軟體邊界錯誤的最好跡象之一是價值流中的問題，例如高 WIP 或外部依賴性導致的高等待時間。團隊中的高水平 WIP 表明認知負荷太高——領域可能太大，單個團隊無法擁有並需要拆分。
定期的跨團隊依賴表明不同領域的兩個部分經常一起變化。也許應該更改域邊界，使它們成為同一域的一部分並由單個團隊擁有。