问题
总体架构设计在什么时机进行？是每个迭代做还是先做完再迭代？
这是少数几个被提到的技术问题。在两天的培训课程之后，最后剩下的纯的技术问题一般只占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. 敏捷地架构设计
每种产品的架构设计方法各不相同，如果把上面“敏捷的架构设计”理解成为敏捷开发，那么军工、航空、银行这些项目，多半就不适合敏捷开发了。
但如果说一切产品的架构设计，都应该“敏捷地”进行——就是不拘泥于形式，及不追求大而全，也不追求小二瞧，而是要放下这些包袱，轻松地分析这个产品到底应该怎样做架构设计——则基本上防止四海皆准则。
本篇还有一个下篇，会讲到“全民皆架构”，又会回到人的管理中来。
来源：oschina
链接：https://my.oschina.net/u/109139/blog/42245