在軟體開發的過程，如下的15條實踐比較經濟實用：
（1）控制專案組的團隊規模
不超過10人
，人員要少而精。
（2）需求文件化
，無論大小專案必須清晰的描述需求。
（3）採用
用例、介面原型描述需求
，採用這2種手段強制使
需求描述
的完備而清晰。
（4) 專案的階段計畫與2周計畫，
階段計畫
定義總體承諾，
2周計畫定
義近2周的詳細任務安排。
（5）逐日跟蹤+周例會
，每天輪詢專案組每個成員的進展，每週召開全組成員的協調會議。
（6）需求評審+設計評審
，需求與設計文件必須經過評審，評審可以是正式的審查可以是不規範的走查，但是通過評審可以發現問題，促進溝通。
（7）測試驅動開發
，寫**前寫測試用例，採用自動化的單元測試工具，通過編寫測試用例可以提醒開發人員規避那些問題，通過自動化測試，可以重複、頻繁的進行回歸測試。**總是在修改的過程中變的越來越差的。
（8）單元測試+**走查+重構
，單元測試與**走查合起來做到100%語句覆蓋，重構可以提高**的結構，優化設計，提高軟體的可維護性。
（9）每日聯調，早發現介面的問題
，並始終保持有乙個可以演示的版本。
（10）
需求階段編寫系統測試用例
，作為驗證需求的一種手段，促進需求的描述達到可測試、可度量的程度。
（11）
小版本發布，定義需求的優先順序
，定義在開發過程中明確的發布版本，使開發過程可見，使專案組成員有成就感。
（12）進行專案的
經驗教訓總結
，向歷史學習，向案例學習，自己的經驗教訓最容易為自己所接受。
（13）
有標準就要安排qa人員檢查執**況
，無論規範的完備性如何，首先要說到做到，培養組織的執行力。
（14）採用
svn等配置管理工具
管理**與文件，規避基本的版本混亂。
(15)
客戶方參與的需求變更控制
，需求的變更很大程度上源於專案組外部的原因，應從源頭規範化需求的變更。
對於不同的企業、不同的專案，上述的實踐可能也難以做到，但是我想上述的15條應視為乙個基本集合。
如何管理小型軟體專案？
所謂的小型專案一般是指估計工作量大於3人月小於9個人月的專案。對於沒有實施cmmi的企業，這類專案一般是放任自流，少有管理了，對於實施cmmi的企業，如果這類專案也想要達到cmmi的要求，管理的成本相對投入比較大，難以平衡管理的成本與收益，因此，需要做裁剪。如何裁剪，就是難點。
經過與多個客戶討論，最終形成了如下的參考意見。每個企業的特點不同，這些實踐對於不同的企業，仍然有不同的實現困難，可以在下述實踐的基礎上繼續裁剪。但是，管總比不管要好，有總勝於無，總是要有基本的管理才可以。
1，商務管理
商務人員與客戶談判時，應要求
客戶明確需求
商務人員與客戶要
確定需求變更的流程
商務人員談判時，
應定義需求變更的成本由哪方承擔
商務人員與客戶
商定專案驗收標準
商務人員與客戶的
商定雙方合作中的溝通問題，包含
溝通渠道、溝通方式、溝通時間以及反饋時間約束，並商議多長時間內不給反饋資訊，即可預設接受。
合同評審應由
專案經理參與
2，專案策劃
專案經理與高層經理、客戶確定專案的
平衡策略，即
需求、質量、進度、成本哪個指標優先
專案經理根據本專案實際情況，
制定專案執行的過程規範
專案經理
確定**評審和單元測試的**覆蓋率等質量目標
專案經理
確定專案的生命週期模型、階段劃分
專案經理
制定專案階段計畫，並
明確每個階段的交付物
專案經理
進行wbs分解，並細化
《專案階段計畫》，採用ms project工具
識別需求與進度
風險，定義
規避措施
3專案監督與控制
專案經理負責
召開周例會，並生成
《周進展報告》或會議紀要
專案所有成員填寫
日誌，專案經理
根據日誌每天跟蹤專案組成員的任務進展情況
建立日誌軟體，每天
填寫日誌的工作量要少於5分鐘
定期向高層經理匯報進度
周例會時要
監督風險的狀態情況
專案結束時，專案經理
負責召開結項總結會，並生成
《專案總結報告》
4 質量保證活動
**規範的檢查
需求變更流程的檢查
缺陷關閉情況的檢查
監督專案組單元測試和
**評審的覆蓋率的落實情況
監督專案各工作產品是否滿足組織級標準與規範
5 配置管理活動
使用svn工具進行配置管理
所有的工作文件均應入庫
專案結束時，
所有的文件應完整入庫
客戶往來郵件定期整理備份
6 度量與分析
根據工作日誌，按
計畫內外、工作型別、階段進行統計分析，由
日誌系統
自動進行
統計全生命週期生產率
工作量資料均來自
日誌系統，
**規模資料在專案結束時採集
7 需求工程
識別重要的
功能需求和非功能需求，形成文件化的srs
描述需求時採用
介面原型與
use case方式
接受客戶電子檔形式的需求變更（含郵件）
至少2人以上參與
需求變更的影響分析，並反饋客戶
專案需求須
專案經理確認同意後方可變更
8 軟體設計與實現
系統架構設計文件化，形式不限
系統架構設計評審
編碼單元測試及**重構，引入junit、nunit等工具
**走查
每日聯調所有已完成的模組，並進
行冒煙測試
在開發過程中，請
客戶每月參與1次對已完成的部分軟體的確認
系統測試，
未經公司系統測試通過，不能發布系統
專案管理 軟體開發那點事
幾天前，在乙個咖啡廳跟別人談事的時候，聽見隔壁兩個人閒聊。乙個人是搞經濟學的，另乙個人問他 經濟學複雜嗎?回答 不複雜，經濟學裡只有兩件事兒 一是刺激經濟很重要 二是天下沒有免費的午餐 當時頗有感觸，看似詭異的回答，卻蘊含著對自己擅長領域的高濃度概括和思考。從那個晚上起，我就走進了自己擅長領域 兩件...
軟體開發專案成本管理實踐
本文將從專案經理 軟體開發團隊的角度，怎麼做專案成本管理。首先，了解專案成本構成 軟體專案成本由直接成本和間接成本構成，可以把間接成本分攤到直接人力成本中，例如每人日450元，就是生產一線人員的成本，包括人員工資 分攤支撐線人員工資 辦公費用等各項費用。本文假設間接成本分攤到一線開發人員的人力成本中...
書籍推薦 《超越餛飩，有效管理軟體開發專案》
這是一本有關軟體開發專案管理的書，雖然我不是乙個專案經理，但我的工作需要與他們打交道，因此讀讀也未必是壞事。整本書近400頁，但快速讀一遍花費兩三個晚上就足夠了。與其說這是一本書，不如說這是一本文集。這本書的作者達到了30位，他們多是工作在一線的專案管理者 諮詢師，針對專案管理的不同方面闡述了自己獨...