SpecDD 讲座归来有感 - 1

前段时间在京仪大酒店参加2012敏捷大会，其中听了 TechExcel CEO 周铁人博士关于SpecDD一个讲座，深有所感，所以上来发表一下听后感。

 

之前对于敏捷开发，我还是比较喜欢Scrum的方式，不过Scrum的方式大家也知道，虽然很敏捷，但是总是有些缺陷的，周博士那天也提到下面这几个点，我比较同意。

 

1.      缺少对多团队参与的大型项目的指导框架。 （我的想法：敏捷一般是针对小团队，但是类似大公司，比如微软、Sony这样子的，需要共同开发一个大的软件，比如Windows 8，能不能运用敏捷，怎么去运用敏捷，这种问题在现有的敏捷体系下很难回答出来）

 

2.      缺少开发和QA测试的集成模型。（我的想法：现有的敏捷中对于测试这块的确重视不多，甚至有人认为开发做得好完全就不必测试了，其实真的开发做的100% Bug Free，这个世界上的确不用测试了，但是能吗？另外，开发一般只考虑正在做的这个功能是否能够正常工作，但是对于多个功能之间的调用之类的测试就不会考虑很多）

 

3.      无法支持需求驱动下完整的可追溯性。（我的想法：Scrum不推荐写文档啊，提Bug啊，最好所有事情，都能面对面交流就行了，但是实际情况呢？面对面的交流，也许你今天能记得，但是明天可能忘记；如果只有一个Bug要修，你记得很清楚，但是如果是100个Bug要修呢，你能记得很清楚吗？如果你手下有N个开发，你怎么去记得哪个功能分配给谁在做呢？）

 

4.      整个团队完全致力于项目的开发是基本前提。一旦开发团队的方向出现变化，会导致项目的崩溃。（我的想法：其实这个现象已经在很多开展敏捷开发的团队中见到，都是一开始满意欢喜想上马敏捷，最后却崩溃了。因为“专家”所谓的敏捷固定过程中，人人都要主动交流啊，自领任务啊，估算任务等这种很理想的状态并不是所有公司，所有人都能实现的，一旦当偏离值出现的时候，也就是这个项目崩溃的开始。）

 

5.      一旦使用敏捷方法失败，不但时间会被浪费，团队人员也会出现松动。当相关人员离职后，整个过程的经验积累也无法得以保存。（我的想法：同第三点）

 

很多公司虽然在搞敏捷，其实都是被很多所谓的“专家”搞混了，以为敏捷会有一个固定的模式，其实这个是不对的，敏捷只是一种指导思想，软件的生命周期不会因为敏捷而发生变化，还是会有需求，还是会有开发，也还是会有测试，在这个的基础上，怎么去让这些过程能够衔接得很好，最后得到一个质量好的产品，才是最重要的。显然，敏捷是其中的一个方法，但是它也不是万能的，因为不同的产品会有不同的开发模式，比如，银行软件可能就不太适合敏捷。

 

 

 

周博士的SpecDD，在我看来，其实是对于Scrum的一个升级。很明显，周博士这么多年在一个软件公司的工作经验，让他能看到现有的敏捷体系中的很多不足之处，所以提出这个SpecDD概念。

 

 

 

 

这个模型中，大家可以看到Scrum的精神思想其实也完全体现得淋漓尽致，这个也就是为什么我说SpecDD其实可以看作Scrum的一个升级版一样。

 

在这个模型中，我最有感受的是测试这块，所以下面我就主要说说这块，其他部分那天会议其实大家也听到与讨论过了，所以今天就暂时不谈了。 

 

（未完待续）