| 出版日期：2002-03-11 总期号：1099 本年期号：16 |
|
 |
别拖开发进度后腿
成杰 软件项目开发中，开发进度的控制是每个项目经理经常感到困惑的问题。我们常常见到一些项目一拖再拖，迟迟不能结项，极大地消耗开发方和使用方的资源。同时，我们也见到一些成功的项目，虽然在开发过程中遇到了波折和困难，但最终总能够如期交付使用。成功和不成功的原因是什么，有什么方法可以解决？ 如何提高和维持软件开发项目团队中每个成员相对较高的工作效率，是一件非常复杂的工作。它不仅仅是技术性的工作，同时还渗透着管理与协作的规则和理念。 资源的调配与整合 由于不同软件企业的管理模式和不同级别经理的授权范围不同，每个经理所能掌握、控制的资源的种类和数量是不同的，但毫无疑问，每个项目经理手中的资源都是有限的。一个相对完备的软件开发团队，至少拥有以下不同方面的主管角色，项目经理(资源调度、进度控制、激励与督促)、系统分析员(复杂系统分析和设计)、质量主管(代码质量控制、文档管理)。 
开发团队角色关系图 在系统比较简单的情形下，这些不同的角色是由一个人承担的。但根据项目的复杂程度，项目经理应该考虑优先配备高级主管人员。 单纯的代码编写人员是相对容易得到的，但得到一组能够配合得相当好的代码人员并不简单。在开发管理比较理想的团队项目中，项目的开发进程和系统的分析与设计都应在编码开始之前完成，程序员之间的配合是靠前期的分析与计划自然实现的。但即使在这样的团队里，员工之间良好而默契的关系仍然是不可替代的。 任务细分易于控制 一个系统的开发不太可能完全按照计划的进程完成。项目经理要掌握计划与实际之间的差距，不断地调控才不会最终偏离DEAD-LINE太远。把一个项目分解成不同的工作“粒度”，是一种基本的做法。它是能够把工作分配给团队成员的前提条件。不同程度的分解会产生不同的效果。基本上，工作分解得越细致，整体进度就越容易控制和把握。判断一项工作是否已经全部完成，是一种非此即彼的0/1判断，它远比判断一项任务的完成程度要容易和准确。假设你总体判断一项工作需要200人日完成，而没有对这项任务进行更细致的分解。那你便没有办法判断，在耗用完200人日的资源之前，实际与计划相比是超前还是落后，当然也就没有办法做出调控的决策。就是说，你辛辛苦苦用了100人日后，印象上好像应该完成了一半的工作，但没有办法证实。所以，建议把大的工作尽量进行细致的划分。如果你划分的粒度有5人日大小，那你最多对5人日的工作失去判断能力。然而分解项目是一项技术专业性非常高而且非常费力的工作。所以无限地分解细化工作也不一定划算。我觉得0.5%-5%是一个非常适当的范围。就是说，一项100人日的工作，最好能分解成为若干0.5人日-5人日大小的工作。考虑到软件规模的差异对进度判断的影响，进行项目分解时的另一个原则是，如果分解出的一项工作粒度太大，最好让承担这一工作的人对其进行二级分解，并提交更详细的计划。 遵守开发规范 有些开发人员有不守规则的习惯，以为在不受到约束时能够发挥更大的效率。在很多项目组里，这种行为会得到项目经理或多或少的姑息。可是也有些开发经理本身就不太认同开发需要完整的规范。比如文档的齐备、注释的完整等等，有些项目经理可能以为其作用不如运行中有效的代码重要，而严格的质量评测、审查机制更被一些人认为在项目进行中可有可无。其实，完整而规范的开发流程可能在单个小型任务中降低原型产生的效率，而在复杂的、生命周期较长的、需要团队协作的系统中，却是成功的必要条件，可以提高开发质量，降低开发周期，增强代码的可重用性和易读性，使软件便于维护，开发人员之间便于交流和协作。 |
||||||||||||||||||||||||||
