4. WIP
WIP （work in process）指的是已經(jīng)開始但尚未完成的工作。
4.1 批量大小要經(jīng)濟合理
計劃驅(qū)動的順序開發(fā)過程的另一個核心理念是，傾向于將相同類型的工作分批匯集到一個獨立階段中執(zhí)行。稱為“整體推進”，即在開始后續(xù)活動之前，必須先全部完成當前階段的所有事情。
順序開發(fā)的理念是，大批量的產(chǎn)品開發(fā)也能實現(xiàn)規(guī)模經(jīng)濟。
在 Scrum 中，建議產(chǎn)品開發(fā)采用小批量的方式
4.2 識別并管理庫存資源以達到良好的流動
制造業(yè)有一個值得軟件開發(fā)行業(yè)借鑒的教訓就是庫存的高成本。 我們在守著大量庫存的時候如果事情有變，就會導致一種或多種形式的浪費。為了最小化風險，能干的制造商采用一種經(jīng)濟合理的方法管理庫存——手頭保留一部分庫存，但通過實行準時供給的庫存管理方式，只留合理的庫存數(shù)量。
WIP 剛好是產(chǎn)品開發(fā)過程中需要管理的關(guān)鍵變量。傳統(tǒng)開發(fā)方式中，批量大小設置得相當大（通常為100%），實際上傾向于制造大量庫存。在軟件開發(fā)中，如果出現(xiàn)大量 WIP，后果很嚴重，會嚴重影響變更成本曲線。
Scrum 的目標是合理地平衡適量庫存和過多庫存之間的關(guān)系。
4.3 關(guān)注閑置工作，而非閑置人員
閑置工作（idle work）：有些工作我們想做卻由于其他事情的阻礙而無法做。
閑置人員（idle worker）：指的是員工有能力做更多工作但當前并沒有100%投入。
很多傳統(tǒng)軟件開發(fā)企業(yè)更關(guān)注如何消除閑置人員所造成的浪費，給他們找來更多的工作或者分配到多個項目中，這樣做的確是降低了人員空閑浪費，但同時卻增加了工作停頓所造成的浪費。
舉個最佳實例：奧運會 4 * 100 米接力賽，如果采取讓人 100% 連軸轉(zhuǎn)的策略，并不能贏得接力賽的金牌，這里我們關(guān)注的應該是“看好接力棒，而不是隊員”。
在 Scrum 中，我們需要找出工作流的瓶頸并集中精力消除它，相較于努力讓每個人都100%連軸轉(zhuǎn)，這樣做更加經(jīng)濟合理。
4.4 考慮延期成本
延期成本是工作延期或里程碑延期達成所產(chǎn)生的財務成本。
5. 進度
5.1 根據(jù)實時信息來重新制定計劃
在計劃驅(qū)動的順序開發(fā)過程中，計劃是工作如何開展、何時進行的權(quán)威信息源。因此，計劃是需要遵循的。在 Scrum 中，我們認為盲目信計劃往往會讓我們忽視“計劃可能有錯”這個事實。
在 Scrum 開發(fā)過程中，我們的目標不是為了滿足某個計劃或者某個事先認為事情如何進展的預言。相反，我們的目標是快速地重新制定計劃并根據(jù)開發(fā)過程中不斷出現(xiàn)的、具有重要經(jīng)濟價值的信息進行調(diào)整。
5.2 通過驗證工作結(jié)果來度量進度
在計劃驅(qū)動的順序開發(fā)方式中，如果每個階段的開始和結(jié)束都符合預期，那么產(chǎn)品開發(fā)工作的進展看起來就非常好。然而到最后階段，完全按計劃制造出來的產(chǎn)品可能與客戶期望得到的交付價值相去甚遠。
在 Scrum 中，通過構(gòu)建可工作、已驗證的成果來度量進度。這些工作成果交付了價值并且可以用來驗證重大的假設。
5.3 聚焦于以價值為中心的交付
順序開發(fā)特有的結(jié)構(gòu)決定了只有在工作快結(jié)束時才集成并交付特性。傳統(tǒng)開發(fā)的一個相關(guān)理念是，在交付特性過程中產(chǎn)生的計劃和文檔本身也是有價值的。但大多數(shù)時候也只局限于對下游過程有價值，而非對客戶有價值。
Scrum 是一種客戶價值為中心的開發(fā)方式。它是基于優(yōu)先級排序的增量交付模型，價值最高的特性持續(xù)構(gòu)建并在下一個迭代中交付。這樣，客戶就可以盡快且持續(xù)獲得高價值特性。
在 Scrum 中，價值的產(chǎn)生是通過向客戶交付可工作的資產(chǎn)、驗證重大假設或獲取有價值的認知來實現(xiàn)的。
6. 執(zhí)行
6.1 快速前進，但不匆忙
在 Scrum 中，核心目標是靈活、適應、快速?？焖俚恼J知和反應能夠及早產(chǎn)生收入或降低成本。但是，不要匆忙，不然可能違反 Scrum 可持續(xù)節(jié)奏的原則——人們應該以長期穩(wěn)定的節(jié)奏工作。而且，匆忙還可能付出犧牲質(zhì)量的代價。
6.2 內(nèi)建質(zhì)量
在 Scrum 中，質(zhì)量并不是測試團隊在最后階段“測”出來的，而是由跨職能的 Scrum 團隊負責并持續(xù)內(nèi)建于每個沖刺中。
6.3 采用最小夠用的儀式
計劃驅(qū)動的開發(fā)過程傾向于重儀式、以文檔為中心、重過程的方法。
Scrum 是以價值為中心的，它帶來的一個副作用是，幾乎不強調(diào)以過程為中心的儀式。我們的目標是消除可有可無的繁文縟節(jié)，因此，我們?yōu)閮x式設定了一個較低的標準，“基本夠用”。
Scrum 并不反對文檔。相反，我們是從經(jīng)濟角度仔細審查需要創(chuàng)建哪些文檔。
