之前对于敏捷开发，我还是比较喜欢Scrum的方式，不过Scrum的方式大家也知道，虽然很敏捷，但是总是有些缺陷的，如下：
1、缺少对多团队参与的大型项目的指导框架。（我的想法：敏捷一般是针对小团队，但是类似大公司，比如微软、Sony这样子的，需要共同开发一个大的软件，比如Windows 8，能不能运用敏捷，怎么去运用敏捷，这种问题在现有的敏捷体系下很难回答出来）
2、缺少开发和QA测试的集成模型。（我的想法：现有的敏捷中对于测试这块的确重视不多，甚至有人认为开发做得好完全就不必测试了，其实真的开发做的100% Bug Free，这个世界上的确不用测试了，但是能吗？另外，开发一般只考虑正在做的这个功能是否能够正常工作，但是对于多个功能之间的调用之类的测试就不会考虑很多）
3、无法支持需求驱动下完整的可追溯性。（我的想法：Scrum不推荐写文档啊，提Bug啊，最好所有事情，都能面对面交流就行了，但是实际情况呢？面对面的交流，也许你今天能记得，但是明天可能忘记；如果只有一个Bug要修，你记得很清楚，但是如果是100个Bug要修呢，你能记得很清楚吗？如果你手下有N个开发，你怎么去记得哪个功能分配给谁在做呢？）
4、整个团队完全致力于项目的开发是基本前提。一旦开发团队的方向出现变化，会导致项目的崩溃。（我的想法：其实这个现象已经在很多开展敏捷开发的团队中见到，都是一开始满意欢喜想上马敏捷，最后却崩溃了。因为“专家”所谓的敏捷固定过程中，人人都要主动交流啊，自领任务啊，估算任务等这种很理想的状态并不是所有公司，所有人都能实现的，一旦当偏离值出现的时候，也就是这个项目崩溃的开始。）
5、一旦使用敏捷方法失败，不但时间会被浪费，团队人员也会出现松动。当相关人员离职后，整个过程的经验积累也无法得以保存。（我的想法：同第三点）
很多公司虽然在搞敏捷，其实都是被很多所谓的“专家”搞混了，以为敏捷会有一个固定的模式，其实这个是不对的，敏捷只是一种指导思想，软件的生命周期不会因为敏捷而发生变化，还是会有需求，还是会有开发，也还是会有测试，在这个的基础上，怎么去让这些过程能够衔接得很好，最后得到一个质量好的产品，才是最重要的。显然，敏捷是其中的一个方法，但是它也不是万能的，因为不同的产品会有不同的开发模式，比如，银行软件可能就不太适合敏捷。
在我看来，SpecDD其实是对于Scrum的一个升级。
这个模型中，大家可以看到Scrum的精神思想其实也完全体现得淋漓尽致，这个也就是为什么我说SpecDD其实可以看作Scrum的一个升级版一样。
在这个模型中，我最有感受的是测试这块，所以下面我就主要说说这块，今天就暂时不谈了。
（未完待续）