【IT168 技术文章】

    螺旋、迭代、增量，不同的名词代表了同样的含义－分阶段开发软件。众多的方法学都采用了这种思路设计软件过程。但是在实践中，更多时候，分阶段开发软件带来的是痛苦。看来，我们常常被书中优美的叙述所迷惑，却没有真正想过实施中的难题。那么，如何管理分阶段的软件开发呢？如何应对现实中的难题呢？

    考核和评估之别 在绩效管理中，有两个名词：考核和评估，分别表示了绩效考核和绩效评估两种绩效管理方式。这两者有什么区别呢？

    我们说考核是一种制度，而评估是一个过程。怎么理解呢？很多的公司都有绩效考核的制度，这个制度一般是在年底的时候，对员工今年的工作做一个评定。考核是一个点。但是评估不一样，评估是针对某一段时间中员工工作中的不足之处，需要改进之处进行评价。不论是考核还是评估，它们两者虽然都是为了达到评价并改进员工行为的目的而设计的，但是做法是不同的。考核针对过去的事情进行评定，容易实现，但是效果不佳，因为时间一长，大家可能忘记了以前的事情，而要公平的对过去一年的表现做一个评定也不是一件容易的事，评估则不同，评估是不断进行的，针对刚刚发生的事情做出评价，并找到改进方法。就好像我们在第一章中举的外卖店的例子，不断地对过程进行分析和改进，这就是一种评估。评估的效果不错，但难以实现。

    软件开发中的考核和评估
    
    这一思路在软件过程中，直接表现为里程碑和迭代的思路。我们可以想想，里程碑是不是一种制度。在需求结束的时候，我们需要需求规约文档，风险列表等等一系列的文档，在设计结束的时候，我们也需要另一些文档。这种处理方式就是考核的思路。但是很多时候，这种考核起到的作用是有局限性的：

    工件的设计原本是为了辅助生成最终的代码，但是往往会演变成为了通过里程碑而设计；

    里程碑的设计不能够完全捕获所有的问题，部分的风险被隐藏了；

    难以对工作量和工作价值进行评估；

    里程碑揭露问题的时间要远远落后于问题出现的时间；
   
    这里对里程碑的方式做一些分析。我们对问题的理解往往是逐步深入的。在项目一开始的时候，业务和技术上都存在问题，存在不确定性和风险，这时候往往是最需要评估和验证的。但是里程碑方式往往要求必须深入的分析需求，很多的问题并没有得以解决，而是被悄悄的有意或无意的掩盖了。需求毕竟不是软件，它是一个不同人具有不同理解的模型，这时候，项目中各个角色对它的理解都不相同，但是这并不影响他们做出一致的决定－通过需求里程碑。问题到了设计阶段依然存在，这时候需求阶段隐藏的一些问题开始出现，导致我们不得不补充一些工作量。但是所有的问题也没有得到解决，依然存在未知的风险。那么风险到了什么时候才会暴露出来呢？最乐观的情况是在编码时期发现，最悲观的情况是在交付期发现。我们把这种过程称为固化考核过程。

    问题在哪里？除了软件本身，模型也好、文档也罢，都不能够代替最后的代码。在精益原则中，我们说，必须消除浪费。当我们在开发工件的时候，我们的浪费行为已经或多或少的出现了。

    与固化考核过程相对的，我们认为存在另一种动态评估过程。里程碑或是检查点并不是不重要。但是我们需要转换思路，来将里程碑的实践做的更好一些。我们上面提到说里程碑方式最大问题就在于一定要等到问题都积累起来了才解决问题，而这个时候往往已经错过了解决问题的非常好的时机。而动态评估过程的含义就是在过程进行中不断的发现并解决问题，而不是等到问题累积到一定程度才批量解决。过程随着环境的变化不断的调整，以适应变化性和不确定性的需要。而里程碑实践重在提供一个复审的机会，能够从一个较高的层次上来评价软件。

    这种过程就是分阶段开发软件的思路，我们也可以称呼它为迭代、螺旋、增量，都没有关系。关键在于，我们需要不断的发现导致客户不满意的问题，发现改进接电话的方法，发现改进做菜的方法，发现更快送货的方法。