前言
軟件開發(fā)項目計劃為項目管理服務的，本文用項目管理的眼光去看待項目計劃的內容。應用本文的方法制定的項目計劃可以：
1. 讓項目的時間、成本、進度的估算可以通過簡易的公式進行一次性計算得到
2. 讓不了解項目實現(xiàn)技術的人，如客戶、投資者、管理者及愿意了解項目的人員很容易地了解項目的時間、成本、進度的狀態(tài)及其完工估算
3. 讓項目工作量的分配更具體、更客觀，對成員的績效表現(xiàn)顯而易見
4. 使項目之間的工作績效具有可比性

實例
一般情況下我們的項目計劃是這樣的：
1. 第一層是項目開發(fā)的實際階段
2. 第二層是所在階段的工作
3. 第三層是對較大工作量的工作做進一步分解

問題
這樣的計劃有以下幾個缺點：
1. 不適應迭代開發(fā)的工作模式。多數(shù)應用軟件的開發(fā)不是純粹“瀑布開發(fā)模型”，當?shù)竭_后面的階段時，不可避免的發(fā)現(xiàn)以前階段的工作沒有真正完成，需要繼續(xù)進行。例如，設計階段時，極有可能會發(fā)現(xiàn)分析需求階段中漏了一個功能沒有考慮進去，以致分析需求階段沒有真正完成而需要繼續(xù)。
2. 計劃的實際執(zhí)行數(shù)據(jù)不能作為項目的完成估算的依據(jù)。 比如調研和需求確認階段完成時，依據(jù)該階段的實際執(zhí)行數(shù)據(jù)不能預知項目將在什么時間結束，在什么成本范圍完成。有以下幾個原因：
1) 階段本身的界限是不清晰的
2) 階段之間的時間、成本、進度的分配關系并不確定
3. 這些估算數(shù)據(jù)難以被以后的開發(fā)計劃所借鑒。當一個項目或一個階段結束后，我們總會想在這個已執(zhí)行完成的計劃的上面得到一點關于估算方面的經驗或教訓，如：
1) 這個項目的總開發(fā)成本與其他項目相比，是多了還是少了？
2) 設計分析階段的時間分是不是不與項目的需求不匹配？
3) 哪個階段的成本分配有問題？
4) 各項工作的平均時間合不合適？
按上面的計劃，我們不能夠很好的回答這些問題，是因為這個計劃是按階段來劃分的，實際工作中，這些階段的界限并不明顯，無法得到準確的數(shù)據(jù)。
4. 當需求變更時，不知把這些變更的工作放入項目計劃的哪個階段。因為這些變更往往包含了很多的階段。有人建議把它們放到一個叫做“需求變更”的特殊階段中，但這些變更是不可預知的，它幾乎分布到項目的整個開發(fā)過程中，我們又如何在計劃是反應它們呢？

實際過程
在介紹本文的方法以前，了解RUP(rational unified process) 的朋友，知道軟件開發(fā)過程并不是我們想象的如此簡單。它告訴我們在同一個時間內所有的開發(fā)階段是有可能共存的。也是說整個開發(fā)過程可以是多個迭代同時進行。
我們回顧一下日常的開發(fā)過程：
1. 得知有一個項目需要開發(fā)。有可能是老板告訴你的，也可能是業(yè)務部門告訴你的，總之我們要為它而工作了，同時確信老板同意開始這個項目
2. 對這個項目涉及的人員及其需求進行調查。這里的需求包括了所有項目的需求，比如老板對這個項目的要求及期望，用戶對這個項目的期望，開發(fā)人員對這個項目的期望。這時，我們很快會發(fā)現(xiàn)，調查所有人是不可能的，調查所有需求也是不可能的。因此，
1) 我們會先找?guī)讉€關鍵人物，了解他們的期望，確定系統(tǒng)的邊界（或叫輪廓，XP(Extreme Programming)中把它叫系統(tǒng)隱喻）；
2) 再把系統(tǒng)劃分為幾個部分，確定先做哪個部分后做哪個部分；
3) 再一個一個部分對需求進行調查
當我們在調查的時候，常常會發(fā)現(xiàn)新的部分之間的關聯(lián)，這使我們不得不對這兩個部分的內容進行檢查，加的加，改的改，刪的刪。
3. 基于調查的結果進行設計。這個時間，我們經過對這些需求的分析、歸類，設計一個開發(fā)的模型以支持這些需求。設計時也免不了會發(fā)現(xiàn)需求不對的地方，對需求進行加的加，改的改，刪的刪。
4. 基于設計的結果進行編碼、集成。也免不了會發(fā)現(xiàn)設計、需求不對的地方，對需求進行加的加，改的改，刪的刪。
5. 基于編碼的結果進行測試，以驗證軟件是否達到了需求。我們常常發(fā)現(xiàn)這時的需求與設計之前的需求已有了很大的變化。
6. 發(fā)布（部署）產品，進行項目收尾。
如果某一時間，客戶要知道項目進行到哪了，我們告訴他設計已完成，正進行編碼工作。當有需求變更時，相關的需求、設計又要來過?？蛻裟懿粦岩晌覀兊幕卮鹈?？

解決方法
做過軟件開發(fā)的人就會知道，上面的過程描述中有很大的問題。我們的做過程并沒有錯，一個一個需求，一個一個功能的實現(xiàn)，有變更時就一個一個變更的實現(xiàn)，大家都這樣做，也只有這樣做。對于一個應用軟件項目來講，而不太可能真正的按軟件書上寫的過程一個一個過程的做下去，集中10天做完所有的需求，集中20天內做完所有設計。
做的過程沒有錯，把過程描述出來，為什么就錯了？原因很簡單：我們在描述時，總喜歡套用一些“模式”，一些書寫的“方法”，而不是按實際的過程描述。如果我們不套用任何模式，將會如何呢？我們再來描述一遍上面的過程：
1. 了解軟件項目的故事（story）。開始一個軟件應用項目，了解關鍵人物都有哪些？他們要求是一個什么樣的系統(tǒng)？把這些要求描述成一個一個的故事，如果稍稍規(guī)范一點。就會象這樣：
1) 這個系統(tǒng)的目標是為了誰解決什么問題
2) 第一步做什么，系統(tǒng)反饋什么
3) 第二步做什么，系統(tǒng)反饋什么
4) …
5) 問題解決了，結束本故事
我們會仔細的看這些故事，發(fā)現(xiàn)有些地方看不懂，于是我們就去問清楚，有些事情是那個描述故事的A也不清楚的，但A告訴我們B會懂，于是我就問B；有些事情A也不知道有誰會知道，我們就把它放在一邊，等知道的時候再問，繼續(xù)看其他的故事。
2. 了解系統(tǒng)隱喻，構造軟件框架。永遠也問不清楚所有的事情，所以當我們知道整個系統(tǒng)的是為了解決什么問題，將用什么辦法來解決它（暫時叫做系統(tǒng)隱喻），關鍵人物也認可時，我們就不再問下去了。我們依據(jù)這個系統(tǒng)隱喻去構造一個最上面的故事。然后，只關心與這個故事有關的故事。同時構造一個程序框架以支持項目的開發(fā)
3. 實現(xiàn)故事。在軟件框架上，實現(xiàn)一個故事，再實現(xiàn)一個故事，…
4. 實現(xiàn)變更。有時發(fā)現(xiàn)事情并沒有想象的簡單，于是就變更它，這就要求我們實現(xiàn)這些次變更。它象實現(xiàn)故事一樣：實現(xiàn)一次變更，再實現(xiàn)一次變更，…
5. 部署軟件。感覺軟件已達到了可被接受的預想或合適的要求了，就發(fā)布這個軟件。

上面所說的故事就是我們常說的用例（use case）。我們可以使用用例的形式來描述整個系統(tǒng)的計劃內容，并計算它的工作量，為工作之間、項目之間的績效提供一個統(tǒng)一的衡量標準。
這時，我們發(fā)現(xiàn)：
1. 由故事（有些項目可以用故事所包含的步驟）的數(shù)量可計算出開發(fā)的工作量
2. 我們實際開發(fā)工作過程的時間、成本、進度是可以被不了解項目實現(xiàn)技術的人所感知的

如果我們仔細查看項目的所有工作，會發(fā)現(xiàn)有些工作不是基于某個用例的，也與某些用例沒有直接關系，如何拿用例來計算它的工作量呢？在項目的開發(fā)中確定存在這些工作，如項目開始時的“了解軟件項目的故事”。但通過分析知道，在一個軟件項目中頂層用例的數(shù)量是不難預測的，也是說在這個時期要向關鍵人了解的用例數(shù)是可以預測的。我們不難發(fā)現(xiàn)，要了解的用例數(shù)越多，需求了解的工作量就越大。在相同類型的應用軟件開發(fā)中，需求了解的工作量與用例數(shù)量的比例是基本一致的。同理，了解系統(tǒng)隱喻，構造軟件框架、部署軟件的工作量與用例的量也是成比例的。

在沒有不熟習技術的前提下，根據(jù)本人的經驗，同類軟件項目的工期與底層用例數(shù)或步驟數(shù)有著可計算的關系，如WEB應用軟件中，一個底層故事的開發(fā)時間大約為1.5個人日。這個是經驗數(shù)據(jù)，在不同的公司可能有所不同。網上也有文章證明不同規(guī)模的應用軟件，故事與程序代碼的行數(shù)有一定的計算關系。這樣我們的不同項目，或同一項目的不同故事之間，在時間、成本、進度上就具有了可比性。
同時，我們發(fā)現(xiàn)：
3. 讓項目的時間、成本、進度的估算可以通過簡易的公式進行一次性計算得到
4. 讓項目工作量的分配更具體、更客觀，對成員的績效表現(xiàn)顯而易見
5. 使項目之間的工作績效具有可比性

要注意的問題
1. 在不同層次上的用例有著不一樣的工作量比例，一定要分清。比如WEB應用軟件的用例可以這樣劃分：
用例層次　 對應系統(tǒng)的對象
頂層　　　 項目，如網上商城
上層　　　 子系統(tǒng)，如網上商城＼用戶管理
中層　　　 流程，如網上商城＼用戶管理中＼注冊流程
底層　　　 頁面，如網上商城＼用戶管理中＼注冊流程＼第一個頁面
2. 這種用例與工作量的比例關系，是建立一定量的基礎之上的，比如20個以上才有這個比例關系。對于一般應用軟件的計劃及績效的計算是合適的，但對于個例是不適用的，不能憑這個比例來衡量某幾個用例的工作量。

總結
好了，下面總結一下本文方法的實現(xiàn)步驟：
1. 了解軟件項目的故事。從項目關鍵人物那了解到系統(tǒng)的主要故事有哪些，并力求描述清楚
2. 了解系統(tǒng)隱喻，構造軟件框架
3. 實現(xiàn)故事。先實現(xiàn)頂層故事；再一個一個故事實現(xiàn)
4. 故事變更。實現(xiàn)一次變更，再實現(xiàn)一次變更，…
5. 部署軟件

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