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