預測與適應
　　在使用Scrum時，經常需要平衡預測性的事前工作與適應性的適時工作之間的關系。下面五個敏捷原則與這個主題相關：
　　保持選擇開放
　　承認無法一開始就把事情做對
　　偏好適應性、探索式的方法
　　用經濟合理的方法積極主動接受變化
　　在預測性的事前工作和適應性的適時工作之間做出平衡
　　保持選擇開放
　　對于需求或設計，計劃驅動的順序開發(fā)方式要求在當前這個階段就做出重要的決策并進行審批。而且，在進入下一個階段之前必須先做出決策，即使這些決策依據的知識有限。
　　Scrum認為，不該單單因為通用過程要求此時做出決定，我們就得做出不成熟的決定。相反，在使用Scrum時，我們傾向于“保持選擇開放”這個策略。這個原則常被稱為“最后責任時刻”（LastResponsibleMoment，LRM）（PoppendieckandPoppendieck，2003），意思是推遲做出承諾，直到最后責任時刻再做出重要的、不可逆轉的決定。那么，最后責任時刻是什么時候呢？這個時刻就是不做決定的成本大于做決定的成本時（參見圖3.6）。此時，就需要做出決定了。
　　圖3.6在最后責任時刻做出決定
　　為了領會這個原則，我們考慮下面這種情況。在產品開發(fā)工作的第一天，我們對自己的工作內容了解得最少。隨后的每一天，我們的了解都能多一點點。既然如此，為什么要在第一天或者很早就做出所有最關鍵且（也許）無法逆轉的決定呢？大多數人都傾向于等有更多信息之后再做出更明智的決定。在處理重要的或不可逆轉的決定時，如果決策太早且有錯，就會處于圖3.6中決策成本的指數部分。更好理解決策之后，決策成本會下降（因為市場和技術的確定性增加，做出錯誤決策的可能性降低了）。這說明我們應該在掌握更多信息之后再做決策。
　　承認無法一開始就把事情做對
　　計劃驅動的過程不僅要求有完整的需求和全面的計劃，還想當然地認為事先就能“把事情做對”。但實際情況是我們基本上不可能事先就能以正確的方式得到所有需求，也不可能基于這些需求以正確方式得出詳盡的計劃。更糟糕的是，一旦需求有變，還得修改需求和計劃基線以適應當時的實際情況（詳情參見第5章）。
　　在Scrum中，我們承認自己不可能事先確定所有需求或計劃。事實上，我們認為這樣做可能很危險，因為可能漏掉重要的知識而產生大量低質量的需求（參見圖3.7）。
　　圖3.7計劃驅動的需求獲取與產品知識積累
　　圖3.7表明，在使用計劃驅動的順序過程時，在早期產品知識積累有限的時候就產生了大量需求。這樣做是有風險的，因為它使我們產生錯覺，認為自己已經消除了結果不確定性。一旦了解得更多或事情有變，可能還會造成巨大的浪費（詳情參見后文）。
　　在Scrum中，我們也會預先產生需求和計劃，但原則是夠用就好，一旦了解更多在建產品的相關知識，我們就會填充需求和計劃的細節(jié)。畢竟，在開始構建前，即使我們篤定要以什么方式構建哪些特性，但在把早期的增量可交付物放到目標使用環(huán)境之后，還是會發(fā)現(xiàn)不對勁兒的地方。此時，種種實際情形都會推動我們改變初衷，去做真正適用、適時的東西。
　　偏好適應性、探索式的方法
　　使用（或利用）現(xiàn)在已知的東西并對未知的東西進行預測，這是計劃驅動的順序過程關注的重點。Scrum則更傾向于恰當運用探索式方法，在此基礎上采用適應性的試錯法。
　　探索指的是通過某些活動來獲得知識，例如構建原型、創(chuàng)建概念驗證、實施研究或進行試驗。換句話說，則是面對不確定，我們通過探索來獲取信息。
　　工具和技術對探索成本有很大的影響。在過去，軟件產品開發(fā)的探索成本很高，因而采用預測性的、盡量一開始時做對的方法是有利的（參見圖3.8）。
　　圖3.8過去的探索成本
　　舉個例子，我在佐治亞理工學院讀大一時（上世紀80年代初），我用過幾次打孔卡——跟打字機似的，如果出錯或需要修改，是很煩人的。必須非常小心地為所有解決方案逐個做打孔卡，然后再排隊等待使用大型機，可能得等上24小時才能驗證解決方案是否正確，在這樣的背景下，“快點試一試，看情況”這個理念是讓人很難接受的。即使微不足道的排版錯誤，也至少得耽誤一天的工夫。瀑布過程在面對不確定性時可以仔細考慮當前知識并做出預測，以求找到優(yōu)化的解決方案，這種做法在經濟上是合理的。
　　幸運的是，現(xiàn)在的工具和技術越來越好，探索成本也隨之下降。從經濟層面上不再是探索的阻礙。事實上，到如今，快速構建少量內容并根據用戶反饋進行調整，其成本往往低于事先投入精力試圖一次性做對所有事情。解決方案的目標使用環(huán)境（技術）如今已變得更加復雜，所以能夠采取這種做法也是很值得慶幸的。
　　在Scrum中，只要具備足夠的知識，就可以得出明智、合理的最終解決方案。然而，在面對不確定性時，不要一廂情愿地預測，要用低成本的探索方式來換取相關信息，并綜合利用這些信息得出明智、合理的最終解決方案。通過行動所獲得的反饋可以幫助我們確定是否還需要進一步探索以及何時進行。
　　用經濟合理的方法接受變化
　　我們都知道，使用順序開發(fā)方式時，后期變更成本比早期變更成本高很多（參見圖3.9，基于Boehm1981）。
　　圖3.9順序開發(fā)方式的變更成本曲線圖
　　舉個例子，分析階段的變更可能只花1美元，但在后期測試階段，同樣的變更卻可能花1000美元。為什么會這樣呢？如果分析階段出現(xiàn)的錯誤能在現(xiàn)階段被發(fā)現(xiàn)，那么修正成本肯定不高。但如果直到設計階段才發(fā)現(xiàn)這個錯誤，則不僅需要修正錯誤需求，可能還要修復基于這個錯誤需求所做的設計。每往后延一個階段，錯誤的影響也越大，甚至出現(xiàn)這樣的情況：分析階段的小錯誤到測試或運行階段演變成大錯誤。
　　為避免后期變更，順序開發(fā)過程的做法是設法提高預測的準確度，澄清系統(tǒng)需求及其實現(xiàn)過程，再加以嚴格控制，力求最小化需求和設計變更。
　　不幸的是，早期活動階段的過度預測往往適得其反。不僅無法消除變更，反而成為交付延期和預算超支的原因之一。為什么會出現(xiàn)這種有悖常理的事實呢？首先，為了消除昂貴的變更，我們被迫在每個階段進行過度投資，即做一些不必要、不切實際的工作。其次，在尚未得到干系人對工作產品的反饋以驗證我們的假設之前，我們被迫在過程早期對重要的假設進行決策。結果，根據這些假設而產生大量工作產品。后來，在這些假設被證實（或被推翻）或發(fā)生變更的時候（例如，需求的出現(xiàn)或演變），很可能得修改或放棄原有的工作成果，這樣的情況時有發(fā)生。自我實現(xiàn)的預言，其經典模式莫過于此（參見圖3.10）。
　　在Scrum中，我們認為變更是很正常的。我們相信，產品開發(fā)所固有的不確定性是無法事先通過加班加點來預測的。因此，必須準備好積極主動迎接變更。不過，在出現(xiàn)變更時，我們希望能比傳統(tǒng)開發(fā)更經濟的方式來處理，即使變更發(fā)生在產品開發(fā)工作后期。
　　因此，我們的目標是要讓變更成本曲線盡可能長期保持平穩(wěn)——即使在后期接受變更，開銷也是經濟合理的。圖3.11說明了這個觀點。
　　我們可以通過對在制品數量和工作流進行管理來實現(xiàn)這個目標，因此，與順序開發(fā)相比，在使用Scrum時，變更成本受時間的影響更小。
　　不管使用哪種方式來進行產品開發(fā)，我們都希望有這樣的關系：小的需求變更所造成的實現(xiàn)方式變更也相應較小，因而成本變更也�。ú浑y想象，大型變更帶來的成本顯然更高）。我們從這種關系中希望得到的另外一個特征：不管變更請求何時出現(xiàn)，都要保持這種關系。
　　圖3.10自我實現(xiàn)的預言
　　圖3.11讓變更成本曲線趨于平穩(wěn)
　　在使用Scrum時，很多工作產品（例如詳細需求、設計和測試用例）都是以剛好及時的方式產生的，以免創(chuàng)建非必需的工件。這樣，在發(fā)生變更時，不必丟棄或重新修改的、基于假設而產生的工作或被迫做出的決定要少得多，因此可以讓成本和變更請求的大小更加成比例。
　　使用順序開發(fā)方式時，庫存會隨著時間的推移而增加，這意味著早期所建的工件和被迫做出的不成熟決定最終造成變更成本快速上升。這導致圖3.11中傳統(tǒng)開發(fā)方式的曲線在早期就出現(xiàn)拐點（曲線突然上升的那個點）。在使用Scrum開發(fā)時，到達某個時間點之后，變更成本和變更請求的比例也會變得很離譜，但這個時間點會出現(xiàn)得更晚一些（如圖3.11中的Scrum曲線拐點所示）。
　　平衡預測性的事前工作和適應性的剛好及時工作之間的關系
　　計劃驅動開發(fā)有一個基本的理念：事先得到詳細需求和計劃是至關重要的，并且做事情要有先后。在Scrum中，我們相信前期工作有幫助，但不宜過度。
　　在Scrum中，我們承認不可能事先精確獲得所有需求和計劃。這是否意味著不應該事先做需求和計劃呢？當然不是！Scrum的要義是找到平衡點，即使平衡預測性的前期工作和適應性的剛好及時工作之間的平衡（參見圖3.12，改編自Cohn2009中的圖）。
　　在開發(fā)產品時，應該從經濟合理的角度來設置平衡點，滿足法規(guī)、監(jiān)管和∕或公司的目標的前提下，盡量根據快速反饋持續(xù)進行調整，少做事前預測。
　　究竟怎樣才算平衡？這在一定程度上由這幾個因素推動：所建產品的類型、待建產品（結果不確定性）和產品構建方式（方法不確定性）的不確定程度以及開發(fā)中的限制。過度預測要求我們在普遍存在不確定性的情況下做出假設。過度調整可能會讓我們處于動蕩中，讓人覺得工作效率低下、混亂。為了能夠快速開發(fā)創(chuàng)新產品，在我們的工作環(huán)境中，一方面要調整，一方面也要通過剛好夠的預測來取得平衡，以免陷入混亂。Scrum框架在秩序與混亂之間取得了很好的平衡。