第3章
SAFe原則
3.1 原則＃ 1——采取經濟視角
你可能會忽略經濟，但經濟不會忽略你。
—— Donald Reinertsen，《産品開發流的原則》
摘要
精益的目标是在最短的可持續前置時間内，為人類和社會提供最佳的品質和最優的價值。為了實作這個目标，需要對經濟效益有基本的了解。如果沒有這樣的認識，即使是一個技術成熟的系統也可能需要很高的研發成本、很長的傳遞時間，或者由于生産和營運成本太高以至于無法在經濟上支援有效的價值。
為此，整個産業鍊中的上司者、管理層和知識工作者就必須完全了解他們所做出決策的經濟影響。傳統的觀點是，隻有那些了解業務、市場和客戶經濟情況的決策者和當局者，才有必要了解這些活動與經濟之間的關系。
然而，如果這些對經濟相關的了解隻是集中在上司者那裡，就會造成基層員工在處理日常工作問題時要麼缺乏相關資訊，要麼将問題更新到掌握資訊的管理層。其中第一個選擇會直接破壞經濟成果，而第二個選擇會導緻延遲價值傳遞，這都會帶來不好的影響。
詳述
SAFe十分強調經濟效益在成功的解決方案開發過程中所發揮的重要作用。是以，SAFe的第一個精益-靈活原則就是采取經濟視角。之是以是排名首位的原則，是因為如果不能滿足客戶或解決方案提供者的經濟目标，那麼解決方案能否長期存在就令人懷疑了。解決方案失敗的原因有很多，其中不能滿足經濟要求是一個主要的原因。本章介紹了通過精益-靈活方法達到優化經濟成果所需的兩個基本方面：
- 盡早和經常傳遞
- 了解每一個項目群和價值流的經濟平衡參數
這兩個方面在下文中都有概述。此外，SAFe将這些原則在各種實踐中進行了執行個體化，例如 7.5 節所闡述的主題。
一般來說，企業決定擁抱精益-靈活開發，是由于目前流程不能滿足生産的需要，或者是他們認為目前流程将來會被取代。在選擇精益-靈活的道路上，通常選擇基于增量式的模型，盡早和持續傳遞價值，如圖3.1-1所示。
這樣的決策将會帶來顯著的，或許是最基礎的經濟效益，如圖3.1-2所示。
圖3.1-2展示了精益-靈活方法在這種流程中可以盡早地給客戶傳遞價值。而且，這些價值随着時間不斷累積，客戶持有時間越久，得到的價值就越大。相比之下，在瀑布模型中，價值隻能按照計劃在開發周期結束時得到傳遞。
這種差異也展示了使用SAFe的經濟效益。此外，該圖并沒有考慮盡快得到解決方案相關回報的好處；同時也忽略了瀑布傳遞模式最終可能無法按時傳遞，或是無法證明可用性。而且，還有第3個也是最後一個因素，如圖3.1-3所示。
圖3.1-3展示了一個關鍵的差異化優勢：隻要品質滿足要求，産品和服務越早投入市場，價值就越高。畢竟，如果能早于競争對手提供相應産品，客戶無法從其他廠商那裡獲得産品和服務，就願意花更多的錢來購買。随着時間的推移，産品就會趨于同質化和陷入價格戰，也就沒有了價值差異化，這就是産品發展規律。這就意味着即使是在早期提供給客戶最小可行産品（MVP），也比在後期提供全面的功能更有價值。
是以産生的淨效應是累積總利潤會更高。這是精益-靈活開發的基本前提——它固化在精益-靈活理念中，更是在最短的可持續前置時間内完成解決方案開發的驅動力量。
了解經濟平衡的參數
此前讨論的基本原理是采用更有效的經濟模型來更快速傳遞的驅動力。然而，在執行項目群時仍然有很多工作要做。畢竟，解決方案生命周期中的經濟決策也将最終決定傳遞的成果。是以，有必要更深入地讨論多種經濟參數的平衡。Reinertsen（參考資料 [1]）描述了五種基本因素，可以用于站在經濟角度評估特定的投資情況，如圖3.1-4所示。
對于五種參數的解釋如下：
- 開發費用：為了實作某種能力所需要的人力和物料成本。
- 周期時間：為了實作某種能力的時間
- 産品成本：（銷售商品的）制造成本和/或部署及營運的成本
- 價值：所實作的能力對于業務和客戶的經濟價值。
- 風險：解決方案的技術或業務成功與否的不确定性。
了解經濟平衡的參數，有助于優化生命周期的收益——這也是解鎖開發中最佳經濟價值的關鍵。然而與此同時，這需要對項目有更深刻的了解，以下是兩個例子：
- 一個團隊正在建構家庭自動化系統，據估計将更多功能轉為軟體實作可以減少100美元的電子部件的成本，但是這麼做可能會延遲釋出前置時間3個月。那麼團隊應該執行這個項目嗎？答案顯然是“視情況而定”。它取決于産品預期的銷售量和如果推遲3個月釋出産品的延遲成本（CoD）之間的對比。在做出決策之前，還需要做進一步的分析。
- 一個大型軟體系統，如果有大量的技術債務，是很難進行維護的。而且開發費用是嚴格固定的。如果專注于現在的技術債務，在短期内将會減緩價值傳遞，但是從長期來看，會有利于減少未來特性傳遞的前置時間。那麼團隊應該采取這種措施嗎？答案同樣是“視情況而定”。在做決策之前需要更多的定量分析。
除了經濟平衡的參數，Reinertsen 還介紹了一些關鍵的原則，有助于團隊從經濟的角度出發做出明智的決策。
- 量化延遲成本（CoD）的原則——如果你隻對一件事進行量化分析，那就是 CoD。
- 持續經濟平衡的原則——經濟有效的選擇必須在整個過程中持續不斷地進行。
- 最佳決策時間的原則——每一個決策都有它的最佳經濟時間。
- 沉沒成本的原則——不要考慮已經花費的成本。
- 第一決策規則的原則——使用去中心化經濟控制的決策規則。
以上最後一個原則與SAFe緊密相關，可以推導出SAFe的原則＃ 9——去中心化的決策，該原則将在 7.5 節中進一步描述。
參考資料
[1]Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
3.2 原則＃ 2——運用系統思考
系統是必須被管理的，它不會進行自我管理。如果讓其自我管理，各個元件就會變得自私、互相競争，成為彼此獨立的利潤中心，進而破壞整個系統。系統管理的奧秘就是面向組織目标，協調各個元件之間的合作。
——W. 愛德華茲·戴明
SAFe來源于三個基礎知識體系：系統思考、靈活開發和精益産品開發。系統思考采用全方位思考來進行解決方案開發，将系統及其環境的所有方面整合到系統本身的設計、開發、部署和維護中。
了解這些概念有助于上司者和團隊掌控解決方案開發群組織的複雜性，以及總上市時間的全局視圖。下面将會一一進行介紹。
解決方案就是一個系統
SAFe指導複雜軟體和網絡實體系統的開發和部署。它們由SAFe解決方案展現，該解決方案是有形的，可以提供最終使用者價值，是每一個價值流的主題（例如，應用程式、衛星、醫療裝置或網站等）。當涉及這些有形的系統時，戴明的評論“系統是必須被管理的”，會引導我們做出批判性的洞察：
- 團隊成員必須清晰了解系統的邊界是什麼，系統自身是什麼，系統如何與周圍的環境及其他系統進行互動。
- 僅僅優化一個元件是無法達到系統優化的，元件反而會變得自私，并獨占其他元件所需的資源（比如計算能力、記憶體、電力供應等）。
- 為了讓系統的行為表現良好，就必須了解其預期的行為，并對其架構有更深入的了解（元件如何協同工作以實作系統的目标）。意圖設計是系統思考的基礎。
- 一個系統的價值會通過其連接配接部件進行傳遞，比如接口和接口之間的依賴關系，這些連接配接部件是提供最終價值的關鍵要素。持續關注這些接口及其互動至關重要。
- 一個系統的進化速度取決于系統中最慢的內建點。完整系統的內建和評估越快，系統掌握的實際知識的增長速度就越快。
建構系統的企業也是一個系統
系統思考還有第二個方面：建構系統的組織中所包含的人員、管理和流程也是一個系統。“系統必須被管理”的理念也适用于此。否則，建構系統的組織的各個元件将隻做局部優化并變得自私，進而限制了價值傳遞的速度和品質。這也會引導我們做出另一組對于系統思考的洞察：
- 建立複雜系統是一種社會性工作。是以，上司者必須創造一種環境，使人們可以通過最優的合作方式建構最好的系統。
- 供應商和客戶都是價值流不可或缺的組成部分。他們必須被視為合作夥伴，建立長久的信任基礎。
- 在這種情況下，僅優化一個元件是無法對整個系統進行優化的。同樣，僅優化本地團隊或職能部門，也并不一定能提高企業的價值流動。
- 價值跨越組織邊界。想要加快價值傳遞，就需要消除職能筒倉，或者建立跨職能組織，比如靈活釋出火車（ART）。
了解并優化完整的價值流
價值流是SAFe的基礎。SAFe投資組合本質上是價值流的集合，每個價值流向市場傳遞一種或多種解決方案。如圖3.2-2 所示，每個價值流包含了一系列的步驟，可以通過新系統或現有系統來內建和部署一個新的概念。
系統思考的第三個方面是了解和優化完整的價值流，這是減少從概念到現金所需的總時間的唯一方法（參考資料[2]）。系統思考要求上司者和員工掌握完整的價值流，并對其不斷進行優化，特别是當價值流跨越技術群組織邊界時。
一個基本的流程是價值流映射，它是一種系統的方法，用來檢視産生價值所需的所有步驟。價值流映射讓上司者迅速認識到實際的增值工作步驟（建立代碼群組件、部署、驗證等）僅僅消耗了總上市時間的一小部分。這種認知促使上司者不斷關注步驟間的延遲。圖3.2-3 提供了價值流映射的示例。請注意，圖中從提出特性到部署之間的時間幾乎全都是等待時間，進而導緻一個非常低效的過程。
隻有管理能夠改變系統
每個人都已經盡了最大努力；問題存在于系統之中……隻有管理能夠改變系統。
戴明的這段話為我們提供了對系統思考最後一個方面的了解——系統思考需要采取一種新的管理方式，也就是說管理者是問題解決者，他們具備長遠的系統視角，并且積極清除障礙。這些精益靈活上司者：
- 展示和教授系統思考和精益-靈活的價值觀、原則和實踐。
- 參與問題解決，消除障礙和無效的内部系統。
- 使用和教授根本原因分析和糾正措施技術。
- 與團隊合作，共同實作關鍵裡程碑，幫助團隊識别和解決問題。
- 具備長遠眼光，投資于基礎設施、實踐工具和教育訓練等支援能力，進而實作更快的價值傳遞，更高的品質和生産力。
總結
了解系統思考的方方面面，有助于上司者和團隊真正明白他們所做工作的目的和内容，以及對周圍的影響。反過來，這也會形成一個更加精益、更加智慧的企業，可以更好地處理組織結構和解決方案研發的複雜性。相應地，這也會帶來更好的業務成果。
[1]Deming, W. Edwards. The New Economics. MIT Press, 1994.
[2]Poppendieck, Mary, and Tom Poppendieck. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.
3.3 原則＃ 3——假設變異性，保留可選項
創造系統級設計和子系統概念的多種可選方案；而不是過早地選擇一個勝出方案，然後消除與之不同的其他可選項。隻有那些存活下來的設計選項，才是最強大的可選方案。
——艾倫 C. 沃德，《精益産品和流程開發》
系統開發人員都會傾向于減少變異性，這是人的本性。表面上看起來，你認為自己經過深思熟慮并且已經做出了相應的決策，應該能走得更遠。但是，現實情況往往并非如此。
雖然變異性會導緻糟糕的結果，但有些時候也不盡然。
變異性的自身無所謂好與壞。相反，是時間的經濟效應和變異性的類型決定了最終的結果。如果過早地專注于消除變異性，可能會導緻企業萌生厭惡風險的文化，這樣員工也就不能通過試錯和學習來擷取經驗。
精益知識工作者們認識到，在項目的早期除了一些基本的系統目标之外，對項目的實際情況往往知之甚少（确實，如果能掌握所有資訊，那麼系統早就建構成功了）。然而，傳統的設計方法往往讓開發人員迅速地開始實作單一的方案，而這個方案僅僅是衆多潛在解決方案中被認可的一個，然後再通過修改推薦的設計，直到最終滿足系統的目标。
這也許是一個很有效的方法——當然，前提條件就是團隊最初所選擇的單一方案不能有誤。然後再通過後續的疊代進行細化，但是最終可能需要浪費許多時間才能得到一個并不是最佳設計的解決方案（參考資料[1]）。不幸的是，如果最初選擇的單一方案不是最優的，那麼後果就是：系統越大越需要技術創新，所帶來的損失也會越大。
一個更好的方法是，可以參考使用基于集合的設計（SBD，即多個設計構成一組）或者基于集合的并行工程（SBCE，即多個并行工程構成一組）（參考資料 [2]），如圖 3.3-1 所示。
在基于集合的設計中，開發人員最初會考慮非常廣泛的設計思路，提出多種設計選項。接下來，他們持續地評估經濟效益和技術難度之間的平衡，在內建的學習點上，可以示範與目标的比對情況。然後，基于示範的結果和所擷取的經驗，去除那些不太好的選項，收斂到一個最終的設計。
采取這種流程，可以讓設計選項的持續時間盡可能延長，在必要的時候進行收斂，并最終産生更優的技術實作和經濟效益。
[1]Iansiti, Marco. “Shooting the Rapids: Managing Product Development in Turbulent Environments.” California Management Review, 38. 1995.
[2]Ward, Allan C., and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute, 2014.
3.4 原則＃ 4——通過快速內建學習環進行增量式建構
産品的內建點，是控制産品開發和提升系統的關鍵支點（杠杆點）。如果沒有處理好內建點的時間，項目就會陷入困境。
——Dantar P. Oosterwal
在傳統的方法中，根據“階段 – 門限”進行開發，項目一開始就立刻投入成本，随後成本逐漸累積直到最終方案得以傳遞。通常，在項目執行期間極少傳遞實際價值，而是直到所有功能完成後才在最後一次性傳遞價值，有時候項目也會面臨時間延期或者成本超支的問題。在開發過程中，一般很難收集到有意義的回報，因為流程就不是為收集回報而設計的。更重要的是，開發流程本身也并不是按照允許客戶評估需求和能力的增量式提升來設計和實作的。是以，風險在項目執行中會一直存在，直到項目結束，有時候甚至會進入到部署和客戶最初使用環節。
毫無疑問，這種典型的“階段–門限”流程容易導緻錯誤和問題，經常導緻失去客戶的信任。為了調整這些問題，合作雙方會在項目早期進行需求定義，并選擇“最好的”設計，他們也會執行更加嚴格的“階段–門限”評審。不幸的是，這些補救辦法實際上都存在一些潛在的問題。這是開發流程中存在的一個系統級别的問題，是以必須從系統化的角度去解決這個問題。
內建點可以從不确定性中擷取知識
精益原則與實踐解決問題的方式與上述方法有所不同，并不是在項目早期選擇單一的需求和設計方案，也并不假設這些方案是完全可行和滿足要求的，而是基于一定範圍的需求和多種設計選項（原則＃ 3）進行一系列短周期（時間盒）的增量式解決方案建構。每一個基于時間盒的活動都會産出一個可工作系統的增量，這個增量是可以傳遞的。後續的時間盒會在之前增量的基礎上，逐漸傳遞演進的解決方案，直至最後的釋出。在內建點上，擷取經驗知識不僅僅是為了技術可行性研究，也可以得到最小可行解決方案或者原型，供市場驗證、建立可用性、擷取客戶回報等。在必要的地方，這些快速回報點允許團隊轉向另一個有效的解決措施，進而可以更好地服務于目标客戶的需要。
根據意圖設定內建點
在一定程度上，開發流程和解決方案的設計聚焦在基于節奏的內建點。每一個內建點都會建立一個“拉動事件”，拉動各種方案要素進行整體內建，即使隻解決了系統的一部分目标也會進行內建。內建點也會将利益相關者拉動到一起，建立定期的同步有助于確定方案的演進，進而解決真正的問題和目前的業務需要，而不是僅僅依賴于在流程開始的時候建立起來的假設。每一個內建點都會通過将不确定性轉化成經驗知識的方式傳遞價值，這些經驗知識包括：
- 目前設計選項的技術可行性的相關經驗知識
- 基于客觀度量的解決方案的潛在可持續性經驗知識（原則＃ 5）
通過更快的周期進行更快的學習
內建點是休哈特（Shewhart）的PDCA（計劃–執行–檢查–調整）循環（如圖3.4-1所示）的一個示例，是控制解決方案開發中變異性的機制（參考資料[3]）。
內建點越頻繁，學習速度就越快。在複雜系統開發中，本地內建點用于確定系統中的每個元素和能力都能夠履行其職責，為整體解決方案意圖做出 圖3.4-1 PDCA循環貢獻。然後，這些本地內建點也必須內建到更高的系統級别中。系統規模越大，內建的層級就越多。解決方案設計者意識到：最高層級的、發生頻率最低的內建點，提供了度量系統進展的唯一标準，他們也在努力盡可能頻繁地創造這些內建點。所有的利益相關者也明白：如果內建點的時間沒有控制好，項目就會陷入困境。但是即便是這樣，這些經驗知識也會有助于激發對範圍、技術方法、成本和傳遞時間的必要調整，以重新定向項目來滿足調整後的期望。
[1]Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.
[3]Deming, W. Edwards. Out of the Crisis. MIT Press, 2000.
3.5 原則＃ 5——基于對可工作系統的客觀評估設立裡程碑
實際上，按時進行“階段–門限”傳遞與項目的成功并無關系。但有些資料表明，反過來卻是相關的，即成功的項目都是按時進行階段傳遞的。
——Dantar P. Oosterwal，《精益機器》
“階段–門限”裡程碑的問題
現在，對于大型系統的開發需要大量資源——投資總額可以達到數百萬、上千萬，甚者過億美元。開發人員和客戶有義務共同確定對于新的解決方案的投資可以提供必要的經濟收益。否則，何必要進行投資呢？
顯然，利益相關者必須進行協作，進而幫助確定在整個開發過程中實作預期經濟效益的潛力，而不僅僅是“一廂情願”地認為最終可以得到美好的結果。為了應對這一挑戰，業界引入了“階段 – 門限”（瀑布式）的開發流程，這種流程會對一系列确定的裡程碑進行度量和進度控制。
這些“階段–門限”裡程碑也不是任意設定的，它們遵循一定的邏輯性和一系列的流程——發現、需求、設計、實作、測試和傳遞。當然，這種裡程碑的設定方法并不總能獲得好的收效，如圖3.5-1所示。
導緻這個問題的根本原因是沒有認識到在假設“階段–門限”顯示真實進展情況，進而消除風險的過程中，犯了四個關鍵的錯誤：
1.将需求集中起來，同時進行職能筒倉式的設計決策，導緻了後續的解決方案缺乏完整性。
2.過早的設計決策和“虛假的可行性”（參考資料 [1]）：
- 一個早期的選擇是在當時做出的最佳選擇
- 随後的開發流程就假設一切按照計劃進行
- 直到最後才發現最初的選擇是不切實際的（原則＃ 3）
3.假設存在一個确定的解決方案，而且隻進行一次嘗試就可以建構成功。這樣就忽視了流程中固有的變異性，并且沒有提供有效的處理方法。改變将是遲早的事。變異性遲早是要表現出來的。
4.在前期就進行決策，建立了大批量的需求、代碼和測試，形成了很長的隊列。這也導緻了大批量的工作交接和延遲的回報（原則＃ 6）。
基于客觀事實設立裡程碑
顯然，“階段–門限”模型并沒有像預期的那樣降低風險，是以就需要一種不同的方法。
原則＃ 4 提供了解決這一困境的一些要素。
在整個開發過程中，系統進行增量式的建構，每一次建構都是一個內建點，在內建點上可以示範一些已經實作的内容，以驗證目前解決方案的可行性。與“階段–門限”開發方法不同，基于客觀事件所設立的每一個裡程碑都包含研發的所有步驟——需求、設計、開發、測試），進而達到增量式的價值傳遞，如圖3.5-2所示。
此外，這種裡程碑會基于的節奏進行（原則＃ 7），一個固定的節奏可以形成一種紀律，確定定期提供可用性和評估，同時能提前确定時間邊界，也可以用來去除那些不太理想的選擇。在關鍵的內建點上要對哪些要素進行有效的度量呢？這取決于所要建構系統的類型，關鍵點在于利益相關者可以在整個解決方案開發周期内頻繁地對系統進行度量、評價和評估。這樣可以提供财務、技術和符合目标的組織治理，進而確定持續的投資可以産生與之相比對的回報。
3.6 原則＃ 6——可視化和限制在制品，減少批次規模，管理隊列長度
接近滿負荷地使用産品開發流程是一場經濟災難。
——Donald Reinertsen
為了實作最短的可持續前置時間，精益企業努力實作持續流動的狀态，即新的系統可以迅速地從概念到盈利。實作持續流動需要消除傳統方法中的基于“開始－完成－開始”的項目啟動和開發流程，也要消除阻礙流動的現行“階段–門限”的方法（原則＃ 5）。
實作流動的三個關鍵點是：
- 可視化和限制在制品。
- 減少工作項的批次規模。
- 管理隊列長度。
可視化和限制在制品
團隊和項目群的工作過載，任務量超出了他們所能承擔的範圍，這是一個常見且有害的做法。過多的在制品（WIP）會影響優先級，導緻頻繁地在不同工作場景之間進行切換，并增加開銷。這種情況會使員工作過載，将注意力集中在即時任務上，降低了生産力和吞吐量，并增加了傳遞新功能的等待時間。
糾正問題的第一步是讓目前的 WIP 對所有的利益相關者清晰可見（如圖 3.6-1 所示）。這個看闆說明了每一個步驟的工作總量，也作為對初始過程的診斷，并顯示出目前的瓶頸。通常，僅需簡單地可視化目前的工作量就可以喚醒團隊成員，讓他們開始意識到要解決同時開展工作太多而沒有形成流動的問題。
下一步就是處理在制品數量和可用開發容量平衡的問題。如果在執行過程中，達到了WIP的上限，就不再承接新的工作任務。
然而，限制在制品（WIP）是需要有知識、有紀律和有承諾的。甚至有些時候看起來是反直覺的，比如以前有些人認為放入系統的工作越多，完成的就越多。這種關系在接近滿負荷之前是成立的，但是如果超出了一定的限度，系統就會變得動蕩，也會降低吞吐量。這說明，有效的WIP管理是不可取代的。
減少批次規模
減少在制品和提高流動性的另一種方法是減少工作的批次規模，這些工作包括需求、設計、編碼、測試和其他相關工作。小批量通過系統的速度更快，變異性更小，并能夠促進快速學習。速度更快的原因是顯而易見的。變異性減少是由于批次中事項數量的減少。因為每個事項都會有一些變異性，是以大量的事項會累積成更多的變異性。
從經濟的角度上來看，最優的批次規模依賴于持有成本（延遲回報、庫存損壞和延遲價值傳遞帶來的成本）和交易成本（準備和實施該批次的成本）。如圖3.6-2所示，說明了“U型曲線”是批次規模的最優曲線（參考資料[1]）。
為了提高處理小批量的經濟效益，進而增加吞吐量，團隊必須聚焦在減少批次的交易成本上。通常包括增加在基礎設施和自動化上的關注和投資，包括考慮比如持續內建和建構環境、DevOps自動化，以及系統測試的配置時間。以上這些關注都是與系統思考的融合（原則＃ 2），也是進行長期優化的關鍵要素。
管理隊列長度
實作流動性的第三個措施是管理隊列長度并減少隊列長度。利特爾法則（基于排隊論的法則）告訴我們，系統提供服務的等待時間等于隊列的長度除以平均的處理效率（雖然這可能聽起來很複雜，可是在星巴克排隊買咖啡的時候也會證明利特爾法則的有效性）。是以，假設平均的處理效率一定，隊列越長，等待時間越長。
對于解決方案開發來說，這意味着無論團隊多麼有效地處理工作任務，隻要團隊實作的工作任務隊列越長，那麼等待時間就越長。是以，要實作更快的服務，就必須減少隊列的長度或者提高處理效率。雖然提高處理效率是一個有價值的目标，但是減少等待時間最簡單的方式是減少隊列長度。在工作中，可以通過保持較短的待辦事項清單和并不過多進行承諾來做到這一點。同時，可視化工作有助于确定簡化流程的方法，同時縮短隊列長度以減少延遲，減少浪費并增進對于成果的可預測性。
實作流動的三種主要方式是：可視化和限制在制品、減少批次規模和管理隊列長度，這三種方式對于提高吞吐量非常有效。通過采取這些方式，可以觸發在客戶滿意度和員工參與度方面的快速和可衡量的改進，對靈活團隊及其客戶也可以帶來收益。
[1]Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas, 2009.
3.7 原則＃ 7——應用節奏，通過跨領域計劃進行同步
節奏和同步可以限制變異性的累積。
解決方案開發在本質上是一個内在不确定的過程。否則，解決方案早就已經存在了，下一代解決方案的創新也就沒有空間了。這種内在的不确定性風險與企業活動是互相沖突的，比如企業活動需要管理投資、跟蹤進展、對于未來成果有足夠的信心，進而制定計劃和承諾一個合理的行動實施。
精益-靈活團隊在“安全地帶”中工作，這個“安全地帶”有足夠的不确定性提供創新的自由，同時也讓企業有充足的信心來保證營運。實作這種平衡的主要方式是了解目前所處的狀态。而應用節奏、同步和跨領域計劃有助于對目前狀态的了解。
節奏
節奏是流程中穩定的心跳，可以提供一種優雅的節拍模式。節奏讓日常工作有規律進行，進而使知識工作者可以管了解決方案開發過程中那些可變的部分。通過将不可預測的事情變得可預測，節奏帶來了很多額外的益處：
- 等待時間可預測，如果你所需要的工作傳遞物不在目前的這個項目群增量（PI）時間盒内，那麼可能就會在下一個時間盒内。
- 通過引導計劃活動，使人員和資源的使用更加有效。
- 降低了關鍵活動的交易成本，這些活動包括計劃、內建、示範、回報和回顧等。
同步
同步允許在同一時刻從不同的角度出發，進行工作任務的了解、解決和內建（如圖3.7-1所示）。其結果是：
- 将系統中不同的資産進行整合，以評估解決方案的可行性。
- 将開發團隊和業務團隊的共同使命協調一緻。
- 将客戶融合到開發的流程中。
總之，盡管有前面描述的風險，節奏和同步——更為重要的是相關的其他活動，仍然可以共同幫助團隊充滿自信地開展工作。
通過跨領域計劃進行同步
在SAFe的所有活動中最關鍵的一環是：所有的利益相關者定期聚集在一起進行跨領域的計劃和同步。這項活動被稱為PI計劃，它是所有其他活動的支撐，它也使團隊有機會展示和評審目前的真實狀态。
PI計劃活動的三個主要目的是：
1.評估解決方案的目前狀态——一個內建的、解決方案級别的示範和評估，确定了對目前狀态的客觀了解。這項活動通常在計劃會議之前進行。
2.再次對齊所有利益相關者的共同技術和業務願景——基于目前狀态，業務上司和技術上司一起重新設定使命，考慮最小數量的限制條件（原則＃ 8和原則＃ 9）。這項活動用于對齊所有利益相關者的近期和遠期願景。
3.有助于團隊對下一個項目群增量進行計劃和承諾——基于達成的新共識，團隊對于在接下來的時間盒内要完成的工作進行計劃。共享的計劃和控制可以授權團隊在給定的限制條件下，為達到最佳可能的解決方案建立出最佳可能的計劃。
大型系統的開發從根本上講是一種社交活動，這種計劃活動為建立和完善社交網絡提供了一個持續的機會。
解決方案開發的内在不确定性是無法治愈的。如果可以治愈，那麼治愈的結果可能比原來的疾病更糟糕。然而，應用節奏和同步，以及定期地進行跨領域計劃，提供了在“安全地帶”中開展工作所需要的各種工具。
[2]Kennedy, Michael. Product Development for the Lean Enterprise. Oaklea Press, 2003.
3.8 原則＃ 8——釋放知識工作者的内在動力
看起來，任務的績效提供了内在的獎勵……這種驅動力……可能與其他元素一樣，都是基礎……
——丹尼爾·平克，《驅動力》
精益-靈活上司者必須接受一個相對較新的、改變遊戲規則的事實：對于知識工作者的管理其實是一個自相沖突的說法。正如彼得·德魯克指出的：“知識工作者比他們的老闆更了解自己所從事的工作”（參考資料 [2]）。在這種情況下，員工完全更有能力自己定義必要的工作以達成他們的目标，那麼經理們如何試圖細緻地監督，甚至親自協調這些員工的技術活動呢？
事實上，經理們做不到。經理們能做的是釋放知識工作者的内在動力。下面将介紹一些實施指導。
利用系統視圖
在深入了解其他的激勵機制之前，我們必須注意到一個重要的見解，即SAFe的精益-靈活原則本身也是一個系統。此外，這個系統的元素互相協作，建立了一個新的授權模式。通過 SAFe，知識工作者現在能夠：
- 跨越職能的邊界進行溝通
- 基于對經濟效益的了解進行決策
- 獲得有關解決方案有效性的快速回報
- 參與持續和增量式的學習并提高掌控能力
- 參與更高效、更充實的解決方案開發過程——這就是最強大的動力之一
了解薪酬的作用
許多組織的運作仍然基于那些已經過時的、對人員潛力和員工績效的假設，而且大多基于傳統觀念而不是科學。這些組織繼續追求的做法是，短期激勵計劃和按照證據的績效工資支付方式，但實際上這種度量方式并不奏效，甚至會帶來危害。
丹尼爾·平克和彼得·德魯克，以及其他一些學者指出了知識工作者的薪酬激勵因素的一個基本悖論（參考資料[1,2]）：
- 如果企業不能支付足夠的工資，員工就不能被激勵。
- 但是，如果達到了一個臨界點，工資就不再是一個長期的激勵因素了。這個臨界點
就是知識自由和自我實作。當這種狀态實作時，知識工作者的頭腦可以自由地專注在工作上，而不是在金錢上。
當達到了這個臨界點之後，增加激勵性薪酬元素讓員工把注意力轉移到金錢而不是工作上，反而導緻員工的績效成績變差。
精益-靈活上司者都很清楚，知識工作者的構思、創新和在工作場所中深入參與工作，是無法用金錢來激勵的；反之，也不會被威脅、恐吓和恐懼所脅迫。那種基于激勵的報酬——通常由個人的目标管理（MBO）決定，會導緻内部競争，甚至有可能破壞必要的合作，乃至無法實作更宏偉的目标。如果這樣的話，企業就會在競争中失敗。
提供目的、使命和最小可能限制的自主性
丹尼爾·平克主張知識工作者需要具備自主性——也就是他們與生俱來的自我指導和自我管理的能力。提供自主性，同時利用它來實作企業的更大目标，這一點是上司者的重要職責所在（參考資料[1]）。
經理們和員工們也都知道，自我指導的動力必須在更大的目标下發生。為此，上司者們需要提供一些更大的目标——把員工的日常工作和企業的發展目标聯系起來。
在建構系統時，知識工作者作為一個團隊進行合作。是以，成為高績效團隊的一員同樣是另一個重要動力。上司者可以通過以下指導來鼓勵團隊做出最大努力（參考資料[4]）：
- 确立使命感——要有一個概要的目标和戰略方向，以及一個強烈的願景。
- 對于具體工作和項目計劃，僅給出少量的、最小化的指導，甚至沒有任務說明和計劃。
- 對于需求和最小可能的限制條件發起挑戰，由團隊決定如何實作這些需求。
創造一個互相影響的環境
“如果要做到有效地上司，就必須尊重員工和傾聽他們的聲音”（參考資料 [2]），而且是在互相影響的環境中（參考資料 [4]）。上司者可以創造這種良好的環境，他們可以給予員工強有力的回報支援，放下自己的職權影響力，并鼓勵員工按照如下的方式開展工作：
- 在恰當的地方提出不同意見。
- 鼓勵員工堅持自己的立場。
- 讓員工清晰自己的目标并推動員工達成目标。
- 促進管理者和員工共同解決問題。
- 協商、讓步、同意和承諾。
我們生活在一個嶄新的時代，這個時代的特點是員工更加聰明，在具體的工作中比管理者具備更多的知識。釋放這種原始潛力可以顯著改善員工的活力，同時也可以為客戶和企業提供更好的成果。
[1]Pink, Daniel. Drive: The Surprising Truth About What Motivates Us. Riverhead Books, 2011.
[2]Drucker, Peter F. The Essential Drucker. Harper-Collins, 2001.
[3]Bradford, David L., and Allen Cohen. Managing for Excellence: The Leadership Guide to Developing High Performance in Contemporary Organizations. John Wiley and Sons, 1997.
[4]Takeuchi, Hirotaka, and Ikurijo Nonaka. “The New New Product Development Game.” Harvard Business Review, January 1986.
3.9 原則＃ 9——去中心化的決策
由知識工作者自己來決定如何開展自己的工作，這是最佳的方式。
——彼得·德魯克
在最短的可持續前置時間内傳遞價值需要去中心化的決策。任何需要上升到上司層進行的決策都會帶來延遲，也會導緻決策的品質降低，這是因為缺乏對具體環境的考慮，再加上在等待時間内會發生的各種變更。
相反，去中心化的決策可以減少延遲，提升産品開發的流動和吞吐量，并能更快回報和做出更多創新性的解決方案。
戰略性決策中心化進行
當然，并不是所有的決策都是去中心化分散進行的。有些決策是戰略性的，其影響深遠，超出了團隊的範圍、知識或職責。此外，上司依然對成果負責。他們還擁有市場知識、長遠視角，并了解引導企業所需的業務和财務狀況。
那麼，這些決策應該是集中進行的，它們具有以下特征：
- 發生頻度不高——這些決策通常是不緊急的，并且适合做更深入的思考（例如，産品戰略、國際擴張）。
- 長期有效——一旦做出決策就不大可能改變，至少在短期内不會改變（例如，對标準技術平台的承諾、圍繞價值流進行組織調整的承諾）。
- 對于經濟效益有重大影響——這些選擇會帶來巨大而廣泛的經濟效益（例如，常用的工作方式、标準開發語言、标準工具、離岸外包）。
上司層負責制定這些類型的決策，并得到受決策結果影響的利益相關者的支援。
其他類型的決策去中心化進行
絕大多數的決策并沒有達到需要進行戰略性決策的高度。這些決策都可以授權給團隊分散進行。這些類型的決策包括以下特征：
- 發生頻度高——分散決策所要解決的問題是反複發生和常見的（例如，團隊和項目群待辦事項清單的優先級設定，實時界定靈活釋出火車範圍，對缺陷和緊急問題的回應）。
- 時間上很緊急——這些類型決策的延遲會帶來高昂的延遲成本（例如，單點釋出，客戶緊急事件，與其他團隊的依賴關系）。
- 需要本地資訊——這些決策需要考慮特定的具體環境，無論是技術、組織，還是特定的客戶或市場影響（例如，向特定客戶釋出版本，解決重大設計問題，個人和團隊的自組織以應對新出現的挑戰）。
去中心化的決策應由那些了解具體環境，并詳細了解目前情況的技術複雜性的從業人員決定。
一個輕量級思考的決策工具
了解決策的制定方式有助于知識工作者更加清晰地了解決策過程。上司層的責任是建立決策規則（例如，包括經濟架構），然後授權其他人進行決策。圖3.9-1展示了一個簡單的工具或練習，用于考慮決策是中心化進行還是去中心化進行。