專案目標
:包含進度,成本
,質量三個方面的目標
.其中成本主要是人力資源的投入
.而質量目標一般應該是產品進入維護階段後的缺陷洩露情況
.專案進行過程需求
,設計和開發各階段相關工件需要達到的質量要求
.這三個要素是專案的主要目標
,相關還可能存在其它目標
.如你需要控制專案範圍的變化幅度
,你需要在專案過程中人員技能水平提高了怎樣乙個水平
,你對各過程定義的偏差限度等
.整個專案管理過程和階段的活動都是圍繞相關目標進行
,在有限的資源情況下按時按質的完成專案.
假設和約束
:假設和約束最大的區別就是乙個是確定的
,乙個是不確定的
.假設最重要的是要出乙個依據
,這個依據對專案計畫過程和專案目標的實現造成影響
,但根據專案現在已知因素又無法確定這個依據是否是一定成立的
.而約束則是這個依據一定是成立的
,專案必須遵循這個依據
.所以假設的例子有專案假設在進入設計開發階段後編碼人員能夠到位
,假設專案執行過程中範圍偏差不會超過
10%,
假設專案估算依據的歷史估算資料是真實可信的
.而約束我們考慮因素同樣是從專案幾個要素考慮
,從進度
,資源和質量等
.另外要考慮的就是技術約束
,如專案所使用的開發工具
,技術架構
,必須遵循的技術標準等
.如專案必須使用
**標準開發網頁以滿足不同瀏覽器瀏覽
,專案資源約束在
**人內
,專案必須在
**日發布版本等.
專案驗收標準
:太重要了
,這是專案收尾的乙個重要依據
,專案收尾時候的專案驗收必須通過專案驗收標準進行
,防止扯皮
.專案的的產出是產品
,服務和成果
.對於每項都必須定義明確的驗收準則和標準
.因此專案交付物必須是可以驗證的
,如果是乙個不可驗證的東西則不能稱為專案的交付物.
角色和職責
:這個一定要分清楚
,職責和職務一般只有乙個
,但其可以承擔多個角色的任務
.角色和職責間是乙個多對多的關係
.如評審員就是乙個虛擬的角色
,可能並沒有乙個專門這樣的職務
.但需求,設計
,開發或測試人員都可以擔任評審員.
專案自定義過程
:cmmi
**的乙個重要概念
,專案應該是依據組織級的標準過程來定義專案自己的過程
,組織級可以定義相關的裁剪標準
,專案依據裁剪標準對保證過程進行裁剪得到自定義的專案過程
.由於多過程或輸出控制項的控制問題,一般
cmmi
並不推薦採用敏捷或迭代的方**或生命週期模型
,現在有專門的
agile cmmi,
是研究的乙個重要話題.
里程碑和基線
:里程碑就是對上階段的工作進行總結和評審
,確認階段的交付物是否達到了要求和質量標準
,確認是否可以進入下乙個階段的工作
.里程碑的總歷時為零
.在里程碑達到並評審通過後
,可以對里程碑的所有交付物進行基線
,基線的物件是配置項
,基線的目的是保證工作產品的一致性
,基線的工作產品做為下乙個階段活動和任務的自己輸入和依據.
專案的方法,工具
,技術和標準
:這幾個因素都是重要的專案要素
,而對於敏捷方**或敏捷專案管理則更強調這些要素
.專案在資源和進度等都能夠滿足專案需求情況下仍然失敗很多時候的原因就是方法
,工具或技術的選擇上面出現問題.
估算:專案允許的工作量偏差或規模的偏差一般在
20-30%
左右，而進度偏差一般要求更嚴格，因此對於估算的準確度最好能夠在
80%以上，如果估算不準確將導致後續頻繁的調整進度計畫．專案管理或計畫是乙個漸近的過程，因此估算最好能夠做兩次，在軟體需求出來後再進行一次估算，估算較為準確的設計開發工作量．由於功能點估算一直存在的估算項無法和最終的活動和任務對應起來
,估算的資料功能的
eif和
ilf無法分解到事務功能上面的問題
,因此個人認為功能點估算更適合做專案總規模的乙個估算．根據總規模
/生產率得到乙個較為可信的專案週期資料．專家法和三點法估算是我們常用的估算方法，三點法可以通過
pert
計算出乙個最可能的估算值，同時得到乙個專案週期的估算範圍資料．
進度計畫
:再來談下順序問題，首先是確定清楚範圍，選擇專案的生命週期模型，然後進行頂層
wbs分解，對分解後的
wbs進行規模的估算，根據歷史的生產率資料推算出相關的工作量資料．根據
wbs確定出相關的活動和任務，對活動進行排序和建立依賴關係，確定專案的角色責任矩陣和資源分配準則並根據該準則對活動安排資源，繪製網路圖確定關鍵資源和關鍵路徑，排進度表並對資源進行平衡．
**專案管理者聯盟
在對任務分配資源的時候，優先保證關鍵資源分配到關鍵任務上面，同時當關鍵資源承擔多個任務的時候乙個普遍原則是： 設
a1,b1
是兩個關鍵任務，
a的後續依賴任務是
a2,b1
的後續依賴任務是b2，
a1可以比b1早
3天開始，
a2到結束關鍵路徑長為l1，
b2到結束關鍵路徑長為
l2. a.
當兩個從後續任務開始算起的關鍵路徑長差不多時，關鍵資源優先開始可以提前開始的任務。即優先開始
a1任務。 b.
當l1比l2
短3天以上時候，這個時候反而要優先開始
b1任務，雖然這個時候開始要閒置關鍵資源，這點很重要。
人員計畫：最主要是就是分階段的人員投入計畫．對於軟體開發專案一般在需求和總體設計階段僅僅需要投入
20-30%
的人員即可．因此人員計畫最好是分階段投入的計畫．投入人員必須規定相關的技能要求，規定了技能要求後需要對專案人員進行技能評估，如果專案成員的技能達不到要求，則還需要制定相關的培訓計畫，並對培訓效果進行跟蹤，並將該項列入專案的風險跟蹤和控制．
人員技能
:一般要求開發人員至少應該有
1-2年的工作經驗
,這應該是乙個基本的要求
.智商再高
,基礎理論再好沒有經過一段時間的實戰相關知識是不可能轉化為技能的
.但過了
1-2年這個階段
,工作經驗和技能就是非線性的關係了
,並不是說你工作經驗長你的技能水平就一定高
,這跟個人和環境等諸多因素相關
.工作了5年或
8年的可能技能水平一般
,而工作了
2年的可能技能就能夠達到專家水平
. training.mypm.net
風險計畫：風險管理是專案管理的乙個重要內容，風險管理的過程貫穿整個專案生命週期。風險管理計畫中首先要確定風險管理小組的成員和各自的職責，對於
pdm專案，風險小組負責人為專案經理
.風險小組確認後就要確定風險管理過程中需要使用的相關的工具和方法。其中包括風險識別的方法，風險分析的方法，風險監控的方法和風險應對的方法。這些方法和工具組織級都有明確的定義和指導原則，對於存在多種方法時要根據專案實際情況選擇。
對於專案的風險**和分類，組織級都有明確的標準和定義，專案一般都可以直接採用，但需要注意的是有可能需要專案實際情況對其進行裁剪。如專案本身不可能存在採購方面的風險時候，就需要將其裁剪到，這樣在後續的風險識別和分析中都不用再過多考慮。
專案計畫中的風險應對策略不是針對某個特定風險的，所以這裡的應對策略更多是通用的應對策略：如開發原型，技能評估和培訓，資料模擬等。當遇到實際的風險時候，如何去應對還要根據風險的實際情況進行分析。
training.mypm.net
專案管理者聯盟
專案計畫階段就應該分析出專案在當前狀況下的所有風險，並對風險進行優先順序排序，當確認了是專案的關鍵風險後，需要制定這些風險的減輕計畫和應對措施，這些內容都需要體現到進度計畫中，進度計畫必須包含這些內容才是乙份完整的進度計畫。
在當我們積累了足夠多的歷史資料後可以對風險進行組合分析和量化分析，對於風險量化分析可以採用決策樹和蒙特卡洛模擬等方法進行。具體的方法可以參考以下文件
質量計畫
:專案計畫中要做的質量計畫和
qa要出的質量保證計畫完全是不同的．
qa的質量保證計畫關注點在過程和工件的一些審核上面，保證專案遵循計畫和過程執行．專案計畫中的質量計畫更多傾向去產品的質量和要達到產品質量需要採取的控制措施．質量目標中**與使用者對質量的要求，**於專案至少質量改進需求，**於歷史專案的相關經驗，因此首先應該制定出相關的質量目標，然後根據質量目標去估計專案的缺陷趨勢和各階段缺陷數，為了達到質量目標所需要投入的評審，測試和
review
等相關的工作量．對評審和測試的覆蓋率的要求，有這些資料後就可以估算出專案的質量成本
coq,copq
和cogq.
專案管理計畫的內容
專案管理計畫要記錄計畫的假設以及方案選擇，要便於各干係人間的溝通，同時還要確定關鍵的管理審查的內容，範圍和時間，並為進度評測和專案控制 提供乙個基準。計畫應該具有一定的動態性和靈活性，隨著環境和專案本身的 變更而進行適當的調整。計畫應該能夠有利於專案經理管理專案團隊和評估專案 的進展狀況。整合專案資...
系統程式設計師成長計畫 記憶體管理 三
作者 李先靜 記憶體管理器 在前面學習共享記憶體的時候，我們重新實現了迴圈佇列，兩個實現的不同之處只是在於記憶體分配和釋放上。對比一下 fifo ring create的實現 第一種實現用malloc分配記憶體。fiforing fifo ring create size t length retu...
系統程式設計師成長計畫 記憶體管理 三
作者 李先靜 記憶體管理器 在前面學習共享記憶體的時候，我們重新實現了迴圈佇列，兩個實現的不同之處只是在於記憶體分配和釋放上。對比一下 fifo ring create的實現 第一種實現用malloc分配記憶體。fiforing fifo ring create size t length retu...