昨晚看完《人月神話》一書，結(jié)合我所做項(xiàng)目經(jīng)歷，對我感觸最深詞語有：人月、里程碑、文檔管理。
人月
在書本提到：
認(rèn)為用人月作為衡量一項(xiàng)工作的規(guī)模是一個(gè)危險(xiǎn)和帶有欺騙的神話。他暗示著人員數(shù)量和時(shí)間是可以相互替換的。
在帶項(xiàng)目確實(shí)犯過使用人員數(shù)量和時(shí)間相互替換的錯(cuò)誤。當(dāng)項(xiàng)目緊張時(shí)，考慮過加人手問題，如果只受到編碼進(jìn)度因素影響，這樣確實(shí)能解決問題。但實(shí)際上，不僅受到編碼進(jìn)度，還會(huì)受到分析設(shè)計(jì)、人員培訓(xùn)、人員溝通時(shí)間、資源配合、外圍接口等等影響。這些都是相互影響，影響的結(jié)果是非線性。請記住Brooks法則：
向進(jìn)度落后的項(xiàng)目中增加人手，只會(huì)使進(jìn)度更加落后。（Adding manpower to a late software project makes it later）
當(dāng)項(xiàng)目進(jìn)度已落后比較好的做法是：
分析當(dāng)前項(xiàng)目落后的原因，主要內(nèi)部因素還是外部因素引起。
如果是外部因素引起無須增加人手，還可以考慮減掉人手，以免消耗更多人月。
如果是內(nèi)部因素再分析是人員工作問題還是錯(cuò)誤估算時(shí)間的問題，項(xiàng)目落后往往是錯(cuò)誤估算時(shí)間的問題。
當(dāng)項(xiàng)目進(jìn)度已落后，切忌增加人手。
里程碑
曾參與過項(xiàng)目都比較遵守軟件項(xiàng)目流程，但項(xiàng)目計(jì)劃的里程碑不夠明確。主要害怕承擔(dān)責(zé)任。項(xiàng)目經(jīng)理負(fù)責(zé)做項(xiàng)目計(jì)劃，但不應(yīng)該他承擔(dān)所有責(zé)任，責(zé)任需要共同承擔(dān)，項(xiàng)目計(jì)劃用于督促雙方是否遵守計(jì)劃完成任務(wù)。
里程碑必須是具體的、特定的、可度量的事件。
在需求分析、設(shè)計(jì)階段的里程碑，主要交付產(chǎn)物是需求分析書、系統(tǒng)概要設(shè)計(jì)文檔和數(shù)據(jù)庫設(shè)計(jì)文檔。交付產(chǎn)物都需要雙方評審?fù)ㄟ^才能達(dá)到里程碑要求。
在編碼階段的里程碑的交付產(chǎn)物是比較難的定義，要每個(gè)程序員評定各自負(fù)責(zé)功能實(shí)現(xiàn)程度是比較主觀。在這個(gè)階段可以采用是兩兩監(jiān)督方式，比如A同事所實(shí)現(xiàn)功能，需要B同事來檢查實(shí)現(xiàn)功能進(jìn)度，如果功能實(shí)現(xiàn)進(jìn)度是100%，需要雙方簽字確認(rèn)。同時(shí)，A也監(jiān)督B的所實(shí)現(xiàn)功能進(jìn)度。如有問題需求追究雙方責(zé)任，這樣可以避免實(shí)現(xiàn)功能與需求說明書不一致問題。
說明在每個(gè)階段定義明確里程碑，方便以后檢查進(jìn)度和以及知道進(jìn)度落后的原因。
管理文檔
經(jīng)歷幾個(gè)項(xiàng)目組后，發(fā)現(xiàn)都不注意管理文檔。大部分開發(fā)人員都認(rèn)為理解需求就好，不注意更新文檔。這樣會(huì)影響后續(xù)開發(fā)和維護(hù)工作。
最常見的問題是：容易出現(xiàn)新同事不熟悉已離職同事負(fù)責(zé)的模塊功能。這情況下，只好咨詢老同事怎么實(shí)現(xiàn)，如老同事知道該功能業(yè)務(wù)流程還好，雖然還會(huì)造成一定溝通成本提升。但老同事不知道該功能業(yè)務(wù)流程時(shí)，就需要老同事和新同事一起熟悉該功能，至少耗費(fèi)兩個(gè)人工作時(shí)間去了解該功能，這是就能體現(xiàn)需求文檔和設(shè)計(jì)文檔的重要性。
還有一個(gè)比較常見問題是：需求變更記錄文檔。需求變更影響到項(xiàng)目開發(fā)、項(xiàng)目測試、項(xiàng)目驗(yàn)收。如果需求變更沒有及時(shí)通知上面所說某一環(huán)節(jié)，都會(huì)影響到整個(gè)項(xiàng)目進(jìn)度。
在項(xiàng)目處于各個(gè)階段都需要嚴(yán)格管理文檔版本，保持版本庫的文檔是最新的。
