4.2　小批量持續流動的流程

我們前面講過，軟件交付過程要追求快，從改一行代碼到把它發布上線，都要盡量快。因為從確定需求到設計開發再到發布上線的整個流程，就是要盡量快。那么如何做到呢？一個重要的策略就是不要等待。

4.2.1　大批量帶來等待等問題

觀察瀑布模式中的等待：由于大批需求被一起規劃設計，所以盡管每個需求可能只需要不多的設計時間，但是需要等待所有的需求都被設計好后才能開始實現。大批需求帶來很大的開發工作量，在實現某一個具體小功能時，可能只需要不多的時間，但需要等待所有的功能都實現后，才能進行集成。大量的軟件改動帶來繁重的集成工作，如果到項目后期才集成和測試，那么就要等問題一個個冒出來并被解決掉，說不定還需要多輪測試。總之，對于軟件的一點改動，花在它本身的功能設計、代碼實現、質量保證上的時間可能并不多，但是由于總是需要湊齊足夠的需求才能往下推進流程，所以等待的時間就會很漫長。最后的效果就是從確定需求到發布上線的整個流程，很慢。具體到本書關注的軟件交付過程，也是很慢的。

當總是需要湊齊需求時，還會帶來一些連鎖反應，讓流程變得更慢。其中最明顯的問題是，修復一個Bug所花費的時間變長了。比如你改了幾行代碼，當時就得到了反饋，提示寫得有問題，那么你自然就只需要在那幾行代碼中排查。那幾行代碼又是剛寫的，記憶還新鮮，很快就能找出原因并改正。但是，如果過了很久才得到反饋，那么你就不知道問題是具體哪個地方的改動引起的，從而導致排查困難。而且那段程序的結構和邏輯，你可能也記不清了，又要重新熟悉，重新進入狀態。

4.2.2　短周期、小顆粒度、減少在制品

這么看來，等待真不是一件好事兒，要盡量避免。如何避免呢？別湊一大批！也就是說，要在各個方面追求小批量：小批量的設計功能、交代開發任務，小批量的集成，小批量的測試，小批量的發布。這樣就有可能讓整個流程持續地流動起來，而不是走走停停。

瀑布模式顯然違背了這一策略，導致了漫長的交付周期。而如果將四周甚至兩周作為一個迭代周期的話，相比之下就好得多。然而這并不是終點，它可以更好：一方面，迭代可以一直延伸到上線，而不是止步于內部演示版本，上線才是真正的Done；另一方面，一次迭代包含了多個需求，它們之間還是會相互等待、相互影響的。所以，更理想的情況是每個需求都可以在精益看板墻上不受干擾自主地往前走：開發、測試直到發布。也就是說，想改就改、想測就測、想發就發。

這里需求的顆粒度也有講究，不要太大。所以在精益需求分析與管理實踐中，要做需求拆分：將大需求拆分成小需求，可以分別獨立開發和發布上線。這也符合小批量的原則。

在精益方法中還提到了控制在制品數量，因為在制品數量大意味著排隊等待時間長，也意味著一個人可能要并行處理多件事情，需要頻繁切換。控制在制品數量，也符合持續流動這個原則。

4.2.3　小批量持續流動的交付過程

以上是從敏捷和精益的視角來看小批量持續流動這個策略的。下面我們來看看持續集成、持續交付是如何踐行小批量持續流動這個策略的。

持續集成意味著代碼改動要及早和經常提交與合并，這樣有利于減少合并沖突和錯誤，并且在彼此工作有依賴時，能及時獲取到別人的改動，及早開工。

持續集成還意味著及早和經常構建與測試。一旦收到提交的代碼，就自動進行構建、靜態代碼分析、單元測試等工作，以便盡早發現問題，而不是非要湊齊再開始。顯然，這也符合小批量持續流動的原則。

持續交付更進一步，把及早和經常做的事情擴展到了部署到測試環境并測試，甚至擴展到了及早和經常發布上線。

可見，敏捷、精益、持續集成、持續交付，它們都反映了這個重要的策略：小批量持續流動。

以上講的是大的方面。根據小批量持續流動這個原則，在集成發布階段還有不少細節值得注意。比如發布窗口應當盡量去掉，做到無須等待、隨時發布。