`

SpecDD 讲座归来有感 - 1

 
阅读更多

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

 

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

 

 



 

 

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

 

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

 

(未完待续) 

  

  

 

 

 

 

 

 

 

 

  • 大小: 74.3 KB
分享到:
评论
发表评论

文章已被作者锁定,不允许评论。

相关推荐

Global site tag (gtag.js) - Google Analytics