在技術價值流中，工作通常從 Development 流向 Operations，連接業務與客戶。The First Way 要求工作從 Development 到 Operations 的流動必須快速且順暢。我們為全局目標（而非局部目標，如開發完成率、測試發現率或 Ops 可用性指標）進行優化。

我們透過以下方式增加流動：使工作可見化、縮小批次大小、內建品質以防止缺陷傳遞到下游。目標是減少變更部署到生產環境所需的時間，同時提升服務的可靠性與品質。

使工作可見化（Make Our Work Visible）#

技術與製造業價值流之間的一個重大差異在於：我們的工作是不可見的。與實體流程不同，在技術價值流中，我們無法輕易看到流動受阻或工作堆積在受限工作中心前面的情況。

在製造業中，工作站之間的轉移是高度可見的，因為庫存必須被實體搬運。但在技術工作中，轉移只需點擊按鈕（例如將工單重新分配給另一個團隊）。正因如此容易，工作可能因資訊不完整而在團隊之間不斷彈跳，或帶著未被發現的問題傳遞給下游。

為了看清工作流動順暢之處與排隊停滯之處，我們需要使工作盡可能可見。最佳方法之一是使用視覺化工作看板，如 Kanban Board 或 Sprint Planning Board：

  • 工作從左側發起（通常從 backlog 拉取）
  • 從一個工作中心拉動到下一個（以欄位表示）
  • 到達右側完成（標記為「done」或「in production」）

Figure 6: An example kanban board

理想情況下，Kanban Board 應涵蓋整個價值流，工作只有在到達看板右側才算完成。工作不是在 Development 完成功能實作時結束，而是在應用程式成功運行於生產環境、為客戶交付價值時才算完成。

將所有工作中心的工作放入佇列並使其可見，讓所有利害關係人都能在全局目標的脈絡下更容易地排定優先順序，使每個工作中心專注完成最高優先級的工作，提升整體產出。

限制在製品（Limit Work In Process, WIP）#

在製造業中，日常工作由生產排程決定。但在技術工作中，情況動態得多 – 尤其在共享服務中，團隊必須滿足許多不同利害關係人的需求。結果，日常工作被當天的優先事項所主導，緊急請求從各種溝通管道湧入。

製造業中的中斷是高度可見且代價高昂的，這會抑制頻繁中斷。然而，中斷技術工作者卻很容易，因為後果對幾乎所有人都是不可見的，即使對生產力的負面影響可能遠大於製造業。研究顯示，即使是排列幾何圖形這樣的簡單任務，在多工時完成時間也會顯著退化。

我們可以透過在 Kanban Board 上為每一欄或工作中心設定 WIP 限制來限制多工：

  • 例如設定測試欄位的 WIP 限制為 3 張卡片
  • 當該欄位已有 3 張卡片時，除非有卡片完成或被移回，否則不能新增
  • 所有工作必須先以卡片形式呈現，強化「所有工作都必須可見化」的原則

限制 WIP 也讓阻礙工作完成的問題更容易被發現。當我們限制 WIP 後可能發現無事可做，這時正確的做法不是開始新工作，而是找出造成延遲的原因並協助解決。正如 David J. Andersen 所說：「Stop starting. Start finishing.」（停止開始，開始完成。）

縮小批次大小（Reduce Batch Sizes）#

建立平穩且快速流動的另一個關鍵是小批次作業。在 Lean 製造革命之前，以大批次生產是常態，因為切換作業成本高昂。然而，大批次會導致 WIP 暴增、流動變異性增大，最終造成長前置時間與品質低落。

Lean 的關鍵教訓：要縮短前置時間並提升品質，就必須持續縮小批次大小。理論上的下限是 Single-Piece Flow（單件流），即每次只處理一個單元。

信封遊戲模擬#

以寄送十份手冊為例，每份需要四個步驟（摺疊、裝入信封、密封、蓋章）：

  • 大批次策略：先摺好全部十張紙，再全部裝入信封… 第一份完成品要等 310 秒
  • 小批次策略（single-piece flow）：完成一份的全部步驟後再做下一份，第一份完成品只需 40 秒 – 快了八倍

而且若第一步就出錯，小批次策略只需重做一份，大批次策略則需要重做全部。

在技術價值流中的應用#

大批次的負面效果同樣適用於技術價值流。想像年度軟體發布排程：整年的程式碼一次釋出到生產環境部署，會造成突然的高 WIP 與大規模下游中斷，驗證了我們的常見經驗 – 變更越大，生產錯誤越難診斷修復，修復時間越長。

技術價值流中 single-piece flow 的等價物就是 Continuous Deployment（持續部署）：每個提交到版本控制的變更都會被整合、測試並部署到生產環境。

減少交接次數（Reduce the Number of Handoffs）#

當部署前置時間長達數月時，通常是因為有數百甚至數千個操作步驟需要將程式碼從版本控制移到生產環境。每次工作在團隊間傳遞，都需要各種溝通協調：請求、規格化、排程、測試、驗證等。

每次交接都是一個潛在的等待佇列，且每次交接都會不可避免地遺失一些知識。經過足夠多次交接，工作可能完全失去其原始脈絡。

解決方法：

  • 自動化大部分工作，減少交接需求
  • 重組團隊，使其能自主交付價值給客戶，而非不斷依賴其他團隊

持續識別並提升約束（Continually Identify and Elevate Our Constraints）#

要減少前置時間並增加產出，我們需要持續識別系統的約束並改善其工作容量。Dr. Goldratt 在 Beyond the Goal 中指出：「在任何價值流中，始終存在一個方向的流動，而且始終只有一個約束；任何不在該約束上的改善都是幻象。」

Goldratt 的五個聚焦步驟：

  1. 識別系統的約束
  2. 決定如何利用系統的約束
  3. 從屬其他一切於上述決策
  4. 提升系統的約束
  5. 若約束已被打破，回到步驟一，但不要讓慣性成為新的約束

DevOps 轉型中的典型約束演進#

在從數月到數分鐘的部署前置時間演進過程中，約束通常依序出現在：

  • 環境建立：對策是建立隨需、完全自助式的環境
  • 程式碼部署：對策是自動化部署，讓任何開發者都能自助完成
  • 測試設定與執行：對策是自動化測試並平行化執行
  • 過度耦合的架構：對策是建立更鬆耦合的架構，讓變更能安全且自主地進行

當所有這些約束都被打破後，約束將落在 Development 或 Product Owner 身上 – 這正是我們期望的位置。

消除價值流中的困難與浪費（Eliminate Hardships and Waste）#

Shigeo Shingo（Toyota Production System 的先驅之一）認為浪費是企業存續的最大威脅。Lean 中常用的定義是：「超出客戶需求且願意付費之外的任何資源使用。」

在軟體開發中，浪費和困難被定義為任何導致客戶延遲的事物。以下類別來自 Mary 和 Tom Poppendieck 的 Implementing Lean Software Development：

  • Partially done work（半成品）：價值流中未完成的工作，隨時間流逝而過時貶值
  • Extra processes（額外流程）：不為客戶增加價值的額外工作
  • Extra features（額外功能）：組織或客戶不需要的功能（即「鍍金」）
  • Task switching（任務切換）：在多個專案間切換造成的上下文切換成本
  • Waiting（等待）：工作之間的延遲，增加交期並阻止客戶獲得價值
  • Motion（搬運）：在工作中心之間搬移資訊或材料的成本
  • Defects（缺陷）：錯誤、遺漏或不清楚的資訊與產品，缺陷產生與發現之間的時間越長，修復越困難
  • Nonstandard or manual work（非標準或手動工作）：對他人的非標準或手動工作的依賴，理想上應自動化、自助式、隨需可用
  • Heroics（英雄主義）：個人或團隊被迫執行不合理的行為來達成目標

我們的目標是讓這些浪費和困難可見化 – 任何需要英雄主義的地方 – 然後系統性地減輕或消除這些負擔，以實現快速流動的目標。