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

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

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

方案
之前提到了在时间的角度上，从技术和商业层面上的架构设计，下面看看横向的架构设计。

方案1：开发人员全体参与架构设计

敏捷开发整体上是一个崇尚“跨职能”的管理方法，开发和测试融合（所以才有很多类似自动化测试、单元测试、持续集成这些需要开发人员强参与的测试活动），开发与产品融合（开发人员要参与客户价值分析）等等，所以在架构设计与编码这两块，也不会分得很开，不能有人专门做架构，另外一些人专门编写代码。

一方面，“架构设计”一旦变成一个文档，就要被写，被读，效率不说，中间难保不发生歧义，因此做架构的人和写代码的人在一定程度上融合一下，能大量减少不必要的架构设计，尤其是某些细节。

二方面，文档或设计本身不是工作产品，在上面投入太多的工作量，极有可能是浪费而非保障。

当然问题是：哪些人有能力做架构？

这个问题如果换成：哪些人可以开一家新的世界500强企业？答案是“大学在校生”（IT界最近的世界500强多数都是在大学里边成立的）。所以同样是这些人，一样能做架构，只是看怎么做了。

方案2：用师徒团队搭建全民架构团队

如果没有专门的架构人员和编码人员，那么最好的结构就是师傅们做架构，同组的徒弟们将其实现为编码。

“这不也是分工吗？”是的，但是由于师傅们与大家密切合作，所以他很快就会把架构能力传递到徒弟手中，也会逐渐找到一些帮助自己做架构的徒弟，从而让自己能腾出手来做更大范围或更高层次的架构。

由于师傅要为全组的成败负责，所以这种传授过程是由衷的，中间没有什么可以扯皮的。（关于这种机制如何运作如果有疑问，请参考“松结对编程系列”）

方案3：商务人员参与架构

一个产品中有三样东西是核心：商业模式，业务架构，技术架构。

其中业务架构是核心，商业模式是从外界观察到的业务架构，而技术架构是从技术角度看到的业务架构。怎么讲呢？请看案例。

案例
比如360这个软件，它的技术架构到底是什么？

刚开始，看上去是个单机版的杀毒软件；后来呢，变成了一个云查杀；再往后，出现了浏览器；又弄了一些五花八门的网络功能，甚至包括聊天……

如果单独从技术的角度看，很难把一个单机版的杀毒软件重构成聊天软件，除非在早期就有人想到这个软件日后要用来聊天。谁会在早期知道呢？业务人员。

业务人员能“预知”未来，所以就不要让开发人员蒙在鼓里，而是提前做好技术准备和储备，架构的变迁就顺理成章。

分析
实际上无论质量、进度、成本、架构、客户价值、赚钱……这些，都应该是“全民”的，至少是尽量全民的。

否则，自然就会有人沉迷于自己负责的那一部分，而将其他的置于自己可以抱怨、对抗的另外一个部门，很难把整个事情做好（有我）。

有一家企业在面试等待区会故意放置一个扔在中间的扫把，看哪个面试者在进入的时候会将其扶起来。很难说我们是否会需要一个有心把扫把扶起来的程序员，但是我们的确需要一个能帮助开发组做好架构的业务人员，也需要一个能帮助架构师写好架构的程序员，还需要能帮助程序员把架构实现出来的架构师……