我們假設一個project中有以下狀況：
（1）需求不明確，沒有完整、詳細的需求描述。用戶沒有提供標準的需求文檔。
（2）技術架構明確要求爲J2EE，要求使用：Struts,Tile,EJB,DAO,OJB，數據庫爲Oracle 8i/9i，集成開發工具要求爲WSAD，系統有大量的計算，對性能有明確要求。
（3）團隊人數爲6人，三人爲剛大學畢業的新人，對上述技術架構和開發工具不熟悉。另外3人均不能full time參與。其中項目SA只能參與第一週（5天）。
（4）交付時間特別急，要求3周就必須完成。但是交付物只需要：SRS（軟件需求描述）、源代碼/安裝包、安裝文檔，不需要概要設計、詳細設計等文檔。
（5）項目規模不大，業務需求約爲12個左右，其中有5個非常簡單的需求（增加、刪除、修改，沒有特別的計算）
基於上述狀況，不能根據大概判斷就直接拒絕，首先進行了風險識別（實際的Risk Management Plan就不show了）：
（1）項目範圍不明確，特別是不明確最終用戶的需求。
（2）沒有確立變更機制，沒有SOW（Statement of Work）
（3）沒有明確的驗收條件
（4）沒有合適的標準軟件過程、開發模式、生命週期適合本項目
（5）對於上述的技術架構沒有經過驗證和測試，特別是OJB。
（6）項目組對於上述技術（J2EE）要求沒有足夠的開發經驗，有經驗的SA時間不能保證。
（7）項目組對於客戶指定的WSAD不熟悉
（8）測試服務器的性能可能不能滿足測試要求
（9）關鍵資源（SA和另外2位）不能確認能夠參與的時間
（10）Team爲全新，之前都沒有互相進行團隊並行開發
識別風險後對每一個制定了應對計劃。
做到這裏，已經可以跟Manager彙報說不可能了...
然後基於項目需求分解WBS(Work BreakDown Structure),找來SA進行歷時估算，對每一個UseCase估算其開發時間，當然按照有相關開發經驗的人員來估算的。得到了總共Effort以及Price。
根據最終的交付時間回溯列出了一個Schedule，設置多個重要的Milestone。
回來來Review自己做的Project Plan，仔細看看Schedule，可能嗎？別忘了，我們還不能週六週日加班，－_－。
不管如何，這是個混亂的項目，進度、資源、風險，各個方面都有大的問題，抱怨是解決不了問題的，還是腳踏實地做下去吧。
回過頭來，該做的事情還得繼續做下去：
第一步，控制需求（Scope）。客戶不是沒有需求描述嗎？我們自己根據其提供的需求原始文檔編寫，同時做出需求的UI原型，我們不確定的地方都做爲Assumption。提交給用戶審覈，不必要的功能通過談判砍掉：時間這麼短，架構、性能要求高，怎麼可能做出那麼多需求來？很快需求控制住了，我們實現的功能很明確。
心得：這個項目能夠控制住需求的原因有二：（1）採用需求原型開發，根據自己對需求的理解快速把UI整理出來。（2）仔細的編寫SRS，把一些假設（Assumption）明確的寫進去，避免後續的問題。
現在該回到主題：XP（極限編程）了。
（1）No Plan, then plan every day. 現在說自己寫了一個項目計劃，但是3周時間，這麼短如何跟蹤？所以每週制定一個Activities List，每天計劃，每天跟蹤！任務分配到個人並定義相關接口人員。
心得：（a）天天分配新任務並跟蹤的做法對於Team members來說工作強度太大，壓力也太大，不適合長時間項目使用。一般我會事先說好採用的時間段。在長時間項目中只在關鍵階段採用該方法。
（b）天天計劃要求PM對工作任務和技術方面非常熟悉，否則就是瞎指揮！危害很大，Team members背後可能都把你罵死了，你還自以爲自己安排得非常好。因此首先需要徵詢SA或者Senior Enginneers的意見，在計劃和分配時也需要得到相關members的同意。不要直接命令下去。
（c）理性對待Delay，過程中有2天的Delay，不要試圖加班等初級手段趕上去，一般來說，趕只會越趕越慢。想想看有沒有其它的解決之道。
（2）Continous integration：採用Smoke Testing的方法. 也就是冒煙測試，保證從項目初期到最後交付都有一個可運行的版本。指定一個配置管理員，負責每天將最新版本部署在測試服務器上，保證可以編譯並運行。
心得：由於配置管理skills方面的原因，初期並未能run起來，之後才能得以跑起來。
（3）Simple Design：其實我想做詳細設計也沒門，因爲SA只有一週的時間參與，怎麼做？做一個例子，數據庫上建一個table：product，然後從前臺JSP,Tile ->Struts->EJB->OJB->DB能夠跑通，可以在頁面上add，delete，update。嗯，中間漏了DAO，可以以後加嘛。這個例子做好之後做爲例子供其它Team member學習和熟悉。
心得：迫不得已的做法，但是的確有好的效果，在SA做這個例子的期間，其它人緊張的進行環境準備和技術準備，大家得以熟悉開發工具和開發環境以及必須的技能。有一個現實的例子，普通程序員開發起來心裏更有底一些，自己設計會有問題，難道照着做還不會嗎？
（4）Pair programming，當然有些變通，Pair programming的意思是兩個程序員在一臺機器上來開發代碼。我的做法是將前臺部分的功能（從Jsp，Tile，struts到EJB）根據不同特別分配給3位Entry SE（入門級軟件工程師）。這部分工作量很大，大家的缺陷都非常多，但是通過互相檢查和共享，效果很不錯。進展快得人可以更快將功能集成進系統。
心得：如果採用水平分配任務，可能有的人能夠做得好能夠提前進度，但是任何一人出了問題，那麼整個系統就沒有一個功能可以run，同時在接口上的溝通成本會非常大。
（5）40-hours work, 在項目初期就先說好，前兩週開發時間不要求加班，在最後一週集成測試時纔要求晚上部分加班。
心得：象這類風險大的項目，如果全靠加班才能做好，那麼肯定是初期有大問題。還是那句話：進度不是趕出來的，進度是plan出來的。
沒有完全採用CMMi的一套Process，而是採用了XP的部分Best Practice，最終項目按時、按質提交，似乎完成了不可能完成的任務，但是當SQA來Audit的時候，報表很難看。所以採用這種方法有以下缺陷：
（1）知識保存：所有的項目管理經驗都在PM腦子裏，設計理念在SA裏，好的實現都在開發人員的腦子裏和代碼行間。項目結束後，不少項目組成員都到了其它項目組，後續項目（該項目有後續大的單子）得不到之前繼承的知識。
只剩下了結果。
（2）Tracking：只有PM瞭解項目的真實情況，其它人都無法知道，SQA也沒法檢查（XP裏面是沒有SQA的）。
由於一直是在CMMi下面Lead項目，因此部分工作還是採用CMMi的Process，比如配置管理（CM），需求管理（Requirement Management），PMR（Project Management Review），Risk Mangement， Issue Management，DefectTracking等等。
