在學習了評估價值和為需求排定價值優先順序的一些方法之後，我們接下來就看看在迭代或者衝刺中應該注意些什麼才能不枉費之前的努力。畢竟前期花了那麼大的精力，但是迭代衝刺之後卻提交了乙個沒什麼價值的產品，那可不是所有人願意看到的結果。如果把之前的操作都看作是計畫的話，那麼敏捷最主要解決的就是乙個 計畫趕不上變化 的問題。我們擁抱變化，前提是這些變化確實是對客戶有價值的。
從最早我們接觸到敏捷概念開始，就知道敏捷最大的特點是迭代、增量式的開發。在這裡，我們再具體的說一說增量到底增的是什麼。其實你也應該猜到了，我們增量增的就是最有價值的那一部分。而價值是如何衡定的呢？相信前面的文章已經說了很多了，在你的大腦裡也應該有一些印象了。
我們在每次迭代都會交付產品的一部分，但有時候並不一定每次的結果都會是一次完整的交付。我們用什麼來確定這次交付之後價值確實會產生？那就是上線，或者說是發布。
我們的發布計畫一般會以乙個發布路線圖為基準。在這個路線圖中，我們會在乙個或多個迭代之後進行一次發布。這個發布是以上線為標準的，也就是說，我們要確保發布的質量，確定這次的發布是沒有問題的一次發布。
雖然，一次把事情做好是乙個好的要求，也是乙個好的習慣。但是，我們的發布，特別是最初的發布，往往都充滿著不確定性。這些不確定性的由來也是專案會產生各種風險的主要原因。那麼，我們有什麼方式來解決這個問題呢？
沒錯，這裡又要引出乙個 最小可行性產品 的概念。它的英文簡稱是 mvp ，這可不是 nba 球賽中的那個 mvp ，而是 minimum viable product 的簡稱。它還有乙個別名，最小市場特性 mmf 。
這個產品不同於 產品經理 所畫的 原型圖 或者 線框圖 。那些是測試性質的「圖」，mvp 是真實可以上線執行的產品，而且是可以匯入 種子使用者 的產品。這樣的產品有什麼用處呢？最典型的就是可以「試探」市場，而且是非常快速地進行驗證。
很多網際網路公司的產品會有 「灰度發布」 這一概念，當然，這是對**進行大改版時的主要操作。目的就是通過篩選一批種子使用者進行測試反饋從而驗證新的功能介面是否符合預期。對於老產品中新功能的推出也有類似的例子，比如我們經常會收到一些**的邀請去體驗最新的功能。這些，其實都是網際網路公司的專案開發團隊在進行 mvp 的驗證。
一般 mvp 的驗證會在初始階段也就是第一次發布實現，而且這個發布是越快越好，越早越好。在通過 mvp 之後，我們就要進入正式的迭代衝刺階段了。在這個階段，我們要如何保證每次的迭代衝刺以及發布計畫都符合我們的價值交付的理念，這就需要一些敏捷工具的支援。
任務板和看板
通過敏捷框架的學習，我們已經了解過 精益 中的看板和 scrum 的任務板。看板的功能是什麼？監控進度？不，更重要的是資訊視覺化。之前就強調過，團隊中的所有人都可以看到，都可以思考這個任務到底有沒有為專案產品帶來價值。在這其中，在製品 wip 又是乙個重要的內容。
在製品與在製品限制
在 精益 的學習中，我們就已經接觸過 wip 的概念。我們的任務其實和流水線上的在製品是一樣的。還記得 精益 的核心嗎？消除浪費。在沒有成為乙個可交付的產品之前，在製品是消耗著投資方的資本並且沒有任何交付反饋的。同時，過多的 wip 還會降低整個工作流程的效率，同時掩蓋這些效率問題。最後，在製品沒有解決，帶來的就是返工和質量問題的風險。
由於這些問題的存在，敏捷主要關注的就是如何去限制 wip 的數量。通常的做法就是使用 看板 ，當看板上出現空閒的列時，或者任務過多產生堆積的列時，就表明 wip 出現了問題。這時，我們就需要關注在這其中最核心的瓶頸事務。消除瓶頸任務，是限制 wip 的核心。它要解決的問題是優化生產效率而不是優化資源利用。當生產效率問題解決後，產品的價值才能更順暢的通過增量交付。否則，我們交付的價值可能是充滿不確定因素和風險的未知內容。
瓶頸任務有哪些呢？最典型的就像是我們的資料庫設計出了問題，或者使用者介面有邏輯方面的錯誤，這些其實都是 非功能性需求 ，而這些需求非常容易產生瓶頸。這時候，往往需要大量的時間來解決。相信團隊的力量，及時調整發布計畫，盡早解決瓶頸或者將瓶頸移到下乙個迭代衝刺中做為最高優先順序的任務來解決。這些都是我們可以應用的方法。
想像一條高速公路，它通行最順暢的時候是我們有計畫地限制車流的時候。而在一次迭代衝刺中，限制 wip 的數量，也是這樣的概念。另外，它和 scrum 中不能修改任務這一條是不衝突的。因為這些往往是不在計畫之中的情況，也是我們在一次迭代之後的評審中所要關注的重點問題。
累積流量圖
同樣也是針對 wip 的乙個工具。我們先來看看這個圖長成什麼樣。
這一張累積流量圖可能比較複雜，我們可以看到橫軸是時間，縱軸是工作項數量，也就是我們的需求數量。曲線表示各個步驟中所完成的需求數量。核心關注的是開發線和完成線，中間的垂直距離就是我們的在製品數量。
從這個圖中，我們可以清晰地看到 wip 的消耗情況，曲線之間的差距變大則表示 wip 在增加，效率受到了影響。正常情況下，它們應該是保持恆定並最終與最頂上的 backlog 線交合到一起。這時，也是專案完成的時間。
它是乙個綜合的價值流度量方法，可以得到不同維度的資訊。讓改進更有方向，我們可以縮短週期時間，或者增加迭代週期內的任務數量，所有的手段成功與否，都可以從這張圖中清晰地反映出來。
漸進明細
換個說法，滾動式規劃。專案中的不可預見因素太多，而且在每次迭代後都可能出現未知的問題和瓶頸。這也正是敏捷中將 可交付的軟體 高於 完備的文件 的原因。在每次的迭代衝刺之後，評審會議就成為了非常重要的一點。就像上面所說的，對於 wip 中的瓶頸的解決，也是體現在這裡。
甚至很多情況下，客戶或者使用者都不清楚他真正想要的東西是什麼，我們盡早交付價值的原因也是讓所有人都清楚，我們現在交付的「價值」到底是不是真實的客戶所需要的價值。所謂撥開雲霧見真章，這也是敏捷的核心思想。因此，敏捷提倡的 客戶合作 並不是空穴來風。頻繁交付、隨時變化、客戶合作，似乎我們又重溫了一遍敏捷宣言。
對於敏捷專案來說，怎麼簽合同其實是乙個挺棘手的問題。如果是傳統的專案，在部分情況下由於已經有了固定的工期和前期的成本估算，所以往往都會是乙個固定總價合同就搞定了。這也是我們最常見的外包情況。
但是，敏捷對於「固定」這兩個字並不友好。因為我們一直在強調敏捷是要擁抱變化的。所以說，傳統的固定總價合同明顯不適用於敏捷專案。那麼成本補償合同呢？這個合同本身就不多見，因為它比較利好於乙方，如果甲方沒有強大的審計能力，那麼也不太可能簽出這樣的專案合同。
那麼對於敏捷來說，我們可以使用什麼樣的合同呢？第一，既然我們一直在講價值驅動交付，那麼我們也可以按照發布以及對應價值的完成來分階段簽定階段性的固定總價合同。比如說，我們每乙個月或兩個月會有一次發布，那麼我們的合同就以這個發布週期來每次單獨進行簽定。
除了這種合同之外，還有一種直接就是對工作包建立固定**的合同，這種合同就更詳細了。其實，上述的兩種合同都有點麻煩，因為我們可能會經常來回地去簽字。其實，還有一種合同也是不少敏捷團隊的好選擇，那就是固定總價+變更費用合同。先以類似於傳統專案的方式預估乙個總價，然後再制定變更費用的條款細則。如果不加錢，那麼就根據變更項的優先順序砍掉較低優先順序的內容。
總之，敏捷合同其實是非常不好籤的，如果甲乙兩方都是敏捷型的組織，使用工作包合同是相當不錯的選擇。但如果甲方是乙個非常傳統的大型企業的話，其實還是固定總價合同更適合。這一塊我們就當是簡單的了解，不需要太過於深入的研究，畢竟簽合同這事，我們所能提供的建議非常有限。
我們通過幾篇文章，幾百上千字說了半天的價值相關的內容。但是這些其實都只是計畫或者是一種意想的優先順序的排序。目的只是為了讓我們能夠清晰地弄清楚每乙個階段應該做什麼。但是當迭代衝刺結束的時候，我們應該要去驗證這個迭代衝刺或者是發布時的價值是否和我們的目標一致。所以，就需要我們 頻繁地驗證和確認 。這也是敏捷的乙個核心理念，通過什麼呢？測試、檢查點和評審。
在敏捷軟體開發中，測試驅動開發、探索性測試、mvp 這些其實都是為我們的測試提供的工具。為什麼敏捷這麼在乎測試，因為測試可以保證我們結果的唯一性。從而讓我們很快的就能得到反饋，也方便後續的持續整合。正常來說，一次持續整合就是通過所有測試並且可以進行線上發布的版本。這個版本在未發布前都是可以做為我們的檢查點的。在迭代衝刺結束時，評審會議將是我們核對價值實現的乙個重要方面。這些內容在之前的敏捷框架中都已經有過說明，如果沒有印象了，那就回去再好好看看吧！
這下我們算是搞清楚增量交付到底是交付的什麼，以及真實的客戶價值其實就是在一次次的迭代中通過增量的價值交付所找到的。最後我們簡單地了解了下敏捷合同以及如何核實和驗證交付的價值。可以看到，價值是敏捷中非常重要的東西，而交付價值則是貫穿敏捷原則的一條主線。說白了，敏捷定的宣言、原則，各種框架工具，最終的目的是什麼呢？就是為了向客戶交付價值。
好了，價值相關的討論我們就告一段落，接下來我們將學習的是與 客戶、領導 或者 甲方打交道的內容，也就是對於 相關方 的規劃管理。內容還有很多，精彩還在繼續！
《某培訓機構教材》
《使用者故事與敏捷方法》
《高效通過pmi-acp考試（第2版）》
《敏捷專案管理與pmi-acp應試指南》
訪談 關於持續敏捷交付與服務矩陣
andy singleton所著的 unblock a guide to the new continuous agile 一書為基於雲的分布式開發提供了持續交付的思路和實踐。書中講述了如何構建 測試 頻繁發布 以及如何讓處於持續交付環境中的管理團隊 產品和企業做到持續敏捷。關於什麼是持續敏捷 它和...
訪談 關於持續敏捷交付與服務矩陣
andy singleton所著的 unblock a guide to the new continuous agile 一書為基於雲的分布式開發提供了持續交付的思路和實踐。書中講述了如何構建 測試 頻繁發布 以及如何讓處於持續交付環境中的管理團隊 產品和企業做到持續敏捷。關於什麼是持續敏捷 它和...
敏捷武士看敏捷高手交付卓越軟體一書讀書筆記
一 讓每個人都上車 1 將專案的目標 願景和背景傳達給團隊成員，使其在執行過程中做出明智的決策。2 向利益相關者提供資訊以幫助他們決策專案是否應該繼續。二 交付啟動計畫 1 為什麼會進行這個專案。它快速地提醒我們為什麼會進行這個專案 客戶是誰以及為什麼會決定首先考慮這個專案。a 深入工作現場 b 發...