書接上回，今天咱們講，敏捷原則

在深入瞭解Scrum之前，先理解推動並影響Scrum方法的基本原則是很有幫助的。這篇文章將幫助大家理解Scrum與各種傳統產品開發方式的差異，為後續解讀打下基礎 。

把敏捷原則與傳統開發原則進行對比，目的不是為了說明Scrum好而計劃驅動的順序開發不好。這兩種方法都是專業開發人員工具箱中的工具。沒有不好的工具，只有使用時機不當的工具。（大白話，火箭炮是武器，梅花鏢也是武器，具體哪個有用，得看你在什麼樣的戰場上。）

純正而傳統的計劃驅動開發常常稱為“瀑布開發”，它來源於人們總是希望計劃和預測工作內容（客戶希望最終產品包含那些特性），確定最佳工作方式（這些特性以哪一種最適合的方式完成）。它的思路是：計劃制定的越好，對產品的理解就越好，執行也就越好。一般執行順序如下圖：

對於明確定義、可預測且不可能發生任何重大變更的問題，計劃驅動開發方式是很適用的。然而，這個理念很難適應大多數產品開發工作中固有的不確定性。

Scrum巧用產品開發的可變性和不確定性來產生創新解決方案。

積極採用有幫助的可變性：在軟體產品開發行業，我們的目標不是製造產品，而是建立產品的單個例項。（大白話，製造業製造的產品，是批量生產且規格相同的，比如某款汽車。單個例項是獨一無二的，比如騰訊的微信，阿里的支付寶。）每次建立產品的單個例項，都必然存在一些變數。

採用迭代和增量開發：迭代開發承認我們在把事情做對之前有可能做錯，在把事情做好之前有可能做壞。迭代開發本身是一種有計劃的修改策略。通過多次開發來改善正在構建的特性，逐步得出一個完善的解決方案。增量開發基於一個古老的原則，先構建部分，再構建整體。

通過檢視、調整和透明充分利用可變性：在Scrum中，我們不僅要檢視和調整正在構建的產品，還要檢視和調整構建產品的方式。為了更好的檢視與調整，我們依賴於透明性。資訊透明才能讓每個相關人員看到並瞭解正在發生的事情。它能帶來更多的溝通並同時在過程和團隊成員中建立互信。

同時減少各種各樣的不確定因素：開發新產品是一個很複雜的工作，具有很高的不確定性。這種不確定性可以分為一下兩大類：（Laufer 1996）

• 結果不確定性

• 方法不確定性

在Scrum中，我們不會限制自己只在處理完一類不確定性之後才處理另一類不確定行。相反，我們採取更全面的方法，重點關注於同時減少所有不確定性，

不到最後時刻，不輕易做決定：這個原則常稱“最後責任時刻”（Last Responsible Moment,LRM）(Poppendieck and Poppendieck, 2003)。比如，在產品開發工作的第一天，我們對自己的工作內容瞭解得最少。隨後的每一天，我們的瞭解都能多一點點。既然如此，為什麼要在第一天或者很早就做出最關鍵且（也許）不可逆的決定呢？

舉個決定下太早的例子，一個三句話的悲傷的故事：

1. 欲練此功，揮刀自宮。

2. 我已自宮，卻未成功。

3. 若不自宮，也能成功。

承認無法一開始就把事情做對：我們不可能事先就能正確的到所有需求，也不可能基於這些需求以正確的方式得出詳盡的計劃。在Scrum中，我們也會預先產生需求和計劃，但原則是夠用就好，一旦瞭解更多在建產品的相關知識，我們就會填充需求和計劃的細節。（大白話，幾個詞大家自己體會，計劃經濟，市場經濟，還有摸著石頭過河）

偏好適應性、探索式的方法：Scrum傾向於恰當運用探索式方法，在此基礎上採用適應性的試錯法。探索指的是通過某些活動來獲得知識，例如構建原型，概念驗證，進行實驗。

用經濟合理的方法接受變化：如下圖使用順序開發方式時，後期變更成本比早期變更成本高很多。

在使用Scrum時，每一次迭代都極力避免建立非必需的工件。這樣，在發生變更時，丟棄或重新修改的工作量要少得多。

平衡預測性的事前工作和實際工作之間的關係：適度做計劃，在Scrum中，我們相信前期工作有幫助，但不宜過度。

快速驗證重要的假設：假設是指即使某些猜測或看法並沒有被驗證過，也認為它是正確、真實或可靠的。在使用Scrum時，如果某個假設本質上就很糟糕，我們就可能很快發現錯誤並藉機恢復。

利用多個認知迴圈並行的優勢：在Scrum中，我們知道持續獲取認知是成功的關鍵，反饋迴圈可用來提高認知。例如每日例會是一個每日迴圈，衝刺評審是一個迭代級迴圈。

妥善組織工作流程以獲得快速反饋：快速反饋能提供比較好的經濟效益，因為如果反饋滯後，錯誤加劇，會導致故障呈指數級增長。

批量大小要經濟合理：在產品開發中採用小批量的方式可以減少週期時間，減少工作的變動，加速反饋，減少風險，降低管理成本，提高積極性和緊迫性，降低成本，減少計劃延期。

識別並管理庫存以達到良好的流動：一般情況下，軟體開發企業根本意識不到自己是有庫存的。問題在於產品開發過程中處理的知識資產和庫房裡積壓的存貨不同，他們是不可見的。Scrum的目標是合理的平衡適量庫存和過多庫存之間的關係。

關注閒置工作，而非閒置人員：在Scrum中，我們深信閒置工作（idle work）比人員（idle worker）更浪費，經濟危害也更大。閒置工作指的是有些工作我們想做卻由於其他事情的阻礙兒無法做（例如構建或測試）。這種停頓也許是因為必須等另一個團隊完成之後才輪到我們做。又或者我們要做的工作太多而無法同時完成。

考慮延期成本：延期成本是工作延期或里程碑延期達成所產生的財務成本。

根據實時資訊來重新制定計劃：我們的目標是快速的重新制定計劃並根據開發過程中不斷出現的、具有重要經濟價值的資訊進行調整。

通過驗證工作結果來度量進度：在Scrum中，重要的不是開始了多少工作，而是完成了多少對客戶有價值的工作。聚焦於以價值為中心的交付。

快速前進，但不匆忙：在Scrum中，核心目標是靈活、適應、快速。通過快速交付，快速獲得反饋並儘快將價值交到客戶手中，同時應該以長期穩定的節奏工作。話句話說，要快，但不要匆忙。

以質量為魂：在Scrum中，質量並不是測試團隊在最後階段“測”出來的，而是由跨職能的Scrum團隊負責並持續內建於每個衝刺中。這樣便大大減少了為提高質量而後期做大量測試的情況。

採用最小夠用的儀式：在Scrum中，我們的目標是消除可有可無的繁文縟節。因此，我們為儀式設定了一個較低的標準，也就是“基本夠用”。（大白話，就是減少不必要的流程。）

結語

本文重點介紹敏捷的核心原則-推動我們在Scrum中進行軟體開發的基本理念。下一篇文章，我們將介紹Scrum-衝刺。

欲知後事如何，且聽下回分解。

注：原文首發於微信公眾號敏捷變革中心。歡迎關注，新文釋出搶先讀。