對于一個項目來說，以疊代和增量的方式進行運作意味着什麼？在本系列的文章中，我們通過分析涉及項目的各種觀點來回答該問題。在第一部分中，我們定義了什麼是我們所謂的疊代和增量開發，并分析了這種方式對生産軟體的核心開發團隊來說意味着什麼。在 第二部分中，我們集中讨論了以疊代和增量方式運作項目對客戶意味着什麼。在這最後一部分中，我們考慮疊代和增量開發對項目管理團隊的影響。
一旦您讓那些在一系列共享的疊代工作中進行協作的業務和開發團隊緻力于将業務價值移交回業務中，您就需要考慮管理觀點以及為什麼它是重要的。
首先，設想一個缺乏管理指導的軟體開發項目。（也許您已經參與過一個這樣的項目)。這種項目經常缺少中長期的方針，前進的方向似乎按照随機路線，并且很少有團隊成員知道他們努力的方向。不制定疊代，您很難知道項目什麼時候完成、完成項目需要什麼資源，或者什麼時候需要這些資源。不估計産品的成本，很難使客戶和贊助人為最平凡的項目提供資源，且不能顯示出項目是如何朝着傳遞解決方案的目标前進的。
人們很容易陷入這樣一種理想的思維困境，即如果一個團隊受委托要達到一個目标，那麼他們将自動地自行組織并實作他們對組織的所有承諾，且迅速有效地傳遞高品質的軟體。事實上，甚至最好的團隊也需要一些監督來確定日常的工作向長期的目标進展着。更重要的是，管理的任務是将能夠進行這樣工作的團隊集合起來。
糟糕的管理從根本上導緻許多項目的失敗，這一點也不意外。 1 很容易令人相信的是（如許多非管理人員所想的）管理隻不過是疏遠官僚主義，管理人員的作用是在其他團隊成員工作時阻止官僚主義。事實上，許多普通的管理是這樣的。但是，如果所有的管理人員都這樣做，那麼項目将很可能失敗。
管理不僅是記錄意見、保持進度及考慮預算：提供上司能力和方針是達成結果所必要的。适當的管理為必要的問題提供清晰的答案：
- 我們解決的問題是正确的嗎？
- 我們擁有傳遞解決方案的資源嗎？
- 我們現在是在處理正确的東西，朝着最終的目标進行着嗎？
- 我們是在欺騙自己，認為能在配置設定的時間和資源之内真正傳遞解決方案嗎？
計劃和測量不是到他們自身的終結，而是幫助管理人員回答這些問題的工具。
項目管理人員的觀點
如我們在第一部分所講的，一個疊代包含将軟體開發的核心規程應用于生産出可證明的，可執行的開發後的産品，并確定在一系列的疊代後（每次都根據産品和由先前疊代而來的教訓）産品會不斷增進。這在圖 3-1 中表現出來，依賴于第 1 部分的圖 3 和第 2 部分的圖 1 和 5 中所示的開發團隊、業務分析員和客戶的觀點。
圖 3-1：從項目管理人員的觀點考慮的疊代項目
從項目管理人員的觀點出發，每次疊代似乎是将軟體開發的所有規程應用于生産滿足具體的已達成協定的目标集合的産品的過程中的小型獨立的項目。疊代是小型項目的觀點與應用最普遍的項目定義一緻，如：
項目：承擔建立獨特的産品、服務或結果的臨時努力。 2
疊代确實是臨時的、延續兩個到六個星期、 3 并在疊代的可論證的釋出中生産出獨特的産品。
最簡單地說，疊代計劃過程是協定、執行和評估的循環：
- 對疊代的目标，包括評估标準、時間表和限制，與團隊達成協定。
- 對團隊将如何實作目标的計劃達成協定。
- 執行計劃。
- 根據最初的目标集和評估标準來評估團隊的成就。
- 從整體上評估疊代結果對項目的影響。
- 開始下一次疊代。
從管理人員的觀點出發，這些活動在整個項目中會不斷地發生，如圖 3-2 所示，并形成基本模式（可以按照這樣的模式對關于疊代的工作進行計劃和管理）。
圖 3-2：從管理觀點考慮的疊代
管理人員還從整體上為項目提出方針，并組織工作以便每次疊代都逐漸地對解決方案的傳遞做出貢獻。要做到這點，他們必須從整體上計劃、執行和評估項目，并将項目作為一系列連續的疊代進行組織。管理過程的兩層之間的關系如圖 3-3 所示。
圖 3-3：整體的且疊代的項目管理過程
疊代和增量項目的計劃、監控、控制及管理在以下方面，從根本上異于非疊代的項目：
- 項目團隊互動的動态性
- 裡程碑的特性
- 對依賴的處理
- 度量和測度
- 必要的資源
- 項目工作的并行程度
最重要的差別之一是進展的度量方式。取代用中間工作産物（如需求文檔、分析模型和設計規格）的完成來度量進展，我們根據開發和測試的方案的多少來度量進展。 如圖 3-4 所示，每次疊代都将導緻向解決方案的傳遞的可度量的發展。
圖 3-4：度量成功測試的軟體中的增量
從對進展的主管評價（經常根據生成的文檔）到對進展的客觀度量（通過生産軟體的工作量來度量）的轉移是疊代方法和更傳統方法的最根本的差別。分析每次疊代結束時對進展的客觀評價的趨勢可以使項目管理人員控制項目并做出變更以提高項目成功的幾率。
疊代可以使項目成為一系列更小的獨立項目，每個項目都依賴于前一個項目的結果和性能。由每次疊代的結束時刻進行的評價所形成的回報使您可以對下一個和所有後來的疊代調整計劃。
品質管理人員的觀點
這些正常的疊代評估提供了評價進展的機制。在這些局部的裡程碑上，要根據目的和目标集由團隊評估疊代計劃中的進展。一個暗示是基于活動的狀态報告（您所處理的内容是什麼？）并不像基于成就的狀态報告（您已經完成了什麼？您接近到什麼程度？）那麼重要。利用疊代的方法，很難将事實隐藏很久。
事實上，這種測量活動而不是真實進展的方法隻會引發問題。項目團隊需要靈活地使他們的活動達到所期望的目标，項目管理人也許不能足夠準确地預見未來，以計劃所有用來實作目标的工作。更加開明且解放的做法是給予項目團隊一些需要達到的目标，并授權給他們可以靈活地響應變更。 通過限制創造能力和響應性，詳細的活動程度計劃實際上會危及項目成功而不是確定成功。
在每次疊代過程中對項目結果的客觀測量省掉了通過對中間産品的主觀品質評估來對項目進展進行的評估。取代通過堅持在開始建立任何内容之前結束使用需求來判定需求的品質，您可以通過拿到第一批可用的需求并使他們通過開發循環，在疊代的過程中，生成工作和測試了的代碼來評估需求。這為項目是否達到目标提供了客觀的證據，因為他們将在實際中使用而不僅是用于稱贊。度量品質的方法從根本上改變了。品質度量着重于正常的可以提供對項目的持續洞察的疊代評估。對過程和工作實踐的回顧有規律地捕捉從項目中得到的經驗，并在項目中造成一個持續的過程改進的文化。這些觀察可以立即被應用到下一次的疊代中以提高品質和團隊效率。
通過在每次疊代過程中測試生産出的版本、提供管理和品質訓示器，以及測量項目進展來進行客觀的度量。因為每次都要對前一次疊代傳遞的需求進行反複回歸測試，是以這種不斷的整合及測試導緻了随着項目進展而不斷增加的測試覆寫面，如圖 3-5 所示。
圖 3-5：在不斷的疊代中測試負載在增長
對疊代方法的采用可以幫助提高由以下内容傳遞的成果的品質：
- 通過将需求迅速地轉變成可以進行觀察測量的内容來盡早地減少對需求的誤解
- 通過檢驗技術方法來盡早地減少開發風險
- 從項目的一開始就調節并控制變更
- 在項目的早期，還可以進行變更的時候，提供一種方式來評估過程效力、進度表、團隊生産力，及資源是否充足
在疊代的方法中，品質管理人員集中于産品和過程的有用性，從整體上支援團隊的效率。強調從完整性到“适合目标”的其中一項内容的品質變更。品質管理人必須放開這樣的誤解，即“停止産品并不再做變更會帶來更進階别的品質。”
這并不意味着事情永遠不完結 —— 隻是要求項目團隊不要考慮這樣的完成，以便他們發揮積極減少項目風險的才能。
有一個普遍的誤解，疊代開發從未真正完成工作，一些人将靈活的疊代項目視為要永遠進行工作。這肯定不是真的。 對所有的疊代存在一個最終的目标：最終版本。每次疊代就像一面牆中砌好的一列磚：每次疊代都為達到築牆的最終目标做出貢獻，并且可以測量每次疊代對整體目标的貢獻，就像可以測量每個砌好的磚列對整堵牆的貢獻一樣。
總結：從團隊觀點考慮的疊代
采用疊代和增量開發技術不是隻影響到開發人員和其他涉及項目的技術人員的純技術決策。它代表着設計和發展項目所采用的方式的根本變更，一個影響到每個參與項目的人的變更。是以疊代開發要求整個項目團隊改變工作和互動的方式。同時，項目管理不再必要，這不是一個意義深遠的變更。而是它簡單地需要一種不同的更适應管理的方法。
疊代開發是針對問題解決和解決方案開發的基于團隊的方法。它要求所有參與的人 —— 包括開發團隊、客戶團隊，和管理團隊 —— 都采用協作的技術。
從開發團隊的觀點出發，采用疊代和增量開發是需要授權的，并要求團隊成員積極進取地用他們認為最适當的方式處理項目危機和難題。通過設定清晰的目标和客觀地度量結果（但不訓示活動）來管理疊代可以確定輕松地找到最佳的方式來傳遞成果。
從客戶和業務團隊的觀點出發，引入清晰有意義的目标，并結合回顧可論證成果的能力，可以使那些最終使用新軟體的人在項目中發揮積極作用，并與開發團隊分享所有權。疊代對所有涉及項目的業務人員産生深遠且長久的影響，并且從根本上改變了他們規定、支付，并實作軟體解決方案商業利益的方式。
從管理團隊的觀點出發，每個項目都被分解為一系列小的項目，稱為疊代，每個疊代都建立在前一個疊代的結果之上，并不斷增加地實作項目的總目标。當授權開發團隊創造革新的且有效的解決方案時，這種對項目的分割引入了正常的，可度量的，使項目保持正軌的裡程碑，将項目成功的幾率最大化。