為保證事情或工作高起點、高質(zhì)量、高水平開展，常常需要提前準備一份具體、詳細、針對性強的方案，方案是書面計劃，是具體行動實施辦法細則，步驟等。那么方案應該怎么制定才合適呢？以下就是小編給大家講解介紹的相關方案了，希望能夠幫助到大家。
軟件開發(fā)的實施方案篇一
系統(tǒng)開發(fā)嚴格按照軟件工程的方法進行組織，系統(tǒng)的開發(fā)過程按
照需求分析、系統(tǒng)分析與設計要求、系統(tǒng)編碼、系統(tǒng)測試幾個過程有 序推進。下表所示系統(tǒng)開發(fā)流程圖，采用原型及迭代方式開發(fā)，根據(jù) 用戶需求持續(xù)改進，直到最終用戶確認滿意。
1.1 開發(fā)流程總述
如下圖示流程定義了我公司內(nèi)部的軟件開發(fā)過程，以指導和規(guī)范軟件項目中開發(fā)過程的定義和相應的實施。
該過程可劃分為一系列子過程，包括：軟件需求分析、設計、編
碼、測試、驗收、維護，每個子過程又由一系列任務和活動組成，如 設計過程又可分為結構設計和詳細設計。但是在實際開發(fā)項目中，情 況仍然會是千變?nèi)f化的，因此我們也并不是一成不變的死板執(zhí)行一個 僵化的工作流程，我們的原則是在一個規(guī)范流程的指導和約束下，根 據(jù)具體工程項目的實際要求，為每一個項目評估并制定真正能夠最好 的滿足該項目要求的開發(fā)流程。
開始
軟件需求分析
y
n：改進
y
n：改進
y
n：改進
《軟件需求規(guī)格說明書》（初稿）
《系統(tǒng)測試計劃》《系統(tǒng)測試案例》
（初稿）
《用戶手冊》（概要）《追溯表一》
《軟件需求規(guī)格說明書》
《系統(tǒng)測試計劃》《系統(tǒng)測試案例》
《個人評審記錄》
《評審報告》
同行評審
通過
結構設計
評審通過
《結構設計說明書》（初稿）
《集成測試計劃》《集成測試案例》
（初稿）
《用戶手冊》（初稿）《追溯表一》
《結構設計說明書》
《集成測試計劃》《集成測試案例》
《個人評審記錄》 《評審報告》
《詳細設計說明書》（初稿）
《單元測試計劃》《單元測試案例》
（初稿）
《用戶手冊》（修改稿）《追溯表一》
《詳細設計說明書》
《單元測試計劃》《單元測試案例》
《用戶手冊》（修改稿）
《個人評審記錄》
《評審報告》
源代碼、源代碼文件清單
《單元測試報告》（經(jīng)過審批）
《軟件問題狀態(tài)登記表》 《軟件問題報告單》
《集成工作單》
《集成測試工作單》
《集成測試報告》（經(jīng)過審批）
《軟件問題狀態(tài)登記表》
《軟件問題報告單》 集成的軟件系統(tǒng)
《系統(tǒng)測試報告》（經(jīng)過審批）
《軟件問題狀態(tài)登記表》
《軟件問題報告單》
《系統(tǒng)管理員使用說明書》(經(jīng)過審批)
《安裝手冊》（經(jīng)過審批）
《用戶手冊》（經(jīng)過審批 軟件系統(tǒng)（系統(tǒng)測試通過）
驗收測試報告
《軟件問題報告單》
《軟件問題狀態(tài)登記表》
驗收報告 可交付產(chǎn)品
《軟件需求規(guī)格說明書》（升級版）
《客戶需求登記表》
《客戶需求統(tǒng)計表》
《設計說明書》（升級版）
《軟件問題報告單》
《軟件問題狀態(tài)登記表》
《軟件維護實施計劃》 維護后的軟件系統(tǒng)
詳細設計
評審通過
編碼
集成測試
系統(tǒng)測試
驗收
維護
結束
圖 1.1-1 軟件開發(fā)流程總圖
在應用系統(tǒng)軟件開發(fā)項目中，我們?nèi)詫⒆裱@一思想，這一點將在隨后的項目開發(fā)實施計劃部分有具體的體現(xiàn)，在這里和下面的相關章節(jié)中，我們?nèi)詫@著這個完整的開發(fā)流程來分析說明，以此來闡明我們對項目開發(fā)的完整過程管理思想和相關實踐。下面我們對這個軟件開發(fā)工作流程進行簡要地分解說明。
1.2 軟件需求分析
（1）概述
由于應用系統(tǒng)與眾多相關應用軟件需要進行交互，因此需要先對這些應用系統(tǒng)進行分別梳理，充分做好需求調(diào)研工作，編寫經(jīng)項目單位認可并評審通過的《系統(tǒng)需求規(guī)格說明書》。
軟件需求分析是按照項目定義的軟件開發(fā)過程，根據(jù)系統(tǒng)分配給軟件的需求（見 《系統(tǒng)需求規(guī)格說明書》），進行軟件質(zhì)量特性規(guī)格說明的過程。該過程包括進一步明確軟件運行環(huán)境，明確對軟件的功能、性能和數(shù)據(jù)要求，以及軟件與硬件、軟件與軟件之間的接口要求等，并對軟件需求進行驗證和文檔化，即完成對軟件需求的分析與規(guī)格定義。
本元素在整個過程中的位置如下圖所示：
系統(tǒng)分配給軟
件的需求
軟件需求分析 結構設計
圖示：軟件需求分析在軟件開發(fā)過程中的位置
（2）入口準則和出口準則
1）入口準則
要素
判斷準則
客戶需求（《系統(tǒng)需求規(guī)格
已由 ccb批準為基線
說明書》）
已進入配置庫
2）出口準則
要素
判斷準則
已經(jīng)過審查
軟件需求規(guī)格說明書
已批準為基線
已進入配置庫
系統(tǒng)測試計劃
已經(jīng)過審查
已獲得批準
系統(tǒng)測試案例
已進入配置庫
用戶手冊（概要）追溯表一
已編寫
已填寫
（3）評審
評審《軟件需求規(guī)格說明書》，具體評審過程見《評審程序文件》，對軟件需求的評審準則包括：
● 系統(tǒng)需求和系統(tǒng)設計的可追溯性；
● 與系統(tǒng)需求的一致性；
● 內(nèi)部一致性；
● 可測試性；
● 軟件設計的可行性；
● 運作和維護的可行性。
對軟件需求中的問題，與系統(tǒng)工程組或客戶一起確定和審查，根據(jù)審查結果對軟件需求進行適當?shù)男薷模匾獣r按基線變更控制的要求對客戶需求進行相應的修改。對軟件需求規(guī)格說明書進行同行評審。
審查、批準軟件需求規(guī)格說明書。
將軟件需求規(guī)格說明書置于配置管理之下。
（4）工作產(chǎn)品
● 《軟件需求規(guī)格說明書》 ● 《系統(tǒng)測試計劃》 ● 《系統(tǒng)測試案例》 ● 《用戶手冊》 ● 《追溯表》（5）職責
● 項目經(jīng)理：負責組建軟件需求分析組；確定是否需要對有關
人員進行培訓；負責軟件需求規(guī)格說明書的審查和批準。
● 軟件需求分析組：軟件需求分析的主要承擔者，負責完成本
過程元素要求產(chǎn)生的所有工作產(chǎn)品。
● 系統(tǒng)測試負責人：負責組織軟件系統(tǒng)測試組對軟件需求進行
分析，審查軟件需求的可測試性；參與軟件需求規(guī)格說明書的審查和批準。
● 質(zhì)量保證人員：參與工作產(chǎn)品的審查，統(tǒng)計缺陷，并對軟件
需求分析過程進行審計。
● 系統(tǒng)開發(fā)組：配合處理涉及客戶需求的軟件需求問題?！?客戶：必要時參與軟件需求規(guī)格說明書的審查和批準。
1.3 結構設計
（1）概述
結構設計是指按照《軟件需求規(guī)格說明書》，設計軟件系統(tǒng)的體系結構，即模塊結構，定義每個模塊的主要功能和模塊之間的聯(lián)系（即接口），并確定軟件系統(tǒng)的數(shù)據(jù)體系結構。
本元素在整個過程中的位置如下圖所示：
軟件需求分析
結構設計 詳細設計
圖示：軟件需求分析在軟件開發(fā)過程中的位置圖
（2）入口準則和出口準則
1）入口準則
要素
判斷準則
軟件需求規(guī)格說明書 經(jīng)過審查
審查獲得批準
進入配置庫
2）出口準則
要素
結構設計說明書 集成測試計劃 集成測試案例 用戶手冊（初稿）
判斷準則
經(jīng)過審查
審查獲得批準
進入配置庫
已完善
追溯表一
（3）評審
● 對《結構設計說明書》和《集成測試計劃》進行同行評審。
● 對結構設計中的問題，與軟件需求分析人員一起確定和審查，并對結構設計進行適當?shù)母摹?/p>
● 審查、批準《結構設計說明書》，必要時，對其進行設計評審。● 將《結構設計說明書》、《集成測試計劃》 和《集成測試案例》
置于配置管理之下。
（4）工作產(chǎn)品
● 《結構設計說明書》 ● 《集成測試計劃》 ● 《集成測試案例》 ● 《用戶手冊》 ● 《追溯表》（5）職責
1）項目經(jīng)理
負責選擇合適的設計人員，組建結構設計工作組；負責《結構設
計說明書》和《集成測試計劃》的審查和批準。
2）結構設計人員
結構設計階段工作的主要承擔者，負責完成本過程元素產(chǎn)生的所
有工作產(chǎn)品。
3）系統(tǒng)分析員
配合處理涉及軟件需求的問題。
4）系統(tǒng)開發(fā)負責人
負責組織系統(tǒng)工程組對結構設計進行分析，審查結構設計的可測
試性；負責協(xié)調(diào)處理涉及軟件需求的問題；參與《結構設計說明書》
和《集成測試計劃》的審查和批準。
5）軟件測試負責人
負責組織軟件測試組對結構設計進行分析，審查結構設計的可測
試性；參與《結構設計說明書》和《集成測試計劃》的審查和批準。
1.4 詳細設計
（1）概述
詳細設計是根據(jù) 《結構設計說明書》進行模塊設計，將結構設計所獲得的模塊按照單元、程序、規(guī)程的順序逐步細化。詳細定義各個單元的數(shù)據(jù)結構、程序的實現(xiàn)算法以及程序、單元、模塊之間的接口等，作為以后編碼工作的依據(jù)。
本元素在整個過程中的位置如下圖所示：
結構設計
詳細設計 編碼
圖示：詳細設計在軟件開發(fā)過程中的位置
（2）入口準則和出口準則
1）入口準則
要素
判斷準則 經(jīng)過審查 審查獲得批準
結構設計說明書
進入配置庫
2）出口準則
要素 判斷準則
要素
判斷準則 經(jīng)過審查 審查獲得批準
詳細設計說明書
進入配置庫
（3）評審
對《詳細設計說明書》和《單元測試計劃》可進行走查或（和）
同行評審；
對詳細設計中的問題，與結構設計人員一起確定和審查，并對詳細設計做出適當?shù)母模?/p>
審查、批準《詳細設計說明書》，必要時，對其進行設計評審；將《詳細設計說明書》和《單元測試計劃》置于配置管理之下。
（4）工作產(chǎn)品
● 《詳細設計說明書》 ● 《單元測試計劃》 ● 《單元測試案例》 ● 《用戶手冊》 ● 《追溯表》（5）職責
1）項目經(jīng)理
負責選擇合適的設計人員，組建詳細設計組；負責《詳細設計說
明書》和《單元測試計劃》的審查和批準。
2）詳細設計人員
詳細設計階段工作的主要承擔者。負責完成本過程元素產(chǎn)生的所
有工作產(chǎn)品。
3）系統(tǒng)分析員
配合處理涉及軟件需求的問題。
4）系統(tǒng)開發(fā)負責人
負責組織系統(tǒng)工程組對詳細設計進行分析，審查詳細設計的可測
試性；負責協(xié)調(diào)處理涉及軟件需求的問題；參與《詳細設計說明書》
和《單元測試計劃》的審查和批準。
5）軟件測試負責人
負責組織軟件測試組對詳細設計進行分析，審查詳細設計的可測
試性；參與《詳細設計說明書》和《單元測試計劃》的審查和批準。
1.5 編碼
（1）概述
編碼階段主要完成的工作是根據(jù)詳細設計說明書編寫程序源代
碼，包括必要的數(shù)據(jù)文件，并進行單元測試，單元測試的內(nèi)容包括模
塊內(nèi)程序的邏輯、功能、參數(shù)傳遞、變量引用、出錯處理等方面。
本元素在整個過程中的位置如下圖所示：
詳細設計
編碼 集成測試
圖示：編碼階段在軟件開發(fā)過程中的位置
（2）入口準則和出口準則
1）入口準則
要素
判斷準則
詳細設計說明書
經(jīng)過審查
單元測試計劃 獲得批準
進入配置庫
2）出口準則
要素
判斷準則
源代碼文件
源代碼文件獲得批準
源代碼文件清單
源代碼文件進入配置庫的源代碼區(qū)
單元測試報告
提交測試負責人
軟件問題報告單
提交問題管理渠道
（3）評審
對源代碼文件進行同行評審，主要的方法為對照詳細設計說明書對代碼進行查閱，也可根據(jù)編程者的經(jīng)驗或程序的難度、重要程度，選擇走查評審方式，但目的都是發(fā)現(xiàn)程序存在的問題。
（4）工作產(chǎn)品
● 源代碼文件 ● 《單元測試報告》 ● 《軟件問題報告單》 ● 《軟件問題狀態(tài)登記表》（5）職責
1）項目經(jīng)理
建立編碼組、測試組或相應崗位，并進行必要的培訓；跟蹤進度
和問題解決狀態(tài)； 對提交的源代碼進行批準（或指定負責人進行批準
工作）。
2）程序員
編寫程序代碼；測試程序代碼；修改程序代碼；提交工作產(chǎn)品，批準后將其導入配置區(qū)的源碼庫。
3）單元測試人員
測試源代碼；提交測試報告和軟件問題報告單。
4）評審人員
對指定源代碼文件進行閱讀，發(fā)現(xiàn)缺陷和問題，填寫評審報告。
1.6 模塊集成測試
（1）概述
集成測試階段主要完成的工作是集成和集成測試。集成是參考結構設計說明書并根據(jù)詳細說明書中規(guī)定的系統(tǒng)集成方案將不同的經(jīng)
測試的程序單元進行構造，并逐步構造成一個完整的軟件產(chǎn)品的過程；集成測試則是在集成完成之后，對各單元、模塊之間接口的正確性和集成后功能的正確性進行驗證。
對于大型軟件，集成測試可以采取分步進行的方法，可以先對各子系統(tǒng)進行集成測試，然后在子系統(tǒng)之間進行集成測試。
本元素在整個過程中的位置如下圖所示：
編碼
集成測試 系統(tǒng)測試
圖示：集成測試在軟件開發(fā)過程中的位置
（2）入口準則和出口準則
1）入口準則
要素
判斷準則 經(jīng)過審查 獲得批準 進入配置庫
結構設計說明書
詳細設計說明書
集成測試計劃
源代碼文件
2）出口準則
要素
判斷準則 獲得批準 進入配置庫
提交集成測試負責人 已進入軟件問題管理流程
集成的軟件系統(tǒng)
（完整的源代碼和目標代碼）
集成測試報告
軟件問題報告單
（3）審查階段
核查集成狀態(tài)和結果，并進行批準；
批準后，將目標程序和程序清單進入目標代碼庫。
（4）工作產(chǎn)品
● 集成后的系統(tǒng)目標代碼（包括文件清單），及相應的源代碼
（包括文件清單）● 集成測試報告 ● 《軟件問題報告單》 ● 《軟件問題狀態(tài)登記表》 ● 《集成工作單》 ● 《集成測試工作單》（5）職責
● 項目經(jīng)理：建立集成組、集成測試組或相應崗位，并進行必
要的培訓；跟蹤進度和問題解決狀態(tài)；對集成后的系統(tǒng)目標
碼進行批準（或指定負責人進行批準工作）。
● 集成負責人員：負責集成過程的實施。
● 集成人員：負責環(huán)境構建，集成的過程操作，并將集成后的目標代碼提交批準。
● 程序員、設計人員：修改源碼或設計，解決集成過程中出現(xiàn)的與源碼有關的問題。
● 測試人員：測試系統(tǒng)目標碼，將測試報告和軟件問題報告單
提交測試負責人。
1.7 系統(tǒng)測試
（1）概述
系統(tǒng)測試的主要任務是從系統(tǒng)需求的角度對系統(tǒng)運行的正確性和性能進行驗證。系統(tǒng)測試的依據(jù)為系統(tǒng)測試計劃。
本元素在整個過程中的位置如下圖所示：
集成測試
系統(tǒng)測試 驗收
圖示：系統(tǒng)測試在軟件開發(fā)過程中的位置
（2）入口準則和出口準則
1）入口準則
要素
判斷準則 經(jīng)過審查
系統(tǒng)需求
要素
判斷準則 獲得批準 進入配置庫 編寫完成系統(tǒng)的目標代碼
系統(tǒng)測試計劃
用戶手冊
2）出口準則
要素
判斷準則 獲得批準
系統(tǒng)測試報告
軟件問題報告單
（3）工作產(chǎn)品
● 《系統(tǒng)測試報告》 ● 《軟件問題報告單》 ● 《軟件問題狀態(tài)登記表》（4）職責
● 項目經(jīng)理：負責建立系統(tǒng)測試組或相關的崗位，并進行必要的培訓；跟蹤進度和問題解決狀態(tài)；對最終的目標代碼進行
批準（或指定負責人進行批準工作）。
● 程序員、設計人員：修改源碼或設計，解決集成過程中出現(xiàn)的與源碼有關的問題。
● 測試人員：測試系統(tǒng)目標碼，將測試報告提交測試負責人，將軟件問題報告單提交問題管理渠道。
1.8 驗收
（1）概述
驗收階段主要由驗收測試、驗收測試問題改正和驗收三部分組成：
驗收測試的主要目的是驗證所開發(fā)的系統(tǒng)在用戶的使用環(huán)境下
（或模擬的使用環(huán)境下）是否滿足系統(tǒng)需求，從用戶的角度驗證整個
系統(tǒng)運行的正確性。
驗收測試問題改正是對驗收測試中發(fā)現(xiàn)的差異性問題進行修改。
驗收則是在驗收測試的基礎上，依據(jù)項目合同或項目任務書對項
目的完成情況進行綜合評價。
本元素在整個過程中的位置如下圖所示：
系統(tǒng)測試
驗收 維護
圖示：驗收在軟件開發(fā)過程中的位置
驗收的三個組成部分視項目立項類型和客戶的要求選擇執(zhí)行。
（2）入口準則和出口準則
1）入口準則
要素
判斷準則
驗收測試前完成評審。
驗收測試計劃（有驗收測試要求的項目）
測試（系統(tǒng)測試、集成測試、單
已完成元測試）
2）出口準則
要素
判斷準則 已提交 已關閉 已提交
驗收測試報告
驗收測試問題報告單
驗收報告
（3）工作產(chǎn)品
● 驗收測試報告
● 《軟件問題報告單》
● 《軟件問題狀態(tài)登記表》
● 驗收報告
● 可交付產(chǎn)品
（4）職責
● 驗收測試組：負責驗收測試的各項活動。
● 開發(fā)組人員：負責驗收測試中發(fā)現(xiàn)問題的改正和測試輔助?！?項目管理人員：負責指派驗收測試責任和完成測試規(guī)程；確
保測試質(zhì)量和進程；確保組間協(xié)調(diào)?！?驗收組：具體進行驗收?！?ccb：批準運行基線。
1.9 維護
（1）概述
維護期是指： 軟件產(chǎn)品 / 系統(tǒng)驗收后，進入軟件運行 / 系統(tǒng)維護階段，直至軟件產(chǎn)品下一個版本的發(fā)布或系統(tǒng)維護期終止；
本元素在整個軟件開發(fā)過程中的位置如下圖所示：
驗收
維護
圖示：維護在軟件開發(fā)過程中的位置
（2）入口準則和出口準則
1）入口準則
要素
判斷準則
軟件產(chǎn)品 / 系統(tǒng)
已驗收
2）出口準則
要素
判斷準則
軟件產(chǎn)品
已退役
合同約定的維護期限
已到期
合同約定的維護范圍
已超出，須另簽協(xié)議
（3）工作產(chǎn)品
《軟件需求規(guī)格說明書》
《客戶需求登記表》
《客戶需求統(tǒng)計表》
《設計說明書》
《軟件問題報告單》
《軟件問題狀態(tài)登記表》
《軟件維護實施計劃》
維護后的軟件系統(tǒng)
（4）職責
維護負責人：制定軟件維護實施計劃，確認維護類型、需求范圍，分配維護任務，追蹤任務的完成情況及其他項目管理工作。
軟件維護人員：負責進行軟件維護任務的執(zhí)行。
qa人員：負責協(xié)助維護負責人根據(jù)實際情況剪裁標準流程。
軟件開發(fā)的實施方案篇二
項目管理實施方案
作為一個項目管理者,如何要成功的做好項目管理;首先必須先要明白的是在特定的領域中賦予這個角色所要實現(xiàn)的目標、承擔的職責、以及項目管理者的具體工作內(nèi)容是什么? 從我個人的淺見和角度以及我們所從事的it領域來分析回答以上三個問題。第一:目標
作為一個項目的管理者,必須要明確的知道自己的工作目標;我個人認為項目管理者的目標無非就是以下兩點:
1、就是清晰明確地了解項目利害關系者的需求和期望,努力做到滿足項目利害關系者的不同需求;項目利害關系者包括:項目團隊成員和項目團隊外成員(比如各部門的部門負責人和市場人員,客戶等。
2、就是保證開發(fā)項目按需按時保質(zhì)的完成。 第二:職責
作為項目的管理者,首先要端正態(tài)度,要明確知道自己的工作職責,認識到這份工作職責的本質(zhì)。項目管理者不是來管人的,而是來支持人的,是來協(xié)調(diào)資源的,是來營造一個適合團隊成員比較認同的工作環(huán)境和氛圍的,是來為一個共同的目標和大家一起戰(zhàn)斗共同成長的?？梢源蟾鸥爬ǔ梢韵聨c:
1、建立有效的工作流程保證項目的順利進行。
2、制定詳細周密的項目計劃。
3、跟蹤,推動項目按計劃進行。
4、積極解決項目過程中出現(xiàn)的問題和沖突。
5、調(diào)動開發(fā)團隊的積極性,創(chuàng)造力,推動團隊成員在項目過程中不斷成長。
6、項目風險識別、風險評估、風險解決和風險管理策略以及做好突發(fā)風險的應急預案。
7、實現(xiàn)目標
第三:項目管理者的具體工作內(nèi)容
最后一個是項目管理者的具體工作內(nèi)容,作為項目管理者必須清晰的知道自己的工作范圍和所要做的工作內(nèi)容以及工作重心,分為以下六點:
1、項目前期階段
對項目進行技術可行性分析、技術評估、成本評估以及風險評估。與需求提出方的代表進行需求討論,明確項目的目標、價值;確定項目范圍、功能及優(yōu)先級。組建項目團隊,特別要搞清楚項目的key person(對產(chǎn)品有決定權的人。項目啟動會議,相關的利害關系人員都必須參加。
該階段完成后的成果:確認后的最終軟件需求規(guī)格說明書文檔。
2、分析設計階段
根據(jù)確認后的軟件需求規(guī)格說明書,制定項目進度計劃,工作任務分解(wbs;資源申請,項目涉及到的開發(fā)資源、測試資源、設計資源(包括人員和軟硬件資源;數(shù)據(jù)庫設計;系統(tǒng)設計;文檔(包括use case、demo系統(tǒng)原型、test case等;評審會議。
該階段完成后的成果: a、user case(系統(tǒng)用例;b、demo(系統(tǒng)原型;
c、系統(tǒng)設計文檔(概要設計和詳細設計;d、數(shù)據(jù)庫設計文檔。
最后對完成的成果,包括user case和設計文檔等進行評審。
3、執(zhí)行階段(開發(fā)和測試
準備開發(fā)環(huán)境、測試環(huán)境;跟蹤,推動項目按計劃進行;以周報的形式通報項目的進展情況。對項目的階段成果進行評估,以確保該階段完成的質(zhì)量,包括代碼審核、sql 審核等。對需求變更進行控制管理;對項目風險進行管理;測試階段bug fixed及改進、收集反饋意見。
4、發(fā)布階段
包括制定項目發(fā)布計劃,用戶培訓,發(fā)布上線。
5、上線后監(jiān)控
數(shù)據(jù)監(jiān)控(日志、服務器狀態(tài),根據(jù)監(jiān)控出現(xiàn)的問題,及時進行bug fixed及改進或做補丁升級。
6、結束階段
產(chǎn)品交付,項目總結會。
第四:基于以上三個問題所做的應對細則
要做好項目管理,并能確實解決好以上三個問題,實現(xiàn)目標、履行職責、完成工作中的具體內(nèi)容,從我個人這幾年的工作經(jīng)驗和面臨的一些問題,還有所積累的一些項目管理中的一些知識以及自己的觀察和思考的角度看,應該要努力做好以下這幾個方面的具體工作:
1、項目開發(fā)時間的估算
制定項目進度時間表的時候,需要估算每個任務所需的時間,其中開發(fā)任務中模塊的分配和時間估算是其中最主要的部分;在分配模塊和估算開發(fā)時間時需要遵循的原則和目標:
1、保證項目整體的進度。
2、有助于確保開發(fā)編碼的質(zhì)量。
3、有助于提高開發(fā)編碼的速度。
在公司現(xiàn)有的技術框架下,開發(fā)人員主要的工作是投入在具體的商業(yè)邏輯上。通常每個模塊所需的開發(fā)時間取決于以下三個因素:
1、所負責模塊的商業(yè)邏輯的復雜程度。
2、開發(fā)人員的技術水平和對項目所在應用的熟悉程度(包括對框架和應用的熟悉程度。
3、該模塊技術實現(xiàn)上是否有技術難點;這里所謂的技術難點定義是:在現(xiàn)有系統(tǒng)中還未實現(xiàn)的、開發(fā)人員自身也未沒接觸過的技術。對于這樣的難點,開發(fā)者沒有相關的代碼可以參考,自己也沒有經(jīng)驗,所以需要投入一些時間研究解決。
模塊分配和開發(fā)時間估算的步驟:
1、在劃分好模塊后,首先自己先估算一下每個模塊所需要的開發(fā)時間。
2、然后召集所有開發(fā)人員,討論模塊的分配和開發(fā)時間估算。將劃分好的模塊,讓開發(fā)人員從中挑選他們感興趣的模塊。這樣做可以提高開發(fā)人員的主動性和參與性。在分配模塊的時候還需從以下幾方面考慮,以確保開發(fā)的速度和質(zhì)量: a、相同類似的模塊由同一人負責開發(fā),比如用戶管理的增刪改由同一開發(fā)者負責。
這樣做的好處就是開發(fā)者對相關邏輯會更加熟悉,同時接口的定義也會比較明確,溝通的成本比較低,同時功能實現(xiàn)的缺陷也相應的會降低。
b、技術難度比較大的模塊由技術水平比較高的人負責。c、業(yè)務邏輯比較復雜的由對這塊邏輯比較了解的人負責。
3、模塊分配完后,開發(fā)人員評估自己負責開發(fā)的模塊所需要的時間。在此過程中最好做到要和開發(fā)者比較詳細的討論每個模塊的技術實現(xiàn),以便使時間的估算更加準確。
4、對開發(fā)人員估算的時間進行確認。在確認過程中作為項目管理者應參考以上提到的三個因素,同時將自己估算的時間和開發(fā)人員估算的時間進行比較。這其中的差異當然會存在的。對于那些差異比較大的,將與技術人員探討其中的緣由。對于時間周期比較長的任務,盡量將任務通過再細分的手段細化任務,爭取每個任務的最長時間不超過3天;時間周期越長的任務,不確定性越高,風險也越高,越有可能成為項目的瓶頸,影響項目的進度。
2、code review code review是保證項目中代碼質(zhì)量非常重要的一個環(huán)節(jié),在這一環(huán)中我們公司做的非常欠缺,把關不嚴格;這是導致每次測試后出現(xiàn)大量bug的主要原因,這一環(huán)需要納入績效考核中,實行責任追究制,實施重點監(jiān)控。出現(xiàn)這樣的薄弱環(huán)節(jié),造成這樣的原因,我想也是有很多因素造成的;比如開發(fā)人員對需求不是很明確,以自己比較主觀的因素去完成任務的;還有對整個系統(tǒng)業(yè)務邏輯沒有正確的清晰的認識的原因,以及對項目組成員培訓不到位的原因等眾多因素糾集在一起才產(chǎn)生的。
如何做好這方面的工作?首先編碼要有“編碼規(guī)范”文檔,code review要有“代碼審
核規(guī)范”文檔:記錄代碼實現(xiàn)應該遵循的標準。通過這兩個文檔來規(guī)范開發(fā)人員的代碼實現(xiàn),代碼編寫者必須要嚴格按照規(guī)范來進行;代碼審核者根據(jù)這些標準來code review代碼,同時在code review過程中不斷完善該文檔。
在做好這些前期工作的前提下,分以下幾個步驟來實施:
1、檢查開發(fā)者的代碼實現(xiàn)是否遵循了編碼規(guī)范。
2、從代碼的易維護性、可擴展性角度考察代碼的質(zhì)量,提出修改建議。
3、代碼編寫者和代碼審核者坐在一起,由代碼編寫者按照use case依次講解自己負責的代碼和相關邏輯,從web層-到manage層再到dao層;
4、代碼審核者在此過程中可以隨時提出自己的疑問,同時積極發(fā)現(xiàn)隱藏的bug;對這
些bug記錄在案。
5、代碼講解完畢后,代碼審核者給自己安排幾個小時再對代碼審核一遍。代碼需要一
行一行靜下心來看。同時代碼又要全面的看,以確保代碼整體上設計優(yōu)良。
6、代碼審核者根據(jù)審核的結果編寫“代碼審核報告”,“審核報告”中記錄發(fā)現(xiàn)的問題
及修改建議,然后把“審核報告”發(fā)送給相關人員。
7、代碼編寫者根據(jù)“代碼審核報告”給出的修改意見,修改好代碼,有不清楚的地方
可積極向代碼審核者提出。
8、代碼編寫者bug fixed完畢之后給出反饋。
9、代碼審核者把code review中發(fā)現(xiàn)的有價值的問題更新到"代碼審核規(guī)范"的文檔中, 對于特別值得提醒的問題可群發(fā)email給所有技術人員。如果通過以上步驟,還因為是代碼編寫者的原因而出現(xiàn)嚴重的缺陷問題,將通過績效考核來加深代碼編寫者的印象,并在周報會議上做通報批評。
3、需求變更管理
需求變更管理也是項目管理中最重要的一個環(huán)節(jié),對需求變更管理的有效性將直接影響項目的成功與否。
對待需求變更的態(tài)度:
1、需求變更是不可避免的。
2、需求變更要必須被管理。
3、積極發(fā)現(xiàn)引起變更的因素,促使變更盡可能早的出現(xiàn),減低變更帶來的風險。 需求變更管理的目標:
1、相關的干系人必須清楚地了解發(fā)生的變更。
2、變更處于有效的管理中。
3、盡量降低變更帶來的風險。
通過制定需求變更的流程,確保項目中的需求變更有效地進行,實現(xiàn)上述的目標。需求變更流程:
1、確定需求的基準線。將以user case作為需求基準線,在user case確認之后的任何需求改變,都需要走需求變更流程,這一環(huán)節(jié)我們基本沒有,期間有時候使的工
作很混亂,也就是因為沒有一個規(guī)范的變更流程而造成的;如果建立了這么一個流程規(guī)范和機制,需求變更沒有走這個流程的將不被認可。
2、項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產(chǎn)品經(jīng)理、市場人員、開發(fā)人員、測試人員等。
3、項目管理者評估該需求變更。針對接收到的需求變更的要求,召集相關人員討論該需求變更的合理性、可行性,實施的代價以及對項目的影響。包括可能影響的項目范圍,進
度,費用,質(zhì)量等計劃。項目管理者作為項目的負責人,對項目的成功與否負有主要的責任。所以需求變更的決策者應該由項目管理者承擔。
4、需求變更確認后由專人將需求變更記錄下來,通知給項目中所有成員。其中以下人員對需求的變更是緊密相關的,他們必須知曉并認可此需求變更。包括(客戶方,需求分析人員,測試人員,相關開發(fā)人員。需求變更記錄格式如下: 序號變更提出時間變更描述變更類型(是 對原有需求 的修改還是 新增需求 原因變更提出 者
開發(fā)人員對進度的 影響(工 作量
1 2
5、確定變更的負責人。承擔需求變更的具體工作,比如基線控制,對需求變更的記錄,并通知相關人員。
6、相關人員接收到確認的需求變更后,做以下事情。需求分析人員修改需求說明書和user case的相關內(nèi)容。測試人員修改測試用例的相關內(nèi)容。開發(fā)人員修改代碼中的相關部分。
7、按照變更后的計劃實施項目,并進行檢查,跟蹤,對變更后的實施反饋和可能出現(xiàn)的問題及時溝通和處理。
8、需求凍結。項目越到后期,需求變更對項目的影響就越大,所以在一定時候要進入需求凍結階段,不再接收新需求或需求的變更。
4、風險管理
風險管理是項目管理者最重要的工作之一。風險管理是一個持續(xù)的過程,貫穿于整個項目過程中,風險管理包括風險識別、風險評估、風險解決以及風險管理策略。
在項目的實施過程中需要不斷地識別和應對風險,并加以有效的控制,風險管理的好與壞直接影響項目的實施效果,從某種意義上講,項目實施對于項目管理者就是識別、分析、應對、控制風險的過程,使項目的約束性目標和質(zhì)量目標朝有利的方向發(fā)展。
項目不同于日常任務,它有明確的起止時間和目標,要在明確的范圍、時間和成本約束下,達到相應的質(zhì)量標準,并取得用戶的滿意。影響項目成敗的因素涉及方方面面,并且風險伴隨著項目的始終,是客觀存在的,作為一個項目管理者,應該具備良好的風險控制意識,善于識別風險并分析風險的影響,從中發(fā)現(xiàn)影響目標的風險點,并施
加影響或采取應對措施,把風險的負面影響降到最低,并且風險控制應該貫穿項目始終。
風險引起的負面后果集中體現(xiàn)在進度延后、成本超支、質(zhì)量不達標等方面,導致這些問題的因素主要包括目標以及需求不明確、范圍蔓延以及需求變更、代碼質(zhì)量或返工風險、人員技能和資源的不足、缺乏良好的團隊協(xié)作等。下面將詳細描述一下這些問題以及出現(xiàn)這些問題時的應對方案:
1、目標以及需求不明確
為了市場競爭或內(nèi)部管理決策的需要,業(yè)務部門提出的需求往往要求的時間比較緊迫,需求的提出大多停留在幾張紙或口頭的傳達上,沒有形成正式的業(yè)務需求文檔,在沒有明確的需求范圍的情況下,有時為了迎合業(yè)務部門的口味匆匆開工,過程中用戶不斷地提出新的想法,技術人員開始疲于奔命和應付,很難保證項目的進度和質(zhì)量,也難以取得業(yè)務部門的認可。所以,在項目的前期一定要采取相應的手段或措施,與業(yè)務部門共同明確項目目標、需求范圍,充分考慮現(xiàn)有的時間和資源約束,將需求排定優(yōu)先級, 對于關鍵的需求優(yōu)先實現(xiàn)，其他輔助性的根據(jù)過程中的具體情況進行滾動式計劃，并取 得業(yè)務部門的書面確認。在此過程中要注重挖掘用戶的隱性需求，可以通過引導、系統(tǒng) 原型等手段讓用戶在前期充分暴露自己的想法和需求。
2、范圍蔓延以及需求變更 在有了明確的目標和需求范圍的情況下，需求的變更還是不可避免的，業(yè)務部門在 看到具體系統(tǒng)的真實雛形之后，源源不斷地要求、新想法隨之產(chǎn)生，如果不對此加以控 制，新的需求的加入通常會影響已實現(xiàn)的需求，并且對項目進度和成本產(chǎn)生很大的影響。項目管理者針對這種情況一定要采取嚴格的變更控制流程，不能礙于面子，否則最終的 結果往往是出力不討好。針對用戶提出的新需求，按照正式流程提出變更申請，組織相 關團隊成員進行分析及評估，作為是否實施的依據(jù)，變更控制負責人根據(jù)分析結果判斷 是否批準，如果批準，那項目組可以安排實施，否則，正式拒絕用戶的請求，當然實際 情況下可以采取一些軟措施緩解矛盾。需求變更風險：需求已經(jīng)打上了基線，但此后仍然有變更
發(fā)生，對項目造成影響。如何減少此類風險的發(fā)生？ 前期的需求討論要詳細、充分。需求文檔中需求的范圍要明確、功能描述要清楚。找出項目中需求的決策者(通常會是產(chǎn)品經(jīng)理、相關職能主管、客戶，所有的需求要經(jīng) 過他們的認可?？蛻粼陧椖窟^程中的全程參與有助于降低此類風險。需求討論、需求確 認、user case 確認、測試階段的客戶驗收等環(huán)節(jié)，都要要求客戶參與。在發(fā)生需求變 更時，嚴格按照需求變更流程執(zhí)行。在分析設計階段的中的確認和評審也是降低此類風 險的重要手段。
3、代碼質(zhì)量或返工風險 質(zhì)量風險主要指開發(fā)代碼的質(zhì)量。如何提高開發(fā)人員開發(fā)的質(zhì)量？在制定項目計劃 時，對開發(fā)時間的評估要盡可能的合適。合理的開發(fā)時間對開發(fā)質(zhì)量的影響也很大。有 時開發(fā)人員為了趕進度在比較緊張的時間需要完成指定的任務，可能就存在很大的開發(fā) 質(zhì)量問題。開發(fā)要有一套嚴格可行的代碼規(guī)范，編碼時嚴格遵守，到現(xiàn)在為止，我們這 個方面做的不是很規(guī)范，做的也很不足，大家編寫的代碼隨意性比較大，代碼編寫者的 主觀意識性比較強。要建立一套大家認可并且規(guī)范可行的編碼規(guī)范和考核規(guī)范，code review 時嚴格考核。在編碼前，開發(fā)人員要對框架熟練掌握；一份好的系統(tǒng)設計文檔對 指導開發(fā)非常重要。返工是項目組最不愿意看到的，既浪費人力、物力和財力，又影響團隊積極性。需 求不明確或范圍沒有有效控制都可能造成返工，另外造成返工的原因是質(zhì)量沒有達到用 戶要求。往往有這樣一種情況，每個團隊成員按照項目計劃報告進度都是 100%完成，但一到最后系統(tǒng)交互測試或集成的時候就會發(fā)現(xiàn)一大堆問題，不得不花費很大精力回頭 排查、修改程序，造成這種情況的主要原因是過程中質(zhì)量保證沒有做到位，把大部分問 題留在了后面。這就需要在項目實施過程中采取有效的措施來規(guī)避返工的風險，通常的 做法有同行評審，比如概要設計完成之后，邀請其他項目組的技術專家進行技術評審以 發(fā)現(xiàn)架構設計問題； 管理評審，通過組織級的質(zhì)量審計看產(chǎn)品以及實施過程是否滿足質(zhì) 量要求；代碼走查，在編碼過程中加入至少一次的代碼走查，排查不符合規(guī)范或性能要 求的代碼，走查通常能夠發(fā)現(xiàn) 50%-70%的錯誤；每日構建，這是一種非常有效的方法，可以避免把各部分的集成問題拖到最后，并且能夠及時發(fā)現(xiàn)相應的錯誤，日構建一般在 項目的中后期開始，每天自動從版本服務器上獲取源代碼進行自動編譯和測試。
4、人員技能和資源的不足 項目實施過程中由于人員技能欠缺造成的進
度延后和軟件質(zhì)量問題并不少見，一個 熟練的技術人員完成同樣一個任務需要 3 天，但一個生手可能就需要 7-10 天。項目管
理者應該在前期就分析清楚項目所要采用的技術以及相應的人員技能要求，針對不同的 角色，及時采取相應的技能培訓，以保證項目的順利實施。如果對于項目中某些部分專 業(yè)性特別強或新技術，短期內(nèi)又不能快速建立技能的情況，可以考慮將該塊任務外包，借鑒合作商的力量降低實施風險，當然要進行外購人力成本與自建人力成本的效益分 析。開發(fā)過程中遇到技術難題，導致開發(fā)時間延遲或者需求不得不發(fā)生變更。如何減少 此類風險的發(fā)生？在項目開始前的技術評估階段，明確技術難點，提前安排人員進行攻 克。如果在可預期的時間內(nèi)無法解決，如果可以，將向需求提出方要求變更需求或?qū)ふ?可替代方案。這樣的風險應該在項目的前期階段就應該解決在萌芽狀態(tài)來避免這樣的風 險在后期或中期出現(xiàn)。項目所需人力資源無法按時到位，導致資源風險。如何減少此類風險的發(fā)生？這個 就需要在項目計劃制定的時候提前申請確認資源，并在項目過程中不斷溝通協(xié)調(diào)。
5、缺乏良好的團隊協(xié)作 軟件項目實施屬于知識型，要發(fā)揮團隊成員的創(chuàng)造力，不同于制造業(yè)計件生產(chǎn)，各 模塊最終要集成在一起形成一個有機的整體，這就需要各小組之間的密切配合，界定清 楚工作界面及接口關系，并在實施過程中持續(xù)地溝通交流和共享，首先團隊要融為一體，產(chǎn)出的軟件才能融為一體。這是一個團隊的軟實力，團隊之間的協(xié)作好壞也將是個潛在 的風險問題，在項目啟動和團隊組建的時候就應該加以規(guī)避這樣的風險出現(xiàn)。項目風險管理的要點：
1、上述我們所說的風險管理都是指可以預期將要發(fā)生的風險，那些不可預期將要發(fā)生 的風險不屬于風險管理的范疇。這也將是考驗一個項目管理者的經(jīng)驗和知識對能否 管理好風險至關重要的內(nèi)容。
2、對不可預期的風險，項目管理者要有潛在的風險意識評估，做好一些可操作性的預 案準備。
3、詳細明確的項目計劃、以及項目執(zhí)行過程中每個要點的質(zhì)量保證是降低項目風險的 必要條件。
4、風險報告是項目團隊以及領導了解項目風險的一個有效手段。 風險報告的格式： 序號 風險簡介 對項目的影響 解決方案或?qū)Σ?/p>
5、團隊管理 團隊就是一組個體為實現(xiàn)共同的目標而相互依賴、一起工作的共同體。團隊工作顧名思 義就是團隊成員為實現(xiàn)這個共同的目標而付出的共同努力，項目團隊的工作是否有效直接關 系到
項目的成敗。團隊管理是個漸進的過程。世界上只有完美的團隊，沒有完美的個人。好的高效的團隊 不是管理出來的，而是營造出來的。團隊成員需要有大家可認同的團隊文化，這需要大家共 同的努力。
1、營造良好的工作環(huán)境和氛圍。
2、建設優(yōu)秀或鮮明的團隊文化。
3、保持高效的溝通。
6、項目會議 組織會議是項目管理者日常工作中一項非常重要的工作任務，項目過程中很多重要的決 定都是在會議中做出的，也有很多由于不成功的會議而對項目本身造成了不好的影響。首先看看不成功的會議常常表現(xiàn)為哪些形式：
1、會議氛圍不好，參與者發(fā)言不踴躍；
2、會議討論常常偏離主題；
3、會議沒有取得預期的結果；
4、會議時間常常一拖再拖。 這些不成功的會議最終的結果就是：既浪費了大家的寶貴時間又沒有達到會議的目的，很多人都對這樣的會議都有抵觸情緒，對此也是深惡痛絕。以下是組織會議時應該注意的問 題，也可看作組織會議的最佳實踐。在列出最佳實踐之前有三點我們必須要清楚：
1、會議是否會取得成功很大程度上取決于會議的組織者。只有組織得有力，會議才有 可能取得成功，這是會議成功的充分條件。
2、會議的組織者和參與者的想法通常是不一致的，有時候甚至會大相徑庭。所以不要 希望會議的參與者和你一樣，對會議有著如此的期待，對大多數(shù)參與者而言，在會議中他只 是一個發(fā)表想法的人，他不用對會議的成功承擔責任。
3、以下十一條最佳實踐是形式上的約定，具體的實施可以根據(jù)實際情況來做。 組織會議的十一條最佳實踐：
1、只有需要開會時才開會。有時候兩三個人單獨小范圍溝通會更加有效。
2、提前發(fā)出會議議程，以便會議參與者知道他們來做什么。
3、請對人很重要，不要把非必要的人召來開會，當然也不要漏掉那些關鍵人物。在確 保必要人物都在的情況下一次會議參與者越少效果越好。
4、提前預約參與者的時間，以確保他們能按時到場。
5、會議的開場很重要。會議組織者要在開始前做好幾件事情。通常我建議有幾點要在 開場時說： a、再一次強調(diào)會議的目標，我們來做什么。b、強調(diào)會議的主題與基調(diào)。比如：本次會議是一個需求確認會，而非需求討論會，主要是討論做還是不做以及告知大家我們要做什么，而不要把太多的精力放在討論 如何做上面。c、說明一下會議的規(guī)則。如要發(fā)言，請舉手；不要有小圈子討論；不要打斷別人 的講 話，等別人說完你再說等等。
6、會議過程中時刻注意引導和控制會議，以確保會議按照目
標進行。一次會議的氛圍 是否良好，討論是否充分，好的引導至關重要。比如多提一些開放式的問題。
7、會議記錄很重要，把一些結論和有價值的內(nèi)容記錄下來，這些是本次會議的重要成 果之一。
8、會議要有結論。我們常在會議上聽到有人說："大家討論了這么半天，結論呢？"。沒有結論的會議是沒有意義的。
9、會議后別忘發(fā)會議紀要，以及一些 action，什么人什么時候做什么。
10、會議后的 action 執(zhí)行情況的反饋很重要。反饋是對會議參與者的尊重，同時也告知 了會議的效果。否則會讓大家感覺到這是一個可無可無的會議，大家以后參與的積極性 也會降低。很多會議往往都不注意這一點。
11、按時結束的會議會受到所有人的歡迎。
7、版本控制 版本控制也是項目管理者的一個重要工作內(nèi)容之一，一個項目或產(chǎn)品的完成不可能是一 步到位的，在項目完成的后期可能會有多個不同的版本的發(fā)布（開發(fā)版本，測試版本，發(fā)布 版本等）。需要做好版本的管理和控制。
8、項目總結 在項目完成后，總結整個完成項目的過程和經(jīng)歷，為下一次的項目啟動提供參考經(jīng)驗，完善不足，避免在類似的項目中出現(xiàn)可能存在的相同的錯誤發(fā)生。
