廣泛的引用這些變化作為一種“新的思想”，我們將關注軟件開發(fā)項目中的不同個體角色：
在傳統(tǒng)的瀑布型的方法中，分析人員與用戶和項目團隊之外的涉眾打交道。目標是理解并開發(fā)一個代表了一系列需求的方案，文檔化這些需求然后將這些需求文檔交給開發(fā)團隊。一些開發(fā)組織用一種“未來”狀態(tài)的長列表來詳細說明需求；另一些組織在高層次上表達需求，為解釋需求保留了很大的空間。在這兩種情況下，必須有這樣的假設，分析人員既要了解業(yè)務又要了解用戶，并且這個分析人員應該是指定系統(tǒng)應該具有什么功能的人。
一旦分析人員文檔化了需求，他或者她就會要求用戶來檢查這些需求文檔（甚至如果他們不能完全理解用來表達需求的技術語言，并且/或者他們不能通過可視化的方法來表示當系統(tǒng)被實現(xiàn)時許多需求是如何滿足用戶的需要的）。然后，實現(xiàn)需求規(guī)格說明就是開發(fā)人員的工作了。典型的，不論是開發(fā)人員還是測試人員都沒有參與到闡述需求的工作中。并且一旦需求被規(guī)格化，很少會有在分析人員與設計人員之間的積極的交互。分析人員只是簡單的闡明需求說明書中包含的內容。
這種傳統(tǒng)的模型在某些方面的缺陷將在下面被解釋。
 |
|
首先， 瀑布型的方法失敗的認識到客戶、開發(fā)人員和測試人員參與需求說明工作的價值。沒有對業(yè)務和技術擁有優(yōu)秀的理解將不可能創(chuàng)建出能夠改進你的業(yè)務的軟件系統(tǒng)。不幸的是，很少有人同時在業(yè)務和技術領域具有深厚的知識背景。這就意味著，分析人員、開發(fā)人員、測試人員和客戶應該一起工作提供需要的所有的信息以確保開發(fā)人員可以創(chuàng)建“正確的”軟件系統(tǒng) — 也就是說，一個充分滿足客戶業(yè)務需要并且提供從根本上有效的改進客戶業(yè)務的能力的軟件。
讓我們來看一個簡單的例子以說明這樣的團隊協(xié)作的好處。
例子：基于 Web 的航班預約系統(tǒng)
我們假設一個分析人員負責對這個基于 Web 的自助服務的航班預約系統(tǒng)的需求工作。這個分析人員指定用戶將提供一個航班的代碼并指明行程的開始地和目的地。如果用戶不知道航班代碼，他們可以通過提供城市名字進行查詢。然后，這個分析人員指定，在用戶預定了一個指定的航班后，他們將會得到關于如何聯(lián)系不同的代理以預約到達目的地時的地面交通工具。
當設計人員檢查系統(tǒng)需求時，他回想起曾經(jīng)看到過一個能夠提供部分功能的并且經(jīng)過證明的Web 服務的方案。這個低成本的服務允許用戶導航機場的地圖顯示并快速的找到符合他們需要的機場，甚至假如用戶不熟悉他們的目的地城市或者不熟悉目的地的地區(qū)的機場。
在與客戶驗證了策略后，分析人員和設計人員對需求作了改動以包含這個 Web 服務的實現(xiàn)。然后，在幾天的開發(fā)工作后，設計人員發(fā)現(xiàn)了這個服務的另一特性：當用戶選擇了一個機場時，他們會自動的收到一個機場信息的列表，信息中包括可得到的地面交通工具的模式和對每種模式預定的容量。設計人員和分析人員與客戶和項目經(jīng)理討論了這個發(fā)現(xiàn)，大家都同意合并這個額外的 Web 服務的特性到他們的新系統(tǒng)中，代替他們原來指定的創(chuàng)建一個地面交通引用的特性。
就像你從這個簡單的例子中所看到的那樣，在項目的早期階段就讓設計人員/開發(fā)人員參與到需求中能夠帶來巨大的好處。他們中的每一個人都可以建議分析人員或者最終用戶考慮不到的能力和方案。當然，衡量預期的項目范圍變化的價值仍然是項目經(jīng)理和客戶的責任，分析人員仍然必須理解業(yè)務需要并驅使系統(tǒng)應該在何處結束。但是他或她可以通過與設計人員/開發(fā)人員協(xié)作找到更好的方案。
傳統(tǒng)開發(fā)模式的另外一個缺陷是缺乏在分析人員與最終用戶之間的交流。 最終用戶被期望預先的指出需求并且對需求進行檢查，但是他們有限的參與了方案的開發(fā)。在許多情況下，和約的商定是以預先被描述的需求為基礎的，并且后來的變更需要有一個和約上的協(xié)商。
在整個開發(fā)的生命周期中維護在用戶與分析人員之間的交流是尤其有效的。雙方都應該理解他們擁有相同的目標：建立滿足質量要求的可以解決問題的方案，同時成本是可接受的。如果他們的關系是圍繞著爭論關于什么是以前達成的一致和誰應該為此付錢，而不是建立一個正確的方案的話，那么項目就陷入了麻煩之中。這并不意味著分析人員應該接受所有的需求或者最終用戶不應該作出變更的請求。相反，這意味著所有的項目相關的人員應該在提出需求和最終進入到訂單中的需求進行一個平衡以形成更好方案的開發(fā)。他們需要認可當他們過分的嚴格時，應該通過一些討論以達到一個折中的方案，并且要作積極的改變以保持項目按照計劃進行。當然，這一點做起來要比說的有難度。但是朝著有效的團隊協(xié)作的第一步是在分析人員與最終用戶之間建立起有建設性的對話。
傳統(tǒng)的開發(fā)方法提倡詳細的預先需求，并且在過去的多年里很多人覺得項目失敗是因為他們的需求對啟動項目是不夠詳細的。但是增加需求說明的詳細程度將會減少的回報。在一些情況下，項目團隊需要不斷的構建方案，并假設需求在整個項目周期不斷的改進。記住： 軟件項目的主要目標是在盡可能低成本的條件下生成可執(zhí)行的能夠解決手工形式的業(yè)務問題的代碼。一旦你的需求到達了一定的細化程度，將他們定案的最廉價的方法是對系統(tǒng)進行部分的實現(xiàn)以可以向最終用戶進行演示。同時你可以一起確定你還需要提供什么樣的其他能力。 定案需求通常要經(jīng)過幾次的迭代，在迭代期間你可以調整需求、設計和代碼，然后對測試進行引導。
在項目周期的后期你可以不必正式的文檔化很多的詳細的需求；代碼本身可以提供足夠的文檔，并且很少在團隊中誤解什么是需要實現(xiàn)方面存在風險。這依賴于正被開發(fā)的系統(tǒng)自然的改變了參與的人數(shù)、系統(tǒng)期望的生命跨度、和約的義務和附加的質量標準的需求。最后，也許是最重要的，你應該象驅趕技術風險一樣在項目中盡早驅趕商業(yè)上的風險。 在細化預想的需求上花費過多的時間會使你的注意偏離出降低關鍵的風險。
|
|
 |
|
迭代開發(fā)，對開發(fā)人員來說使用與迭代開發(fā)相關聯(lián)的最佳實踐和現(xiàn)代的工具技術，同樣需要在思想上的轉變。首先，就像我們在上一部分討論的，開發(fā)人員需要在指定需求中扮演更多積極的角色。
過去，開發(fā)人員以對辣手的問題提出聰明的解決方法為榮。他們創(chuàng)造唯一的方案以使系統(tǒng)性能最大化、內存使用最小化或者提供良好的圖形用戶界面。當然，開發(fā)人員仍然需要提出聰明的方法， 但是他們的精力需要從構建方法轉向到發(fā)現(xiàn)聰明的方法以盡量的將可重用的資產(chǎn)、開發(fā)源碼的軟件、通用的商業(yè)現(xiàn)貨 (COTS) 組件和 Web 服務集成成為一個可使用的方案。為了成為優(yōu)秀的開發(fā)人員，你需要知道如何最好的利用交互式的開發(fā)環(huán)境（IDE）和建模環(huán)境。“這里沒有發(fā)明”的態(tài)度是達不到預期的目標的；作為一個開發(fā)人員，你的精力應該放在通過利用各種可重用的資產(chǎn)來產(chǎn)生可使用的方案上。今天快速并廉價的生產(chǎn)出高質量的產(chǎn)品才是應該受到褒獎的。
質量是測試團隊的職責。在傳統(tǒng)的開發(fā)中，在項目的最后幾周，整個系統(tǒng)才交付到可憐數(shù)量的測試人員手中，他們被要求盡可能多的找出軟件系統(tǒng)的缺陷。他們負責質量，開發(fā)人員負責修改他們發(fā)現(xiàn)的缺陷。迭代開發(fā)正好與之相反，迭代開發(fā)認為 質量是項目中每一個人的職責。現(xiàn)在我們擁有支持這種共有職責概念的工具和過程，允許我們交付高質量的代碼。新的工具技術允許我們同步代碼和設計。他們也使我們可以在系統(tǒng)被完成前測試代碼產(chǎn)生的內存泄漏問題和性能問題，這是在過去無法達到的?，F(xiàn)代的配置管理和變更管理環(huán)境支持了每日構建，不僅允許我們測試我們分離的代碼，還允許我們測試我們的代碼如何與系統(tǒng)的其他部分代碼的集成。
現(xiàn)代的最佳實踐包括測試先行的設計：首先你要指出你應該進行什么測試，然后再構建能夠通過這些測試的軟件。這樣創(chuàng)建高質量的代碼是我們重點要考慮的事情?，F(xiàn)代的工具技術也支持 設計的質量問題， 1 它使質量成為了設計過程中的主要部分。它允許你在設計過程的早期就進行質量的測量并且可以自動的從設計模型中產(chǎn)生測試。通過保證設計的質量增強了整個系統(tǒng)的質量并保證了測試代碼的完成。
總而言之，使用迭代式的開發(fā)方法，開發(fā)人員角色需要進行擴展；除了簡單的實現(xiàn)需求規(guī)格說明，開發(fā)人員必須在決定什么對整個系統(tǒng)是必要的方面承擔更多的任務。這包括幫助確保需求是正確的和在可接受的成本下創(chuàng)建出高質量的系統(tǒng)。為了作出最好的決定，開發(fā)人員需要更好的理解項目的遠景和驅動項目的業(yè)務問題。這樣開發(fā)人員才有可能創(chuàng)建一個滿足需求和能夠解決業(yè)務問題的方案。
 |
|
|
|
過去，我們注意到按照傳統(tǒng)的方法，當項目快要結束時，開發(fā)出來的軟件才被交給測試人員，讓測試人員通過找到軟件的缺陷來為軟件“注入質量”。每一個測試人員都可能會退縮，因為通過經(jīng)驗他們知道這種方法是多么沒有效率和令人失望的。
使用迭代的開發(fā)方法，測試人員仍然要負責確定系統(tǒng)的質量是否足以發(fā)布，但是他們確保完成高質量系統(tǒng)的方法卻從根本上發(fā)生了變化。首先，測試人員在項目非常早的時候就參與其中，因為每一個迭代（可能除了第一個迭代）都會產(chǎn)生可以被立即測試的可執(zhí)行的結果。在項目早期，測試更關注找到“影響大的”問題，而不是驗證代碼是不是已經(jīng)可以交付了。這就意味著你不能簡單的將代碼交給測試人員； 相反，測試人員需要與分析人員和開發(fā)人員密切的合作以便他們能夠理解在每個迭代中什么是需要被測試的。
此外，測試人員必須向團隊的其他能夠適當?shù)母慕?jīng)需求、設計、代碼和其他支持性的產(chǎn)物的成員提供測試的反饋。測試人員可以通過這些任務來幫助其他項目成員的工作：通常他們可以幫助產(chǎn)生更好的需求，因為他們在計劃方法來測量一個需求是否被滿足的方面是經(jīng)過訓練的。同時，現(xiàn)代的集成測試和開發(fā)環(huán)境允許他們通過使用基線的代碼配置進行連續(xù)的測試工作。
就像分析人員和開發(fā)人員承擔了更多的任務一樣，測試人員也承擔起了更多的任務。 在項目周期的后期，測試人員作為質量專家，對整個開發(fā)團隊提供專家意見。例如，除了執(zhí)行大量了集成和驗收測試之外，他們可以在質量的相關決定上對項目經(jīng)理進行指導。
因為貫穿整個項目中需求是被迭代的識別、細化、開發(fā)和測試的，因此項目團隊并不應該過早的生成所有被執(zhí)行的測試的詳細說明。相反，早期的焦點應該是理解對于一定的階段或者迭代的測試的目標 -- 他們應該完成什么。這將焦點移到了識別每個迭代的潛在的問題領域上，并且開發(fā)測試以暴露那些問題領域。
迭代開發(fā)意味著在項目的早期你就要開發(fā)測試系統(tǒng)的關鍵能力。同時也意味著你需要在后續(xù)的迭代中測試和重新測試這些能力以確保你認為應該被解決的問題不會再一次出現(xiàn)。不通過有效的自動化測試進行完全的回歸測試是不切合實際的 — 而且通常是不可能的， 因此你必須要在整個項目中不斷的開發(fā)出可自動化的測試。有效的實現(xiàn)這一點的訣竅是理解在迭代不斷持續(xù)時什么元素是可以保持穩(wěn)定的；通過這種方法，你可以避免為每一個迭代重寫自動化測試。這就要求你對系統(tǒng)的體系架構有一定的了解；在比較靠后的迭代中，測試應該更注重系統(tǒng)詳細的功能性。
|
|
|
|
迭代開發(fā)方法的一個最重要的區(qū)別是他被設計成為在項目的早期將主要的風險去除掉。利用這個差別需要對項目所面臨的風險公開而且誠實。同時你逃避風險的自然傾向會使人們推遲處理這些風險，風險不知何故的被忽略 — 就像他們從未發(fā)生過。風險就像是傳染?。耗愫雎运骄茫奈：驮酱?。 風險必須在整個項目中被持續(xù)的識別并劃分優(yōu)先級；每一個迭代都必須被降低風險的原則性的目標所驅動。
使用這種方法會需要一些文化上的變化。典型的管理形式規(guī)定你應該對廣大聽眾避免承認風險，因為人們可能會斷定你們在運作一個有問題的項目。這是一個危險的方法：假裝風險不存在不會使風險離去。
傳統(tǒng)的情況下，項目經(jīng)理通過詢問團隊成員什么活動已經(jīng)被完成來確定項目的狀態(tài)。他們假設但所有活動都被完成時，項目也就被完成了。但是這種方法經(jīng)常會導致項目的失敗。檢查被完成的活動是不好的測量項目進度的方法，因為它并沒有對活動的結果的質量進行量化。如果項目經(jīng)理能夠精確的計劃項目團隊需要做的每一項工作，并且沒有會背離項目計劃的事情發(fā)生，這種方法 可能會滿足項目的需要。然而，就像很多項目經(jīng)理知道的那樣，事情很少是按照計劃進行的。甚至是如果你創(chuàng)建了更為詳細的計劃，結果也是令人驚訝的。 無論我們如何努力的預期未來，我們也不能預期每一件事情。
因為我們不能預測未來，軟件項目的經(jīng)理需要對他們的一些關鍵的策略進行風險的管理。這需要改變你的測量方法：代替基于完成活動的測量方法，你應該使用基于可演示的結果的方法進行測量。這是 基于結果管理的基礎。應用基于結果的管理策略意味著將重點放在風險上并正面的處理它。通過特意的結構化項目的活動以處理風險，你可以揭示隱藏的問題，解決問題并穩(wěn)定的減少項目進程中的不確定因素。
此外，因為一個軟件開發(fā)項目的主要結果是軟件本身， 所以你所交付的產(chǎn)物應該是成功的主要量度。你可以使用象一系列被通過的軟件測試、代碼中的缺陷的數(shù)量和他們的精確度等等的矩陣來評估你的軟件。換句話說，移到迭代開發(fā)就意味著要通過根據(jù)指定目標和需求產(chǎn)生的的測量可演示的結果， 而不是通過計算有多少活動、產(chǎn)物或者工作產(chǎn)品被完成來評估項目的狀態(tài)。為了評估項目的穩(wěn)定性（有效管理的另一個量度），你也應該跟蹤需求、設計和代碼中的冗余。
早期，我們注意到添加詳細的信息到需求也許不總是對項目有益的。對其他類型的文檔也是同樣的。你的質量保證計劃、軟件開發(fā)計劃或者需求管理計劃都不是項目健康的良好量度。太詳細不總是更好的：你應該調整你特定項目需要的文檔詳細級別。決定合適詳細級別的方法是關注風險和結果：如果你添加詳細信息到某一產(chǎn)物可以減少風險或者改進特定結果的質量，那么這個投入是值得的；否則，在更有生產(chǎn)力的活動上花費時間是更好的。
使用瀑布型的方法項目經(jīng)理需要付出很多的注意以詳細的計劃和指定需求。而使用迭代開發(fā)的方法項目經(jīng)理可以根據(jù)工作中的風險來權衡的將時間花費在細化需求、架構、設計和實現(xiàn)上。他們會問：“什么樣類型的活動可以最有效的立即降低風險呢？” 也許原型化一個方案可以處理與項目客戶買進相關的風險，或者也許他們需要實際的設計、實現(xiàn)和測試架構以完全的處理架構方面的風險。
對于項目經(jīng)理來說移到迭代開發(fā)方法需要的其他思想的改變是開始將質量保證作為一個集體的職責考慮。我通常會驚訝的聽到項目經(jīng)理說“我需要測試小組對我的開發(fā)人員保持忠誠，”或者“如果分析人員沒有寫下單個的需求，他們將不會被實現(xiàn)。” 當然，你的確需要測試小組來建立高質量的應用，并且失敗的文檔化和跟蹤需求將導致問題的出現(xiàn)。但是如果開發(fā)人員不把質量當作自己的責任，你也就會陷入到質量問題中。為了實現(xiàn)這一點，你需要從通過信任你的團隊和清晰的交流你們的預期開始。假如你不能信任這些人，那么也許這些人不應該屬于你的團隊。
理想的情況下，項目經(jīng)理應該能夠宣稱“我的開發(fā)人員負責交付高質量的代碼；為了幫助開發(fā)人員，我們有一個測試團隊，測試團隊有專業(yè)的能力并可以驗證被交付的代碼是否是高質量的，”并且“我們的開發(fā)人員負責實現(xiàn)滿足最終用戶需要的應用。為了幫助開發(fā)人員，我們有一個分析的團隊在適當?shù)脑敿毤墑e上文檔化需求，并且分析人員是開發(fā)人員和最終客戶之間的橋梁。” 創(chuàng)建交能夠協(xié)同工作的團隊 — 也就是說使團隊中的分析人員、開發(fā)人員和測試人員能夠一起工作來實現(xiàn)高質量的結果 — 是成功的迭代開發(fā)的關鍵之一。
|
|
|
|
許多組織都有質量專家 — 負責達到一定的標準的人，比如 SEI CMM / CMMI 中的標準，或者是組織內部的質量標準。許多組織也有方法專家，他們或者來自軟件工程過程組（SEPG），或者是獨立的負責軟件開發(fā)中的方法。
通常，這些質量和方法專家在采用迭代的開發(fā)思想時存在最大的問題。他們中的許多人花費了他們職業(yè)生涯的大部分時間來驅使組織按照“文檔越多越好”、“越多檢查越好”、“對于過程工作，需要被徹底的文檔化”，和“過程應該提供一個基于時間的你所需要執(zhí)行的項目中的特定任務的描述”這樣的傳統(tǒng)的至理名言來指定過程。他們相信通過跟隨這些提供了高度形式化的原則，就可以避免項目的失敗。
然而，當這樣做的太過火時，將產(chǎn)生相反的效果，因為 高度的形式化將增加迭代的成本，并鼓勵使用瀑布型的周期。相反，你需要通過風險驅動，對每個迭代產(chǎn)生可演示的結果的迭代方法徹底的平衡文檔的最佳實踐。這種方法允許項目團隊增強產(chǎn)品的質量，同時也可以降低形式化的程度和整個的成本。我們應該注意，使用迭代的方法并不排斥使用高度形式化的方法，高度形式化的方法可能對安全第一的應用或者其他嚴格要求質量的應用是有用的。 2
一個關鍵的變化是軟件過程和質量方法應該提供給項目經(jīng)理調節(jié)項目風險的足夠的靈活性；項目經(jīng)理應該不斷的監(jiān)視項目的活動和狀態(tài)，并且調整過程的執(zhí)行以降低關鍵的風險。一個過程可以指明如何應對各種風險和產(chǎn)生被需要的結果，但是風險典型的是預先未知的，因此你不可能在早期就指明什么任務應該被執(zhí)行來應對風險。你也不知道哪一個需求應該被指定什么時候用什么組件來設計和實現(xiàn)他們。這就意味著你所用的過程需要提供關于里程碑代表什么、如何實現(xiàn)它和如何降低風險的清晰的管理指南 — 通過注意項目執(zhí)行的細節(jié)來保留過程的靈活性。
你不能通過在項目過程中簡單使用具體的指導來創(chuàng)建一個一個有效的項目計劃。項目計劃本身需要是一個迭代的過程，包括對當前風險、進度、測試結果等等進行評估以為下一階段的迭代的詳細計劃收集輸入。
這也意味著項目的檢查或者審計不應該主要的關注驗證是否項目團隊已經(jīng)制造了一系列的產(chǎn)物或者執(zhí)行了一系列的活動。相反，審計應該瞄準在識別和驗證風險和確認 適當?shù)?/em>產(chǎn)物和活動被完成以降低風險上。審計也應該檢查以前的問題以識別出公共的失敗模式，并且建議過程的修改以保護將來的最小失敗的可能性。
|
|
|
|
使用傳統(tǒng)的軟件開發(fā)方法的客戶期望在開發(fā)工作中有最小的投資。他們想預先指出所有的需求，確定一個固定的價格，然后等待最終系統(tǒng)的交付。經(jīng)常的，會產(chǎn)生在期望值和實際交付系統(tǒng)之間的非常大的差距 — 解決方案并沒有滿足客戶真實的業(yè)務需要。
通過轉向迭代開發(fā)，改變客戶和開發(fā)團隊之間的交互模式，客戶和開發(fā)團隊都可以避免大量的痛苦。在一個迭代開發(fā)的項目中， 客戶應該是構建應用團隊中的不可缺少的一部分?？蛻襞c開發(fā)團隊的其他成員協(xié)同工作以確保最終交付的應用系統(tǒng)滿足被需要的業(yè)務價值?？蛻舻慕M織應該盡可能的保持與開發(fā)團隊之間交互的興趣，以確保開發(fā)團隊可以理解他們應該構建什么和項目中具有什么樣的風險和問題。如果客戶沒有幫助指導開發(fā)的工作，開發(fā)團隊可能會開發(fā)出錯誤的應用 — 每個人都會蒙受損失。
在迭代開發(fā)的模式中，客戶不能僅僅指出他們所預期的然后就等待系統(tǒng)交付。不論他們怎么清晰的定義，所有的需求都從屬于眾多的說明和可能的實現(xiàn)。對開發(fā)團隊來說，與其生成更加詳細的需求，還不如投入時間更加頻繁和有效的與項目的關鍵投資人（包括客戶）進行溝通。那么，當客戶查看演進的應用時，他們將獲得應用應該做什么的更好的理解，并可以提供有建設性的建議以改進系統(tǒng)。同時，如果在項目中業(yè)務要求發(fā)生快速的變化，需求也需要隨之發(fā)生改變。
客戶也可以從公開協(xié)商迭代式的和約中受益，一個叫作 累進的獲取得方法。使用這個方法，首先雙方可以為整個項目協(xié)商一個大致的協(xié)議作為描述雙方管理商業(yè)關系的合法的指導。然后項目被劃分為兩個或者更多的子和約。早期的和約基于時間和所需的資源指明了款額，因為任何一方都不能足以知道整個方案和可能的開發(fā)成本以作出合理的預先承諾。后來的和約式固定的價格，它最小化了雙方對應該的交付產(chǎn)物的不一致。 3
|
|
我們已經(jīng)討論了對軟件開發(fā)采用迭代的方法不僅僅簡單的需要遵循一系列的指南。迭代開發(fā)和支持迭代開發(fā)的現(xiàn)代技術改變了軟件開發(fā)游戲中的規(guī)則，并使許多在過去戰(zhàn)統(tǒng)治地位的公理失去了效力。成功的從瀑布型的方法向迭代的方法轉變要求軟件開發(fā)團隊在個人的責任和如何與團隊其他成員交互上發(fā)生了變化。換句話說，它要求在多中角色團隊成員的行為和價值上作出明顯的和持久改變。
只有每一個團隊成員都能夠理解迭代開發(fā)需要做的必要的改變的基本原理，組織才能夠實現(xiàn)這些變化。在每一個項目的開始，對于項目團隊來說，公開的討論我們在本文中的迭代開發(fā)訓練部分已經(jīng)討論的必要的行為和有感知的變化是有益處的。本文可以作為這些討論的出發(fā)點：項目團隊應該贊同這些思想上的改變和上面針對他們特定項目討論的實踐。
基本上，本文是關于如何通過使用迭代開發(fā)的方法和通過確保整個團隊共享項目的遠景建立“正確的”軟件的，并講述了你應該如何與團隊緊密的合作來實現(xiàn)這個遠景。項目經(jīng)理能夠在工作過程中鼓勵這種變化，但是它最終建立在團隊成員接受和有效的實施是些變化之上。
