廣泛的引用這些變化作為一種“新的思想”，我們將關(guān)注軟件開發(fā)項目中的不同個體角色：

• 分析人員主要負(fù)責(zé)與客戶交互和需求。
• 開發(fā)人員主要負(fù)責(zé)設(shè)計、實現(xiàn)和單元測試。
• 測試人員主要負(fù)責(zé)功能、性能和系統(tǒng)測試。
• 項目經(jīng)理主要負(fù)責(zé)持續(xù)的項目團隊的跟蹤并關(guān)注關(guān)鍵的交付產(chǎn)物。
• 質(zhì)量保證和方法專家負(fù)責(zé)質(zhì)量標(biāo)準(zhǔn)和最佳實踐。
• 客戶負(fù)責(zé)澄清他們的業(yè)務(wù)需求關(guān)心什么樣的能力。

分析人員的新思想

在傳統(tǒng)的瀑布型的方法中，分析人員與用戶和項目團隊之外的涉眾打交道。目標(biāo)是理解并開發(fā)一個代表了一系列需求的方案，文檔化這些需求然后將這些需求文檔交給開發(fā)團隊。一些開發(fā)組織用一種“未來”狀態(tài)的長列表來詳細說明需求；另一些組織在高層次上表達需求，為解釋需求保留了很大的空間。在這兩種情況下，必須有這樣的假設(shè)，分析人員既要了解業(yè)務(wù)又要了解用戶，并且這個分析人員應(yīng)該是指定系統(tǒng)應(yīng)該具有什么功能的人。

一旦分析人員文檔化了需求，他或者她就會要求用戶來檢查這些需求文檔（甚至如果他們不能完全理解用來表達需求的技術(shù)語言，并且/或者他們不能通過可視化的方法來表示當(dāng)系統(tǒng)被實現(xiàn)時許多需求是如何滿足用戶的需要的）。然后，實現(xiàn)需求規(guī)格說明就是開發(fā)人員的工作了。典型的，不論是開發(fā)人員還是測試人員都沒有參與到闡述需求的工作中。并且一旦需求被規(guī)格化，很少會有在分析人員與設(shè)計人員之間的積極的交互。分析人員只是簡單的闡明需求說明書中包含的內(nèi)容。

這種傳統(tǒng)的模型在某些方面的缺陷將在下面被解釋。

分析人員的新思想 建立與最終客戶的持續(xù)的交互以確保開發(fā)人員可以創(chuàng)建正確的系統(tǒng)。 鼓勵盡早的開發(fā)和實現(xiàn)系統(tǒng)的關(guān)鍵能力部分，以加深你對什么需求將滿足業(yè)務(wù)需要的理解。 從一開始就與開發(fā)人員和測試人員一起優(yōu)化序需求。 為需求選擇適當(dāng)?shù)脑敿毘潭?，可以根?jù)你的項目和當(dāng)前的生命周期階段而定。

分析人員不應(yīng)該孤立的指定需求

首先， 瀑布型的方法失敗的認(rèn)識到客戶、開發(fā)人員和測試人員參與需求說明工作的價值。沒有對業(yè)務(wù)和技術(shù)擁有優(yōu)秀的理解將不可能創(chuàng)建出能夠改進你的業(yè)務(wù)的軟件系統(tǒng)。不幸的是，很少有人同時在業(yè)務(wù)和技術(shù)領(lǐng)域具有深厚的知識背景。這就意味著，分析人員、開發(fā)人員、測試人員和客戶應(yīng)該一起工作提供需要的所有的信息以確保開發(fā)人員可以創(chuàng)建“正確的”軟件系統(tǒng) — 也就是說，一個充分滿足客戶業(yè)務(wù)需要并且提供從根本上有效的改進客戶業(yè)務(wù)的能力的軟件。

讓我們來看一個簡單的例子以說明這樣的團隊協(xié)作的好處。

例子：基于 Web 的航班預(yù)約系統(tǒng)

我們假設(shè)一個分析人員負(fù)責(zé)對這個基于 Web 的自助服務(wù)的航班預(yù)約系統(tǒng)的需求工作。這個分析人員指定用戶將提供一個航班的代碼并指明行程的開始地和目的地。如果用戶不知道航班代碼，他們可以通過提供城市名字進行查詢。然后，這個分析人員指定，在用戶預(yù)定了一個指定的航班后，他們將會得到關(guān)于如何聯(lián)系不同的代理以預(yù)約到達目的地時的地面交通工具。

當(dāng)設(shè)計人員檢查系統(tǒng)需求時，他回想起曾經(jīng)看到過一個能夠提供部分功能的并且經(jīng)過證明的Web 服務(wù)的方案。這個低成本的服務(wù)允許用戶導(dǎo)航機場的地圖顯示并快速的找到符合他們需要的機場，甚至假如用戶不熟悉他們的目的地城市或者不熟悉目的地的地區(qū)的機場。

在與客戶驗證了策略后，分析人員和設(shè)計人員對需求作了改動以包含這個 Web 服務(wù)的實現(xiàn)。然后，在幾天的開發(fā)工作后，設(shè)計人員發(fā)現(xiàn)了這個服務(wù)的另一特性：當(dāng)用戶選擇了一個機場時，他們會自動的收到一個機場信息的列表，信息中包括可得到的地面交通工具的模式和對每種模式預(yù)定的容量。設(shè)計人員和分析人員與客戶和項目經(jīng)理討論了這個發(fā)現(xiàn)，大家都同意合并這個額外的 Web 服務(wù)的特性到他們的新系統(tǒng)中，代替他們原來指定的創(chuàng)建一個地面交通引用的特性。

就像你從這個簡單的例子中所看到的那樣，在項目的早期階段就讓設(shè)計人員/開發(fā)人員參與到需求中能夠帶來巨大的好處。他們中的每一個人都可以建議分析人員或者最終用戶考慮不到的能力和方案。當(dāng)然，衡量預(yù)期的項目范圍變化的價值仍然是項目經(jīng)理和客戶的責(zé)任，分析人員仍然必須理解業(yè)務(wù)需要并驅(qū)使系統(tǒng)應(yīng)該在何處結(jié)束。但是他或她可以通過與設(shè)計人員/開發(fā)人員協(xié)作找到更好的方案。

分析人員和最終用戶的交流應(yīng)該貫穿于整個項目的生命周期中

傳統(tǒng)開發(fā)模式的另外一個缺陷是缺乏在分析人員與最終用戶之間的交流。 最終用戶被期望預(yù)先的指出需求并且對需求進行檢查，但是他們有限的參與了方案的開發(fā)。在許多情況下，和約的商定是以預(yù)先被描述的需求為基礎(chǔ)的，并且后來的變更需要有一個和約上的協(xié)商。

在整個開發(fā)的生命周期中維護在用戶與分析人員之間的交流是尤其有效的。雙方都應(yīng)該理解他們擁有相同的目標(biāo)：建立滿足質(zhì)量要求的可以解決問題的方案，同時成本是可接受的。如果他們的關(guān)系是圍繞著爭論關(guān)于什么是以前達成的一致和誰應(yīng)該為此付錢，而不是建立一個正確的方案的話，那么項目就陷入了麻煩之中。這并不意味著分析人員應(yīng)該接受所有的需求或者最終用戶不應(yīng)該作出變更的請求。相反，這意味著所有的項目相關(guān)的人員應(yīng)該在提出需求和最終進入到訂單中的需求進行一個平衡以形成更好方案的開發(fā)。他們需要認(rèn)可當(dāng)他們過分的嚴(yán)格時，應(yīng)該通過一些討論以達到一個折中的方案，并且要作積極的改變以保持項目按照計劃進行。當(dāng)然，這一點做起來要比說的有難度。但是朝著有效的團隊協(xié)作的第一步是在分析人員與最終用戶之間建立起有建設(shè)性的對話。

過度的指出預(yù)想的需求是不明智的

傳統(tǒng)的開發(fā)方法提倡詳細的預(yù)先需求，并且在過去的多年里很多人覺得項目失敗是因為他們的需求對啟動項目是不夠詳細的。但是增加需求說明的詳細程度將會減少的回報。在一些情況下，項目團隊需要不斷的構(gòu)建方案，并假設(shè)需求在整個項目周期不斷的改進。記住： 軟件項目的主要目標(biāo)是在盡可能低成本的條件下生成可執(zhí)行的能夠解決手工形式的業(yè)務(wù)問題的代碼。一旦你的需求到達了一定的細化程度，將他們定案的最廉價的方法是對系統(tǒng)進行部分的實現(xiàn)以可以向最終用戶進行演示。同時你可以一起確定你還需要提供什么樣的其他能力。 定案需求通常要經(jīng)過幾次的迭代，在迭代期間你可以調(diào)整需求、設(shè)計和代碼，然后對測試進行引導(dǎo)。

在項目周期的后期你可以不必正式的文檔化很多的詳細的需求；代碼本身可以提供足夠的文檔，并且很少在團隊中誤解什么是需要實現(xiàn)方面存在風(fēng)險。這依賴于正被開發(fā)的系統(tǒng)自然的改變了參與的人數(shù)、系統(tǒng)期望的生命跨度、和約的義務(wù)和附加的質(zhì)量標(biāo)準(zhǔn)的需求。最后，也許是最重要的，你應(yīng)該象驅(qū)趕技術(shù)風(fēng)險一樣在項目中盡早驅(qū)趕商業(yè)上的風(fēng)險。 在細化預(yù)想的需求上花費過多的時間會使你的注意偏離出降低關(guān)鍵的風(fēng)險。

開發(fā)人員的新思想 擴大了的職責(zé)包括詳細設(shè)計、實現(xiàn)和單元測試。 成為需求工作中的一部分：幫助闡明需求然后創(chuàng)建符合需求的方案。 成為了測試工作的一部分：按照測試先行的設(shè)計原則開發(fā)代碼。 盡可能的重用已存在的方案而不是重新構(gòu)建方案。

回頁首

開發(fā)人員的新思想

迭代開發(fā)，對開發(fā)人員來說使用與迭代開發(fā)相關(guān)聯(lián)的最佳實踐和現(xiàn)代的工具技術(shù)，同樣需要在思想上的轉(zhuǎn)變。首先，就像我們在上一部分討論的，開發(fā)人員需要在指定需求中扮演更多積極的角色。

過去，開發(fā)人員以對辣手的問題提出聰明的解決方法為榮。他們創(chuàng)造唯一的方案以使系統(tǒng)性能最大化、內(nèi)存使用最小化或者提供良好的圖形用戶界面。當(dāng)然，開發(fā)人員仍然需要提出聰明的方法， 但是他們的精力需要從構(gòu)建方法轉(zhuǎn)向到發(fā)現(xiàn)聰明的方法以盡量的將可重用的資產(chǎn)、開發(fā)源碼的軟件、通用的商業(yè)現(xiàn)貨 (COTS) 組件和 Web 服務(wù)集成成為一個可使用的方案。為了成為優(yōu)秀的開發(fā)人員，你需要知道如何最好的利用交互式的開發(fā)環(huán)境（IDE）和建模環(huán)境。“這里沒有發(fā)明”的態(tài)度是達不到預(yù)期的目標(biāo)的；作為一個開發(fā)人員，你的精力應(yīng)該放在通過利用各種可重用的資產(chǎn)來產(chǎn)生可使用的方案上。今天快速并廉價的生產(chǎn)出高質(zhì)量的產(chǎn)品才是應(yīng)該受到褒獎的。

質(zhì)量是測試團隊的職責(zé)。在傳統(tǒng)的開發(fā)中，在項目的最后幾周，整個系統(tǒng)才交付到可憐數(shù)量的測試人員手中，他們被要求盡可能多的找出軟件系統(tǒng)的缺陷。他們負(fù)責(zé)質(zhì)量，開發(fā)人員負(fù)責(zé)修改他們發(fā)現(xiàn)的缺陷。迭代開發(fā)正好與之相反，迭代開發(fā)認(rèn)為 質(zhì)量是項目中每一個人的職責(zé)。現(xiàn)在我們擁有支持這種共有職責(zé)概念的工具和過程，允許我們交付高質(zhì)量的代碼。新的工具技術(shù)允許我們同步代碼和設(shè)計。他們也使我們可以在系統(tǒng)被完成前測試代碼產(chǎn)生的內(nèi)存泄漏問題和性能問題，這是在過去無法達到的?，F(xiàn)代的配置管理和變更管理環(huán)境支持了每日構(gòu)建，不僅允許我們測試我們分離的代碼，還允許我們測試我們的代碼如何與系統(tǒng)的其他部分代碼的集成。

現(xiàn)代的最佳實踐包括測試先行的設(shè)計：首先你要指出你應(yīng)該進行什么測試，然后再構(gòu)建能夠通過這些測試的軟件。這樣創(chuàng)建高質(zhì)量的代碼是我們重點要考慮的事情?，F(xiàn)代的工具技術(shù)也支持 設(shè)計的質(zhì)量問題， ¹ 它使質(zhì)量成為了設(shè)計過程中的主要部分。它允許你在設(shè)計過程的早期就進行質(zhì)量的測量并且可以自動的從設(shè)計模型中產(chǎn)生測試。通過保證設(shè)計的質(zhì)量增強了整個系統(tǒng)的質(zhì)量并保證了測試代碼的完成。

總而言之，使用迭代式的開發(fā)方法，開發(fā)人員角色需要進行擴展；除了簡單的實現(xiàn)需求規(guī)格說明，開發(fā)人員必須在決定什么對整個系統(tǒng)是必要的方面承擔(dān)更多的任務(wù)。這包括幫助確保需求是正確的和在可接受的成本下創(chuàng)建出高質(zhì)量的系統(tǒng)。為了作出最好的決定，開發(fā)人員需要更好的理解項目的遠景和驅(qū)動項目的業(yè)務(wù)問題。這樣開發(fā)人員才有可能創(chuàng)建一個滿足需求和能夠解決業(yè)務(wù)問題的方案。

測試人員的新思想 成為團隊中在質(zhì)量問題上的指導(dǎo)者。 與分析人員和開發(fā)人員一起工作以確保需求和設(shè)計是可測試的。 在項目的早期就應(yīng)引入測試。 穩(wěn)定能力的持續(xù)的自動化測試。

回頁首

測試人員的新思想

過去，我們注意到按照傳統(tǒng)的方法，當(dāng)項目快要結(jié)束時，開發(fā)出來的軟件才被交給測試人員，讓測試人員通過找到軟件的缺陷來為軟件“注入質(zhì)量”。每一個測試人員都可能會退縮，因為通過經(jīng)驗他們知道這種方法是多么沒有效率和令人失望的。

使用迭代的開發(fā)方法，測試人員仍然要負(fù)責(zé)確定系統(tǒng)的質(zhì)量是否足以發(fā)布，但是他們確保完成高質(zhì)量系統(tǒng)的方法卻從根本上發(fā)生了變化。首先，測試人員在項目非常早的時候就參與其中，因為每一個迭代（可能除了第一個迭代）都會產(chǎn)生可以被立即測試的可執(zhí)行的結(jié)果。在項目早期，測試更關(guān)注找到“影響大的”問題，而不是驗證代碼是不是已經(jīng)可以交付了。這就意味著你不能簡單的將代碼交給測試人員； 相反，測試人員需要與分析人員和開發(fā)人員密切的合作以便他們能夠理解在每個迭代中什么是需要被測試的。

此外，測試人員必須向團隊的其他能夠適當(dāng)?shù)母慕?jīng)需求、設(shè)計、代碼和其他支持性的產(chǎn)物的成員提供測試的反饋。測試人員可以通過這些任務(wù)來幫助其他項目成員的工作：通常他們可以幫助產(chǎn)生更好的需求，因為他們在計劃方法來測量一個需求是否被滿足的方面是經(jīng)過訓(xùn)練的。同時，現(xiàn)代的集成測試和開發(fā)環(huán)境允許他們通過使用基線的代碼配置進行連續(xù)的測試工作。

就像分析人員和開發(fā)人員承擔(dān)了更多的任務(wù)一樣，測試人員也承擔(dān)起了更多的任務(wù)。 在項目周期的后期，測試人員作為質(zhì)量專家，對整個開發(fā)團隊提供專家意見。例如，除了執(zhí)行大量了集成和驗收測試之外，他們可以在質(zhì)量的相關(guān)決定上對項目經(jīng)理進行指導(dǎo)。

因為貫穿整個項目中需求是被迭代的識別、細化、開發(fā)和測試的，因此項目團隊并不應(yīng)該過早的生成所有被執(zhí)行的測試的詳細說明。相反，早期的焦點應(yīng)該是理解對于一定的階段或者迭代的測試的目標(biāo) -- 他們應(yīng)該完成什么。這將焦點移到了識別每個迭代的潛在的問題領(lǐng)域上，并且開發(fā)測試以暴露那些問題領(lǐng)域。

迭代開發(fā)意味著在項目的早期你就要開發(fā)測試系統(tǒng)的關(guān)鍵能力。同時也意味著你需要在后續(xù)的迭代中測試和重新測試這些能力以確保你認(rèn)為應(yīng)該被解決的問題不會再一次出現(xiàn)。不通過有效的自動化測試進行完全的回歸測試是不切合實際的 — 而且通常是不可能的， 因此你必須要在整個項目中不斷的開發(fā)出可自動化的測試。有效的實現(xiàn)這一點的訣竅是理解在迭代不斷持續(xù)時什么元素是可以保持穩(wěn)定的；通過這種方法，你可以避免為每一個迭代重寫自動化測試。這就要求你對系統(tǒng)的體系架構(gòu)有一定的了解；在比較靠后的迭代中，測試應(yīng)該更注重系統(tǒng)詳細的功能性。

項目經(jīng)理的新思想 公開項目面臨的風(fēng)險，持續(xù)的重新評估風(fēng)險，并且使用風(fēng)險來為項目工作進行優(yōu)先級的劃分。 通過衡量可演示的結(jié)果而不是一系列被完成的活動來評估項目狀態(tài)。 在項目的早期，對整個項目開發(fā)高層次的計劃，但僅僅對當(dāng)前的和下一個迭代生成詳細計劃。 根據(jù)你如何有效的處理風(fēng)險的經(jīng)驗，在任何給定的時間上評估你在需求、架構(gòu)、設(shè)計、實現(xiàn)和測試上的投入。 信任你的團隊。給他們足夠的知識和職責(zé)讓他們?nèi)?fù)責(zé)產(chǎn)品的質(zhì)量。幫助他們團結(jié)在一起工作。

回頁首

項目經(jīng)理的新思想

迭代開發(fā)方法的一個最重要的區(qū)別是他被設(shè)計成為在項目的早期將主要的風(fēng)險去除掉。利用這個差別需要對項目所面臨的風(fēng)險公開而且誠實。同時你逃避風(fēng)險的自然傾向會使人們推遲處理這些風(fēng)險，風(fēng)險不知何故的被忽略 — 就像他們從未發(fā)生過。風(fēng)險就像是傳染?。耗愫雎运骄?，它的危害就越大。 風(fēng)險必須在整個項目中被持續(xù)的識別并劃分優(yōu)先級；每一個迭代都必須被降低風(fēng)險的原則性的目標(biāo)所驅(qū)動。

使用這種方法會需要一些文化上的變化。典型的管理形式規(guī)定你應(yīng)該對廣大聽眾避免承認(rèn)風(fēng)險，因為人們可能會斷定你們在運作一個有問題的項目。這是一個危險的方法：假裝風(fēng)險不存在不會使風(fēng)險離去。

傳統(tǒng)的情況下，項目經(jīng)理通過詢問團隊成員什么活動已經(jīng)被完成來確定項目的狀態(tài)。他們假設(shè)但所有活動都被完成時，項目也就被完成了。但是這種方法經(jīng)常會導(dǎo)致項目的失敗。檢查被完成的活動是不好的測量項目進度的方法，因為它并沒有對活動的結(jié)果的質(zhì)量進行量化。如果項目經(jīng)理能夠精確的計劃項目團隊需要做的每一項工作，并且沒有會背離項目計劃的事情發(fā)生，這種方法 可能會滿足項目的需要。然而，就像很多項目經(jīng)理知道的那樣，事情很少是按照計劃進行的。甚至是如果你創(chuàng)建了更為詳細的計劃，結(jié)果也是令人驚訝的。 無論我們?nèi)绾闻Φ念A(yù)期未來，我們也不能預(yù)期每一件事情。

基于結(jié)果的管理

因為我們不能預(yù)測未來，軟件項目的經(jīng)理需要對他們的一些關(guān)鍵的策略進行風(fēng)險的管理。這需要改變你的測量方法：代替基于完成活動的測量方法，你應(yīng)該使用基于可演示的結(jié)果的方法進行測量。這是 基于結(jié)果管理的基礎(chǔ)。應(yīng)用基于結(jié)果的管理策略意味著將重點放在風(fēng)險上并正面的處理它。通過特意的結(jié)構(gòu)化項目的活動以處理風(fēng)險，你可以揭示隱藏的問題，解決問題并穩(wěn)定的減少項目進程中的不確定因素。

此外，因為一個軟件開發(fā)項目的主要結(jié)果是軟件本身， 所以你所交付的產(chǎn)物應(yīng)該是成功的主要量度。你可以使用象一系列被通過的軟件測試、代碼中的缺陷的數(shù)量和他們的精確度等等的矩陣來評估你的軟件。換句話說，移到迭代開發(fā)就意味著要通過根據(jù)指定目標(biāo)和需求產(chǎn)生的的測量可演示的結(jié)果， 而不是通過計算有多少活動、產(chǎn)物或者工作產(chǎn)品被完成來評估項目的狀態(tài)。為了評估項目的穩(wěn)定性（有效管理的另一個量度），你也應(yīng)該跟蹤需求、設(shè)計和代碼中的冗余。

更少的也許是更多的

早期，我們注意到添加詳細的信息到需求也許不總是對項目有益的。對其他類型的文檔也是同樣的。你的質(zhì)量保證計劃、軟件開發(fā)計劃或者需求管理計劃都不是項目健康的良好量度。太詳細不總是更好的：你應(yīng)該調(diào)整你特定項目需要的文檔詳細級別。決定合適詳細級別的方法是關(guān)注風(fēng)險和結(jié)果：如果你添加詳細信息到某一產(chǎn)物可以減少風(fēng)險或者改進特定結(jié)果的質(zhì)量，那么這個投入是值得的；否則，在更有生產(chǎn)力的活動上花費時間是更好的。

使用瀑布型的方法項目經(jīng)理需要付出很多的注意以詳細的計劃和指定需求。而使用迭代開發(fā)的方法項目經(jīng)理可以根據(jù)工作中的風(fēng)險來權(quán)衡的將時間花費在細化需求、架構(gòu)、設(shè)計和實現(xiàn)上。他們會問：“什么樣類型的活動可以最有效的立即降低風(fēng)險呢？” 也許原型化一個方案可以處理與項目客戶買進相關(guān)的風(fēng)險，或者也許他們需要實際的設(shè)計、實現(xiàn)和測試架構(gòu)以完全的處理架構(gòu)方面的風(fēng)險。

使項目中的每一個成員都參與到質(zhì)量保證中

對于項目經(jīng)理來說移到迭代開發(fā)方法需要的其他思想的改變是開始將質(zhì)量保證作為一個集體的職責(zé)考慮。我通常會驚訝的聽到項目經(jīng)理說“我需要測試小組對我的開發(fā)人員保持忠誠，”或者“如果分析人員沒有寫下單個的需求，他們將不會被實現(xiàn)。” 當(dāng)然，你的確需要測試小組來建立高質(zhì)量的應(yīng)用，并且失敗的文檔化和跟蹤需求將導(dǎo)致問題的出現(xiàn)。但是如果開發(fā)人員不把質(zhì)量當(dāng)作自己的責(zé)任，你也就會陷入到質(zhì)量問題中。為了實現(xiàn)這一點，你需要從通過信任你的團隊和清晰的交流你們的預(yù)期開始。假如你不能信任這些人，那么也許這些人不應(yīng)該屬于你的團隊。

理想的情況下，項目經(jīng)理應(yīng)該能夠宣稱“我的開發(fā)人員負(fù)責(zé)交付高質(zhì)量的代碼；為了幫助開發(fā)人員，我們有一個測試團隊，測試團隊有專業(yè)的能力并可以驗證被交付的代碼是否是高質(zhì)量的，”并且“我們的開發(fā)人員負(fù)責(zé)實現(xiàn)滿足最終用戶需要的應(yīng)用。為了幫助開發(fā)人員，我們有一個分析的團隊在適當(dāng)?shù)脑敿毤墑e上文檔化需求，并且分析人員是開發(fā)人員和最終客戶之間的橋梁。” 創(chuàng)建交能夠協(xié)同工作的團隊 — 也就是說使團隊中的分析人員、開發(fā)人員和測試人員能夠一起工作來實現(xiàn)高質(zhì)量的結(jié)果 — 是成功的迭代開發(fā)的關(guān)鍵之一。

質(zhì)量保證和方法專家的新思想 為項目選擇適當(dāng)?shù)男问郊墑e（更多的不總是更好的）。 關(guān)注在整個項目周期中維護質(zhì)量，但是可以是靈活的。最好的到達高質(zhì)量的做法不是僅僅通過瘋狂的關(guān)注檢查和測試實現(xiàn)的，而是通過在給定時間上對需求、架構(gòu)、設(shè)計、實現(xiàn)、檢查和測試的良好平衡實現(xiàn)的。 采用風(fēng)險驅(qū)動的過程方法。你的過程應(yīng)該允許項目經(jīng)理對項目當(dāng)前的風(fēng)險情況采用戰(zhàn)術(shù)性的活動。

回頁首

質(zhì)量保證和方法專家的新思想

許多組織都有質(zhì)量專家 — 負(fù)責(zé)達到一定的標(biāo)準(zhǔn)的人，比如 SEI CMM / CMMI 中的標(biāo)準(zhǔn)，或者是組織內(nèi)部的質(zhì)量標(biāo)準(zhǔn)。許多組織也有方法專家，他們或者來自軟件工程過程組（SEPG），或者是獨立的負(fù)責(zé)軟件開發(fā)中的方法。

通常，這些質(zhì)量和方法專家在采用迭代的開發(fā)思想時存在最大的問題。他們中的許多人花費了他們職業(yè)生涯的大部分時間來驅(qū)使組織按照“文檔越多越好”、“越多檢查越好”、“對于過程工作，需要被徹底的文檔化”，和“過程應(yīng)該提供一個基于時間的你所需要執(zhí)行的項目中的特定任務(wù)的描述”這樣的傳統(tǒng)的至理名言來指定過程。他們相信通過跟隨這些提供了高度形式化的原則，就可以避免項目的失敗。

然而，當(dāng)這樣做的太過火時，將產(chǎn)生相反的效果，因為 高度的形式化將增加迭代的成本，并鼓勵使用瀑布型的周期。相反，你需要通過風(fēng)險驅(qū)動，對每個迭代產(chǎn)生可演示的結(jié)果的迭代方法徹底的平衡文檔的最佳實踐。這種方法允許項目團隊增強產(chǎn)品的質(zhì)量，同時也可以降低形式化的程度和整個的成本。我們應(yīng)該注意，使用迭代的方法并不排斥使用高度形式化的方法，高度形式化的方法可能對安全第一的應(yīng)用或者其他嚴(yán)格要求質(zhì)量的應(yīng)用是有用的。 ²

靈活性是關(guān)鍵的

一個關(guān)鍵的變化是軟件過程和質(zhì)量方法應(yīng)該提供給項目經(jīng)理調(diào)節(jié)項目風(fēng)險的足夠的靈活性；項目經(jīng)理應(yīng)該不斷的監(jiān)視項目的活動和狀態(tài)，并且調(diào)整過程的執(zhí)行以降低關(guān)鍵的風(fēng)險。一個過程可以指明如何應(yīng)對各種風(fēng)險和產(chǎn)生被需要的結(jié)果，但是風(fēng)險典型的是預(yù)先未知的，因此你不可能在早期就指明什么任務(wù)應(yīng)該被執(zhí)行來應(yīng)對風(fēng)險。你也不知道哪一個需求應(yīng)該被指定什么時候用什么組件來設(shè)計和實現(xiàn)他們。這就意味著你所用的過程需要提供關(guān)于里程碑代表什么、如何實現(xiàn)它和如何降低風(fēng)險的清晰的管理指南 — 通過注意項目執(zhí)行的細節(jié)來保留過程的靈活性。

你不能通過在項目過程中簡單使用具體的指導(dǎo)來創(chuàng)建一個一個有效的項目計劃。項目計劃本身需要是一個迭代的過程，包括對當(dāng)前風(fēng)險、進度、測試結(jié)果等等進行評估以為下一階段的迭代的詳細計劃收集輸入。

這也意味著項目的檢查或者審計不應(yīng)該主要的關(guān)注驗證是否項目團隊已經(jīng)制造了一系列的產(chǎn)物或者執(zhí)行了一系列的活動。相反，審計應(yīng)該瞄準(zhǔn)在識別和驗證風(fēng)險和確認(rèn) 適當(dāng)?shù)?/em>產(chǎn)物和活動被完成以降低風(fēng)險上。審計也應(yīng)該檢查以前的問題以識別出公共的失敗模式，并且建議過程的修改以保護將來的最小失敗的可能性。

客戶的新思想 積極的參與描述需求并成為軟件開發(fā)團隊中不可缺少的部分。 對已經(jīng)被開發(fā)的軟件的能力不斷的提供反饋，比如工作原型和用戶界面設(shè)計。 利用一種使用迭代方法的進步的獲得模式；這種模式保證買家和賣家的雙方利益。

回頁首

客戶的新思想

使用傳統(tǒng)的軟件開發(fā)方法的客戶期望在開發(fā)工作中有最小的投資。他們想預(yù)先指出所有的需求，確定一個固定的價格，然后等待最終系統(tǒng)的交付。經(jīng)常的，會產(chǎn)生在期望值和實際交付系統(tǒng)之間的非常大的差距 — 解決方案并沒有滿足客戶真實的業(yè)務(wù)需要。

通過轉(zhuǎn)向迭代開發(fā)，改變客戶和開發(fā)團隊之間的交互模式，客戶和開發(fā)團隊都可以避免大量的痛苦。在一個迭代開發(fā)的項目中， 客戶應(yīng)該是構(gòu)建應(yīng)用團隊中的不可缺少的一部分。客戶與開發(fā)團隊的其他成員協(xié)同工作以確保最終交付的應(yīng)用系統(tǒng)滿足被需要的業(yè)務(wù)價值。客戶的組織應(yīng)該盡可能的保持與開發(fā)團隊之間交互的興趣，以確保開發(fā)團隊可以理解他們應(yīng)該構(gòu)建什么和項目中具有什么樣的風(fēng)險和問題。如果客戶沒有幫助指導(dǎo)開發(fā)的工作，開發(fā)團隊可能會開發(fā)出錯誤的應(yīng)用 — 每個人都會蒙受損失。

在迭代開發(fā)的模式中，客戶不能僅僅指出他們所預(yù)期的然后就等待系統(tǒng)交付。不論他們怎么清晰的定義，所有的需求都從屬于眾多的說明和可能的實現(xiàn)。對開發(fā)團隊來說，與其生成更加詳細的需求，還不如投入時間更加頻繁和有效的與項目的關(guān)鍵投資人（包括客戶）進行溝通。那么，當(dāng)客戶查看演進的應(yīng)用時，他們將獲得應(yīng)用應(yīng)該做什么的更好的理解，并可以提供有建設(shè)性的建議以改進系統(tǒng)。同時，如果在項目中業(yè)務(wù)要求發(fā)生快速的變化，需求也需要隨之發(fā)生改變。

客戶也可以從公開協(xié)商迭代式的和約中受益，一個叫作 累進的獲取得方法。使用這個方法，首先雙方可以為整個項目協(xié)商一個大致的協(xié)議作為描述雙方管理商業(yè)關(guān)系的合法的指導(dǎo)。然后項目被劃分為兩個或者更多的子和約。早期的和約基于時間和所需的資源指明了款額，因為任何一方都不能足以知道整個方案和可能的開發(fā)成本以作出合理的預(yù)先承諾。后來的和約式固定的價格，它最小化了雙方對應(yīng)該的交付產(chǎn)物的不一致。 ³

回頁首

結(jié)論

我們已經(jīng)討論了對軟件開發(fā)采用迭代的方法不僅僅簡單的需要遵循一系列的指南。迭代開發(fā)和支持迭代開發(fā)的現(xiàn)代技術(shù)改變了軟件開發(fā)游戲中的規(guī)則，并使許多在過去戰(zhàn)統(tǒng)治地位的公理失去了效力。成功的從瀑布型的方法向迭代的方法轉(zhuǎn)變要求軟件開發(fā)團隊在個人的責(zé)任和如何與團隊其他成員交互上發(fā)生了變化。換句話說，它要求在多中角色團隊成員的行為和價值上作出明顯的和持久改變。

只有每一個團隊成員都能夠理解迭代開發(fā)需要做的必要的改變的基本原理，組織才能夠?qū)崿F(xiàn)這些變化。在每一個項目的開始，對于項目團隊來說，公開的討論我們在本文中的迭代開發(fā)訓(xùn)練部分已經(jīng)討論的必要的行為和有感知的變化是有益處的。本文可以作為這些討論的出發(fā)點：項目團隊?wèi)?yīng)該贊同這些思想上的改變和上面針對他們特定項目討論的實踐。

基本上，本文是關(guān)于如何通過使用迭代開發(fā)的方法和通過確保整個團隊共享項目的遠景建立“正確的”軟件的，并講述了你應(yīng)該如何與團隊緊密的合作來實現(xiàn)這個遠景。項目經(jīng)理能夠在工作過程中鼓勵這種變化，但是它最終建立在團隊成員接受和有效的實施是些變化之上。