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