13.5項目計劃
我們的項目是日期驅(qū)動的，10月1日是我們項目的正式運行日期，現(xiàn)在是4月中旬，我們只有5個多月的時間，如何規(guī)劃我們項目的進度呢？
可以從項目發(fā)布的日期倒推上來，大家在白板上畫來畫去，最后得出了這樣一幅圖（如圖13-2所示）。
圖13-2項目計劃
小飛：我們可以把8月和9月上旬都做成開發(fā)里程碑，然后把9月中下旬作為穩(wěn)定和發(fā)布階段，這樣是否可以寫更多的功能？
阿超：這是非常理想的情況，但是根據(jù)目前的技術水平和管理水平，我們不能做到這一點。而且目前我們沒有設立任何緩沖區(qū)。在項目的進行中，我們還有可能要做設計變更（DCR，Design Change Request），這些都需要時間。
大牛：為什么叫第0里程碑？
大栓：因為程序員從0開始計數(shù)。
阿超：對，更重要的是在這個里程碑中我們要確定整個系統(tǒng)的框架，別的里程碑（或者叫迭代）都可以看做是在第0里程碑基礎上的增量開發(fā)。
大牛：有道理，咱們集市里擺攤的都很重視早上開市的第一筆買賣，這就相當于第0里程碑。第一筆買賣沒成，一天的生意都受影響。
大栓：那應該叫第0筆買賣。
13.5.1檢查點（CheckPoint）
現(xiàn)代軟件開發(fā)的流程并不是軟件團隊在絕大部分時間里保持絕密狀態(tài)，然后某一天突然對領導和同事宣布——某某軟件成功了！把所有人都嚇了一跳。
我們要在軟件開發(fā)的過程中，經(jīng)常發(fā)布軟件，發(fā)布并不是指發(fā)布給最終用戶，而是在一個階段結束時，讓用戶 / 領導 / 同事看看進展，或者是讓我們內(nèi)部使用。
Stone項目中有下面幾個發(fā)布點、檢查點：
（1）6月底，內(nèi)部發(fā)布。對團隊內(nèi)部發(fā)布，主要目的是驗證發(fā)布流程，保證以后發(fā)布能自動進行。項目的大部分功能還沒有完成。
?。?）7月底，CTP（CommunityTechnical Preview，社區(qū)預覽版本）發(fā)布。對于特定用戶的一些基本功能已經(jīng)完成，發(fā)布的主要目的是聽取一些用戶對系統(tǒng)的意見。
?。?）8月底，Beta版本發(fā)布。這時候絕大部分功能都已經(jīng)完成，可以公開向外界宣布，允許不同背景的用戶登錄并收集反饋。
?。?）9月底，正式發(fā)布。正式把系統(tǒng)移交給運營單位（目前假設移山公司繼續(xù)運營這一網(wǎng)站）。
由上可見，在項目進展的各個階段，我們需要不同類型的發(fā)布，檢查進度，收集反饋，最終保證產(chǎn)品能順利完成。
13.5.2 如何決定各種功能的優(yōu)先級
大牛：Stone項目有這么多功能，每個功能還有子功能。每天每人還有新的想法，我們的電子郵件里有不少討論。到底哪個功能更重要？如何決定？我們以前的項目是開發(fā)人員想到什么功能，就做什么功能，隨意揮灑，也沒有考慮功能的完整性，相互依賴關系和重要性?，F(xiàn)在我們怎么辦？
阿超：這樣是比較亂，我們以前開會討論，達到共識了么？
二柱：當然開過會，不過會上我說這個功能“相當”重要，別人說那個功能“很”重要，另一個人說還有一個功能“特別”重要。還有人說，雖然重要，但是很難做；為啥不先做一些容易的功能呢？也有人說有些事情什么時候做都可以……最后誰也說服不了誰。
阿超：可以把不同任務的技術難度、重要性、緊迫度，以及其他參數(shù)列出來，用數(shù)字來表示不同等級，然后把各個因子的乘積加以比較。
我們可以考慮功能的“價值”、“技術可行性”和“緊迫性”，然后給它們定下級別及數(shù)值?？梢杂貌贿B續(xù)的數(shù)來表示價值的差別，例如1，5，9。
九條：1，5，9聽起來不美，不如1，4，7。
阿超：也可以，這個表就叫1-4-7表好了，如表13-2所示。
表13-2 1-4-7表
|
價值 |
技術可行性 |
緊迫性 |
|
|
1 |
可有可無 |
聽說過，沒見過（比如微軟最近宣布的WPF/E技術） |
也許用戶會感興趣 |
|
4 |
有點意思 |
見過，試驗過 |
有些用戶會喜歡 |
|
7 |
很重要 |
大路貨，很多人都能做 |
用戶哭著喊著要 |
對于諸多的想法，如果用1-4-7表來處理，結果就比較一目了然了，表13-3是一個例子：
表13-3 1-4-7表的實例
|
價值 |
技術可行性 |
緊迫性 |
乘積 |
|
|
想法1 |
1 |
7 |
1 |
7 |
|
想法2 |
4 |
4 |
1 |
16 |
|
想法3 |
7 |
7 |
7 |
343 |
|
想法4 |
7 |
1 |
1 |
7 |
|
想法5 |
1 |
4 |
7 |
28 |
|
想法6 |
7 |
4 |
4 |
112 |
|
想法7 |
1 |
4 |
7 |
28 |
|
想法7 |
4 |
4 |
4 |
64 |
從上表可以看出，對用戶有價值，技術上不難做的，用戶迫切需要的功能會從眾多候選想法中脫穎而出。
大牛和蕓蕓就組織了一次功能“海選”，大家暢所欲言，最后所有人都投了票，除了果凍。
果凍：我不高興，我覺得不能用數(shù)學來搞這些東西，我覺得給一個“4”，或者“7”沒有意義。我不參與。
蕓蕓：那咋辦？我只能等果凍回心轉意？
斯坦：果凍不高興，也許是因為他中意的功能得的分數(shù)不高吧。呵呵，民主聽起來是個好東西，但是真正實行，那感覺就不一樣了。
阿超：評比和投票的目的是為了交流意見，不是為了誰打敗誰。這個選舉沒有失敗者。我們要想辦法理解果凍的擔心，但是同時項目必須往前推動，不能停下來。
13.5.3更詳細的項目計劃
在開了幾次頭碰頭會議之后，頭兒們終于拿出了項目各個階段的比較詳細的計劃。
1．第0里程碑計劃階段
這一里程碑的主要目的是完成基本建設，進行核心部分的設計。其中，數(shù)據(jù)庫的schema設計包括：商品數(shù)據(jù)、商家數(shù)據(jù)、用戶數(shù)據(jù)、交易數(shù)據(jù)，以及用戶反饋信息數(shù)據(jù)（對產(chǎn)品的評價）和用戶售后服務數(shù)據(jù)（退貨，投訴）（如圖13-3所示）。
圖13-3第0里程碑
在這一里程碑中，這個里程碑為期1個月。結束條件是什么呢？是——
?。?）團隊項目服務器正常運轉，100%的員工能正常工作。
?。?）各項設計通過復審。
?。?）總的測試計劃和本階段的測試計劃通過復審。
?。?）系統(tǒng)的典型用戶通過初始復審。
2．第1里程碑（開發(fā)階段）
這一里程碑的主要目的是完成基本功能，達到內(nèi)部發(fā)布Alpha的要求（如圖13-4所示）。
時間為一個月，結束條件是：
?。?）商家能夠注冊，登錄。
?。?）商家能夠上傳產(chǎn)品信息。
?。?）商家能夠修改商品信息。
（4）用戶能夠注冊，登錄。
?。?）用戶可以瀏覽商品主頁。
圖13-4第1里程碑交付件計劃
3．第2里程碑（開發(fā)階段）
項目第2里程碑——進一步完善功能（分類、搜索、購物車、購物交易、用戶論壇、評估、售后服務、可擴展性），達到社區(qū)預覽發(fā)布的標準（如圖13-5所示）。
圖13-5第2里程碑交付件計劃
4．第3里程碑（開發(fā)階段）
在這一里程碑中，我們要實現(xiàn)剩余的主要功能：用戶論壇、評估、售后服務，開始效能測試以保證系統(tǒng)的可擴展性。在前幾個階段一直在進行的UI設計應該基本定型。給網(wǎng)站的所有功能提供統(tǒng)一的界面。
這個階段我們要進行CTP發(fā)布，并收集反饋。
大牛：為什么第3里程碑沒有更詳細的數(shù)據(jù)？
阿超：因為我們看不清未來，目前只能這樣了，寫太詳細了，有時候還不如不太詳細。因為過早的詳細計劃會給人一個印象，認為事情都搞定了，其實不然。
阿亨：但是我們需要詳細的數(shù)據(jù)來幫助測試團隊進行計劃。
大拴：我想起一個相聲，說是兩個視力不好的人爭論廟里新掛上的匾額的字寫得如何如何，連匾額的顏色和落款都描述了一番。兩人正爭執(zhí)不下時，一個和尚路過，說那匾額還沒有掛上去呢！
阿超：阿亨，別往心里去。不過大拴說的有道理，我們有時花時間爭論某些功能的細節(jié)，但是這個功能是否要實現(xiàn)還是一個很大的未知數(shù)。
阿杰：有了阿超這句話，看來我可以少寫不少文檔了。
5．第4里程碑（穩(wěn)定階段）
在這一里程碑中，我們要分析用戶的反饋，慎重考慮增加或者刪除功能，進行設計變更（DCR），完善效能和壓力測試。在里程碑的最后，發(fā)布Beta版本，收集用戶反饋。這時我們可以對用戶界面進行最后的修改，之后，這個時候的網(wǎng)站就很接近最后發(fā)布的網(wǎng)站了。
6．第5里程碑（發(fā)布階段）
修改缺陷，最后驗證所有功能，準備發(fā)布工作，10月1日正式發(fā)布。
同時，計劃下一個版本的工作。
二柱：阿超，我們真的會有下一個版本？
阿超：凡事預則立，不預則廢。我們不是要成為王屋河流域有影響的網(wǎng)站么？當然要經(jīng)過好幾個版本的努力。
鄂公網(wǎng)安備 42010302001612號