迭代型軟件項目開發(fā)計劃的編制
林鎮(zhèn)鋒（深圳市康拓普電力自動化有限公司，PMP）
摘要
項目計劃的編制對一個項目的成功執(zhí)行起著非常重要的作用，而在軟件開發(fā)領(lǐng)域，面對不確定的用戶需求，瀑布型的項目計劃往往成了一紙空文，迭代型的項目計劃又無章可循。本文針對這種現(xiàn)象提出一種適用于迭代型軟件項目開發(fā)計劃的編制方法。
引言
我們知道對于軟件開發(fā)來說，變化的需求才是不變的道理，在制定計劃時期望事情的一切都按照計劃進行，是不切實際的。如果我們拿計劃來評估績效，人們將會說一切都很好，一切都按部就班，即便已經(jīng)出現(xiàn)了某些危險的征兆。這幾年在軟件工程領(lǐng)域有越來越多的有識之士提出，現(xiàn)實中存在兩種生產(chǎn)方式：可預(yù)測的生產(chǎn)和不可預(yù)測的生產(chǎn)，而軟件開發(fā)就屬于不可預(yù)測的生產(chǎn)方式，因此軟件開發(fā)項目不適宜采用可預(yù)測的計劃方式。
正文
經(jīng)過幾十年的發(fā)展，軟件工程領(lǐng)域出現(xiàn)了很多種軟件生命周期模型，有瀑布型，迭代型，增量型等等。軟件項目的開發(fā)計劃的編制要取決于軟件項目的生命周期模型，換句話說，就是瀑布型項目和迭代式項目的開發(fā)計劃的編制方法并不相同。而瀑布模型來源于建筑行業(yè)、制造行業(yè)等可預(yù)測的生產(chǎn)，本來就無法適應(yīng)需求不穩(wěn)定的軟件項目。因此許多項目盡管在一開始就規(guī)定采用瀑布型，卻在實踐中慢慢變成了迭代型。許多采用了瀑布型的項目計劃與現(xiàn)實差距太大，最終變成了無法落實的一紙空文。

其實迭代不是什么新的發(fā)明，其中思想與PDCA的思想也是一致的，都是通過一個螺旋上升的過程不斷逼近目標(biāo)或者期望。這個道理很樸素，現(xiàn)實世界中俯拾皆是，客戶的頭腦中也有這樣的模型，難怪他們動輒說：“剛才提到的這些需求，你們先開發(fā)出來，我們試用一下，看是否合適，再來改進。”

又例如我還發(fā)現(xiàn)在編程領(lǐng)域的重構(gòu)就是迭代思想一種體現(xiàn)。所謂重構(gòu)是這樣一個過程：「在不改變代碼外在行為的前提下，對代碼做出修改，以改進程序的內(nèi)部結(jié)構(gòu)」。重構(gòu)是一種有紀(jì)律的、經(jīng)過訓(xùn)練的、有條不紊的程序整理方法，可以將整理過程中不小心引入錯誤的機率降到最低。本質(zhì)上說，重構(gòu)就是「在代碼寫好之后改進它的設(shè)計」。我們可以打個比方，重構(gòu)就是編碼過程的迭代，通過一次次重構(gòu)的迭代達到更佳的設(shè)計，每次重構(gòu)的迭代都保證了程序的正常運行，這意味著每次迭代的結(jié)果都是可以觀察到的。



圖一
瀑布和迭代

瀑布型的軟件開發(fā)進度計劃一般按照階段劃分，即分為策劃與估計，需求調(diào)研與分析，概要設(shè)計，詳細設(shè)計，編碼與單元測試，集成測試，系統(tǒng)測試，實施交付，項目收尾。
迭代型的開發(fā)進度計劃可以分為兩個層次，第一個層次是總體的計劃，可能歷時幾年或者幾個月，如XP的發(fā)布計劃，RUP的階段計劃。第二個層次是短期的詳細計劃，歷時從一周到2、3個月不等?？傮w計劃劃分整個項目的工作到各個迭代周期中，并不關(guān)注執(zhí)行細節(jié)，時間跨度較大可能會因為需求的變化而修訂；而短期計劃是一個迭代周期的計劃，關(guān)注執(zhí)行細節(jié)，將具體的任務(wù)落實到人，并且由于時間跨度小相對穩(wěn)定。

制定總體計劃
項目總是存在約束條件，例如客戶方要求某年某月完成系統(tǒng)一個版本，這個版本應(yīng)該包含若干功能?；蛘哌@個項目與類似項目相比，可以得到一個大致的完成日期。這些都是制定總體計劃時關(guān)鍵信息。
總體計劃為團隊的工作指出了方向。在總體計劃中主要關(guān)注里程碑，每個里程碑要完成的目標(biāo)或者功能項。因此總體計劃也可以被稱為里程碑計劃。不要為各個活動設(shè)定一個完成時間點，例如設(shè)定詳細設(shè)計的完成日期，編碼與單元測試的完成日期都是沒有意義的。因為這些活動在整個項目進行中都是不斷重復(fù)進行的，即便進行了系統(tǒng)測試也回過來進行詳細設(shè)計和編碼。
有了總的完成日期和各個里程碑，這個計劃的框架基本確定了。我們可以進行功能點的估算得到一個參考的估算值，例如系統(tǒng)需要耗費的工作量（人月或人時），進一步估算，我們可以得到每個活動花費的工作量，例如編碼的工作量是多少個人月或人時，此時結(jié)合項目的實際人力資源情況，當(dāng)這兩者匹配時，計劃是可行的。否則需要對計劃作出調(diào)整。由于有了比較客觀的估算，這種調(diào)整還是比較具有說明力的。
最后總體計劃要確定迭代周期多長，一般為2-3周。
總體計劃批準(zhǔn)通過后建立計劃基線，如果需要修訂必須獲得客戶方的同意，但是總體計劃關(guān)注的層次較高，修訂的機會很小，避免了項目經(jīng)理頻繁更新計劃的困境。
制定迭代計劃
確定了總體計劃后，我們可以為每個迭代周期制定計劃了，但是并非將所有迭代周期的計劃一次性完成，我們只需要制定當(dāng)前迭代周期的計劃即可，到了迭代的后期才能確定什么需要在下個周期內(nèi)完成的事情。
時間箱（TimeBoxing）迭代是將迭代的結(jié)束日期固定下來并且不允許其改變的實踐。一旦某次迭代的時間箱無法實現(xiàn)，我們不能推遲迭代的結(jié)束日期，而是減小范圍，如下圖所示，四個變量中時間變量被固定后，我們只需要考慮范圍，質(zhì)量，人員三個變量。

圖二
迭代計劃可以使用Project進度計劃來編制并跟蹤。項目管理理論中對如何編制進度做了詳細的論述，這包括編制wbs，任務(wù)之間關(guān)系，分配人員，確定任務(wù)的工期，確定任務(wù)的起止時間，進行資源平衡，并行任務(wù)，提前任務(wù)來填充空白時間等技巧。由于迭代計劃的時間跨度短，項目經(jīng)理和團隊成員完全有能力對這個短期的計劃作出比較準(zhǔn)確的判斷和估計，也可以根據(jù)實際情況進行微調(diào)，因此迭代計劃的修訂與跟蹤工作可以很好的開展。
結(jié)束語
實踐是檢驗真理的唯一標(biāo)準(zhǔn)，軟件項目更適合采用迭代的開發(fā)模型，軟件項目計劃也應(yīng)該采用更加符合實際情況的有效編制方式。作者通過幾年的實踐經(jīng)驗，總結(jié)了一種迭代型的軟件項目計劃的編制方法，期望能夠為從事迭代型軟件項目的項目經(jīng)理提供一些有益的參考。
參考文獻
Planning Agile Projects 【英】Martin Fowler
敏捷迭代開發(fā)－管理者指南 【美】Craig Larman著，張曉坤，林旺，曾毅譯 中國電力出版社

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