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