大话软件开发项目管理（二）

上一节的故事可能是很多软件项目负责人经常遇到的一些或多或少的问题，止在说明一点：在实际的工作中，很多软件项目管理人员对于整个软件项目的开发schedule确实很难精确的预估和控制。笔者对此感触最深的一次是听到某位在软件开发领域工作了20多年，中型公司CTO级别的因为某个软件项目Delay后给老总说的一句解释的话：“我做了这么多软件项目，从来没听说软件开发一开始就准确知道啥时候能结束，软件啥时候做结束了，那么从开发到现在就是这个软件项目需要的schedule”。

虽然上面这句话初一听起来觉得有些不可思议（感觉是软件项目的开发时间不能精确预估，oh my god,这是老板板最不愿意听到的一个结论），但是确实说明一个问题：实际的软件项目开发schedule在一开始很难做到精确的估计（虽然这是老板们或是高层决策者最关心的一个问题）。本节的目的也正是对该问题进行一些初探。

通常讲，一个项目（包括软件开发项目）所需的开发时间通过对项目总的工作量评估除以参与项目的人力数就能很简单的评估出来（这也正是目前大多数软件项目管理者采用的方法），如以下公式所示：

从上面关于软件项目开发周期的公式看，这个是很容易评估的呀！！！项目的总工作量就是先通过对整个项目进行模块分解，分别计算出各个子模块的开发工作量然后简单求和；项目人力数这个更容易了，直接给出开发团队中可用并且能够部署到这个项目的人数就OK啦。好吧，我们再把这个公式写的具体些：

从上面公式看，只要我们队项目各个子模块的工作量评估准确了，用比较准确的“人月”数量表示出来，项目的软件开发周期就能够准确的估算出来了，So Easy!!!..........。等等，对这个公式突然想到好几个问题需要澄清：

1. 项目需求变更带来的项目额外工作量的问题；

   问： 如果项目开发过程中项目某些需求变更了，这个项目总工作量是不是就要变化了啊?  

   回答：是的，如果项目在开发过程中遇到项目需求变化（通常情况都会不同程度存在），这部分是会带来额外的项目工作量的。

   问： 那这个因为可能的项目需求变更所带来的额外项目工作量指标能不能在项目前期做到精确评估呀?

   回答：这个.......。一种办法是尽可能的产品需求一次到位（哎，好像这个在实际工作中可能性也不大啊）；另一种办法是将强软件的设计，提高软件的可扩展性（软件重构理论，OCP等XXXX设计原则，XXX设计模式，还有XXXXX......）。尽可能的做到让产品需求变更导致对现有软件代码的更改最小，从而降低因为产品需求变更给项目增加额外的工作量。

2. 人力数的衡量标准问题；

   问： 对于工作量用“人月”这个单位表示，这个“人月”衡量的标准是什么呀? 比如一个清华北大工作10-20年的一位工程师是一个人力，一个从3类学校毕业工作2-3年的工程师也是一个人力；他们之间的能力明显是不一样的呀？

   回答： 好吧，那我们给出的是项目人力数是一个评估出来的平均人力数字（根据人力个体差异间进行一个能力平均折算）。比如，个人技术能力强，工作时间长些的工程师可能折算几个人力，技术能力差些的人可能折算成0.XX个人力。

  问： 那这个平均人力衡量的标准是什么呀？比如：一个清华毕业工作好些年的工程师在大公司的级别可能还是普通工程师（笔者曾今在大公司工作过的一家公司，一位汉城大学毕业生努力工作了7年的工程师在一家大公司还是Assistant Engineer级别），而有些一般院校工作了3-4年的毕业生在小公司可能已经是高级工程师级别了。

  回答： 是的，这个人力数是根据每个公司有具体衡量标准，它是不能跨团队和公司使用的一个标准。因此评估出来的项目总工作量是一个相对于具体团队或公司的一个平均人力水平的一个衡量标准值；

  问： 如果一个因为某些因素（和女朋友吵架了，身体状况改变了，对工作有思想情绪了........）而影响了他短期工作效率，这个是不是对人力评估也是有影响的呀?这个又怎么提前预估呢?

  回答：这个..............。哎，这个问题确实会对人力数评估有影响。对这个问题的解决办法和预估，哎，那这就涉及开发团队成员人的沟通和管理，这个还真有些不好度量了...........。

  问： 如果还有其他一些XXXX........因素.............,导致项目XXXXXX......

  回答： 哎，别问了，看来需要对上面这个软件项目开发周期的公式需要进行一些修正....................。

 

通过初步的问了几个问题，这个软件项目开发周期评估公式好像应该修正成下面这个才能更客观的对其进行描述：

其中，在上面公式中，开发人力因子涉及开发人员能力、状态的度量标准。同时该因子还影响了模块工作量衡量准确度因子以及需求变更因子。

由于软件项目开发周期时间同时新增加了3个变量因子，使得看起来很简单的项目开发周期预估变得似乎不是那么简单了。那么该怎么样解决和控制这些可变因素，给老板们一个满意的交代呢? 嘿嘿，那么请看下回分解。