敏捷开发一千零一问系列之十:总体架构什么时机进行?(下)
这是敏捷开发一千零一问系列的第十篇。(在这里提问,之一,之二,之三,问题总目录)
问题
总体架构设计在什么时机进行?是每个迭代做还是先做完再迭代?
方案
之前提到了在时间的角度上,从技术和商业层面上的架构设计,下面看看横向的架构设计。
方案1:开发人员全体参与架构设计
敏捷开发整体上是一个崇尚“跨职能”的管理方法,开发和测试融合(所以才有很多类似自动化测试、单元测试、持续集成这些需要开发人员强参与的测试活动),开发与产品融合(开发人员要参与客户价值分析)等等,所以在架构设计与编码这两块,也不会分得很开,不能有人专门做架构,另外一些人专门编写代码。
一方面,“架构设计”一旦变成一个文档,就要被写,被读,效率不说,中间难保不发生歧义,因此做架构的人和写代码的人在一定程度上融合一下,能大量减少不必要的架构设计,尤其是某些细节。
二方面,文档或设计本身不是工作产品,在上面投入太多的工作量,极有可能是浪费而非保障。
当然问题是:哪些人有能力做架构?
这个问题如果换成:哪些人可以开一家新的世界500强企业?答案是“大学在校生”(IT界最近的世界500强多数都是在大学里边成立的)。所以同样是这些人,一样能做架构,只是看怎么做了。
方案2:用师徒团队搭建全民架构团队
如果没有专门的架构人员和编码人员,那么最好的结构就是师傅们做架构,同组的徒弟们将其实现为编码。
“这不也是分工吗?”是的,但是由于师傅们与大家密切合作,所以他很快就会把架构能力传递到徒弟手中,也会逐渐找到一些帮助自己做架构的徒弟,从而让自己能腾出手来做更大范围或更高层次的架构。
由于师傅要为全组的成败负责,所以这种传授过程是由衷的,中间没有什么可以扯皮的。(关于这种机制如何运作如果有疑问,请参考“松结对编程系列”)
方案3:商务人员参与架构
一个产品中有三样东西是核心:商业模式,业务架构,技术架构。
其中业务架构是核心,商业模式是从外界观察到的业务架构,而技术架构是从技术角度看到的业务架构。怎么讲呢?请看案例。
案例
比如360这个软件,它的技术架构到底是什么?
刚开始,看上去是个单机版的杀毒软件;后来呢,变成了一个云查杀;再往后,出现了浏览器;又弄了一些五花八门的网络功能,甚至包括聊天……
如果单独从技术的角度看,很难把一个单机版的杀毒软件重构成聊天软件,除非在早期就有人想到这个软件日后要用来聊天。谁会在早期知道呢?业务人员。
业务人员能“预知”未来,所以就不要让开发人员蒙在鼓里,而是提前做好技术准备和储备,架构的变迁就顺理成章。
分析
实际上无论质量、进度、成本、架构、客户价值、赚钱……这些,都应该是“全民”的,至少是尽量全民的。
否则,自然就会有人沉迷于自己负责的那一部分,而将其他的置于自己可以抱怨、对抗的另外一个部门,很难把整个事情做好(有我)。
有一家企业在面试等待区会故意放置一个扔在中间的扫把,看哪个面试者在进入的时候会将其扶起来。很难说我们是否会需要一个有心把扫把扶起来的程序员,但是我们的确需要一个能帮助开发组做好架构的业务人员,也需要一个能帮助架构师写好架构的程序员,还需要能帮助程序员把架构实现出来的架构师……