【每日一学 20260825】敏捷之道——不同领域下的Scrum和DevOps

2026-08-25 15:16:00
蓉蓉
原创
11

一、不同领域的Scrum转型

（1）产品

不管是传统行业还是互联网行业，产品都是核心。传统行业的产品以ToB产品居多，ToC产品占比较少，比较追求业务价值；互联网行业的产品往往都是ToC类产品和通用型ToB类产品，更加追求市场价值。传统行业与互联网行业相比，产品存在的目的也有区别，传统行业的产品更注重功能；互联网行业更注重用户需求、流量变现以及商业化。


（2）需求

传统行业的需求方通常是少数人，大多数需求都来源于业务部门，有时候也可能只是某领导的一句话，再到业务部门、产品部门，按照二八原则来说的话，就是掌握着80%决策权的那20%的人来制定需求；互联网行业的需求则是来自市场上大多数用户的共同需求，按照二八原则为例，也就是80%的需求是由市场上80%用户提出的（这里没有错，两个都是80%）。传统行业和互联网行业的需求边界也会有所区别，传统行业的需求相对明确，需求边界通常都是在合同要求范围，偏离较小；互联网行业的产品初期定位也会比较明确、边界清晰，一旦投入市场，就需要根据用户行为、市场变化随时进行调整，需求边界也会逐渐变得不清晰。


（3）Scrum角色
在传统行业中，业务部门和产品部门往往都是非常强势的，因此在做敏捷转型时，他们通常会主动跟技术部门抢Product Owner的头衔，在这种情况下，我有时会建议采用双Product Owner模式，也就是业务部门或者产品部门选择一个人做Product Owner，同时技术部门也出一个Product Owner，两个Product Owner互相合作，一起梳理Product Backlog；传统行业中的Scrum Master几乎无法跟领导层进行协商，更加无法左右领导层的决策。

而在互联网行业中，通常只有一个Product Owner，Scrum Master可以直接跟领导层进行比较深入且频繁的面对面沟通，既可以提出自己建议，也可以彼此理性协商。

传统行业与互联网行业相比，还有一个非常不一样的职能角色——测试工程师，传统行业的测试工程师和互联网行业的测试工程师地位差异是比较大的。这就导致很多传统行业的测试工程师很难与开发部门做融合，只有很少一部分偏互联网行业的小银行和电信运营商才能做到真正的融合。而互联网行业中测试和开发一直都是一起的，很少出现无法融合的问题。


（4）Sprint周期
传统行业的开发周期通常都比较长，一个项目可能持续一年、两年，甚至更长，这些项目的需求通常比较稳定，这也是传统行业多有双态多模（通常双态是指敏态、稳态；多模根据组织的实际情况可能指传统模型、精益模型、敏捷模型、DevOps模型等）概念的原因，这些项目我通常会根据实际情况建议使用稳态方式，如果一定要使用Scrum的话，Sprint周期也会设置的相对较长，而且一不留神就很可能变成小瀑布模式，传统行业能不能真正跑通Scrum，更多取决于敏捷教练、Scrum Master和Product Owner。

相对的，互联网产品需要更快的满足用户需求，需求的开发周期也比较短，版本之间的间隔可能只有1-2周的时间，大版本最多也就半年时间，所以更适合比较短的Sprint周期。


（5）用户与体验

上文提到，传统行业更注重功能，以交付为目的，原则是满足功能和交付标准，然后才考虑用户体验；而互联网行业首先考虑的是用户体验，产品不仅要能切实解决用户问题，还要易用、好用、用户体验好。这就导致Product Owner在做优先级排序时与传统行业相比会有不太一样的考量。


（6）产品生命周期

传统行业的项目通常是外包的，一般会有1-3年的运维时间，之后就不再有很大的变化了；而互联网产品没有明确的终点，只要资金链有保障，发展前景没问题，产品就可以不断地更新、迭代，吸引更多的用户，创造更大的价值。


（7）行业趋势
现在很多传统行业也在进行互联网转型，互联网的一些产品特征也逐渐流入传统行业中，按照这样的发展趋势来看，敏捷、DevOps都是未来可期的。

二、不同领域的DevOps实施

1.传统行业之间的相同点
想要做DevOps转型的企业，对DevOps的流程和文化都通常是认可的，他们一定已经准备好改变现有的传统流程，向持续构建、持续交付的方向改变；同时也已经准备好要打破开发部门和运维部门之间的那堵无形的墙，加强开发和运维之间的合作的准备。

工具平台和工程实践，传统项目的工具平台通常是比较老旧的，所以在做DevOps转型的时候，很有可能会做大量工具平台的替换和引入，比如有些传统企业还在使用SVN，那在做DevOps转型的时候，我们会建议替换成其他的代码管理工具，还会引入其他的CICD工具、自动化测试工具、度量工具、开源软件治理工具、一体化平台等等，而工程实践也会跟着工具和平台的改变而进行相对应的调整。

只要企业想做DevOps转型，就会设立组织级支撑团队、组织级ETC小组（企业转型推动小组Enterprise Transformation Community），对DevOps转型全过程进行支撑和推动，只是名称会有所差异。

其实不管在什么领域的什么企业，只要他们要做DevOps转型，那他们对大的方向和规则都是认可的，目标也是一致的，只是实现路径会有区别。


2.传统行业之间的不同点
DevOps与传统行业之间最明显的不同点表现在3个方面：规范和实践谁先行、是否允许试错、谁来做交付。

第一个方面：是DevOps规范标准，这个跟企业的监管是否严格有关。监管很严格的企业，一般是先有标准，再进行实践，也就是从上向下的执行。监管不那么严格的企业，可以先有标准，也可以先进行实践，再根据实践的实际情况制定适合自己的标准。

第二个方面：是试错问题，这个问题主要存在于金融相关行业。在金融行业中，像是面客类、渠道类等跟钱无关的系统，通常都是允许试错的；而账务系统、核心系统等，通俗点说就是跟钱有关的系统，都有很高的安全要求，是不允许试错的，为了保证这类系统的质量，团队更愿意选择牺牲研发速度。运营商领域处于一个中间态，有些能够接受试错，有些无法接受试错。

第三个方面：是版本交付到生产环境的动作由谁来做，大多数电信运营商的开发团队就可以做交付，这也是比较符合DevOps的持续交付理念的，研发团队或者跨职能团队可以做到SIT、UAT、生产环境的部署，并且使用制品晋级保证在不同环境之间部署的正确性与合规性；而金融相关领域的开发团队是不能在生产环境进行部署的，生产环境的部署都是由运维部门进行的，所以他们将CD分成了两个部分，非生产环境的部署由开发团队负责，生产环境的部署由运维部门负责。


来源：《敏捷之道》——不同领域下的Scrum和DevOps--文/李欣

发表评论
通过审核后显示您的意见