敏捷开发一千零一问系列之九：整体架构什么时机进行？（上）

这是敏捷开发一千零一问系列的第九篇。（之一，之二，之三，问题总目录）

问题

整体架构设计在什么时机进行？是每一个迭代作仍是先作完再迭代？

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

方案

最先想写成方案一、方案2，但感受有点像说是有不一样的不少并行方法，以后又改为步骤一、步骤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. 敏捷地架构设计

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

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

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