敏捷转型要从 PO 作起

过去我辅导的转型案例里，起手式都是依据看板之父也就是 David J. Anderson 先生所谓的一种成功的方式(注1，第一步、专注于质量)的切入法来开始改变组织的行为模式的，也就是从「要求品质」开始，更具体的说；就是从开发部门开始改起。

这种敏捷化的起步方式看起来十分合理，因为敏捷的初期本来就是针对开发单位所应运而生的(2001年的敏捷宣言目标是专注于开发团队)，因此从开发单位开始改起就很合理了，再来对开发及运维单位做要求品质改善的行为，本来就是不可或缺的要求，所以从这里下手很少会遭人反对的，再说进行品质改善是一种换来纪律的行为，对团队有利而无弊，很少会有人反对的。但是我发现这是错的…

敏捷转型要从产品部门做起

最近，突然发觉敏捷转型要从PO作起才是对的，为什么呢? 因为如果是由客户端就要求你在开发时，每2到3周就要让我看到成果，要求进行功能检核，到底做得对不对、合不合我用，然后寻求我的回馈来作调整的话，这不就是一种小增量、迭代式的开发吗?这就是敏捷啊! 而客户给出的需求只要求能领先开发团队产出的1到 2个开发周期就够了，需求的优先顺序也是客户说了算数。

这个小开发周期结束时的检核会议(review meeting，就等于SCRUM的检核会议)看起来就好像是在作验收一般，这位扮演客户角色的团队成员不正是我们不陌生的PO (product Owner)吗？他的要求自然而然地会将团队导向敏捷化的路径上。

团队为了符合PO的要求，不得不将步调挑整成一种小增量、小迭代的模式，这个时候的开发流程也就自然而然地符合了敏捷的精神，而团队的开发方式自然的就敏捷化了，真是事半功倍。所以敏捷转型要从PO所在的产品部门做起。

人们的需求才是真正在改变这个世界的起因。

让需求敏捷化来引导开发团队

一切都要由让需求够敏捷化开始。不要让开发部门再去主导敏捷化的行为了，应该让需求来引导开发团队的行为才是，需求一旦敏捷了团队自然就敏捷了。

而需求如何变敏捷呢?自然是产品规划部门运用符合敏捷开发的方式来规划需求的产出，由此作推论，便是组织推行敏捷化要由产品的规划部门开始。

过去我的做法则是一直由开发部门的敏捷化作开始，以让开发人员踏上正确的敏捷原则为依据，运用一个较小的开发团队成功的达成敏捷化的方式来作范例，作为组织敏捷化的标竿，然后在来希望这个成功的案例能够吸引其他团队来群起效法。

这种起手式是许多书上的建议，由一个成功的案例让开发团队来主导敏捷化的过程，用好的开始逐步的来推行敏捷化。

老实说；这么多年以后，如果在让我做一次的话，我会选择由产品部门的敏捷化开始。或许这是由于推行DevOps所产生的改变吧，我们藉由下面这张图来做说明: 首先；DevOps的概念实质上应该要包含商业的运作在内的，因此全名应该是 Business DevOps, 而 DevOps则是简称(注2.)。

含有商业运作的 DevOps 图示

上图说明了，如果只有在开发(Development) 单位实行Scrum 的敏捷开发模式，则实质上是在运行Water-Scrum-Fall而非真正的敏捷化。

真正的敏捷必须向前与向后去做推广。因此由产品部门开始实行敏捷化能够以较省力的方式，也就是从能够承上起下的地方是最适合的起始点。

敏捷不是单一部门敏捷就说敏捷化成功了的，一定是由运维、开发一直到业务部门都敏捷了，企业才能尝到哪种成功的滋味。

由开发部门开始运作敏捷的方式，是一种由下往上的推行方式，而由产品部门开始敏捷化的方式则比较偏向由上往下的推行方式。相对的成功率会高一些，当然高层领导的支持，依然是成功的先决条件。只是由客户的立场做起敏捷化来会更符合以顾客为导向的思维方式罢了。

需求看板Up Stream / 开发看板Mid Stream / 运维看板Down Stream

需求看板是敏捷化的源头

如果能从需求端就开始敏捷，则下游的开发与运维端便能够自然而然地跟随著需求而逐渐的敏捷起来。

这个道理不难理解，但执行起来要从哪裡作起呢? 来自各方的需求，运作起来其实可以大致分成：规划与执行二个部分。

上图绿色部分是运作时的执行看板，也就是执行的部分，另外应该还要有一份企业俱有巨观型的规划看板，也是规划部分(它应该包含许多大颗粒的需求，跟流动路径与相对单位需要配合的价值流，这裡就不做细谈)。

它的流动方式决定了下游所有其他看板的依据。包括何时启动由哪一个单位负责及需要些什麽配合。

需求的好坏抉定了开发团队的效能，需求的敏捷化则影响著团队开发的模式。

需求要先视觉化；视觉化可能是最重要的手续，他可以确保开发的流程能够符合精益的原则来进行，能够适当的消除谷仓效应，因此产品部门要实施敏捷化的起步当然是由需求看板做出发，让它务实的反应出规划与执行面的进度与流程（对于完成definition of done的定义有所不同，这是与传统看板最大的差异处，相对的它将更专注于处理 definition of Ready也就是资料备妥）。

运用透明化的讯息来与各个相关单位做联系，这一步是开始也将是敏捷化成败的重要因素。

结语

如果看板之父的企业变革的「一种成功的秘诀」是减少组织转型阻力的方法，则由PO需求开始敏捷化的启动方式，便是一种事半功倍的转型方法。

开发与运维的敏捷化将由于PO对产品规划的敏捷化而牵动，一种基于客户的要求，为了与需求相配合而自然形成的敏捷化。

这种思考方式是认为因为来自客户端的需求方式，所引发的敏捷才是自然因应需求而生的敏捷，是一种在顺畅不过的敏捷衍生过程，前提是以客户为导向。

所以用一种「敏捷的需求」来引发开发、运维配合而自然改变行为模式的敏捷，是一种事半功倍的转变方式，也是一种符合以客户为导向的开发模式。

注1. 《看板方法: 科技企业渐进变革成功之道》by: David J. Anderson

第三章 一种成功的秘诀。有六个步骤:

1. 专注于质量；
2. 减少进行中的工作work- in- progress；
3. 频繁交付；
4. 根据交付速率来平衡需求(demand)请求量；
5. 进行优先级排序；
6. 消除变异性的根源，提升可预测性。

注2. BizDevOps (Business DevOps) 有许多单位向DevOps 之父反映过这个疑虑，Patrick 的回答是认同的，DevOps 应该包含商业运行，只是 DevOps 这个词汇已经被大众所接受了，没有必要在做修改徒增疑惑，只要正确的诠释就好了。

DevOps 落地和实践当然不能完全靠企业自己摸索，明明都有桥了，还摸着石头过河？ 企业级 DevOps 落地实践经验、DevOps 国际标准，都是您前进转型路上的明灯！DOIS 2018 · 深圳站，11月，我们深圳见！