IT项目管理中的度量

原作者：人月神话  来源于：新浪博客

人月：项目进度计划老做不准确，每周都要去调计划，不知道项目计划做来还有什么意义？
神话：那你分析了进度计划做不准确的根源了吗？人月

人月：原因有很多，有突发事件影响，有个人效率的差别，但我觉得主要是我们估算数据不准确，这样导致我们在排进度计划的工期和工时出现很大的偏差。
神话：那什么导致估算数据不准确呢？

人月：原来我们项目估算都是专家法，项目有个很有经验的开发负责人，每次都是他进行估算的，数据是比较准备的。但现在这个人离职了，新的人员有没有估算经验，在估算的时候很大细节问题考虑不到，引起我们估算数据偏差很大。
神话：经验始终停留在个人的头脑里面，这种经验无法量化出来为他人采用。人月，你平时没有收集你做的历史版本的规模，工作量和生产率这些数据吗？

人月：收集了，但不知道如何真正去用这些数据啊！
神话：让我们看下下达任务工作量回馈曲线：工作量－》生产率－》软件规模－》功能点，一个历史版本做完后工作量和软件规模如代码行这些数据都可以收集到，这样你很容易得出你们项目的一个平均生产率。

人月：但是我很难在开始估算时候估计软件的代码行数。
神话：这是历史数据的积累不够，当开始估算的时候我们可以采用功能点或软件需求的用例数来作为估算的具体规模。

人月：还有，项目经常返工，一遇到返工就把我的进度计划打乱了，而且返工很影响大家的积极性。
神话：你采用什么方法控制了返工了吗，人月？
人月：有啊，我们通过评审和Review来在项目的早期阶段提前发现缺陷，减少需求的泄露率。
神话：那你怎么来确认的评审和Review的工作量的安排的呢？
人月：我凭经验随便估计的。

神话：这里其实还是度量的问题，你应该对历史版本的缺陷泄露率数据进行收集和分析，当你发现需求到设计的缺陷泄露很高的时候，你就应该在需求的评审和Review上多花时间，而这个时间衡定是跟你返工工作量对比的，只要小于返工的工作量，那这些评审，讨论和Review的工作量安排就是合理的。

人月：神话，我觉得度量的好处就是帮助我们进行项目中的决策，因为任何一项决策都需要依据，用事实来说话。而我们收集的度量数据正好就是充足有力的证据。
神话：是这样的，所以度量对一个项目来说很重要的，度量不仅仅是收集数据，更重要的是分析数据。

人月：但是我还是不是很清楚，比如我收集到数据表明我进度延后了，但我还是不知道如何去分析这个数据？
神话：这就是度量体系的问题，我们的度量指标不是孤立的，每个度量指标之间都有影响和联系。见上面的关联关系图。


神话：当你发现进度延后后需要管理分析工作量，生产率，规模，需求稳定性，返工情况，缺陷泄露的情况，评审的质量等多方面的其它度量数据，才能够真正发现进度延后的根源在哪里。

神话：如进度延后是由于返工工作量增加了，返工工作量增加原因根据缺陷泄露分析发现是需求阶段缺陷泄露率高而并非需求变更多引起的。需求泄露率高是评审质量出问题，而评审质量出问题根源可能是当初评审时间没有留够。

人月：这里我理解了，其实我们做任何事情都是有目的和目标的，不是规程要求我们这样做而去做，而是我们项目存在问题，我们需求去度量来帮助我们决策，从而解决项目的问题。
神话：是的，规程或规范是手段而不是目的，这点一定要搞清楚。

人月：还有一个问题就是我经常收集不到项目中的真实数据，或者收集的数据本身就不准确，如一个工作任务的实际工作量数据。
神话：为何不在项目中推行PSP呢？个体软件过程既可以保证收集到真实可靠的数据，又可以促使每个人能够有意识的去自我改进。

人月：那CMMI的度量过程究竟应该怎样去做呢？有没有具体的流程
神话：源头在自我需求，所以是首先项目有某种需求－》然后指定度量计划-》收集数据-》分析和验证数据-》根据数据进行决策。