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

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

又例如我還發現在程式設計領域的重構就是迭代思想一種體現。所謂重構是這樣一個過程：「在不改變程式碼外在行為的前提下，對程式碼做出修改，以改程式序的內部結構」。重構是一種有紀律的、經過訓練的、有條不紊的程式整理方法，可以將整理過程中不小心引入錯誤的機率降到最低。本質上說，重構就是「在程式碼寫好之後改進它的設計」。我們可以打個比方，重構就是編碼過程的迭代，透過一次次重構的迭代達到更佳的設計，每次重構的迭代都保證了程式的正常執行，這意味著每次迭代的結果都是可以觀察到的。

圖一
瀑布和迭代

瀑布型的軟體開發進度計劃一般按照階段劃分，即分為策劃與估計，需求調研與分析，概要設計，詳細設計，編碼與單元測試，整合測試，系統測試，實施交付，專案收尾。
迭代型的開發進度計劃可以分為兩個層次，第一個層次是總體的計劃，可能歷時幾年或者幾個月，如XP的釋出計劃，RUP的階段計劃。第二個層次是短期的詳細計劃，歷時從一週到2、3個月不等。總體計劃劃分整個專案的工作到各個迭代週期中，並不關注執行細節，時間跨度較大可能會因為需求的變化而修訂；而短期計劃是一個迭代週期的計劃，關注執行細節，將具體的任務落實到人，並且由於時間跨度小相對穩定。

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

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

迭代型軟體專案開發計劃的編制（轉）

相關文章