良好的開發(fā)程序?qū)浖椖康拇嬖谑侵匾仨毜摹Ｓ辛肆己玫拈_發(fā)程序，軟件開發(fā)人員可以將大部分時間用在讓項目更穩(wěn)定的生產(chǎn)性工作上。如果開發(fā)程序規(guī)劃不良，開發(fā)人員將會花費大部分時間修正錯誤。項目成敗的關(guān)鍵在于擁有良好的準(zhǔn)備工作，并讓有見識的項目出資者了解，項目人員投注了足夠的精力在準(zhǔn)備工作上，以減少后續(xù)發(fā)生的問題。

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

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

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

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

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

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



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

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



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

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

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

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

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

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

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

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

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

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

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



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

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

補救程序

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

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



在項目進(jìn)行的頭幾周，程序?qū)虻膱F隊似乎比害怕使用開發(fā)程序的團隊更沒生產(chǎn)力，因為兩邊工作脫節(jié)程度都差不多，而程序?qū)虻膱F隊會花費較多的時間來執(zhí)行開發(fā)程序，這項投資稍后就會在項目中顯出成效了。

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

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

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

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

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

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

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

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

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

當(dāng)程序?qū)懽魅藛T最具生產(chǎn)力時，他們的感覺也最好。好的項目領(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)就是，本文中沒有任何一個程序規(guī)劃會以任何方式限制程序?qū)懽魅藛T的創(chuàng)意，最多是提供一個支持架構(gòu)，讓程序員們能夠自由地對相關(guān)的技術(shù)性工作發(fā)揮創(chuàng)意，讓他們免于分心在那些消耗注意力的瑣事上。

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

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

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

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

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

建立系統(tǒng)化軟件開發(fā)程序的障礙之一，就是項目團隊害怕自己會在面對太多開發(fā)程序項目時出錯，害怕他們執(zhí)行這些程序后，會變得太官僚化，對項目執(zhí)行造成太大負(fù)擔(dān)。這通常不構(gòu)成顯著的危險，因為：

◆使用本文做法的項目會有個相當(dāng)精細(xì)的開發(fā)程序，不會帶來太多負(fù)擔(dān)。
◆軟件項目常常比第一眼看起來的要大得多。多數(shù)項目的問題出在本身，而不是出在開發(fā)程序中。
◆比較好的做法是開始先設(shè)定較多的開發(fā)程序以供執(zhí)行、再視情況調(diào)整，比開頭毫無章法其后再追加額外程序項目要容易。
◆多設(shè)定些程序項目所花的成本與時間代價要遠(yuǎn)低于不重視這檔子事。接下來，就告訴你為何如此。

上下游

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

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

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

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




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

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

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

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

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

不確定性的角錐

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

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

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

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

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



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

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

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

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

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

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