下面我简单介绍一下敏捷式开发的原理。提到敏捷式的开发，大概在60年代的时候，软件开发是有计划性的，基本是写出来，谁也不知道什么时候能交付，大概在60年代的时候，在美国召开一次会议上头一次提出来，软件工程学的概念，传统工程学通常是把项目分成三步或者四步，先把需求确立起来，进行设计构建。应用到软件里是开始先由分析人员对需求进行分析，然后设计，架构师把整体的东西设计出来，再确定下来交给编程的团队，编程的团队把需求文章拿过来，照着这个再弄出来。所有的这些东西是由不同的人在不同的时间完成的。
这种开发计划性非常强，因为你知道什么人在什么时候做什么事情。但是它会带来很多问题，主要是软件开发和传统的建筑工程学有很多不同的地方，最主要的是客户需求是不断变化的。首先是商业软件，市场本身是在不断变化，客户需求也在不断变化，客户不知道自己需要什么，过两天市场一变，他的需求也变了。客户本身他脑子里并不是很清楚他自己需要什么，他只有自己最后真正看到这个软件了，才有这个想法，这个东西是我确实需要的，但是使用起来，发现不是这样的，我想用另外一个方式，这就给工程学带来了很大的困难。
从工程学来讲，不管需求也好、构建也好，在开始的时候改动设计非常容易，但是你如果在投入生产的时候，再进行改动，成本是非常高的。所以工程学里一个核心的概念，变化是最可怕的一件事情，从设计角度也好、分析的角度也好，不管怎么，不要变化，这样就使成本增加。
如果我们把需求确定下来以后，按照需求一步步做，设计、开发、测试、部署，任何客户提出任何需求，我都不管他。这种方法，作为一个综合客户来说，最后拿到东西，发现其实这是一年以前或者本年以前的东西，他的满意度可想而知。
如果他满意了，又要花半年或者一年时间，重新对这个设计分析，还是这个结果，客户得到的永远是他半年或者一年以前想到的东西。
敏捷式开发最核心的东西是它对变化采取的是适应性的态度，不是排斥性的。我们作为开发方法来讲，不应该避免它的变化，而应该想到使变化成为轻而易举的事情。敏捷式的开发针对一小部分进行设计测试，对每一个循环时间非常短，软件从小到大，从很小的一点到不断的增加扩大，而且增长的过程中是对软件不断修改的过程，修改不是可怕的事情，而是必须做的一件事情。
客户可以对哪些功能开发给予优先，开发的程度可以根据市场来调整，他说这些东西不想要了，可以调整。
从另外一个角度，开发商有需求分析、设计、编辑代码测试等等，最后交给客户，敏捷式开发在初期也会做高层的需求分析，或者架构设计，这个设计非常粗略，非常高层，针对一小部分高层设计开发，每一次一旦得到的可以发布的软件，一步步做下去，最后达到客户满意为止。最大的是客户不用等到做完的时候，而是在每一个环节都可以让客户来测试使用。软件开发的过程控制起来完全在客户手里，由他决定开发的方向往哪里走。因为他是一个软件开发的关键人。
从软件投入使用的角度讲，产品上市的时间是非常重要的。尤其是竞争非常强的行业里，你如果一个产品提前上市的话，对一个产品的作用是不可忽略的。从架构来讲，它对体系架构的应征可以极大的减少风险。
迭代式开发也并不是没有尝试过，但是修改成分太高。我们现在可以进行迭代式开发有很多原因，最主要是我们有修改的代码OO技术，瘦身式的管理JIT带来的新概念，可以通过快速的反馈来提高质量。通过设计和编程可以使编程对设计形成反馈。
文章来源于领测软件测试网 https://www.ltesting.net/
