问题

总体架构设计在什么时机进行？是每个迭代做还是先做完再迭代？

这是少数几个被提到的技术问题。在两天的培训课程之后，最后剩下的纯的技术问题一般只占1/5都不到，多数都是管理问题，而管理问题中，又基本上是人的管理问题，这也说明了在“心法人事物”中，心总是第一位的。

方案

最早想写成方案1、方案2，但感觉有点像说是有不同的很多并行方法，之后又改成步骤1、步骤2，又有点把事线性化了。

现在干脆写回成方案123吧，总之越往后的越终极一些，也越难以一步到位。

方案1：Sprint0

对于长期的项目，常常引入“Sprint0”的概念。

Sprint0就是在开始不断开发功能的众多Sprint迭代前，先做一个准备工作，大约持续一个迭代的周期。

准备工作的内容五花八门，从团队组成，项目范围，到这里说的架构设计。有些团队每过一段，尤其在发布了重要的版本后，都会重新开一个Sprint0，来分析下一个版本的架构设计。

这样就可能出现几种不同的迭代变形，最左边的是最轻量级的（周期短的、架构不重要的），最右边的则相反。

实际上为了解决总体集成和发布问题，还经常采用SprintN+1的方法。

方案2：制定迭代计划。

“架构想不全”这个问题，在于不知道未来要做什么，如果有一个相对清晰的迭代计划，就会驱动架构的设计走向正确的方向。

正确的方向的重要性远远超过“详尽的设计”，只要架构能支撑未来的迭代计划，即使不太详尽，也还可以每个阶段细化。但如果方向是错误的，只会“精确地走向错误的地方”。

有了迭代计划后还有一个好处是架构设计可以分阶段开发了。由于能预见未来发生的事情，因此也就能在关键接口处做好准备，而放心地把某些架构留待几个月后再做。

方案3：补文档。

本人正在用的一个方法。

当设计一个交互性很强的产品时（比如游戏、手机软件），有很多判断来自于面对最终产品时的感受，而不是数据库结构这类东西。所以有时候不得不先把架构放在心里（不是没有），把产品做出个雏形，获得感受后决定是否如此，还是更改设计。

这种方法常常伴随巨大的返工（原因倒不是因为不做架构造成的，做了架构，返工会更多，因为连架构也得返工；不做架构反而减少了返工量），但是对于创新性产品而言，返工不返工不是评价成败的主要因素。

等最终结果得到认可后，会在管理系统中补充被确认的功能的架构。

由于产品都做出来了，所以文字中可以引用很多确定性的数据库表乃至代码等，补文档的过程异常轻松。

案例

无。

分析

1. 敏捷的架构设计

之前智慧敏捷中曾经提到过一个问题“敏捷开发为什么不提倡做架构设计”。

在变化决定一切的领域（比如互联网），提前做一个详尽的架构的确不是一个好事情，一方面时间不运行，另一方面等架构实现了，业务也发生了变化。

因此在这些领域工作，要尝试把架构设计也迭代化，比如方案1表中最右边的不断迭代的Sprint0；另外一个概念则是简单性（Simplicity，maxmize the work not done），简单说就是能不做的事情就推迟做，比如“三个月内不会发布的功能的架构设计”就应该三个月后做。

要做好这些事情，一个前提是不能逃避工作，也就是对现在的我与未来维护产品的人有分别心，“反正我暂时用不到，管他日后谁头疼没有架构设计呢”，否则就极度危险。

2. 敏捷地架构设计

每种产品的架构设计方法各不相同，如果把上面“敏捷的架构设计”理解成为敏捷开发，那么军工、航空、银行这些项目，多半就不适合敏捷开发了。

但如果说一切产品的架构设计，都应该“敏捷地”进行——就是不拘泥于形式，及不追求大而全，也不追求小二瞧，而是要放下这些包袱，轻松地分析这个产品到底应该怎样做架构设计——则基本上防止四海皆准则。

本篇还有一个下篇，会讲到“全民皆架构”，又会回到人的管理中来。