成功的現代項目——以及使用傳統過程開發的成功項目——通常都有詳細定義的項目階段性標志，即從創造性研究狀態到生產狀態的顯著過渡。早期階段著重于實現可演示的功能。后期階段著重于實現可供用戶使用的產品，這種產品關注的是健壯性、性能、適用性以及完整性。
另一個重要方面是從創造性世界到生產世界的過渡對整個團隊的影響。結構良好的團隊通常不喜歡嚴格的過程、細節以及不成熟的精確性。生產能力強的團隊通常會對松散的、不固定的、粗糙的結果感到不愉快。項目管理者需要管理各種團隊的平衡性，這樣技術上領導的重力中心可以在整個生存周期發展進化，從初始階段的管理團隊，到細化階段的架構團隊，到建構階段的開發團隊，再到過渡階段的測試/評估團隊。軟件項目管理中人的因素被低估了，而且團隊動態性的主題值得被給予比大多數項目管理課程所給予的更多的關注。
進展
經典開發過程的很多方面造成了涉眾關系退化到相互間的不信任。信任對在用戶需要、產品特性以及計劃中通過指導和協商取得平衡是基本的。迭代過程加強了涉眾間的有效交流（通過一系列可演示的發布實現），允許基于更為客觀的所有人理解的協商。這需要客戶、用戶、以及管理者集中于可用系統的發布，而不是篤信標準和合同條款。它同時還需要開發組織致力于用能獲得利潤的方式創造價值。
迭代過程需要對一個不斷完整的系統進行順序的建構，這個系統展示了架構，實現了客觀的需求協商，證實了技術方法，并指出關鍵風險。理想的情況下，所有涉眾都著眼于這些里程碑，把它們視為有用功能的遞增發布，這不同于那些投機的對終觀點的論文描述。向可演示驅動的生存周期的過渡造成了非常不同的項目外觀。一個健康的項目將誠實地展示出一個進展與背離共存的序列，而不是一個線性發展價值遞增的軌跡（通常是不誠實的）。
下面是兩個我從未見過的反例的相關觀察：
1.一個具有一張價值持續不斷增長曲線圖的軟件項目一定會有一個待解決的很大的回歸。
2.在解決不確定性，會師于一個可接受的解決方案的過程中，健康的軟件項目表現為一個進展不斷增加，彎路不斷減少的序列。
雄心勃勃的展示是一個健康的項目的發展道路上絕好的里程碑。在生存周期早期進行展示的目的是暴露設計缺陷，不是粉飾門面。涉眾不應對早期錯誤、背離或不成熟的設計反應過激。如果早期工程階段受到過分限制，開發組織建立的中間檢查點將不會那么有抱負。早期的增量是不成熟的。外界涉眾，比如客戶和用戶，不能指望初始發布的版本擁有終發布版本的規格和性能——也是完整、完全可靠、擁有目標級的質量和性能。
另一方面，開發組織必須對連續增量之上的切實的進展負責，并對之進行展示。客觀地量化變化、修改以及更新將會為進展和質量提供誠實的指示。公開和專心的追隨對解決問題是必須的。好的和不好的項目性能在生存周期的早期往往更為明顯。采用指導式的領導方式，成功會孕育成功。在發布一系列可演示的結果以后，你可以很好地預測結果了。持續沒有進展或者停滯的結果序列是項目需要認真重新考慮資源、范圍或者項目價值的標志。軟件項目的經驗已多次表明，早期階段決定項目的成敗。這是使用小型的、能力強的出發團隊處理計劃和架構設計階段工作的原因。如果這些早期階段處理得當，項目將會由能力中等規模的團隊向終產品發展，并成功完成。如果計劃和架構設計階段處理不好，即使出動全世界的程序和測試專家可能也無法在后續階段取得成功。
質量控制
如果你按照迭代開發的精神正在成功管理一個項目，那么多數集成測試應在部件測試之前進行。停下來思考這一陳述。盡管在任何時候都有兩種活動在混合進行，你應該認識到初始的部件開發和測試更多的是作為在一個集成的、系統級的線程或行為內執行一個部件的接口和功能的方法。一旦接口和集成行為被成功測試，部件的完整性也可以測試了。先進行集成測試加速了架構上重要的問題更早進入生存周期的相應階段。它還為持續的系統級和部件級進展和性能的評估提供了演進的測試模板。
這種先進行集成測試的方法的一個關鍵副產品是測試和測試人員成了項目過程中的頭等公民。在傳統方法中，測試人員建立計劃、過程和文檔，它們都是次要于分析和設計工件的。測試人員的工作和生存周期早期的工件對項目的成功沒有太多指示作用，在多數組織內都是由“B選手”（意思是，不能成為分析和設計師的人）來完成的。在健康的迭代項目中，生存周期早期的演示需要重要的測試觀念和產品。很多測試團隊對一些有效的“分析”活動和結果負有責任。太多分析人員在抽象模型內單獨工作，他們的分析受到的制約是有限的。但是測試人員面臨的是建立“測試用例”——真實世界中用例或者評估標準或者預期行為的表現。他們提出一整套不同的問題并從一個不同的角度看世界，因為他們的工作是把抽象的東西翻譯為可測試的東西。
這是一個例子。現在很多項目都面臨著對商業上可獲得的部件和應用程序是采取買還是自己寫的辦法的抉擇。如果第一個面向結果的項目的里程碑是通過演示來作出自己寫/購買的決定的，那么你應該對你的團隊進行如下分工：
分析團隊：與用戶一起工作，捕捉產生差性能的關鍵用例的情況，比如數據量峰值或者關鍵的控制畫面。
設計團隊：設計可以運行候選商業部件的原型。
測試團隊：構建測試用例（比如，一個消息集合、一個測試驅動、一個智能樁模塊、一個有數據的數據庫、一個圖形用戶界面操作的序列等等）。這些用例能夠反映關鍵用例，驅動原型并記錄它的相應。
為了實現這第一個里程碑，你的團隊可以只關注其中兩個關鍵用例（約為用戶需要的10%）、少數幾個關鍵部件以及少數幾個測試用例，但是它們以及用戶將會在生存周期非常早的時候解決掉30%的風險。通過把測試觀點作為過程早期一個同等伙伴包括進來，你將可以吸引更多作出更好分析的人才，因為這項工作更為有趣，而且對成功的貢獻更為有效。
傳統軟件測試方法遵循相同的、應用于軟件開發的文檔驅動方法。開發團隊在建立任何源文件或可執行文件之前先建立需求文檔、頂層設計文檔以及詳細設計文檔。相似地，測試團隊在建立任何測試驅動、樁模塊或工具之前先建立系統測試計劃文檔，系統測試過程文檔、集成測試計劃文檔、單元測試計劃文檔以及單元測試過程文檔。這一文檔驅動方法對測試活動造成的問題與它對開發活動造成的問題是相同的：對大量廢物的刨光，還要留待日后重新組合整理。
為了在生存周期中提早進行集成測試，測試序列應該由迭代過程來組織，而不是根據部件來組織。典型地，它應該被一組用例和其它文本表現的、能有意義地為用戶進行演示的實體所捕獲。下面是一個抽象的描述：
初始迭代：大約五到十個評估標準，抓住與主要用例（對結構選擇和整體商業案例有影響的）相關的驅動問題。
細化迭代：十幾個評估標準，當用候選架構進行演示時，為主要用例檢驗實體框架，并證明關鍵風險已經被解決了。
構建迭代：大約數百個與有意義的用例集相關的評估標準，這些用例集通過測試以后將組成有用的產品子集，可以轉為產品的alpha或beta發布版本。
產品化迭代：完整的用例集和相關的評估標準（可能有上千個），組成了與真正發布產品相關的接受測試結果的標準。
現代過程在產品的測試活動中使用的基本工具、語言、符號以及工件與在產品的開發過程中使用的是相同的。測試是指對某些組件在一個控制情境下的執行以及期望的客觀結果的外在評估。一個測試的成功取決于在一般意義上定義的成功標準下期望結果與實際結果的比較情況。測試是可以大規模自動化由機器完成的評估形式。
