经常听到有人说,数据库很重要,所以应该有一个经验丰富的团队来把关。架构很重要,所以应该由一些架构师来统筹。
先不说这些高级团队到底能做到多大改善。但这种组织架构会带来致命的问题——组织的开发速度上限受限于这些高级团队,甚至是效率最低的那个。
如图,首先问题是,这些团队会在整个开发流程中成为瓶颈,我们无法通过横向扩展团队来提升组织的开发速度。这对软件产生价值的组织来说是致命的。
第二个问题是,开发中的沟通成本大量增加,团队间的沟通成本会远远大于团队内的沟通成本。如果功能开发团队依赖于大量其他团队,就会使整个开发成本变高,价值流速度降低。
第三个问题是,核心团队成员需要长时间培养,人员流动往往会造成致命的打击,就好像组织中有一根软肋,如果竞争花钱把某一个核心团队成员全部挖走,该组织可能会立刻消失。
由此可见,为了保持某些看起来很重要的东西(比如数据库,架构)运行良好,就让专业团队去做的想法有很多致命问题。
那怎么样才是好的实践呢?
特性团队 + 微服务
团队自己负责所有事务,从一开始就避免大型数据库和大型架构的设计,每个功能根据自己的需求,完成相应的服务设计、开发、测试、部署和上线。如果需要修改其他服务,也由该团队自己完成。通过自动化测试去保障质量,而不是由某个高级团队。
如果遇到遗留系统怎么办?
因为遗留系统可能没有足够的自动化测试去保障质量,所以首选的一定不是去修改它。把遗留系统API化,给遗留系统补测试,把一部分功能拆出来另外实现,都是我们常用的方法。
当然,我们还是避免不了去修改它,这种时候,修改还是由团队自己来完成,因为没有人能代替你去理解业务,没有人能代替你提供实现方案。只是团队需要自己足够谨慎,通过增加对遗留系统的了解以及找曾经在系统上工作过的人沟通,从而具备修改它的能力。
总之,指望把当前团队解决不了的问题扔给另一个团队去解决是不靠谱的,我们应该提升团队能力,使该团队具备解决问题的能力,而不是把希望寄托在别的团队上。