为什么企业要做大规模敏捷分析「为什么企业要做大规模敏捷」

背景

软件工程里一个重要的指标就是“可用的软件”，敏捷宣言里也同样告诉我们“工作的软件高于详尽的文档”，那“可用的软件”、“工作的软件”意味着什么呢？在我的理解里，可以经历用户 “千锤百炼”的软件就是一个“可用的软件”。曾经听到过这样的说法：“一个有Bug的软件怎么能叫软件呢？”虽然这话在我们业内人士听起来有些可笑，但是这就是使用软件用户最真实的需求。所以如何在提高代码质量，最大程度地减少软件中的Bug同时，平衡软件迭代速度与交付效率是我今天想跟大家讨论的问题。

我有幸在两种完全不同风格的项目上进行过交付，让我们且称之为项目A和项目B。

项目A是一个客户为主导的巨大项目组，管理为明确纵向层级管理，横向开发团队来自于不同的供应商，并且采用瀑布式开发，由另一个事业部进行测试反馈，部门墙极其严重。

项目B则是一个由业务主导，每个敏捷团队有对应相关的业务领域，客户则是和供应商共同组成一个个敏捷团队，共同达成业务目标。

好了，完成了简单的背景介绍，我就要来说说下面的故事了。

故事总览

首先，假设我们所需要达到的目标是由一个个大大小小功能（颜色模组）组成一个完整的软件，为了达到我们的交付目标，我们需要将每个功能进行开发，测试，将功能模块进行累加，最终获得一个完整而达标的软件。

同时两个项目都使用了大致相同的开发流程，为了保证质量，项目中都有基础的代码审计，CI/CD，应用测试，用户测试，等基本质量保证，软件开发的基础流程如下图。

在这种基础流程都相近的情况下，每个环节在不同架构下执行的的方式却有巨大的差异。

在讨论项目A的流程前，让我们先看看我们熟知的敏捷开发是怎么保证质量的：

项目B的情况

项目b的每一个小敏捷团队将业务需求从路径图（Roadmap）拆解下来，落到各大的业务功能的Epic中，再拆解成具有小的业务价值的用户故事，最后再落到每个具有开发意义的任务，注意，这里提的一直是业务价值，我们还没有开始讨论如何进入开发。

Epic 更多是独立且较大的目标，用于我们识别在关键时间点需要实现的大型业务目标。而用户故事则是一个简短的描述、一个用于表达用户或客户的需求的角色和一个用于描述需求的价值或期望结果的价值陈述，在用户故事中比较关键描述是关于此价值点的“静态““动态”与“非常态“，静态更多的是对价值点的描述，在To C中往往是静态设计图（UI）的描述，动态则是交互，系统间的交互或者功能的用户旅程（UX），而非常态则是描述系统在错误或者误差情况下的表现，以确保当前的价值点在绝大多数情况下得以运行（AC）。最终用户故事将被团队中的技术领导拆解成可以单独执行的开发任务，最终没个独立的开发任务可以由不同的开发人员执行。

在一个大型的价值目标被拆解成了Epic->用户故事->开发任务的过程中需要全团队的多轮确认，多轮确认确保所有人达成统一共识 ，在最大的程度上解决沟通差带来的不确定性。最终需要通过迭代计划会议在团队内部对价值达成共识后，才会进行项目开发。

进入开发任务后每个阶段，参考下图：

我们可以看到4重质量保证：

结对编程：两个人的脑子总比一个人想的全。（其他好处不用赘述）团队中的代码版本差异识别：每对Pair的代码在一天结束时会被整个开发团队审核（当然可以提高代码质量了）代码审计：当对应开发任务 - PR(每笔代码)完成后，会被整个团队提意见（我听过比较离谱的就是：Our PR is waiting for more comments）,修正完成后代码才会进入测试阶段。测试: 最后的最后，才会进行测试，整个测试则是由小团队内部完成，在没有测试的情况下，“非常态”的AC就是整个测试的通过条件。

再这样一轮一轮的开发任务到用户故事的价值交付后，又组成了一个Epic价值交付，最终通过Bug Bash的方式最后确认价值以达到交付标准，我们可以上线整个Epic用于用户的检验。

总结一下敏捷开发的特点：

业务 -> 开发 -> 测试由一个全职能敏捷团队完成大多数内容由团队内部确定由上向下“顺时针“开发尽可能的小型功能，快速迭代小型逆时针回调细节确认业务导向：业务决定质量

用图来表示最终内建的结果，在最终快要上线时，经过团队内质量把控后仅与实际有极少差距，仅需要在日常使用中进行基础运维即可达到我们的价值目标：

项目A的情况

这时候让我们再来看项目A，系统被产品部门完成设计后，交予开发部门进行任务划分，每个开发团队承担不同的功能开发任务，每个功能点再由单独开发人员进行开发并自行测试（本地），最后由客户方进行功能验收后（功能展示 代码审核），代码合入主线进行转测。

说到这儿，举个例子，产品部门提供了本次需要交付的20个功能的设计图，开发团队把设计图分给交付团队（大多由供应商组成），团队成员小王负责对其中一张设计图（类似于一个Epic）的功能进行开发，开发完成后开验收会议，对代码和功能进行审核验证，进入测试流程。所以开发阶段归纳下来的话，如图

这样乍一看确实没有什么问题，开发流程中的各种实践也在做，那这种项目研发模式问题出在哪儿呢？这个时候我们看项目A的关键质量保证动作：测试。

项目A的测试步骤：

先抛结论，在测试阶段，80%时间用于确定问题 定位问题（标红）。所以我们可以着重讨论一下这两个阶段。

确认问题：在确认问题阶段， 往往由测试组发起，通过层层追溯，可以追溯到开发人员（也就是小王），跟小王确认表现层的“静态”/“动态”/“非常态”问题后，测试顺利成章地建立一个问题工单，并分配给小王，宣告此单插在了小王头上，小王需要修正再找测试回归。乍一看又没什么问题，是个好流程，但是执行起来此流程会出现：

因为测试标准中有较多主观的感官感受，导致在跟开发确认问题时经常出现主观问题，此时需要产品介入，并用主观感受进行判定。（缺少用户旅程细节）举例：（一个电话拉会）“小王，我觉得这个页面帧数好低，你要优化一下。”“啊？？？”（此处省略battle的10分钟）终于电话给了产品，产品一句话：“是帧数有点低啊！小王，这你得改”“…”需要产品介入的场景往往流程会变得极长。测试在做测试中，会考虑很多“非常态“问题，在非常态问题中，往往会导致”静态“”动态“的变更，然后经过工单追踪，产品组漫长的重新设计，然后再由开发进行更改。当存在“扯皮”问题，又是另外一副光景。举例：测试打电话给小王，小王说“这不是我的问题，你找xx团队的小李 ”，小李接上电话，“这是你小王开发的啊”..(再次省略battle时间)最终问题很有可能上升到客户方确定问题边界，这样1个小时就过去了。开发的专注思考时间被切碎。在转测后，需要大量地确认问题，也就是跟测试打电话，测试往往是发现问题第一时间就会确认问题，这样导致开发人员每天专注于代码工作的时间被切碎，效率直接下降。

定位问题： 定位问题同样占据了开发人员的大量时间，总体来说：

大量追溯代码：确认问题后，有时会需要确定整个功能代码中的问题点，问题很难定位，尤其遇到比较棘手的概率，性能问题需要对整个代码进行回顾与重构。涉及他方代码：当在长时间确认问题后，问题有时会涉及他人代码，比如框架代码，他人功能代码，硬件代码，这时候需要你找到相关人（打电话），解释，最终把工单走到他人名下（当然没人愿意接单，长时间Battle在所难免）。定位到无法修改的问题：当然在这里又有专门的流程做这件事，问题就出现在因为团队间的互相的部门/信任墙，需要长流程（COC：需求变更会议）来共同确认问题，需要引入大量具有决策权的角色：另外团队的架构师，产品经理，测试经理，还有可怜的小王。最终一个无法修改的工单往往需要2周或者更多的时间进行关闭。流程反复：当出现 确认问题->定位问题->确认问题->定位问题…这个如此反复的流程时，对开发和测试的神经都是一个极大的考验。

后续的修改流程往往较为顺利，但是也会出现一个工单反复无法通过回归的问题，这毕竟是少数，也不是我们主要探讨的范畴。项目在强流程驱动下最终的结果就是：

所有人每天都在加班，所有人每天都在增加流程以确保质量，所有人都很痛苦，当然这里包括小王。

用图来表示开发结束后的状态，空隙区域代表不确定问题，空隙部分需要测试->开发->产品逆流程更改

总结

说了这么多细节，我想现在跳出来问“为什么会出现这样的问题？”这个问题我也想留个大家做一点思考，我做了一些简单而又主观的总结，放在这里：

共识缺失：当大家都在自己的职能部门做自己的工作时，往往会主观地做这件事儿，当这件事儿在后续流转时，没有通过一个整体共识的话，往往需要从底端流程不断向上确认达成共识。大规模“逆时针”回调：因为整体共识由测试发起，加上部门墙重，往往导致从测试->开发->产品的逆时针开发流程，代码重构与返工的工作量极大。价值产出慢：当最终功能在大量回调时，价值产出很慢，导致验证慢，最终导致逆向反馈增加。流程决定质量：还是由测试流程来确定质量的情况下，在产品只进行Happy Pass的情况下，所有人的弥合质量的成本都在成倍增加。

看完了项目A和项目B的整体, 我们最后再来聊聊效率，我们发现，在同等的质量要求下，敏捷效率反而高很多，在流程更短的情况下却交付出了同样质量很高的产品，最后我们通过对比总结一下，为什么敏捷在保证质量的同时还能有更高的效率？

敏捷团队

职能团队

业务决定质量

流程决定质量

回调(重构)路径短

回调（重构）路径长

快速产出价值并验证价值

慢速产出价值验证价值慢

团队成员共同决策->快速达成共识

单一角色决策->长流程确认共识

专注手头工作

分散精力处理流程

团队凝聚力强

职能部门间不信任

开心

痛苦

图片来源：SAFe

我们暂且停在这儿，我要引用SAFe中的一张图来结束我今天的阐述，也在用实例回答：“为什么企业要做大规模敏捷？”

我想答案是：质量高，效率快，大家都开心。

参考资料：SAFe: How the Scaled Agile Framework® Benefits Organizations(https://scaledagile.com/what-is-safe/scaled-agile-benefits/)SAFe for Lean Enterprises - Scaled Agile Framework(https://www.scaledagileframework.com/safe-for-lean-enterprises/)SAFe Lean-Agile Principles - Scaled Agile Framework(https://www.scaledagileframework.com/safe-lean-agile-principles/?_ga=2.7535348.777726564.1672403469-1919242539.1672403469)A Complete Guide About Scaled Agile Framework (SAFe)? - DZone(https://dzone.com/articles/a-complete-guide-about-scaled-agile-framework-safe "A Complete Guide About Scaled Agile Framework (SAFe)? - DZone")

文/Thoughtworks 曾雪松

更多精彩洞见，请关注公众号Thoughtworks洞见！

敏捷制造,精益生产,大量生产的优势表现在那些方面

精益生产优势
　　好处一、降低库存
　　降低库存作为精益生产推行中的一个手段，其目的是为了从根本上帮助企业解决问题降低成本，企业中想要达到低库存就需要高效的流程作为支撑，以及稳定可靠地产品质量来作为其保证。而很多企业而在实施精益生产中认为精益生产就是零库存，而对流程以及产品的品质不管不顾。只是一味的追求降低库存，所以其结果也可想而知，成本不仅没有得到降低而且还急剧上升，于是这些企业就从他们的经验中得出我们的企业或者行业不适合推行精益生产。这样的误解我们是应该极力去避免的。
　　好处二、关注企业流程，提高企业的总体效益
　　可以这样说，有什么样的企业流程就能够产生出什么样的生产绩效。企业在改进流程的过程中要注意其目标是为了提高企业的总体效益。一个企业，如果流程管理好了，其整体效益也会有一个不错的提升。
　　好处三、建立无间断流程以快速应变
　　建立无间断流程，将流程中不增值的无效时间尽可能压缩以缩短整个流程的时间，从而快速应变顾客的需要，这点对于精益生产是很重要的呢。
　　好处四、消除八大浪费
　　企业中普遍存在的八大浪费涉及：过量生产、等待时间、运输、库存、过程(工序)、动作、产品缺陷以及忽视员工创造力，只有从根本上消除这些，那么企业就会快速发展起来了。
　　好处五、全过程的高质量，一次做对
　　质量是制造出来的，而不是检验出来的。检验只是一种事后补救，不但成本高而且无法保证不出差错。因此，应将品质内建于设计、流程和制造当中去，建立一个不会出错的品质保证系统，一次做对。精益生产（www.chinatpm.net）要求做到低库存、无间断流程，试想如果哪个环节出了问题，后面的将全部停止，所以精益生产必须以全过程的高质量为基础，否则，精益生产只能是一句空话。
　　好处六、基于顾客需求的拉动生产
　　在需要的时候，仅按所需要的数量生产，生产与销售是同步的。也就是说，按照销售的速度来进行生产，这样就可以保持物流的平衡，任何过早或过晚的生产都会造成损失。
　　好处七、标准化与工作创新
标准化的作用是不言而喻的，但标准化并不是一种限制和束缚，而是将企业中最优秀的做法固定下来，使得不同的人来做都可以做得最好，发挥最大成效和效率。而且，标准化也不是僵化、一成不变的，标准需要不断地创新和改进。
　　好处八、尊重员工，给员工授权
　　尊重员工就是要尊重其智慧和能力，给他们提供充分发挥聪明才智的舞台，为企业也为自己做得更好。员工实行自主管理，在组织的职责范围内自行其是，不必担心因工作上的失误而受到惩罚，出错一定有其内在的原因，只要找到原因施以对策，下次就不会出现了。所以说，精益的企业雇佣的是"一整个人"，不精益的企业只雇佣了员工的"一双手".
　　好处九、满足顾客需要
　　满足顾客需要就是要持续地提高顾客满意度，为了一点眼前的利益而不惜牺牲顾客的满意度是相当短视的行为。企业要以实际行动来实践，尽管产品供不应求，在一切准备工作就绪以前，从不盲目扩大规模，保持稳健务实的作风，以赢得顾客的尊敬。
　　好处十、精益供应链
　　在精益企业中，供应商是企业长期运营的宝贵财富，是外部合伙人，他们信息共享，风险与利益共担，一荣俱荣、一损俱损。遗憾的是，很多国内企业在实施精益生产时，与这种精益理念背道而驰，为了达到"零库存"的目标，将库存全部推到了供应商那里，弄得供应商怨声载道：你的库存倒是减少了，而我的库存却急剧增加。精益生产的目标是降低整个供应链的库存。不花力气进行流程改造，只是简单地将库存从一个地方转移到另一个地方，是不解决任何数森问芹毕嫌题的。当你不断挤压盘剥你的供应商时，你还能指望他们愿意提供任何优质的支持和服务吗?到头来受损的还是你自己。
　　好处十一、"自我反省"和"现地现物"
　　"自我反省"的目的是要找出自己的错误，不断地自我改进。当错误发生时，并不责罚个人，而是采取改正行动，并在企业内广泛传播从每个体验中学到的知识。这与很多国内企业动不动就罚嫌手款的做法是完全不同的-绝大部分问题是由于制度流程本身造成的，惩罚个人只会使大家千方百计掩盖问题，对于问题的解决没有任何帮助。
　　好处十二、企业中的团队工作
　　在精益生产推行好的企业中，一种灵活的团队工作已经变成一种非常常见的组织形式，在这样的企业中会出现一个人同时归属几个不同的团队，并负责完成不同的任务。如果现在一个企业还是仅仅依靠老板或者几个主要的领导，这样的企业我想是不会长远的。

企业一定要做大吗？

这不是要看你自己的想法嘛。1、经营企业的目的一定是以盈利为主要目的，所以不一定是要做大，而是要做强。2、当然也有少数是以做大为目的，这应该是在企业发展的某个阶段，比如做大以获得更多的市场份额，同时也是为了压缩对手的生存空间。但最终还是要回归到以盈利为目的的方向上来。我们存在这样一种误解，认为小企业的发展就是要做大规模，惟有通过规模扩张才能降低生产成本和交易成本，才能抵御市场风险。其实，小企业所追求的并非是规模和市场占有率，而是在规模、市场占有率与效率之间寻找一个平衡点，实现企业的资本利润率最大化。日本有许多著名的小企业，尽管效益非常好，但它们并不追求上市，甚至连店头交易都不参与。这样做，一方面是为了避免上市所带来的透明化和费用支出，也是为了不与其他投资者分享成果。反观我国的一些小企业，却有不少在追求资本扩张。小企业有自身的优势。小企业首搏的层次少，经营者一般直接面对市场，市场供求信息能及时得到消化。规模小意味着固定资本少，从而使企业更能适应市场变化，及时调整生产方向。在电子网络越来越走近我们的时代，小企业在销售成本方面的劣势，已经变得不再像过去一样重要。因此，服务体系对小企业的支持，并非千篇一律地扶植企业做大规模，而是帮助它们立足市场，利用技术，从而找到合适的生存空间。对于高雹芹亩新技术企源森业来说，做大规模可能非常重要。但对于一般技术企业而言，更重要的是利用现有的技术，产品产销对路，从而降低成本。保持较高的资本回报率。