曾经有个笑话，说三个软件高级人材等待上帝安排工作，一个说自己擅长抽象思维，上帝说那就做系统分析师吧;一个说自己工作非常细心，上帝说那就做QA;最后一个说，我实在没有更多的才能，那就做项目经理吧。有句项目管理名言则是这个笑话的最好解释：对项目经理的知识要求是要有1英里宽，7英寸深。也就是说，各方面的综合能力是项目经理的首要技能。

　　项目管理引入中国好多年了，除了国外的PMP、IPMP认证体系，现在更是将之引入高等学位教育。除了最先应用项目管理的建筑行业，现在各行各业都非常重视行业内的项目管理，这些足以可以看到项目管理的蓬勃发展。但是软件项目失败案例还是比比皆是的今天，如何将项目管理与新理论和技术层出不穷的软件产业双剑合璧?项目管理理论是欧美国家伴随着生产管理起步的，虽然方法论是通用的，但是如何在软件开发中产生更大效益，需要更多的业界项目经理以及高层思索和总结。

　　一个成功的建筑行业项目经理也会是一个合格的IT项目经理吗?项目管理有之一个名言：一个成功的建筑行业项目经理也会是一个合格的IT项目经理。在欧美国家是适用的，这样跨行业的例子也非常多。但据我了解在大陆这样的例子还非常鲜见。尤其软件开发行业，就更没这种先例了，为什么在欧美或者印度模式中，都是行得通，在中国不行呢?欧美或者印度模式的项目经理负责制定开发计划、协调、以及填写各种项目输出表格或模版就够了。在这种模式中项目经理不一定要求必须是技术专家，但更强调项目经理的工作经验，一般会要求项目经理有8年以上工作经验。而在中国，尤其是现在一个有三年工作经验的team leader也会称项目经理，当然他也并不需要对成本、人员、采购等众多项目管理领域的关注，这样的team里也根本不会有技术经理或顾问专有角色的配备，项目经理要更多的关注技术因素，所以项目经理一般是与行业和产品同步成长起来的。如何做好质量、成本、沟通、时间、以及更资源参与的全面项目管理是我们的项目经理的课题。

　　范围管理是项目经理具备的首要能力

　　范围说明是未来项目决策的基线，也是衡量项目是否成功的标准。在我们软件开发项目中，需求规格就是我们项目的范围的体现。我的经验是项目经理应极端重视需求，成功的需求管理才能保证范围在基线内，需求调查、讨论、分析、归档、review、变更、回溯等一系列活动是我们需求管理的有效活动。

　　计划能力是项目经理的应具备的另一个技能，其中软件开发任务的估算是一个难点，即使有历史数据达到CMM4的软件企业也会有20%-50%的误差，我的一些做法用三层到四层的WBS模版从底向上进行时间资源的估计，会从自己经验和相似项目的历史数据中进行加权平均，时间资源的平衡，在WBS分解模版中采用自底向上估计，估计时我们采用了三人以上匿名delphi法，设定差值阈值为30%，如果与平均值的差值比小于此阈值，将不在重新估计，如果大于将进行重新估计，重新估计后如果还是超过设定阈值，估计人要写明为什么如此估计的原因。对于阈值内估计值我们采用历史经验数据进行修正即可作为我们WBS工作包的估计值。

　　合适的软件开发生命周期模式，对软件开发项目尤为关键。根据项目的需求、资源、风险、时间、质量等实际情况，选择合适的软件开发生命周期模式，对软件开发项目尤为关键。印度软件模式中更是提出了流程模式重于项目。在需求不确定、变化较频繁的项目我们可以选用迭代和原型法。在产品按版本递增开发的项目，由于每期需求比较稳定，宜选择瀑布变种的V模型进行测试提前的生命周期。开发模式的选择将影响项目计划，例如V字形，每个过程都有严格的输入输出，上一个过程的输出作为此过程的输入，实际情况中我们会选用改良的V模型，一些过程可以并行，例如需求规格完成后，可以系统测试计划和概要设计并行。在实际项目管理中开发模型生命周期中各过程的输出宜作为milestone(里程碑)设置计划控制点。

　　时间、质量和成本是衡量项目成功的三要素，时间和成本因为有形比较容易监控，质量控制在软件开发项目中非常重要了，所以我们很多过程和活动(文档review、代码走读、单元测试、集成测试、系统测试、以及各过程的需求反馈追踪等)都是保障质量的活动。现在好多项目都特别重视了系统测试(包括功能测试、性能测试等)，但是忽略了单元测试。单元测试是所有测试中最底层的一类测试，是第一个环节，也是最重要的一个环节;是唯一一次有保证能够代码覆盖率达到100%的测试，是整个软件测试过程的基础和前提;单元测试防止了开发的后期因BUG过多而失控;单元测试的性价比是最好的。在项目中我们引入了TDD单元测试实践，并关注了编译检查、代码走读，以及在等价类、边界值、因果图等方法下的黑盒功能

[1] [2] [3] 下一页