这是敏捷开发一千零一问系列的第九篇。(在这里提问,之一,之二,之三,问题总目录)

问题

总体架构设计在什么时机进行?是每个迭代做还是先做完再迭代?
这是少数几个被提到的技术问题。在两天的培训课程之后,最后剩下的纯的技术问题一般只占1/5都不到,多数都是管理问题,而管理问题中,又基本上是人的管理问题,这也说明了在“心法人事物”中,心总是第一位的。

方案

最早想写成方案1、方案2,但感觉有点像说是有不同的很多并行方法,之后又改成步骤1、步骤2,又有点把事线性化了。
现在干脆写回成方案123吧,总之越往后的越终极一些,也越难以一步到位。
方案1:Sprint0
对于长期的项目,常常引入“Sprint0”的概念。
Sprint0就是在开始不断开发功能的众多Sprint迭代前,先做一个准备工作,大约持续一个迭代的周期。
准备工作的内容五花八门,从团队组成,项目范围,到这里说的架构设计。有些团队每过一段,尤其在发布了重要的版本后,都会重新开一个Sprint0,来分析下一个版本的架构设计。
这样就可能出现几种不同的迭代变形,最左边的是最轻量级的(周期短的、架构不重要的),最右边的则相反。
 
Sprint1
Sprint2
...
SprintN
 
Sprint0
Sprint1
Sprint2
...
SprintN
...
Sprint0
Sprint1
Sprint2
...
SprintN
Sprint0
Sprint1
....
SprintN
...
 
 
 
 
实际上为了解决总体集成和发布问题,还经常采用SprintN+1的方法。
方案2:制定迭代计划。
“架构想不全”这个问题,在于不知道未来要做什么,如果有一个相对清晰的迭代计划,就会驱动架构的设计走向正确的方向。
正确的方向的重要性远远超过“详尽的设计”,只要架构能支撑未来的迭代计划,即使不太详尽,也还可以每个阶段细化。但如果方向是错误的,只会“精确地走向错误的地方”。
有了迭代计划后还有一个好处是架构设计可以分阶段开发了。由于能预见未来发生的事情,因此也就能在关键接口处做好准备,而放心地把某些架构留待几个月后再做。
方案3:补文档。
本人正在用的一个方法。
当设计一个交互性很强的产品时(比如游戏、手机软件),有很多判断来自于面对最终产品时的感受,而不是数据库结构这类东西。所以有时候不得不先把架构放在心里(不是没有),把产品做出个雏形,获得感受后决定是否如此,还是更改设计。
这种方法常常伴随巨大的返工(原因倒不是因为不做架构造成的,做了架构,返工会更多,因为连架构也得返工;不做架构反而减少了返工量),但是对于创新性产品而言,返工不返工不是评价成败的主要因素。
等最终结果得到认可后,会在管理系统中补充被确认的功能的架构。
由于产品都做出来了,所以文字中可以引用很多确定性的数据库表乃至代码等,补文档的过程异常轻松。

案例

无。

分析

1. 敏捷的架构设计
之前智慧敏捷中曾经提到过一个问题“敏捷开发为什么不提倡做架构设计”。
在变化决定一切的领域(比如互联网),提前做一个详尽的架构的确不是一个好事情,一方面时间不运行,另一方面等架构实现了,业务也发生了变化。
因此在这些领域工作,要尝试把架构设计也迭代化,比如方案1表中最右边的不断迭代的Sprint0;另外一个概念则是简单性(Simplicity,maxmize the work not done),简单说就是能不做的事情就推迟做,比如“三个月内不会发布的功能的架构设计”就应该三个月后做。
要做好这些事情,一个前提是不能逃避工作,也就是对现在的我与未来维护产品的人有分别心,“反正我暂时用不到,管他日后谁头疼没有架构设计呢”,否则就极度危险。
2. 敏捷地架构设计
每种产品的架构设计方法各不相同,如果把上面“敏捷的架构设计”理解成为敏捷开发,那么军工、航空、银行这些项目,多半就不适合敏捷开发了。
但如果说一切产品的架构设计,都应该“敏捷地”进行——就是不拘泥于形式,既不追求大而全,也不追求小而巧,而是要放下这些包袱,轻松地分析这个产品到底应该怎样做架构设计——则基本上放之四海皆准则。
 
本篇还有一个下篇,会讲到“全民皆架构”,又会回到人的管理中来。