【轉載】
最佳實踐:不要盲目的將最佳實踐作為必須遵守的戒律，但可以作為生成自己最佳方法的起點。
1.正式的風險管理
2.對接口達成一致的意見。包括硬件接口，軟件接口已經(jīng)你的系統(tǒng)同外部系統(tǒng)之間的接
3.同行評審。包括檢查，走查，評審等等。雖然這些概念眾所周知，但團隊由于這些活動將減慢項目的速度，因此它們在死亡之旅項目中常常被忽略。雖然大多數(shù)人在理智上都同意同行評審非常有用，但在死亡之旅項目的那種沉重壓力下，每個人都會考慮盡快的完成自己的工作，而壓根想不起需要其它團隊成員來評審自己的工作產(chǎn)品。
4.基于度量的進度和管理。這就是我們應該依據(jù)以往項目的度量結果來安排進度和進行估算。但當我們沒有出現(xiàn)死亡之旅項目的時候，很少有人去注意和記錄這些有用的度量歷史數(shù)據(jù)。沒有這些歷史數(shù)據(jù)的記錄，我們就很難在新的項目中做出準確和客觀的估算。
5.多設置短周期的檢查點和里程碑。與其每隔兩三個月設置一個里程碑，還不如按星期或天來設置短期的里程碑或檢查點。迭代開發(fā)或Daily Build可以幫助我們達到此目的。
6.項目計劃和項目的實際進度在整個項目范圍內保持透明。
7.針對質量目標進行錯誤跟蹤。這種觀點重點在于盡早的在開發(fā)過程中發(fā)現(xiàn)，跟蹤和記錄問題。不僅能夠預測最終系統(tǒng)的缺陷水平，還可以用最小的花費來解決問題，而不用一直等到項目的系統(tǒng)測試階段。
8.配置管理。不管是被稱為版本控制或源代碼管理，配置管理在大多數(shù)壓力巨大的項目中都是必須的。
9.以人為本。必須要對項目和團隊成員給予足夠的重視。
最差實踐:相對最佳實踐而言，往往慘痛的教訓更讓我們記憶猶新。避免災難往往比追求完美更加重要
1.如果采用相似項目的統(tǒng)計結果來作為比較標準，不要期望進度的壓縮程度大于10%。
2.不要為了壓縮進度而接受新技術。(新技術引入的學習成本和使用風險往往大于其對生產(chǎn)率提高所做的貢獻)
3.不要強迫大家在項目中使用那些與具體用戶相關的解決方案。
4.不要鼓吹萬能方法。(在管理層建議采用某中新工具或方法來拯救項目時必須注意)
5.項目的關鍵路徑上存在著依賴于外部因素決定的活動
6.參與項目評審的一大堆人在評審開始前都不做任何相關的準備(因此也不要期望有很好的評審效果)
7.如果軟件功能的縮減量小于10%，就不要期望能從超過10%的進度滯后中恢復過來。
【?發(fā)表評論?0條?】