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

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

问题

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

方案

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

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

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

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

二方面，文档或设计自己不是工做产品，在上面投入太多的工做量，极有多是浪费而非保障。

固然问题是：哪些人有能力作架构？

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

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

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

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

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

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

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

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

案例

好比360这个软件，它的技术架构究竟是什么？

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

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

业务人员能“预知”将来，因此就不要让开发人员蒙在鼓里，而是提早作好技术准备和储备，架构的变迁就瓜熟蒂落。

分析

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

不然，天然就会有人沉迷于本身负责的那一部分，而将其余的置于本身能够抱怨、对抗的另一个部门，很难把整个事情作好（有我）。

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