参考：https://www.cnblogs.com/alabo1999/p/12961308.html
开发管理，是对开发团队开发活动的管理，开发活动占据整个研发工作量的50%-70%。因此，理顺开发管理工作，提高开发的效率，提升开发的工作质量，是开发管理者所追求的。
开发的主体活动
开发活动的范围很广，主体活动包括但不限于如下：
开发计划管理
软件需求分析
总体设计
子系统和模块的概要设计
UI&UE交互设计
接口设计及文档开发
详细设计和编程开发
单元测试
联调测试
自测修改
系统上线之初
评审、代码审查
用户文档开发
具体要结合开发团队的实际情况，进行适当裁剪
注意：用户需求调研和产品需求开发归于产品部门，不归属开发团队。如果为定制开发的软件项目，大多数归于开发团队。
测试工作归于测试团队，测试工作量可以按开发工作量50%估计。
制定开发计划，一般按下列步骤进行：
开发任务分解
评估工作量
确定顺序
将工作安排给合适的人员
检查约束条件，在开发时间、人力资源和需求集合三者之间协调
开发任务分解
开发任务分解，是开发计划的起点。计划的可行性和有效性，首先依赖于开发任务分解。
开发任务分解，即分解得到开发任务集合的过程，有下列关键点：
1完整性，即开发任务是否覆盖整个开发活动
2任务的力度粗细程度
开发任务分解，既与开发流程涉及的各个节点有关，如软件需求分析、总体设计、编程实现、单元测试和联调测试、用户文档编写等；也与软件的需求项的数量和开发工作量有关。
有时候只有产品需求，就必须给出开发计划。此时只能进行粗粒度的任务分解，工作量估计需要经验，还要留有余量，这种计划一般是项目报价时采用。毕竟很多商业决策都是在信息相对不完整时就必须进行的，如定制开发软件报价，就高度依赖于行业应用的开发经验。
而做了软件需求分析后，确定了软件的规模，以及需要划分几个子系统以及每个子系统的模块组成，此时任务的分解粒度可以比较细化。
而做了软件需求分析后，确定了软件的规模，以及需要划分几个子系统以及每个子系统的模块组成，此时任务的分解粒度可以比较细化。
在公司内部，不妨允许开发计划迭代，先给出大致的计划，然后分阶段细化计划。
在产品需求确定时，输出粗粒度的开发计划。在软件分析后，再行细化和修正。或者按MVP迭代或敏捷开发的Sprint迭代方式，给出每个迭代周期的开发计划。
如果工作任务分解比较细，如每个工作任务的工作量在0.5天到3天之间，开发成员的工作情况的观察点就多了，对控制项目进度风险和质量风险都有好处，这个粒度不妨称为可管理任务量级。但这对计划制定带来更大的挑战，要求进入开发实施前，工作任务分解粒度达到“可管理任务量级”
工作量测算
针对编程开发类任务，在部门建立专家组（高级程序员），评价任务工作量时，抽出2个高级，加上team leader，再临时召集2个中级，作为工作量评估小组。针对一批任务，先有team leader讲解任务内容，然后大家各自写出工作量（以代码开发任务以中级程序员能力为基准），以小时为单位，然后大家亮出结果，如果最高和最低相差较大，则需要阐述理由，大家觉得理由充分，就投票决定工作量；如果相差不大，取中位数的工作量即可。评估后的工作量，作为标准工作量，不管谁来完成该任务，其标准工作量是不变的。对于编程开发类任务，除了程序编码，还应考虑单元测试的时间。
针对系统分析设计类任务，由2个高级，加上team leader，来评估。
工序安排
任务的工序安排，即确定某个任务的前置任务和后置任务，哪些任务可以并行开展。这要求计划编制者对任务的先后次序非常清楚，并且要重点关注高优先级的任务，和容易造成瓶颈的任务，如果这些任务延误，会造成严重影响。工序安排，实际是运用运筹学的方法，提高并行能力。
人员安排
粗的开发计划，只需要对每个任务确定人员资质水平要求即可，如某个任务要求系统分析员、高级程序员或中级程序员。但在项目实施前，所有的开发任务需指定具体的开发团队成员，一人或多人。作为开发小组Team Leader，比较清楚成员的能力水平，对业务的熟悉程度，以及出于人员培训和后备的考虑等，安排合适的成员来负责具体的任务。
平衡计划的约束条件
开发计划有约束条件，需要在开发时间、人力资源和需求集合三者之间平衡。如果开发时间有限制，即项目交付时间点有限制，就需要人力资源和需求集合来平衡。如果时间紧，就要求或者更多的人力资源，或者更少的需求项。更多的人力资源，并不是指更多的人，而是有效人力资源，在项目后期加入人员，由于对项目的不熟悉，效果往往不尽人意。因此，在计划阶段，就需要清楚人力资源的需求情况，考虑到人员到位并不能一厢情愿，因此需要持续评估风险，并及时采取对策。