软件交付的特点与分析

DevOps时代下工作整合问题

什么样的工作需要整合，什么样的工作不应该整合？

在软件交付领域，分角色的精细分工是不利于整体交付效率的，那为什么在DevOps倡导下的全栈工程师、开发运维一体化又会产生新的问题呢？如何解决这些新问题呢？

也许，我们需要认真思考，在整个软件交付过程中，什么样的工作需要整合，什么样的工作不应该整合。

在前DevOps时代，分角色分工的思路其实是来源于工业时代的。做过手工的都知道，如果要手工做100只灯笼，一开始会做得很慢，做了几只后，会越做越快，所谓熟能生巧。

再进一步，把做灯笼的过程拆解一下，比如拆解成搭骨架、糊纸、上色等工序，然后多找几个人来，每人负责其中一道工序，经过几番磨合，由于每个人要做的事情比较单一，很容易上手和熟练，效率将会大大提升。灯笼的成品和质量也会越来稳定。

把这个过程放大，就是一个工厂的模式。

所有工厂都是通过拆解和精细分工获得极高的效率的，而且，分工越精细，效率越高。而生产最大的特点是在不断地做重复的事情，产出是同样的产品，而且产品间的差异越小越好，最好趋近于零。对于重复的事情，就应该通过拆解、精细分工、标准化和自动化来提升效率。

但是软件交付过程则完全不一样，和生产最大的区别就是“不重样”。

每一个软件需求都是不一样的，用户想要的结果也是不一样的，这导致需求分析、开发、测试面对每个需求，或者运维面对每个故障的具体工作是不一样的。

而且软件交付是一个知识工作，是信息流动和转换的过程，而交接会带来信息的衰减和变异，因此在软件交付过程中，按角色分工非但不会带来像生产那样的效率提升，反而会因为信息在不同角色间的交接和传递而产生不必要的摩擦和误解，甚至交付出错误的软件产品。

因此，我们更希望软件交付团队成员可以具备从需求到运维的端到端的交付能力，每个团队针对一个特定的业务领域能够独立完成交付，减少交接，减少对外依赖。

而且这个团队应该足够小（最好不多于7人），以确保团队内目标一致、高效沟通和高度灵活。

然而，对于业务或用户来说，IT系统和服务是一个整体，除了软件，还有硬件。而每个人的带宽和能力都是有限的，术业有专攻，不可能每个人都是全能的，特别是有些细分领域专业度非常高。

如果把所有的职责都归到业务线交付团队，那么交付团队必然需要拥有具备各类所需技能的专家，从而形成新的庞大实体，除了造成不必要的资源浪费外，组织一旦变大，势必又会变得官僚和低效，原本想避免的问题又会重新出现。

三、解决工作整合问题的关键

要找出哪些工作是重复的，哪些是非重复的。

那么问题的症结在哪里呢？通过前面的分析，我们知道，重复的工作，可以通过拆分、精细分工、标准化和自动化来提升效率，非重复的工作，可以通过减少交接和依赖来提升效率。

要解决如何分、如何合的问题，最关键的就是找出哪些工作是重复的，哪些是非重复的。重复的，解决方案是整合资源、角色分工和自动化；非重复的，解决方案是一体化。

那么在软件交付过程中，哪些工作是重复性的呢？我想到的有以下这些：

1、网络、硬件等基础设施

这些IT基础设施不会因为不同的项目和需求有太多的差异，而且专业性强，不太适合一人分饰多角，这些角色整合在一个