谁说敏捷就是无设计?

总是能听到这样的说法:“搞敏捷,就是不要设计,不要文档,需求来了,啥也不想就开始写代码就对了。”

敏捷项目通常确实不需要像传统项目团队那样——先做需求分析,再做概要设计,顶层设计,详细设计,之后才是功能开发,集成测试,系统测试,回归测试,验收测试,等等——通常来说,敏捷团队会在需求没有完全确定的情况下就开始开发,随着持续不断的给客户演示原型版本,获取反馈,不断完善,一步一步的让需求更加清晰明了。这么看来,好像确实没有提到“设计”这么一步。

但事实上,敏捷并不提倡刚拿到需求就开始写代码。相反,我们希望拿到故事的开发人员能够讲故事拆分成更小的任务,根据故事的验收准则(AC),写出实例化的测试用例,然后对这些用例进行编程——也就是所谓的测试驱动开发(TDD)的思想。有些人将TDD最后一个D理解成Design,即设计,也就是测试驱动设计。瞧瞧,我们终于看到“设计”这个词了。

从拿到需求,带正式开始编码,这段时间,对于传统团队,是在做架构设计(概要/顶层/详细);而对于敏捷团队,其实也是在做设计,不过不是软件的架构设计,而是在做需求拆分,或者说是用例设计。通过实现一个个清晰明了的用例,软件的功能逐渐完善,架构也随之不断演进。

每一种架构,都有其局限性,总有其过时的一天;而需求,可以与时俱进。架构的改变,总是伤筋动骨;需求的变化,却可以日积月累。因此:

用演进式的架构去适应每一条已知需求,胜过企图用完美的架构去适应未知的变化。

反对敏捷的人,经常会这样说:“以前我们照着详细设计文档编程就可以了,搞了敏捷,还要自己拆分故事,写用例,我不会,也不想做。”是的,没错,开发人员要自己分析故事,拆分任务,写出用例,实现功能。这,有什么不好呢?

瀑布式开发的团队,开发人员和测试人员都觉得自己最苦逼,因为他们没有话语权,而需求分析人员和架构设计人员每天写写文档,画画PPT,就决定着开发和测试要干些什么事。所以开发和测试都削尖了脑袋要成为“不用写代码的那类人”。

现在真让你做设计了,你又不会了,那请问,你要闹哪样呢?