敏捷和 CMM（摘录）

下面我简单介绍一下敏捷式开发的原理。提到敏捷式的开发，大概在60年代的时
候，软件开发是有计划性的，基本是写出来，谁也不知道什么时候能交付，大概在
60年代的时候，在美国召开一次会议上头一次提出来，软件工程学的概念，传统工
程学通常是把项目分成三步或者四步，先把需求确立起来，进行设计构建。应用到
软件里是开始先由分析人员对需求进行分析，然后设计，架构师把整体的东西设计
出来，再确定下来交给编程的团队，编程的团队把需求文章拿过来，照着这个再弄
出来。所有的这些东西是由不同的人在不同的时间完成的。

这种开发计划性非常强，因为你知道什么人在什么时候做什么事情。但是它会带来
很多问题，主要是软件开发和传统的建筑工程学有很多不同的地方，最主要的是客
户需求是不断变化的。首先是商业软件，市场本身是在不断变化，客户需求也在不
断变化，客户不知道自己需要什么，过两天市场一变，他的需求也变了。客户本身
他脑子里并不是很清楚他自己需要什么，他只有自己最后真正看到这个软件了，才
有这个想法，这个东西是我确实需要的，但是使用起来，发现不是这样的，我想用
另外一个方式，这就给工程学带来了很大的困难。

从工程学来讲，不管需求也好、构建也好，在开始的时候改动设计非常容易，但是
你如果在投入生产的时候，再进行改动，成本是非常高的。所以工程学里一个核心
的概念，变化是最可怕的一件事情，从设计角度也好、分析的角度也好，不管怎
么，不要变化，这样就使成本增加。

如果我们把需求确定下来以后，按照需求一步步做，设计、开发、测试、部署，任
何客户提出任何需求，我都不管他。这种方法，作为一个综合客户来说，最后拿到
东西，发现其实这是一年以前或者本年以前的东西，他的满意度可想而知。

如果他满意了，又要花半年或者一年时间，重新对这个设计分析，还是这个结果，
客户得到的永远是他半年或者一年以前想到的东西。

敏捷式开发最核心的东西是它对变化采取的是适应性的态度，不是排斥性的。我们
作为开发方法来讲，不应该避免它的变化，而应该想到使变化成为轻而易举的事
情。敏捷式的开发针对一小部分进行设计测试，对每一个循环时间非常短，软件从
小到大，从很小的一点到不断的增加扩大，而且增长的过程中是对软件不断修改的
过程，修改不是可怕的事情，而是必须做的一件事情。

客户可以对哪些功能开发给予优先，开发的程度可以根据市场来调整，他说这些东
西不想要了，可以调整。

从另外一个角度，开发商有需求分析、设计、编辑代码测试等等，最后交给客户，
敏捷式开发在初期也会做高层的需求分析，或者架构设计，这个设计非常粗略，非
常高层，针对一小部分高层设计开发，每一次一旦得到的可以发布的软件，一步步
做下去，最后达到客户满意为止。最大的是客户不用等到做完的时候，而是在每一
个环节都可以让客户来测试使用。软件开发的过程控制起来完全在客户手里，由他
决定开发的方向往哪里走。因为他是一个软件开发的关键人。

从软件投入使用的角度讲，产品上市的时间是非常重要的。尤其是竞争非常强的行
业里，你如果一个产品提前上市的话，对一个产品的作用是不可忽略的。从架构来
讲，它对体系架构的应征可以极大的减少风险。

迭代式开发也并不是没有尝试过，但是修改成分太高。我们现在可以进行迭代式开
发有很多原因，最主要是我们有修改的代码OO技术，瘦身式的管理JIT带来的新概
念，可以通过快速的反馈来提高质量。通过设计和编程可以使编程对设计形成反馈。

在开发的过程中，修改成本的降低是核心的。你可以任何时候对系统做任何的修
改。敏捷式是不排除设计的，只不过设计不是由架构师单独想出来的，而是这些设
计非常简单，而是在开发过程中，每一次开发都要进行设计，设计开发不断循环，
技术从简单到复杂，最后逐渐形成一个完整的过程。这个过程不是非常容易演示，
有很多技术需要支持这种设备的改进。最重要是测试、开发、重购和自动化。测试
扮演着非常重要的角色，最简单说，对任何一个功能，开发过程中，作为一个程序
员，既要写出测试程序，也要写出功能程序，他写出这个测试程序，先怎么样测
试，然后这个时候再写功能程序。

很简单一点，他确实减少了很多的浪费，因为写的过程中，对需求的考虑通常会使程序员写出很多没有必要的东西，因为这些测试是可以不断的重复执行的。

这些功能程序是不断增加的。最后到你系统开发快结束的时候，你可以很随便的运行一下所有的测试程序。这就使得我们现在提到这个概念就是重购的概念。重购是通过技术修改进行设计，它不是说想把三层的架构改成四层的架构，而是小范围的改动，使得程序保持灵活性和非常干净的基础上，第一
它使你的细节设计提高，第二使你的大幅度改动变成轻而易举的事情，使设计是在
不断的改进过程中也成为可能。

敏捷开发还有一个很大的特点就是它是以人为本，而不是以方法为本的。我们的软
件开发是脑力劳动，而不是简单的工作。如果你设计出一套方法来，不管什么方
法，让每个人去适应的方法，最后开发效应反而不如你组建一个具有进取心的团
队，这个团队通常情况下是先选择一种方法，细节也一样，在开发过程中，不断对
方法反思，直到达到这个团队的最高开发效应为止。

敏捷开发项目结束的时候和开始的时候方法已经不一样了，这个方法是团队使用的
方法，而且方法的改进不是一个项目经理或者管理人员的事情，而是所有人的工作。

敏捷开发我再做一次定义，敏捷开发不是一个单一的方法，包括编程等。这些方法
的开发创始人他们在一起开了一个重要的会议，提出了敏捷开发的概念，敏捷开
发，只要你的方法跟它相似的开发哲学，这些开发哲学叫做敏捷式开发原理。

第一就是个人和交互要远远比流程和工具重要，第二能工作的软件超越应尽的义务。

通过在中国开展业务差不多四、五个月时间，我们发现中国市场有它自己的特点。
很多不同的软件在使用，而且它们的生命周期通常很短。一些定制软件很少有第
二、第三个版本以上的。最主要的原因是因为它的维护成本太高。所以与其对这个
软件维护，还不如买一个新的软件。

你如果采用敏捷式开发，你的产品上市时间可以达到提高，第二客户满意度得到提
高。很多公司不会抱怨，我确实告诉你这么做的，你也不会做的这么差。如果一个
软件的交付不是真正的成功，而是一个客户满意是真正的成功。