快速交付团队的内功修炼心法（1）

现如今，我们所处的年代是一个快速变化的年代。这种快速变化首先体现在近10年的互联网高速发展。2009年，淘宝在双11的交易额才只有0.5个亿，2018年已经达到了2100个亿。从0.5个亿到2100个亿，市场在变，技术架构也在不停地演变。然而这种演变不仅是互联网的专利，传统行业也在经历着互联网转型的过程。这种转型带给我们了太多的痛苦与挑战……

然而，经过了这一轮互联网转型，我们是不是可以休息一段时间呢？答案却是不能。2016年，阿尔法狗战胜了围棋大师李世石，引发了整个社会对人工智能的关注。但是，我要说，人工智能并不是媒体炒作的那么神奇。它的神奇在于背后海量数据的支撑。然而，当我们收集了海量的数据，应该把它放到哪里呢？放到关系型数据库，数据越多，查询越慢。因此，可以想见，在未来三五年时间里，我们又将经历一轮大数据转型。在这一轮转型中，虽然又会给我们带来很多挑战，但也是会给我们带来很多新的机遇、全新的市场，与全新的发展机会。

然而，当我们看到了这样的机会，我们的竞争对手也看到了这样的机会。我们站在同一起跑线上起跑，谁将获得最后的胜利呢？这里的决定因素就是速度。

从这张图上我们可以看到，什么时候软件价值最高呢？是用户刚刚提出需求的时候。用户刚刚提出需求时，市场还没有相应的产品，如果我们适时推出我们的产品，则用户更有意愿去购买我们的产品。但是，如果经过好几个月后，当我们把所有的功能都完善了再推出产品，则可能由于市场的变化，或者竞争对手的进入，我们的产品就没有价值了。因此，我们需要用更快的速度交付对用户最急切想用的功能，快速占领市场，获得竞争优势。

这是我的一次亲身经历：我们在做一个大数据项目，项目刚刚起步就得到了某省省长的关注。客户告诉我，省长下周就要来视察我们的项目，并且省长关注哪些、哪些分析指标，而这些分析指标是我们在后面阶段才计划做的。把握住这次机会，项目将获得巨大的发展，但留给我们的时间只有一周。在这一周时间里，我们要调整工作计划，完成设计、开发、测试与部署，这将是一次巨大的挑战。

如何才能获得快速交付的能力呢？临时抱佛脚是必然不行的，团队需要在平时修炼内功。而这种内功的修炼体现在了软件研发的方方面面，包括：高效的团队组织、精简的代码维护、强有力的平台支撑、自动化的运维平台。

高效的团队组织

许多团队都有这样一个经历：项目初期，由于业务简单，参与的人少，我们往往可以获得一个较好的交付速度；但随着项目的不断推进，业务变得越来越复杂，参与的人越来越多，交付速度就变得越来越慢，使得团队越来越不能适应市场的快速变化，不断处于竞争的劣势。然而，软件规模化发展是所有软件发展的必然趋势。因此，解决规模化团队与软件快速交付的矛盾就成了我们不得不面对的难题。

为什么团队越大交付越慢呢？如图是我们从需求到交付的整个过程。在这个过程中，我们要经历多个部门的交互才能完成最终的交付，大量的时间被耗费在了部门间的沟通协调中了。这样的团队被称为“烟囱式的开发团队”。

烟囱式的开发团队又会导致烟囱式的软件开发。如图，在大多数软件项目中，每个功能都要有每个功能的页面、controller、service、dao，需要编写大量的代码，并且很多都是重复代码。代码写得越多BUG就越多，日后越难于维护和变更。

最后，统一的发布也制约了交付的速度。如图所示，当业务负责人将需求分配给多个团队开发时，A团队的工作可能只需要1周就可以完成。但是，当A团队完成了他们的工作以后，能立即交付给客户吗？答案是不能，因为B团队需要开发2周，A团队只能等B团队开发完成以后才能统一交付。因此，A团队的开发速度再快，不能立即交付用户，能产生用户价值吗？不能。随着团队的规模不断扩大，这种状况就会越来越突出。经常5-6个团队要等着发布了，突然某个团队出现了重大BUG，其它所有团队都得等，交付速度就变得越来越慢。

如何解决以上问题呢？就需要调整组织架构，将筒状的架构竖过来，我们称之为“跨功能团队”或者“特性团队”。在特性团队中，每个团队都直接面对终端客户。比如购物团队，所有与购物相关的功能都是他们来负责完成，包括从需求到研发，从UI到应用再到数据库，都是这个团队设计开发。最后，经过测试也是这个团队负责上线部署。这样，整个交付过程都是这个团队负责，没有了那么多沟通协调，交付速度自然就提升了。

那么，特性团队就是各自独立工作，相互之间不需要协调吗？也不是。如上图，在这个案例中，不论是购物团队、交易团队、物流团队，都需要读取商品信息。如果他们都直接从商品信息表中读取，则一旦商品信息表发生变更，多个团队都需要变更，还全部都需要测试与发布，这个变更的成本就非常高。因此，商品信息统一交给商品团队去维护，其它团队则去调用它提供的接口。这样，一旦商品信息表发生变更，只需要商品团队去维护，则维护成本得到降低，这才是高内聚的设计。

有了特性团队的组织形式，如果还是统一发布，那么交付速度依然提升不了。因此，在特性团队的基础上，软件架构采用了微服务的架构，即每个特性团队各自维护自己的微服务。这样，当该团队完成了一次开发，则自己独立打包、独立发布，不再需要等待其它团队。这样，交付速度就可以得到大幅度提升。

然而，要这样构建一个特性团队，成本是非常高昂的。团队每个成员都必须既要懂业务，也要懂开发；既要懂UI、应用，还要懂数据库，甚至大数据，做全栈工程师。如果每个特性团队都是这样构建，是没有办法真正落地的。那么，这个问题怎么解决呢？核心的关键在于底层的架构团队。架构团队通过构建技术中台，将软件开发中诸如UI、应用、数据库，甚至大数据的许多技术进行了封装，然后以某种接口的形式开放给业务，那么业务开发的技术门槛将得到降低。这样，特性团队的主要职责就是业务开发，他们从软件技术中解脱出来，则可以将更多的精力放到对需求的理解，对业务的实现，我们称之为“大前端”。所谓大前端，就是一种职能的转变，即业务开发人员不再关注技术，而是更加关注业务，深刻地理解业务，并快速应对市场对业务需求地变化。

采用“大前端+技术中台”的战略，需要架构团队的支撑，更需要微服务架构的支持。因此，随着传统行业向互联网的转型，又要经历一轮新的微服务的转型。那么，微服务长什么样儿呢？如图，当用户以不同的渠道接入到系统中以后，通过服务网关就会调用到各个微服务中去了。每个微服务都是一个软件项目，麻雀虽小五脏俱全，即每个微服务都有各自的基础设施、服务、实体、数据访问与数据库。这时，就有2个重要的概念：去中心化的技术治理、去中心化的数据管理。

去中心化的技术治理，就是每个微服务都有自己的基础设施，它们可以各自不一样。因此，每个团队可以根据各自业务的不同，选用不同的技术架构，甚至不同的语言。这样，可以为日后快速的技术变革创造条件。当今，技术变革越来越快，但要在老项目中进行技术架构调整，对每个团队来说都是一种挑战。为什么呢？因为在传统的单体应用中，一旦技术架构调整，所有的功能都要调整，其成本就会非常高昂。但是，原有的功能运行得好好的，我们为什么要调整它呢？新的技术我们是希望应用在新功能、新业务上。因此，采用了微服务架构，老功能运行在老的技术架构上，而新功能放在新的微服务中，采用新的技术架构。这样，我们采用新技术的成本就会更低，我们就可以更加频繁的采用新技术，从而让我们在市场中获得技术竞争的优势。

去中心化的数据管理，即每个微服务除了有自己的基础设施，通过数据库拆分，还可以有自己的数据库。这样，每个微服务都可以根据自己的需求，采用不同的数据库，这对于即将到来的大数据转型，显得尤为重要。如图，通过微服务的拆分，客户服务与商品服务，对应的客户表与商品表，它们的特点就是数据量小但需要反复读取，因此可以采用一个小型的MySQL数据库，在前面架设一个Redis缓存，就可以很好应对；但交易服务对应的交易数据，其特点是高并发与大数据量写入，一个数据库是肯定支撑不住的，因此选用分布式的NewSQL数据库（如TiDB）；而经营分析与业务查询，是对海量数据的数据分析与秒级查询，因此通过读写分离，将数据抽取到NoSQL数据库或大数据平台中，就能应付这一类的需求，比较典型的应用是Kylin与ElasticSearch。