譯者：無敵哥
原文地址: https://www.tasktop.com/blog/what-flows-through-a-software-value-stream/ 本文翻譯僅供學習交流之用。
原文作者 Mik Kersten 出版了《Project to Product》
本系列共四篇文章，分別是
在本系列文章中，我探討了我們如何需要將同樣的嚴格性引入到軟件交付價值流的設計中，正如我們在先進的製造工廠所看到的那樣。一旦我們就流動的內容達成一致，我們就可以分析這些流動，以確定瓶頸和消除它們的機會。然而，每當我問一個高管級別的 IT 領導，他或她的瓶頸在哪裡，我都會得到一個空洞的凝視或一個模糊的答案，儘管在其他方面來說，他們都是非常有能力的人。
要在生產系統中尋找瓶頸，首先我們必須瞭解流經該系統的內容。我們已經看到了許多軟件交付流的度量，包括代碼行(LOC)、功能點、工作項、故事點、部署和發佈。每個度量都從不同的角度捕獲了價值流的概念，但是每個度量都有其侷限性，特別是當您考慮端到端業務價值流時。
以我與 IT 領導人的交談經驗來說，從商業角度來看，我們對於什麼流經軟件價值流這個核心問題沒有足夠的共識。然而，如果我們要將精益原則應用於軟件交付，這應該是需要回答的最基本的問題。
這種缺乏一致意見的情況意味著，絕大多數企業 IT 組織沒有一個定義良好的生產力度量標準來衡量軟件生產過程中的流程。相比之下，汽車行業生產的汽車數量是衡量汽車價值流的一個明確指標。
另一個衡量標準是生命週期利潤，這是 Donald Reinertsen 在他的開創性著作《The Principles of Product Development Flow》中提出的。諸如 LOC 和每天部署的數量之類的度量屬於這一類，因為它們是交付給軟件消費者的價值的代表物，而不是該價值的直接表示。例如，一行代碼的更改所產生的價值沒準相當於1,000行代碼的更改。但是，如果沒有一個明確的協議，什麼是流動的，什麼是生產單位，我們就遠遠沒有實現任何像Reinertsen建議的生命週期利潤衡量。
商業領袖看到生產力時就知道它的價值，例如，通過能讓市場買單的產品，或者通過比其他產品更快獲得收入的產品。但是，將開發活動與這些結果聯繫起來更像是一種不透明的藝術，而不是一種有紀律的活動。要在價值流中定義生產力，以及瓶頸在哪裡，我們必須首先定義流動的是什麼。
四大流動工作項
為了定義流，我們可以回到精益思維的第一原則，這些原則推動了大規模生產的改進。精益思維首先考慮的不是我們生產什麼，而是客戶拉動的價值。如果我們回想一下早期的軟件時代，公司把安裝 CD 放在包裝盒裡，我們可以試著把它比作汽車生產，定義軟件生產的是盒子，或許也可以把這個比喻延伸到當前DevOps 世界裡的發佈。但是這樣的類比，在現在來看是站不住腳的，在雲計算和軟件即服務的時代，這種類比變得更加無關緊要，因為發佈是如此頻繁和自動化，以至於用戶都看不到它們。如果不是消費者拉動發佈，他們拉動的是什麼樣的價值單元？
要拉動價值，客戶必須能夠看到這種價值，並願意為它交換東西。他們可以交換金錢或者時間。譬如社交媒體工具，一些間接的和基於廣告的盈利產品，他們可以交換使用產品的時間。想想上一次你從一個產品中獲得新的價值，或者重新使用一個你已經有一段時間沒有使用的產品是什麼時候。是什麼引發了你們在時間和金錢上的價值交換？很有可能這是一個新的特性，它滿足了你的需求或者在某種程度上讓你感到高興。或者，它可能是一個缺陷的修復，在價值交互發生之前，阻止了你繼續使用這個產品。這就是定義什麼流經軟件價值流的關鍵所在。如果客戶所需要的是新特性和缺陷修復，那麼這些必須成為流程的一部分。
如果我們將特性增加和缺陷修復作為生產單元，也就是流中的工作項，那麼我們就可以將價值流中所有人員和團隊的工作描述，應用於其中一個單元。如果對組織中的每一個過程和工具都有充分的瞭解，我們就可以確定有多少設計師、開發人員、管理人員、測試人員和Helpdesk專員參與了特定功能的創建、部署和支持。對於缺陷修復也是一樣的。但這是價值流中唯一的工作嗎？
在對308個工具鏈的分析中，我和我的同事們發現了另外兩種工作，這兩種工作對於用戶來說是不可見的，並且是由不同類型的利益相關者在價值流中拉動的。這包括必須由業務分析人員定義的安全性、規範性和合規性工作，這些工作安排在備份日誌開發、實現、測試、部署和維護中。這些工作與特性和缺陷競爭優先權。它不會被客戶拉走，因為通常等到客戶發現的時候已經太晚了。例如，一次安全事故會導致一系列安全缺陷得到修復，並增加了安全特性，但已經發生了。這項工作是由組織內部牽引的，如由首席風險官及其團隊牽引。
我們觀察到的第四類工作是減少技術債務。技術債務的概念是由 Ward cunningham 提出的，它描述了對軟件和基礎設施代碼庫進行修繕工作的必要性，如果不這樣做，將導致今後修改或維護該代碼的能力下降。例如，對特性交付的關注可能導致大量的技術債務積累；在沒有足夠自動化的情況下擴展操作環境可能會導致基礎設施債務。如果不努力減少這些債務，它可能會阻礙未來功能交付能力-----例如，使軟件架構過於複雜以至於無法進行創新。這項工作往往是由軟件架構師完成的。
表1總結了四個流程項目
在分析308個工具鏈時，我們發現了大量不同類型的工作項，這些工作項被定義為敏捷工具、軟件生命週期管理工具或 DevOps 工具，每個都對應著一些交付工作。一些組織使用了詳細的敏捷分類法。Scaled Agile Framework (SAFe)提供了一種這樣的分類方法，可以對流經價值流的工作類型進行細緻的區分。其他組織使用更多的臨時方法，創建自己的工作項目分類，如需求和缺陷。在某些情況下，這些方法導致了幾十種缺陷類型。
無論採用何種方法，當我們通過客戶拉動的視角來看待時，我們都可以將所有類型的工作劃分為表1中的四個流動項。這些流程項遵循 MECE 原則（金字塔原理）: 它們是相互排斥的，完全詳盡的。換句話說，所有流過軟件價值流的工作項都是這些工作項中的一個，而且只能是一個。
軟件交付的其他視角
軟件交付工作的其他特徵也存在，例如 Philippe Kruchten 和他的同事們的“積極 / 消極”與“可見 / 不可見”的四象限(見圖1)和《 DevOps實施手冊》中描述的特性。這種特性描述對於識別開發工作的類型很有用。例如，ITIL (信息技術基礎設施庫)流程定義了問題、事件和變更之間的重要區別。
圖1. Philippe Kruchten 和他的同事們對改進軟件相關任務的描述
不過，這些描述是從流動工作項向下的一層，因為它們更具有交付特性，而不是客戶和價值流特性。因此，我們相信它們對於描述流動工作項交付過程中正在處理的工件類型更加有用。例如，在SAFe中，架構工作的術語是使能（Enabler）。這項工作可以用於支持新特性、修復缺陷、減少技術債務或通過提供支持合規性所需的基礎結構來解決風險。我們已經觀察到我所描述的幾類流動工作項，在這樣的體系結構中在流動。
從客戶和業務利益相關者的角度來看，雖然流動工作項之下的那一層是至關重要的，但是流動工作項的交付決定了某些東西是否通過價值流。這是如何實現的，是否是通過添加新的 API還是僅僅通過向 UI 添加附加內容來實現的，都只是這個高層級視角的一個實現細節。
我們將繼續分析給到我們的每個工具鏈，以確定是否存在其他頂級工作項類型。但到目前為止，我們分析的所有工作項類型都可以映射到這四類流動工作項。我們相信它們是分析軟件價值流的一個有用的抽象，通過這些流動工作項提供的透鏡來研究軟件交付，可以產生有趣的結果。因為這些流動工作項提供了一個不同的、更加以業務和客戶為中心的視角來看待軟件價值流中的流，我們希望它們能夠引發進一步的辯論和討論，並幫助我們建立一個基於交付給客戶的價值而不是已完成工作的虛假的生產力模型。
想要了解更多關於工作是如何在你的軟件價值流中流動的信息，可以深入學習《 Project to Product 》。
注：本文的一個版本最初發表在2018年7月出版的 IEEE 軟件: m. Kersten，“什麼流經軟件價值流，” IEEE 軟件，卷。35，no. 4，pp. 8-11,2018 IEEE doi: 10.1109 / ms 2018.2801538-Original article
這是一系列來自於Mik的博客，這些核心內容可以認為是 《Project To Product》的起源。對Mik來說，從項目到產品，是一個20年的旅程，開始於作為一個開源開發者的十年學習，並將這些學習應用到他過去十年與 不同行業IT 領導者的合作中。這些帖子代表了他一路上最有趣的學習和合作歷程。這些文章最初發表在 IEEE 軟件雜誌的“ On DevOps”專欄中，目標讀者是對軟件體系結構進化感興趣的讀者。
我們會持續放出 Mik Kersten 先生（https://www.tasktop.com/blog/author/mik-kersten/）的若干專欄文章。您如果想了解如何在規模化敏捷維度如何提升研發效能，如何實現從項目到產品的轉化，也可以同步學習規模化敏捷SAFe框架。（＋“CH050791”回“safe”）
Mik先生在2019年10月末的SAFe Summit曾做過一次演講，《Keynote Project to Product From Flow Metrics to SAFe》，專門講述了規模化敏捷SAFe如何通過打造企業的“第二個操作系統”（即你的新價值流網絡）。
