參考：
開發管理，是對開發團隊開發活動的管理，開發活動佔據整個研發工作量的50%-70%。因此，理順開發管理工作，提高開發的效率，提公升開發的工作質量，是開發管理者所追求的。
開發的主體活動
開發活動的範圍很廣，主體活動包括但不限於如下：
開發計畫管理
軟體需求分析
總體設計
子系統和模組的概要設計
ui&ue互動設計
介面設計及文件開發
詳細設計和程式設計開發
單元測試
聯調測試
自測修改
系統上線之初
評審、**審查
使用者文件開發
具體要結合開發團隊的實際情況，進行適當裁剪
注意：使用者需求調研和產品需求開發歸於產品部門，不歸屬開發團隊。如果為定製開發的軟體專案，大多數歸於開發團隊。
測試工作歸於測試團隊，測試工作量可以按開發工作量50%估計。
制定開發計畫，一般按下列步驟進行：
開發任務分解
評估工作量
確定順序
將工作安排給合適的人員
檢查約束條件，在開發時間、人力資源和需求集合三者之間協調
開發任務分解
開發任務分解，是開發計畫的起點。計畫的可行性和有效性，首先依賴於開發任務分解。
開發任務分解，即分解得到開發任務集合的過程，有下列關鍵點：
1完整性，即開發任務是否覆蓋整個開發活動
2任務的力度粗細程度
開發任務分解，既與開發流程涉及的各個節點有關，如軟體需求分析、總體設計、程式設計實現、單元測試和聯調測試、使用者文件編寫等；也與軟體的需求項的數量和開發工作量有關。
有時候只有產品需求，就必須給出開發計畫。此時只能進行粗粒度的任務分解，工作量估計需要經驗，還要留有餘量，這種計畫一般是專案**時採用。畢竟很多商業決策都是在資訊相對不完整時就必須進行的，如定製開發軟體**，就高度依賴於行業應用的開發經驗。
而做了軟體需求分析後，確定了軟體的規模，以及需要劃分幾個子系統以及每個子系統的模組組成，此時任務的分解粒度可以比較細化。
而做了軟體需求分析後，確定了軟體的規模，以及需要劃分幾個子系統以及每個子系統的模組組成，此時任務的分解粒度可以比較細化。
在公司內部，不妨允許開發計畫迭代，先給出大致的計畫，然後分階段細化計畫。
在產品需求確定時，輸出粗粒度的開發計畫。在軟體分析後，再行細化和修正。或者按mvp迭代或敏捷開發的sprint迭代方式，給出每個迭代週期的開發計畫。
如果工作任務分解比較細，如每個工作任務的工作量在0.5天到3天之間，開發成員的工作情況的觀察點就多了，對控制專案進度風險和質量風險都有好處，這個粒度不妨稱為可管理任務量級。但這對計畫制定帶來更大的挑戰，要求進入開發實施前，工作任務分解粒度達到「可管理任務量級」
工作量測算
針對程式設計開發類任務，在部門建立專家組（高階程式設計師），評價任務工作量時，抽出2個高階，加上team leader，再臨時召集2個中級，作為工作量評估小組。針對一批任務，先有team leader講解任務內容，然後大家各自寫出工作量（以**開發任務以中級程式設計師能力為基準），以小時為單位，然後大家亮出結果，如果最高和最低相差較大，則需要闡述理由，大家覺得理由充分，就投票決定工作量；如果相差不大，取中位數的工作量即可。評估後的工作量，作為標準工作量，不管誰來完成該任務，其標準工作量是不變的。對於程式設計開發類任務，除了程式編碼，還應考慮單元測試的時間。
針對系統分析設計類任務，由2個高階，加上team leader，來評估。
工序安排
任務的工序安排，即確定某個任務的前置任務和後置任務，哪些任務可以並行開展。這要求計畫編制者對任務的先後次序非常清楚，並且要重點關注高優先順序的任務，和容易造成瓶頸的任務，如果這些任務延誤，會造成嚴重影響。工序安排，實際是運用運籌學的方法，提高並行能力。
人員安排
粗的開發計畫，只需要對每個任務確定人員資質水平要求即可，如某個任務要求系統分析員、高階程式設計師或中級程式設計師。但在專案實施前，所有的開發任務需指定具體的開發團隊成員，一人或多人。作為開發小組team leader，比較清楚成員的能力水平，對業務的熟悉程度，以及出於人員培訓和後備的考慮等，安排合適的成員來負責具體的任務。
平衡計畫的約束條件
開發計畫有約束條件，需要在開發時間、人力資源和需求集合三者之間平衡。如果開發時間有限制，即專案交付時間點有限制，就需要人力資源和需求集合來平衡。如果時間緊，就要求或者更多的人力資源，或者更少的需求項。更多的人力資源，並不是指更多的人，而是有效人力資源，在專案後期加入人員，由於對專案的不熟悉，效果往往不盡人意。因此，在計畫階段，就需要清楚人力資源的需求情況，考慮到人員到位並不能一廂情願，因此需要持續評估風險，並及時採取對策。
軟體開發計畫
xx公司 2020 01 01 文件管理 合理地管理主文件，確保文件版本的及時更新，同時保持備份文件和源文件的一致性。版本管理 本版本修訂日期 2019 08 12 生效日期 2019 08 12 版本 生效日期 變更內容 編制人 v1.0 2020 01 01 初稿編寫完成 xx 引言標識 本條應...
敏捷軟體開發 計畫
計畫 初始探索 在專案開始時，開發人員和客戶會盡量確定出所有真正重要的使用者素材。然而，他們不會試圖去確定所有的使用者素材。隨著專案的進展，客戶會不斷編寫新的使用者素材。素材的編寫會一直持續到專案完成。這一點我贊成，不可能一開始什麼都確定下來，會慢慢完善 大素材要分解 比如使用者能夠安全地進行存款 ...
軟體開發管理
scrum感言 軟體流程的名稱太多，rup,v model,iso9000，cmm等等不一而足。最近接觸了scrum，收穫良多，與諸位同仁分享。自從有人類社會活動以來，就形成了各種各樣的組織和制度，上到社會體制下到家庭環境，西方到東方，社會風尚 工廠流程 等等，這些東西都具有一種共同的特點 都是為了...