良好的開發(fā)程序?qū)浖?xiàng)目的存在是重要而必須的。有了良好的開發(fā)程序，軟件開發(fā)人員可以將大部分時(shí)間用在讓項(xiàng)目更穩(wěn)定的生產(chǎn)性工作上。如果開發(fā)程序規(guī)劃不良，開發(fā)人員將會花費(fèi)大部分時(shí)間修正錯誤。項(xiàng)目成敗的關(guān)鍵在于擁有良好的準(zhǔn)備工作，并讓有見識的項(xiàng)目出資者了解，項(xiàng)目人員投注了足夠的精力在準(zhǔn)備工作上，以減少后續(xù)發(fā)生的問題。

任務(wù)開始前，你會看到最重要的演示文稿。本章描述讓軟件任務(wù)成功的關(guān)鍵要素。

“開發(fā)程序”的威力

這是一篇有效的軟件開發(fā)程序的教程?！败浖_發(fā)程序”這字眼可以代表許多不同的東西，而底下就是這字眼所要表示的事情：

◆把所有需要的項(xiàng)目記錄下來。
◆使用系統(tǒng)化的做法來控制產(chǎn)品的增加與更改。
◆推動所有要求、設(shè)計(jì)與原始碼系統(tǒng)化的技術(shù)性審查。
◆在項(xiàng)目初期就發(fā)展系統(tǒng)化的品質(zhì)保證計(jì)劃，其中包含測試計(jì)劃、審查計(jì)劃與錯誤追蹤計(jì)劃。
◆建立一套產(chǎn)品功能組件發(fā)展與統(tǒng)合的實(shí)作規(guī)劃。
◆使用自動化源代碼控制系統(tǒng)。
◆在包括需求分析、構(gòu)架確定、細(xì)部設(shè)計(jì)與實(shí)作階段末尾等各個(gè)重要過程完成后重新評估成本與時(shí)間的表格。
◆這些開發(fā)程序都有著明顯的快速成效。

對軟件開發(fā)程序的負(fù)面觀點(diǎn)

“開發(fā)程序”這字眼被一些軟件開發(fā)界的人僅當(dāng)成一個(gè)不實(shí)用的詞匯。這些人認(rèn)為“軟件開發(fā)程序”是死板、苛刻而沒有效率的。這種看法的論點(diǎn)是，最好的項(xiàng)目執(zhí)行方式是聘請你能找到最佳人才，給予他們要求的所有資源，然后放手讓這些你找來的人處理他們最專精的東西。照這種觀點(diǎn)，不受任何程序約束的項(xiàng)目才能夠特別效率。持有這種觀點(diǎn)的人把項(xiàng)目的推動過程想象成了如圖3-1所描繪的樣子：



抱有這種論點(diǎn)的人承認(rèn)“工作脫節(jié)”或非生產(chǎn)性的工作占有一些份量。開發(fā)人員會做錯事，他們承認(rèn)這一點(diǎn)，可是這些錯誤可以很快有效地修正過來當(dāng)然比“開發(fā)程序”所要花費(fèi)的整體成本要少。

依據(jù)這樣的看法，如圖3-2，在項(xiàng)目中加上程序設(shè)定只不過是多余的，還會耗去生產(chǎn)性工作時(shí)間。



這樣的說法有著直覺性的吸引力。在項(xiàng)目開始（圖中暗灰色部分），對執(zhí)行開發(fā)程序的關(guān)切用掉了一些生產(chǎn)性工作的時(shí)間。如果這種情形從頭到尾持續(xù)下去（圖中亮灰色的部分），繼續(xù)花時(shí)間去執(zhí)行開發(fā)程序就不合理了。

不過根據(jù)軟件業(yè)界的經(jīng)驗(yàn)，在中型項(xiàng)目中，圖3-2所示的情形不會在項(xiàng)目中持續(xù)下去。沒在開始建立有效的執(zhí)行開發(fā)程序的項(xiàng)目在一段時(shí)間之后還是被迫建立執(zhí)行程序，而且花費(fèi)時(shí)間更多而得到好處更少。下面就是些愈早設(shè)定開發(fā)程序愈好的情形：

◆變動控制：項(xiàng)目推行到一半時(shí)，團(tuán)隊(duì)成員同意非正式地做個(gè)由主管或客戶直接提出來的大副變動。他們一開始并沒有系統(tǒng)化地控制項(xiàng)目的變動，結(jié)果產(chǎn)品范圍擴(kuò)大了25%～50%以上，而預(yù)算跟工時(shí)也跟著追加了。

◆質(zhì)量保證：在初期沒設(shè)定好消除錯誤程序的項(xiàng)目，陷入了似乎永無止境的測試—改錯—修改—重新測試的冗長循環(huán)中。項(xiàng)目末尾的測試結(jié)果找到了相當(dāng)多的錯誤，“更好控制布告欄“上每天都開會排定不同錯誤修正的順序。由于錯誤太多了，軟件推出時(shí)還有許多已知（雖然不嚴(yán)重）錯誤。最糟的情形下，軟件質(zhì)量可能永遠(yuǎn)達(dá)不到推出水準(zhǔn)。

◆不受限制的審查：項(xiàng)目中太晚發(fā)現(xiàn)的重大錯誤讓軟件在測試階段還須被重新設(shè)計(jì)并重寫，使項(xiàng)目在本來不受任何規(guī)劃控制的情形下嚴(yán)重脫軌。

◆錯誤追蹤：太晚開始追蹤項(xiàng)目中的錯誤情形，忘了來修正一些已知的錯誤，而讓這些可能很好修正的錯誤跟著產(chǎn)品一起推出。

◆系統(tǒng)整合：不同開發(fā)人員發(fā)展的組件到項(xiàng)目末期才整合的結(jié)果，使得組件之間的接口缺乏協(xié)調(diào)，而要花費(fèi)更多精力才能讓這些組件步伐一致。

◆自動化源代碼控制系統(tǒng)：源代碼修定控制建立太晚，讓開發(fā)人員以外將自己的程序版本蓋過源代碼正本或其他人的源代碼檔案。

◆時(shí)程安排：在缺乏時(shí)間表的項(xiàng)目中，開發(fā)人員常被要求每周或經(jīng)常重估剩余工作所需花費(fèi)的時(shí)間占整體開發(fā)工作時(shí)間的比例。

一個(gè)起初就對各種開發(fā)程序漠不關(guān)心的項(xiàng)目，會讓開發(fā)人員在此后覺得他們把時(shí)間都花費(fèi)在開會跟修正錯誤上，而非用在加強(qiáng)軟件功能上。他們知道項(xiàng)目進(jìn)度脫節(jié)了，當(dāng)他們發(fā)現(xiàn)不能滿足時(shí)間底限時(shí)，他們的求生念頭開始萌生，使他們退回“單獨(dú)開發(fā)模式“——只求滿足個(gè)人的時(shí)間底限。他們不再去跟主管、客戶、測試人員、技術(shù)寫作者跟開發(fā)團(tuán)隊(duì)中的其他人打交道，使得項(xiàng)目紀(jì)律蕩然無存。

遠(yuǎn)遠(yuǎn)不如圖3-1所示水準(zhǔn)穩(wěn)定的生產(chǎn)性工作比例、不太注重開發(fā)程序的中型項(xiàng)目一般都經(jīng)歷了如圖3-3中所示的生產(chǎn)力變化方式：



圖中，項(xiàng)目經(jīng)歷了推動中工作過節(jié)狀況遞增的情形。等項(xiàng)目推動到途中，團(tuán)隊(duì)才會明白工作脫節(jié)耗去了許多時(shí)間，如果能進(jìn)行一些對應(yīng)的開發(fā)處理程序是會有好處的，不過已為時(shí)晚矣，對項(xiàng)目的傷害都已經(jīng)出現(xiàn)了。項(xiàng)目團(tuán)隊(duì)試著增加開發(fā)處理程序的功效，可是這樣的努力做得再多也彌補(bǔ)不了工作脫節(jié)的嚴(yán)重情形。有時(shí)努力步伐太慢一樣會讓工作脫節(jié)得更嚴(yán)重。

較幸運(yùn)的項(xiàng)目還可以在仍有殘余的工作時(shí)間里把產(chǎn)品趕出來，不幸的項(xiàng)目就沒辦法在工作脫節(jié)之前完成產(chǎn)品。這種情形持續(xù)數(shù)周或數(shù)個(gè)月后，這些項(xiàng)目一般都會因?yàn)橹鞴芑蚩蛻裘靼醉?xiàng)目推動進(jìn)度受阻而遭到取消。如果你認(rèn)為項(xiàng)目中的開發(fā)程序設(shè)定是件不必要的額外負(fù)擔(dān)，想想看一件被取消的項(xiàng)目可能讓你更劃不來吧。

補(bǔ)救程序

幸運(yùn)的是對這樣凄涼的場景，還有些變通的補(bǔ)救辦法，最令人高興的是完全不用依賴那些“死板而沒效率的開發(fā)程序”。（譯注：“死板而沒效率的開發(fā)程序”原文為rigid，inefficient processes，縮寫成R.I.P，剛好跟請死者“安息”的rest in peace的縮寫相同。）

當(dāng)然，有些軟件開發(fā)程序確實(shí)死板而沒有效率，所以我不建議把這些處理方式用在項(xiàng)目中。本章要描述的是使用能夠增進(jìn)項(xiàng)目彈性與效率的那些開發(fā)程序。
當(dāng)這些開發(fā)程序被用到項(xiàng)目中時(shí)，項(xiàng)目的工作效率比例就會變成圖3-4中的樣子。



在項(xiàng)目進(jìn)行的頭幾周，程序?qū)虻膱F(tuán)隊(duì)似乎比害怕使用開發(fā)程序的團(tuán)隊(duì)更沒生產(chǎn)力，因?yàn)閮蛇吂ぷ髅摴?jié)程度都差不多，而程序?qū)虻膱F(tuán)隊(duì)會花費(fèi)較多的時(shí)間來執(zhí)行開發(fā)程序，這項(xiàng)投資稍后就會在項(xiàng)目中顯出成效了。

等項(xiàng)目進(jìn)行到一半，先前就重視開發(fā)程序處理的團(tuán)隊(duì)跟之前比較，工作脫節(jié)的程度會開始降低，程序的執(zhí)行也會開始順暢起來。同時(shí)害怕使用開發(fā)程序的團(tuán)隊(duì)則開始明白工作脫節(jié)已無法掩飾，開始自己尋求補(bǔ)救辦法。

等項(xiàng)目接近尾聲時(shí)，程序?qū)驁F(tuán)隊(duì)正處于順暢運(yùn)作狀態(tài)，很少出現(xiàn)脫節(jié)的情形，而程序的執(zhí)行也感覺不出有什么費(fèi)時(shí)。少許的工作脫節(jié)狀況難免存在，因?yàn)闉橄@些脫節(jié)現(xiàn)象所花費(fèi)的精力實(shí)在不劃算。當(dāng)上述提到的開發(fā)程序都被執(zhí)行后，程序?qū)驁F(tuán)隊(duì)比起害怕使用開發(fā)程序的團(tuán)隊(duì)會更早進(jìn)入狀態(tài)。

================================================
項(xiàng)目一開始對開發(fā)程序所做的努力終究有所回饋。
================================================

明確注重改善開發(fā)程序的組織，可以在幾年中把產(chǎn)品的上市時(shí)間縮減了一半，錯誤發(fā)生率降低了60%～90%倍。在五年里，洛克希德公司（Lockheed）把產(chǎn)品開發(fā)成本降低了75%，時(shí)間則縮減了40%，而錯誤發(fā)生率也降低了90%。在六年半的時(shí)間里，Raytheon公司的生產(chǎn)力提升了三倍，投資回報(bào)率（Return On Investment，ROI）達(dá)到八倍。Bull HN公司在經(jīng)歷四年的軟件開發(fā)程序改進(jìn)后，投資回報(bào)率也達(dá)到四倍。Schlumberger公司在花三年半的時(shí)間改善軟件開發(fā)程序后，把投資回報(bào)率提升到接近九倍。NASA的軟件工程實(shí)驗(yàn)室在八年中把每個(gè)任務(wù)的平均成本縮減了一半，錯誤發(fā)生率降低了75%，同時(shí)大幅度增進(jìn)了每個(gè)任務(wù)中使用軟件的復(fù)雜度。類似成果也出現(xiàn)在休斯、Loral、摩托羅拉、全錄與其他注重系統(tǒng)化改善軟件開發(fā)程序的公司中。

最好的消息是，你猜猜看，這些生產(chǎn)力、質(zhì)量與時(shí)程表現(xiàn)的改善花費(fèi)的成本是多少？只花費(fèi)了整體開發(fā)成本的2%的代價(jià)而已——通常每名開發(fā)人員每年約花費(fèi)1500美金而已。

開發(fā)程序?qū)?chuàng)意與士氣

對于系統(tǒng)化開發(fā)程序的一個(gè)反對意見是認(rèn)為這樣會限制程序?qū)懽魅藛T的創(chuàng)意。程序員們確實(shí)很需要有創(chuàng)意，不過主管與項(xiàng)目主持人也需要讓項(xiàng)目維持在可掌握的范圍內(nèi)，讓項(xiàng)目進(jìn)展看得出來，而且滿足時(shí)間、預(yù)算與其他目標(biāo)。

系統(tǒng)化開發(fā)程序會限制開發(fā)人員創(chuàng)意的說法，是由于對開發(fā)人員創(chuàng)意與達(dá)成項(xiàng)目目標(biāo)管理兩者之間一些矛盾的想法所致。兩者并行不悖的環(huán)境當(dāng)然是可能的，而且許多公司都已經(jīng)做到了，就像建立一個(gè)能夠同時(shí)滿足不同目標(biāo)間的協(xié)調(diào)并完成這些目標(biāo)的環(huán)境一樣可行。

注重開發(fā)程序的公司已經(jīng)發(fā)現(xiàn)有效率的程序可以支持開發(fā)人員的創(chuàng)意與士氣。在一個(gè)針對約五十家公司的調(diào)查中，發(fā)現(xiàn)只有少數(shù)開發(fā)程序?qū)蚬镜娜藢⒆约汗驹u為“士氣良好”或“士氣高昂”。在對軟件開發(fā)程序付出更多注意的組織中，約有一半的人將自己公司評為“士氣良好”或“士氣高昂”。而在最注重開發(fā)程序的組織中，有60%的人將自己公司評為“士氣良好”或“士氣高昂”。

當(dāng)程序?qū)懽魅藛T最具生產(chǎn)力時(shí)，他們的感覺也最好。好的項(xiàng)目領(lǐng)導(dǎo)者建立清楚的目標(biāo)遠(yuǎn)景，并利用一套開發(fā)程序構(gòu)架讓程序員們覺得自己擁有不可思議的生產(chǎn)力。程序員們討厭阻礙工作的各種障礙，他們不得不拋開眼高手低、毫無章法的脆弱領(lǐng)導(dǎo)者。程序員們欣賞有遠(yuǎn)見、有見識與有魄力的開明領(lǐng)導(dǎo)者。

在此對開發(fā)程序與創(chuàng)意之間所謂矛盾的適當(dāng)響應(yīng)就是，本文中沒有任何一個(gè)程序規(guī)劃會以任何方式限制程序?qū)懽魅藛T的創(chuàng)意，最多是提供一個(gè)支持架構(gòu)，讓程序員們能夠自由地對相關(guān)的技術(shù)性工作發(fā)揮創(chuàng)意，讓他們免于分心在那些消耗注意力的瑣事上。

過渡到系統(tǒng)化開發(fā)程序

如果一支項(xiàng)目團(tuán)隊(duì)目前沒采用系統(tǒng)化程序，一個(gè)最簡單的過渡辦法就是描繪出目前的軟件開發(fā)程序的細(xì)節(jié)，將沒用的部分標(biāo)示出來，試著改正那些地方。雖然項(xiàng)目團(tuán)隊(duì)有時(shí)會宣稱他們目前沒有規(guī)劃開發(fā)程序，每個(gè)項(xiàng)目團(tuán)隊(duì)實(shí)際上都有自己的開發(fā)程序做法（如果他們說目前沒采取開發(fā)程序的做法，他們大概只是沒有一套好的開發(fā)程序規(guī)劃）。

最粗糙的開發(fā)程序做法一般是這樣的：

1．討論要寫出怎樣的軟件。
2．寫出些程序來。
3．測試程序，找出缺陷。
4．除錯，找出錯誤的根源來。
5．修正缺陷。
6．如果項(xiàng)目還沒完成，回到第一步。

本文提供了一套更精巧的軟件開發(fā)程序。

建立系統(tǒng)化軟件開發(fā)程序的障礙之一，就是項(xiàng)目團(tuán)隊(duì)害怕自己會在面對太多開發(fā)程序項(xiàng)目時(shí)出錯，害怕他們執(zhí)行這些程序后，會變得太官僚化，對項(xiàng)目執(zhí)行造成太大負(fù)擔(dān)。這通常不構(gòu)成顯著的危險(xiǎn)，因?yàn)椋?br>
◆使用本文做法的項(xiàng)目會有個(gè)相當(dāng)精細(xì)的開發(fā)程序，不會帶來太多負(fù)擔(dān)。
◆軟件項(xiàng)目常常比第一眼看起來的要大得多。多數(shù)項(xiàng)目的問題出在本身，而不是出在開發(fā)程序中。
◆比較好的做法是開始先設(shè)定較多的開發(fā)程序以供執(zhí)行、再視情況調(diào)整，比開頭毫無章法其后再追加額外程序項(xiàng)目要容易。
◆多設(shè)定些程序項(xiàng)目所花的成本與時(shí)間代價(jià)要遠(yuǎn)低于不重視這檔子事。接下來，就告訴你為何如此。

上下游

好的軟件開發(fā)程序可及早處理項(xiàng)目中的問題。

你有時(shí)會聽到經(jīng)驗(yàn)老到的軟件開發(fā)人員提起軟件項(xiàng)目中的“上游”跟“下游”部分?！吧嫌巍边@字眼只是用來表示項(xiàng)目的開始部分，“下游”則是指項(xiàng)目的末尾部分。

“上下游”的分法對于思考項(xiàng)目上的問題是很有用的。開發(fā)人員在項(xiàng)目開始所做的，在末尾未必有收獲。如果一開始工作處理得當(dāng)，末尾的收獲就會健全并有助于項(xiàng)目成功。如果開始工作做得不好，后來的結(jié)果就可能嚴(yán)重影響成果，不客氣地說，甚至可能讓項(xiàng)目無法完成。

研究人員發(fā)現(xiàn)諸如規(guī)格或架構(gòu)上的錯誤，事后才修正會比一開始就修正錯誤要花費(fèi)多出50～200倍的代價(jià)。圖3-5說明了這種效應(yīng)。




要能讓規(guī)格中的一句話很容易變成幾個(gè)設(shè)計(jì)方式，而這些設(shè)計(jì)方式之后能再變成幾百行的源代碼、幾打的測試情形、許多頁的使用文件、線上求助畫面及許多技術(shù)支持部門的操作說明等等東西。

當(dāng)項(xiàng)目團(tuán)隊(duì)有機(jī)會階段性修正錯誤，立刻修正錯誤會比過一陣子再去修正受影響之處要有意義。這種在錯誤發(fā)生的階段內(nèi)找出錯誤并馬上休正的構(gòu)想稱作“階段圍堵”策略。

============================================
成功的項(xiàng)目借由仔細(xì)審查、要求規(guī)格與架構(gòu)來制
造機(jī)會修正上游問題。
============================================

在上游動作時(shí)還沒寫出任何程序，找尋及修正錯誤，雖然可能讓項(xiàng)目“該做的工作”表面上看來被拖延了，實(shí)際上卻剛好相反。這些工作是在替項(xiàng)目的成功鋪路。

過多程序項(xiàng)目的錯誤會越發(fā)的增加項(xiàng)目的負(fù)擔(dān)，不過缺乏程序規(guī)劃的問題會讓錯誤變成必須花費(fèi)50～200倍的效率成本才能修正的大麻煩。因此寧可多設(shè)定開發(fā)程序事項(xiàng)，也比不做開發(fā)程序設(shè)定來得好。

不確定性的角錐

上游錯誤要多花費(fèi)50～200倍的代價(jià)才能在下游修正的一個(gè)原因是，上游決定的范圍比下游的要廣。

在項(xiàng)目初期，項(xiàng)目團(tuán)隊(duì)面對的是大問題，例如要不要同時(shí)支持Windows NT或Macintosh或是只支持Windows NT就好了，還有報(bào)表格式是使用者自訂還是固定格式。在項(xiàng)目進(jìn)行中，項(xiàng)目團(tuán)隊(duì)面對的是中型問題：有多少子系統(tǒng)；如何按一般情形處理錯誤狀況；或是如何把一個(gè)打印例程從過去的項(xiàng)目移植到現(xiàn)在的項(xiàng)目中。

到了項(xiàng)目末期，項(xiàng)目團(tuán)隊(duì)面對的是小問題，像是要采用哪一種技術(shù)算法，或者要不要讓使用者能夠取消還沒完成的動作等等。如圖3-6所示，軟件開發(fā)是個(gè)持續(xù)漸進(jìn)的程序，將問題由大到小分開處理，從決定大勢走向到解決個(gè)別的小問題。推動軟件項(xiàng)目所花費(fèi)的時(shí)間，就是徹底思考并解決問題所需要的時(shí)間。

本圖中的角錐狀圖形為項(xiàng)目中決策方向未定的事務(wù)量。軟件項(xiàng)目中對問題的決策尺度由大到小。除非團(tuán)隊(duì)成員完成了前一個(gè)階段的大部分工作，不然無法知道一個(gè)特定階段中到底有多少需要決定執(zhí)行方向的問題。

項(xiàng)目團(tuán)隊(duì)最擅于處理大型的決策問題，不過有時(shí)無法預(yù)見（而且不可預(yù)知的）的問題會在后頭因?yàn)榇笮蜎Q策不當(dāng)而出現(xiàn)，若要中途取消一個(gè)行動則表示項(xiàng)目團(tuán)隊(duì)得重新設(shè)計(jì)一個(gè)常式、一個(gè)模塊甚至一整個(gè)子系統(tǒng)。



在某一尺度的決策敲定后，應(yīng)可以事先精確預(yù)估下一尺度將面對的決策種類。不過項(xiàng)目團(tuán)隊(duì)或許可以先做好前頭的決定，但對項(xiàng)目后頭的決策問題只可能作出一般性的猜測。如果你想知道軟件開發(fā)的工作為何，了解項(xiàng)目團(tuán)隊(duì)所有該思考的問題，并明白一個(gè)團(tuán)隊(duì)得在充分了解下一個(gè)階段工作的內(nèi)容之前便決定好現(xiàn)階段中所有的執(zhí)行方向，就成了重要的事情。

不確定性的角錐對項(xiàng)目預(yù)估的意義

不確定性的角錐對軟件項(xiàng)目的預(yù)估有著強(qiáng)烈的意義。它不光表示在前期階段精確評估項(xiàng)目的困難性，還說明那在理論上不可能辦到。在需求規(guī)格階段末尾，項(xiàng)目的范圍還得由一大堆在購架階段、細(xì)節(jié)設(shè)計(jì)階段和構(gòu)建階段要作出的決策所決定。宣稱能夠預(yù)估未定決策對項(xiàng)目影響有多大的人如果不是先知，就是對于軟件開發(fā)的本質(zhì)不太了解的人。

另一方面，尋求控制決策方向以符合項(xiàng)目預(yù)計(jì)時(shí)間或預(yù)算目標(biāo)的人是明智的。只要你愿意痛下決心砍掉一些規(guī)劃功能，在項(xiàng)目初期就確立精確的時(shí)間表和預(yù)算目標(biāo)，并在之后一直按部就班。成功的關(guān)鍵在于以這樣的方式達(dá)成目標(biāo)要求，做法包括在項(xiàng)目初期設(shè)定明確而不沖突的目標(biāo)，保持產(chǎn)品概念非常有彈性，并主動追蹤控制項(xiàng)目中的開發(fā)工作。

==============================================================
在項(xiàng)目開頭，你能制定實(shí)在的成本和時(shí)間目標(biāo)，或是制定充實(shí)的功能
組合，但是你不能強(qiáng)求兩邊的目標(biāo)都要達(dá)成。
==============================================================

【?發(fā)表評論?0條?】