图解精益敏捷的逻辑与实证：设计您自己的工作方式

本文来自作者 glenwang 在 GitChat 上分享「图解精益敏捷的逻辑与实证：设计您自己的工作方式」，「阅读原文」查看交流实录。

「文末高能」

编辑 | 哈比

摘要回放

精益敏捷的书籍已如汗牛充栋，但又没有给人一个明确的产生画面感的扎实理解。本文对精益敏捷的基本定义如下：

一种工作方式；
跟人和组织相关；
其目的是达成组织的目标；
以敏捷四价值观和精益五原则为核心基础。

本文基于作者十余年管理和教练经验，总结软件开发管理中各个敏捷实践的逻辑：

发生作用的原因；
行得通的条件；
达到的效果。

业务有架构、技术有架构、工作方式也有架构。文章脉络大致参照 PMBOK 的组织方式：五大过程组（项目启动、规划、执行、监控、收尾）和十大知识领域（整合、范围、进度、成本、质量、资源、沟通、风险、采购、干系人），并按照精益和敏捷思想有所修正。

分享的目的是帮助您思考精益敏捷的逻辑以及设计您自己的工作方式（Way of Working）。

// 手绘图 by @ 虎头锤

精益敏捷的八大逻辑

两个根本元素

产品、技术与工作方式

当谈到产品时，人们心目中会浮现出一副景象：生活中的衣食住行，或娱乐运动旅游教育所需的各种东西，即人们购买、使用和消费，并能满足人们某种需要的任何东西。

当谈到技术时：人们头脑中也会浮现出一副景象：为了生产出产品，具有专业技能的人在生产产品的过程中所进行的专业活动。

有了对产品的需求，和有了技术，是否就能进行卓有成效的生产活动，和生产出既能满足市场需要，也能帮助企业盈利的产品呢？答案是否定的。

福特汽车是如何崛起的？丰田汽车又是如何后来居上的？这涉及到工作方式和管理问题。

流的历史

工作方式的概念包含的内容很多。下图通过工作方式当中的一个小概念 “流”，介绍一下流的历史，对工作方式做个初步体会。

1104 年建立的威尼斯兵工厂，是为威尼斯海军建造军舰的地方。威尼斯人早年经过长时间的努力，建立了标准化的设计以及可替换的零件，以致在舰船厂中狭窄的水道里，一年能制造出数以百计的战舰。工人们先建造船身，然后再 “漂” 流到下一站，去装配不同的部件。1574 年，法国国王亨利三世被邀请去参观该工厂开发出的先进 连续流 制造技术，从开始组装船身到完成，只需要不到一小时的时间。
1798 年美国正笼罩在可能要与法国开战的阴影之下，惠特尼接受美国政府的委托，在 1800 年前为美军供应 10000 至 15000 支步枪。他按照枪支零件的尺寸设计出一套专门器械和流程，让一般工人通过使用它们分工生产不同的零件。用这种工艺流程生产出来的零件尺寸及公差均一，任何零件皆能适用于任意一把同型号的步枪，只要将它们组装起来便可成为一支完整的步枪。这就是 可互换零件 。而在当时流行的工艺是每把枪由头到尾皆由一位工匠打造，同型号的每一把枪的零件都无法互换。
丰田集团的创始人 Sakichi Toyoda 丰田佐吉（一生研发出 84 项专利，被日本人誉为 “发明王”），于 20 世纪早期，通过在自动织布机上安装能够在任何纺线断掉的时候自动停机的装置，发明了 Jidoka（ 自动化 ）这个概念。这不仅改善了质量，并且使得工人能够解放出来，去多做一些增值的工作，而不只是为了避免守在机器旁。最终这个概念应用到了每台机器，每条生产线，和丰田公司的每个操作之中。
20 世纪初，汽车仍然是富人们才能消费得起的奢侈品，亨利·福特在 1903 年创办福特汽车公司后，励志要打造一辆普通大众都买得起的平民车。当时美国销售的汽车普遍售价在 4700 美元左右，相当于一名普通人六年的总收入，而福特 T 型车售价仅为 850 美元。为了让福特 T 型车更加深入人心，亨利·福特决定改进生产方式以求大幅降低了福特 T 型车的成本，使其售价进一步降低。亨利·福特偶然间在一份肉类加工厂报告中获得灵感，为了满足消费者对 T 型车强烈的需求，他决定采用 流水线 的方式生产汽车。1913 年 12 月 1 日，亨利·福特开发出世界上第一条汽车组装生产线并投入生产。每个工人固定在一个工位组装车辆的某一个零件，原先一辆汽车装配时间需要 700 多个小时，T 型车采用流水线作业仅需 12.5 小时。
在 20 世纪 40 年代，戴明反复强调质量控制的重要性，不断进行质量管理的培训，试图把统计学运用于工业生产。据说，在这一阶段美国政府和企业听过戴明培训课程的人数达三万人。当时，戴明已经是世界公认的抽样专家，不过，他的呼吁，在美国反应寥寥，没有多少人对他的建议和课程真正有兴趣。1950 年 7 月 10 日至 18 日，戴明受 JUSE 邀请在日本四大城市授课。他立足于一个基本信念，即高质量可以降低成本。戴明预言：“只要运用 统计过程控制 ，建立内在质量管理机制，五年后日本的产品就可以超过美国。” 果然，日本的产品质量总体水平在四年后（大约 1955 年）就超过了美国，到 20 世纪 70－80 年代，不仅在产品质量上，而且在经济总量上，日本工业最终对美国工业造成了巨大的挑战。

精益敏捷是当今工作方式的典型代表，上述工作方式中都包含着精益敏捷的要素。

两个根本元素：逻辑和权力

而在精益敏捷工作方式的所有要素当中，有两个根本元素：逻辑和权力。

逻辑元素 ：这是工作方式当中科学的一面。一种方法行得通或行不通，有其原因、条件和结果，这是逻辑和科学。精益敏捷工作方式是可设计的，而只有经过与实际情况相符的设计，才能行得通。
权力元素 ：这是工作方式当中与人有关的一面。在这里，权力一词基本等同于人。在一个组织当中，每个人有他的诉求、动机、地位、法定权力、思想、意志、知识、情感等或物质或精神的属性，这些都是权力。在人的世界里，单纯用逻辑和科学方法是行不通的，因为人和权力是逻辑关系中最重要的要素。权力又大致有两种：凝结在一个个个体身上的，和蕴藏在组织结构中的。这两部分权力都要有很好的处理。

下述精益敏捷八大逻辑当中，第五和第六逻辑重点涵盖权力元素，其他重点放在逻辑元素，但也涉及权力元素。

逻辑一：3C 环境

精益敏捷是如何发展起来的？我们又为什么要实施精益敏捷？答案是我们生活在一个 3C 的环境当中：

客户（Customer）：客户的要求越来越高。客户期望能以更低的价格，买到能满足需要的产品，而且期望产品的交付周期越短越好。以手机为例，十年前市场上的手机品牌很少，升级换代很慢。而现在，手机的品种和升级换代的速度已经让人眼花缭乱，更不要说各种 App 了。就社会和市场上的总产品来说，过去几十年产生的产品数量或许超出了过去几千年产生的产品数量。经济进步、技术进步和消费者的觉醒是背后的推动力量。
竞争对手（Competitor）：行业壁垒越来越低，市场上的竞争对手越来越多。如果一家公司不能满足客户的期望，客户还有更多选择。公司发展不进则退，市场上总有人能以更低的价格做到同样的事。对于手机产品，汽车产品，甚至火箭产品，我们发现越来越多的 “外行” 进入这些行业，而且还玩得风生水起。比如说马斯克和贝索斯两位就分别把火箭的发射成本降到了美国宇航局的十分之一以下。
复杂性（Complexity）：复杂性体现在两方面，一方面是关于需求，另一方面是关于技术。这两方面的进化和不确定性都在加剧。大家都知道芯片集成度的摩尔定律，芯片的集成度每 18 个月提升一倍。十年前电子产品还可以靠人工焊接，现在的芯片管脚已经是人拿着放大镜都看不清，只能机器焊接。这是可见的物理复杂度的一个例子，更多是不可见的复杂度和不确定性。应对复杂性和不确定性的能力，是一家公司的重要核心竞争力。参阅：复杂性与敏捷 - Stacey 矩阵，Cynefin 框架，管理 3.0，敏捷宣言。

在这样一种 3C 的环境之下，精益敏捷的工作方式应运而生，成为企业的如虎之翼和强身健体的利器。

2018 年，全球市值最大的 5 家公司分别是：亚马逊（Amazon）、苹果（Apple）、Facebook、谷歌和微软（Microsoft）。他们都采用了某种形式的精益敏捷，都在 3C 问题上有很好的处理。

并不是说精益敏捷是这些公司成功的唯一原因，但对其成功有重要作用。而要想运用精益敏捷取得成功，需要对精益敏捷的逻辑有清醒的认识，进而设计自己的工作方式，并确保落地。

世界潮流，滚滚向前。环境在变化，不以我们的主观意志为转移。只有顺应潮流，并相应地调整自己的行为，一个企业才有可能基业长青。

逻辑二：三个核心

一家企业要能在 3C 环境中生存发展，需要处理好三个核心问题：

把握用户需求 ：一种业务，只有真正把握住用户需求，才有可能为供需双方实现价值。根据相关统计，整个软件行业的产品和功能有将近一半完全没人用，这是因不能把握用户需求而产生的最大的浪费。
提升效率 ：利润 = 价格-成本。提升效率，即是降低成本，提升利润。管理者的主要职责就是提升效率。而一家企业要在提升效率上有所作为，需要全体员工都能从提升效率中受益。
应对复杂性 ：在复杂性日益增长的时代，传统的慢时代的计划与控制的方法不再生效。应对复杂性，既需要从物的角度的科学逻辑方法，也需要从人的角度激励个体的参与和提升组织的合作。

而对这三个核心问题的处理方法分别是：

用 以用户为中心 来把握需求：贴近用户，了解他们真实的需求。
用 消除浪费 来提升效率：消除浪费即是提升价值。大野耐一说：一个典型的过程中，包含着 95% 的浪费。改善是无止境的。
用 探索式方法 来应对复杂性：采用多层次的 PDCA 循环，不断检视和适应。以团队合作全员参与推动 PDCA 循环。

案例：北电网络破产的原因，在这三个核心问题上都有所体现。

北电的错，看起来像是三大原因：一是技术路线选择的失误，二是对市场预估过于激进，三是内部缺乏有效的管理。

这正是所有技术公司都有可能面临的风险，技术路线的错误，对市场预估的失误，都有可能将一个技术公司拖入深渊。

其实北电的失误不仅表现在对技术市场的 “钝”，它对客户的需求也有些 “钝”。有人就认为，北电的失误是一味追求技术的先进性，而不考虑客户的需求。

以光纤为例，在互联网泡沫破灭之后，北电急急地投入到新一代大容量的研发当中，认为市场复苏之后，运营商就会大规模升级网络。

但当时全球刚刚经过一轮光网络的升级，10G 网络铺完成之后，网络上的业务还没有应用起来。在业务没有发展起来的情况下，运营商当然是不会感觉到网络的容量不够，所以也不会急着扩容。

相反，运营商着急的是如何把网络用起来。所以，北电的 “前瞻性技术” 并不被运营商所接纳。

北电并没有理解客户真正需要什么。这些年，电信运营商也处于转型期，一方面是网络的升级，另一方面，更为运营商所看重的是在现有承载能力上去挖掘业务潜力，而不是无度地投资。

近几年，全球电信业的低迷是有目共睹，这个低迷主要是因为运营商不再疯狂地投资在基础建设方面。对于整个行业的低迷，一些供应商很早就预见到并积极根据客户的需求转型，将企业网、融合通讯、电信专业服务等新业务作为拓展领域，所以不会像北电那样陷入如此的困境。

运营商是电信设备厂商的衣食父母，北电对运营商转型的心理抓得不准。所以，北电的几次转型并没有紧紧地贴着自己的客户去转型，而更多地将命运交给未来可能存在市场的超前技术。客户不会跟着北电走，北电就被无情地抛弃。

远离了客户的北电，越走越远。

至此，我们已经介绍了作为精益敏捷产生背景的 3C 环境，进而推导出精益敏捷所要处理的三大核心问题，及对应的三大核心解决思路。

下述内容是对三大核心解决思路的展开，主要是以 Scrum 作为落脚点。

如果不采用 Scrum，也要有相应的方法保证三大核心解决方案的落地。明白了其中的逻辑之后，可以自己设计自己的工作方式。社区中有很多关于 Scrum 的争论。

我的建议是，用什么或不用什么，要从目的和逻辑出发。只有明白了背后的逻辑，才能主动做出适合自己的选择。

逻辑三：三个核心在 PO 的体现

我们先看一个问题：职责与职位。一种职责可以由多个职位承担，一个职位也可以承担多种职责。从单个职位出发来看，最优的职位设置是没有意义的。

只有放在整个组织的系统中，以组织目标的完成程度来评价，才能看出整体职位设置的优劣。

职位与角色略有区别，敏捷当中更常用的的角色，更少强调地位，更多强调合作。要理解 PO（产品负责人）这个角色，可以从它的历史来源来看。

产品经理的起源

自 1927 年，美国 P&G（宝洁）公司出现第一名产品经理（Product Manager）以来，产品管理（Product Management）制度逐渐在越来越多的行业得到应用和推广，并且取得了广泛的成功。

当时公司推出一种佳美牌（camay）香皂，但销售业绩较差。公司刚启用的一名叫麦古利的年轻人在一次会议上提出：如果公司的销售经理把精力同时集中于 camay 香皂和 lvory（宝洁的一种老牌香皂）的话，那么 camay 的潜力就永远得不到充分发掘。

同时，他提出了 “brand man”(品牌人) 的概念 , 一个品牌人应该有一个销售小组的帮助，每一个宝洁品牌应当当做一个单独的事业在经营，与其它品牌同时竞争。

麦古利赢得了宝洁高层的支持。同时他的成功表现使公司认识到产品管理的巨大作用。之后，宝洁便以 “产品管理体系” 重组公司体系。

这种管理形式为宝洁赢得了巨大的成功；同时，亦成为全球产品管理的典范。

产品经理的产生，标志着从生产者市场向消费者市场的转移。众所周知的乔布斯是产品经理心目中的大神，一众追随者以某布斯的称号为荣。

PO 与产品经理尽管不完全相同，但产品管理依然是 PO 的核心职责，只是在管理方法上与敏捷方法配套。

XP（极限编程）中客户的概念

1993 年开始的 C3（Chrysler Comprehensive Compensation System）项目中，诞生了著名的 XP 方法论。

XP 重新定义了客户的概念。在 XP 中，我们希望客户、管理者和开发人员紧密地工作在一起，以便于彼此知晓对方所面临的问题，并共同去解决这些问题。谁是客户？XP 团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团体。

有时，客户是和开发人员同属一家公司的一组业务分析师、质量保证专家和 / 或者市场专家。有时，客户是用户团体委派的用户代表。有时，客户是真正支付开发费用的人。但是在 XP 项目中，无论谁是客户，他们都是能够和团队一起工作的团队成员。

最好的情况是客户和开发人员在同一个房间中工作，次一点的情况是客户和开发人员之间的工作距离在 100m 以内。距离越大，客户就越难成为真正的团队成员。如果客户工作在另外一幢建筑或另外一个城市，那么他将会很难融合到团队中来。

如果确实无法和客户工作在一起，该怎么办呢？我的建议是去寻找能够在一起工作、愿意并能够代替真正客户的人。

Scrum 中 PO 的概念脱胎于 XP 中客户的概念。

产品经理、项目经理和架构师的三角形

这个三角形更多是基于我在外企通信行业的经验。

产品经理隶属市场部门，当采集到需求后，会以特性需求规范的形式呈现。

特性需求规范会交给项目经理，项目经理召集人员理解需求，转化成特性技术规范，给出估算和规划。根据需求的复杂程度，决定是需要架构师参与，还是只需要一般开发人员参与。

整体上，产品经理、项目经理和架构师呈现出一个支撑项目的三角形，分别从产品管理、项目管理和技术管理的角度发力。

PO 的采用

接着上面的背景，在采用 Scrum 之后，我们是由架构师充当 PO。一方面他封装住了来自产品经理的需求，并转换为用户故事，而不再采用特性技术规范的形式。

另一方面，通过 Scrum 工作方式的采用，项目管理的职责被弱化，分摊到 PO 和团队身上，PO 也需要跟团队更密切协作保证需求被正确有效理解和实施。PO 本身的架构师背景也是一个优势，使他除了问题领域，也能理解解决方案领域。

我们采用 Scrum 和设置 PO 之后，除了作为核心诉求的交付周期的极大缩短之外，在质量和效率方面都有显著提升。

通过上面的溯源，总结一下 PO 角色设置的几个理由：

对于团队来说，他代表的是需求方。不管需求方有多少来源，PO 要能封装住需求方的需求。
PO 又与团队一道密切工作，保证需求的正确传递。
PO 是整个管道中非常关键的一环，需要有足够能力和得到足够授权。
Scrum 和 PO 角色的设置也是对整体管理的简化。

PO 角色的设置也许不是唯一可行的模式，但要想获得 Scrum 和 PO 角色设置的成功，高层管理和整个组织要对 Scrum 和 PO 套路有清晰完整的认识，合理的权力分配和严肃认真的执行。

以下介绍精益敏捷三大核心做法在 PO 的体现。介绍不求完备，主要是理清各个实践的逻辑因果，以帮助读者思考、拓展和实施适合自己的实践。

以用户为中心在 PO 的体现

价值发现和验证 ：

通过各种活动发现客户关注的价值，并获得验证。具体的活动包含客户访谈、客户论坛、给客户做演示、让客户试用产品等。

对于偏后端的产品，需要建立起内部用户的概念，把功能的使用方作为内部用户。功能的提供方和使用方需要协同一致建立起有效的价值发现和验证机制。

价值驱动 ：

主要是指需求的优先级排序。这涉及到两个问题：切割和排序。首先是把需求切割到合适的颗粒度，然后是对需求进行排序，按照二八原理，把最有价值的需求排在前面。这样，也为用户终止开发或变更需求提供了灵活度。参阅：Scrum 合同模式：付费止损，免费变更。

消除浪费在 PO 的体现

减少中间环节

在传统的组织当中，开发团队的两端都离用户很远。在需求侧，等到需要到达团队手里，已经经过了很多环节。

造成的问题，一是需求可能会失真，二是耽误了时间，三是不能直接获得反馈，这些都是浪费。在运维侧，通常是由专职的运维团队负责，开发团队在这方面也远离用户。

后者的解决方案是 DevOps，参阅：DevOps 的前世来生，从《目标》、《凤凰项目》到《持续交付》。

一个组织要在整体上变成精益敏捷型组织，是很困难的，背后涉及到高层管理的认知和责权利的转移。在不理想的情况下，PO 要想尽办法接近用户，缩短团队与用户之间的距离，排除因之造成的浪费。

成功的变革离不开权力。我们也看到过管理者的变换对团队造成的影响，比如说有的管理者是产品导向，只要有利于产品，可以打破既定部门分工的规则，而有的管理者则是规则和流程导向，缺乏打破常规的勇气。

清晰表达

PO 的需求表达的是否清晰，团队是最好的裁判，因为需求是给团队用的。归一化合乎逻辑的格式，是需求表达的有力工具，比如说用户故事和验收标准。

PO 的需求表达训练是值得投资的。有一个团队，最初的时候 PO 没有事先呈现需求，到了计划会上才与团队一道 brainstorm 需求，这当中蕴含着巨大的浪费和低效。后来经过对需求表达的学习和训练，整个团队的效率因此受益很多。

准备好

清晰表达是准备好的一个内容。准备好指的是在每一个活动之前，这个活动所需要的条件要准备好。

Scrum 中所用的术语是 DoR（Definition of Ready），在一个迭代开始前，相关物件和人员要达到准备好的状态。准备好是一个检查列表，示例如下：

需求要有清晰的商业价值。
需求要有明确的验收标准。
人员具备完成产品列表所需的技能。
依赖和风险被识别和管理好。

根据 Scrum 之父 Jeff Sutherland 的研究，准备好能使团队的效率倍增。参阅：从 Vision 到 Value，Backlog 精化带你飞。

颗粒度

不合理的颗粒度是一种浪费。颗粒度太大的需求，难以被理解，难以被估算，并因其模糊本性带来更多的沟通成本。而颗粒度太小的话，会增加管理成本。

用户故事是一种合适的颗粒度。用户故事的一些重要特征：

一目了然格式一致的表达。用户故事有两个部分：描述部分和验收标准。描述部分的常用格式是：As <用户>, I want <功能>, so that <目的>。验收标准可以有多条，常用的格式是：Given <前提条件>，When <动作>，Then<结果>。
鼓励推迟细节，只需有足够的信息以使项目前行。我们不需要一次性把项目的所有需求搞清楚，我们只需要在迭代之前把一个迭代要做的事搞清楚即可。而以用户故事作为基本单元，可以支持这种开发模式。
用户故事以合适的颗粒度，方便理解，方便排优先级，保证重要的事先做。随着时间的推移，不重要的事也许就不需要了。
用户故事鼓励通过交谈了解细节。强调对话而不是书面沟通。
用户故事的验收标准保证成果可以被审核验证。
以用户故事为载体，促进结构化沟通，使谈话有落地点。
从业务角度描述，可以同时被业务人员和开发人员理解。
用户故事的大小适合估算和做计划。颗粒度适合迭代开发。
支持随机应变的开发，检视和适应。
鼓励各方参与交流，传播隐性知识。

参阅：敏捷读书之用户故事：《用户故事与敏捷方法》解读。

探索式在 PO 的体现

快速反馈

《Scrum 指南》说，每个迭代都要构建一个 “完成”、可用的和潜在可发布的产品增量。Sprint 评审会议在 Sprint 快结束时举行，用以检视所交付的产品增量并按需调整产品待办列表。

在 Sprint 评审会议中，Scrum 团队和利益攸关者协同讨论在这次 Sprint 中所完成的工作。根据完成情况和 Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。

这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。

能否在迭代结束时交付可用的产品，是 Scrum 成功与否的试金石。而从各自为政到合作的建立则是对管理方式鸿沟的跨越。

《精益创业》对反馈有更系统化结构化的描述：

Leap（信念飞跃）：每一个商业计划都是从一系列假设开始的。把假设说得像真的一样，是创业者典型的超能力。正是因为整个企业的成功寄托在这一点上，所以它们被称为信念飞跃。
Test（测试）：一个最小化可行产品 MVP 有助创业者尽早开启学习认知的历程。它并不一定是想象中的最小型产品；它是用最快的方式，以最少精力完成开发-测量-认知的反馈循环。
Measure（度量）：一家新创企业的工作是：（1）严格测量企业目前的状况，正视评估中揭示的现实真相。（2）设计实验，从而了解如何让真实数据向商业计划中的理想目标靠得再近些。
Pivot（转型）：每个创业者在开发一款成功产品的过程中，迟早会面临一项重大挑战：即决定何时转型，何时坚持。

参阅：GitChat 的精益创业之旅。

分层计划

敏捷的计划有五层：

组合级 （Discussion）：在这一层，主要是跟产品决策委员会一起讨论哪些产品上还是不上。
产品级 （Envision，Funding，Roadmap）：在这一层，主要是确定产品的愿景、预算和路线图。
发布级 （Story Writing，Release Plan，PB Grooming）：在这一层，包括故事写作、发布计划和产品列表梳理。
迭代级 （Sprint Plan，Review）：这一层包括迭代的计划和评审。
每日级 （Steer Direction，Answer Question）：这一层包括方向的把握和回答团队的问题，这些是通过与团队在站会上和日常的互动交流实现的。

通过把计划分层，从更长期的角度是拥抱变化，从更短期的角度是扎实执行。通过行动排解近忧，通过变通容纳远虑。

参考：PO 工作指导：掌舵 3355 的迭代之河。

PO 的角色建立及按照三个核心思路有效发挥，需要管理者的认知与支持、PO 本人的学习，和周边组织和人员的配合。

逻辑四：三个核心在团队的体现

PO 是上游，团队是下游。PO 主要负责需求，是问题领域。团队主要负责解决方案领域。上下游的合理有效交接很重要。

在 PO 身上落实的三个核心思路，同样要落实到团队身上，但有有几个不一样的地方：需求交接问题，技术能力问题，多人合作管理问题。具体说明如下。

以用户为中心在团队的体现

清楚了解需求

与 PO 的清楚表达需求相对应，团队要做的是清楚了解需求。这可以发生在几个环节：

产品列表梳理会：产品列表梳理会是 PO 帮助团队理解需求的主要时机。团队可以用 DoR 要求 PO，在会议前的准备度达到准备好的标准。团队也要花一些时间准备，大致了解一下背景和上下文，跟需求混个脸熟，省得到时候一头雾水。现场可以用估算纸牌做估算。采用估算纸牌最重要的目的不是估算本身，而是揭示大家的不同理解和假设。
技术梳理会：如果是因为没有解决方案而妨碍了对需求的理解，可以增加一个技术梳理会，探讨解决方案，达到可估算的标准即可。
迭代计划会：是理解需求的第二道闸，提供了又一次澄清需求的机会。
日常工作和每日站会：如果还有不清楚的需求，团队有提问的责任，PO 有解答的责任。
迭代评审会：正常来说，到了迭代评审会不应该再有对需求的分歧。有的话，可以利用迭代回顾会找下原因，对症下药解决。

需求主要是 PO 的责任，但团队要主动参与理解，并且有质疑和追根到底的精神。

对于团队成员不主动参与理解需求的情况，通常是动机和合作的问题。功夫在诗外。需要从后面的权力结构和人的激励入手。

消除浪费在团队的体现

自管理

被管理，是一种浪费。对于管理者，投入是一种浪费。对于被管理者来说，被打断和被控制是一种浪费。最好的管理是自管理。

Scrum 的仪式用得好，就已经是自管理了。人人都是项目经理。

参阅：A1 大白纸计划法。

B=MAT，行为 = 动机 x 能力 x 触发。自管理的能力不难学习，Scrum 事件和流程就是触发，剩下的就是动机问题了。

跨职能

跨职能的含义是，一个团队要具备完成产品列表的全部技能，并且团队的技能分配足够均衡和充分备份，以至于能适配产品列表中对不同技能的需求量，和人员可以自由请假。

跨职能需要组织的政策支持和个人的认知改变。跨职能会加强一个人的能力而不是削弱一个人的能力。

参阅： Scrum 的跨职能团队建设游戏。

可视化

隐藏，是一种浪费。可视化的六个原则是：

可视化价值流动，有效管理创新全过程；
可视化拥堵，分析发现问题，加速流动；
可视化任务资源匹配，实现战术沙盘；
可视化决策规则，养育自组织团队；
可视化风险，管控创新风险；
可视化投入组合情况，平衡长短期利益。

参阅：可视化管理六原则。

流动

在前文流的历史中，已经对流动有所介绍。流动是精益思想五原则当中的重要原则。

在制造业的生产过程中，物有四种状态：

加工；
检查；
停滞；
搬运。

停滞是不流动，检查和搬运是可以优化的流动，只有加工是有价值的流动。

创造流动有三个步骤：

化身为物：把自己想象成被处理的工作，被处理的工作也是没有耐性的。
建立流动：排除障碍，让工作流动起来。
保持流动：把流动持续保持住。

故事泳道是一个在站会中辅助流动的工具。参阅：故事 X 人矩阵。

关于流动效率，参阅：研发组织该如何设计绩效体系。

纪律

技能 x 纪律 = 能力。敏捷对纪律有很高的要求。

几年前，我对 Scrum 有个总结：十论 Scrum 就是知行合一。

人人知行合一：人人计划，人人行动。
时时知行合一：时时计划，时时行动。
团队知行合一：团队决定，团队行动。
敏捷知行合一：快速决定，快速行动。
需求知行合一：接近客户，掌握需求。
支柱知行合一：检验是知，适应是行。
完成知行合一：定义完成，共识目标。
透明知行合一：高度透明，流畅过程。
纪律知行合一：自我纪律，助长能力。
美德知行合一：积极主动，集思广益。

纪律的建立，主要靠目标感，组织目标、团队目标和个人目标的对齐，和同侪压力。

参阅：我与 Scrum 的心路历程。

2014 年，柳传志在微博之夜上表示，联想要开二三十人的会，如果这个会是准时开的，谁迟到的话罚站一分钟；会议正开的时候停下来默哀式的让你站一分钟，这实际是个非常难过的事儿。

这件事情从 1990 年开始一直执行到今天，只要有一定做。包括我自己迟到也被罚过三次。国内商业诚信不好的关键是选择性执法，法律面前人人平等，没有人敢触犯法律。

柳传志的做法是否适合敏捷团队？答案是，只要大家都同意，就可以执行。

团队规模

根据各种研究，小团队是最有效地。其中最有名的说法是贝索斯的两个披萨饼团队。如果两个披萨不足以喂饱一个项目团队，那么这个团队可能就显得太大了。

《Scrum 指南》中说：开发团队最佳规模是足够小以保持敏捷性，同时足够大可以在 Sprint 内完成重要的工作。少于 3 个人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大。过小的团队在 Sprint 中可能会遭遇到技能上的约束，进而导致开发团队无法交付潜在可发布的产品增量。超过 9 人的团队则需要过多的协调沟通工作。对经验过程而言，大型开发团队会产生太多的复杂性而变得无用。产品负责人和 Scrum Master 角色不包含在开发团队人数中，除非他们同时也参与执行 Sprint 待办列表中的工作。

我曾经处理过一个 15 人以上的团队，开始时，大家都认为不可能分成两个团队，因为工作都耦合在一起。后来经过梳理，把工作分类，分成了两个团队，也运作得完全没有问题，效率比之前有很大提升。

完成标准

大野耐一对价值的定义是：

客户愿意为之付钱。
是一个过程。
一次做对。

对于软件开发来说，一次做对的说法不能机械应用，否则还要 Debug 干啥？有完成的标准，大致对应大野耐一所说的一次做对。没有完成的标准，就是浪费。

对于一个迭代来说，完成的标准包括两个方面：关于结果的和关于过程的。跟准备好的标准一样，完成的标准也是一个检查列表，示例如下：

发布到生产环境。
零已知故障。
用户文档的要求。
代码评审的要求。
单元测试的要求。
持续集成的要求。

前三者是关于结果的，是外部质量。后三者是关于过程的，是內建质量。

通过扩大完成标准的范围和提升完成标准的要求，也能帮助一个团队的自我提升。

探索式在团队的体现

小批量

迭代列表本身就是个小批量。

在迭代内部，我们还可以进一步运用小批量的概念。如果一个迭代有 10 个用户故事，到迭代结束时，每个都完成了 90%，这种状态不如有 5 个 100% 完成，有 5 个还没开始做。

这也是一种小批量思维。只要没有完成，80% 也好，90% 也好，都是不可靠的。

如果你的团队在完成上总是有困难，可以尝试更小的批量，大家通力合作，一次完成一个更小的批量，这既能提升效率，也促进合作，为更高的效率奠定基础。

快速反馈

除了在迭代层面的迭代评审的反馈，快速反馈还可以在迭代内部运用。

测试和代码评审都是反馈。结对编程、结对工作，和更紧密的协作都是加速反馈。

参阅：细颗粒度的协作。

分层规划

规划的分层跟在 PO 的那一部分的陈述是一致的。

PO 和团队在规划问题上的分工合作是：

PO 负责方向，包括产品愿景、路线图、用户故事优先级等。
团队负责估算。估算的原则是：让干活的人做估算。
团队通过估算，帮助 PO 理解成本并相应地调整优先级。
团队帮助 PO 理解业务故事背后可能涉及到的技术架构工作。
关于风险：PO 管理与客户有关的风险，团队管理与技术有关的风险，ScrumMaster 管理与组织和沟通有关的风险。

技术卓越

敏捷宣言的原则之一是：坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

技术永远是开发人员的核心能力。在需要快速响应的环境之下，技术提升是 Scrum 团队建设的重要内容。

参阅：众筹式知识分享在团队和组织的运用。

逻辑五：权力结构

敏捷的实施好比是在大海中潜水，在靠近水面的部分没什么大的障碍。前述三大核心思路在 PO 和团队的体现，更多是一些在靠近水面部分潜水的招式。

随着潜水深度的增加，就会遇到礁石。权力结构是一个礁石。

企业中的权力是如何产生的？薛兆丰有一个解释：

我不知道你有没有看过这样的场面，就是在旧社会很落后的时候，有一种职业叫纤夫。他们就是在岸上拉船的人，那是一种苦工。

一群衣衫褴褛的工人，在岸上卖力地把船从一个地方拖到另外一个地方，而这时候，这群辛苦工作的纤夫背后还有一位举着鞭子的监工，为什么会有这样的职业？

如果可以选择，你愿意当纤夫还是当监工呢？很多人会说那我宁愿当监工，被人抽还不如抽别人。但问题是为什么就没见到大家都变成了监工呢？

你要再想想这船是纤夫拉的，收入是他们挣的，凭什么他们挣来的收入还要分一块给这个监工，他们可不可以合计一下，说下次我们找到工作就不要这个监工了。

事实上，监工这个职位一直存在，我们需要对它进行解释。这个解释就是，纤夫们自己知道，他们自己会偷懒，他们会虚张声势地卖力，他们知道如果是这样的话，他们的总收入会下降。出钱请了一个人来鞭打他们自己，他们的收入反而会增加。

我们姑且把上文中的纤夫称为工资奴隶。然而，工资奴隶制无法满足现代经济的需要。在一个被全球化、放松管制、知识工作和新技术所颠覆的市场中，企业现在需要主动、创新、承诺、聪明、激情——而这恰恰与雇佣奴隶制截然相反。参阅：为什么敏捷正在吞噬世界。

因此，这种新型的工作者需要一种新的管理方式。一些人将这种方式称为敏捷组织运作。也有用别的标签的。但是不管它叫什么，它都不只是个新流程。这是一种完全不同的运作方式。

这在经济上更有成效。它对人类的精神有着巨大的潜在益处。它可以创造工作场所，使人类能够贡献他们的全部才能，为其他人类创造有价值和有意义的东西。

对于精益敏捷来说，合理的权力结构是怎样的呢？

共同目标

在 Scrum 团队中，PO、ScrumMaster、团队三个角色各有分工，但大家的目标是一致的，都是为了通过每迭代输出潜在可交付的产品增量来实现产品愿景和价值。

最近在一篇文章中看到一个团队的描述，我认为这是一个真正的敏捷团队，尽管不一定用敏捷的标签。参阅：挣来的普吉之行。

在小的创业公司，创始人的认知就可以决定一个团队的形态。对于大公司来说，建立真正的敏捷团队会有很多困难，但最高管理者的认知是阿基米德点。

共同责任

敏捷影响力第一人 Mike Cohn 说：在一个团队的迭代中，我不能说，我的任务完成了，而张三还有些任务没完成。

一个敏捷团队一荣俱荣一损俱损。如果一个团队的 ScrumMaster 获得了好的绩效，而团队成员普遍获得了不好的绩效，那么这个组织的管理是有问题的。

罗辑思维有个节操币制度：

每个员工每个月可以获得 10 张节操币，每张相当于人民币 25 元。他们可以用这张节操币在我们周边的咖啡厅和饭馆随便消费，还可以获得打折和 VIP 待遇，公司月底统一与这些饭馆结账。

但是，节操币不能自己使用，必须公开赠送给小伙伴，而且要在公司公示你为什么要把节操币送给他，说明具体原因。节操币成为了我们的硬通货，每月公司会公示当月节操王。

每年收到节操币最多的节操王，会获得年底多发三个月薪的奖励。所以，每个人都能看到一个公开的数字，这个节操币的交易情况，反映了每个人与他人协作的水平。

很少收到节操币的人，一定是协作水平和态度比较低的，而且是由全体员工每天的自然协作做出的评价，是一张张真实的选票。这种落后的人，会很快自觉改善，或者离开公司，他们会感受到强烈的压力。

参阅：罗振宇跨年演讲中的精益敏捷要素。

共建体系

上面的节操币制度已经是共建体系的一个例子。

在敏捷团队中，大小制度都可以由团队共建。最常见的一些有：

团队规范与工作协定。
完成的定义。
准备好的定义。

服务而不是权力

如果能做到上面三点，权力就不需要了。

这里有一个有决心改变权力结构的案例。参阅：J.P. 摩根运用 LeSS 框架实施大规模敏捷。

而对于大多数组织来说，彻底的改变是不容易发生的。管理者要有观念的扭转，从掌权者变为服务者：

在团队管理方面：将团队的自组织能力和经理们的有效领导相结合。
在投资管理方面：让团队从以计划为导向的思维方式转化到以价值为导向的思维方式。
在环境管理方面：在由各种流程和外部资源组成的组织环境中，高效地审视组织内各流程的设计以消除各种对组织资源的浪费。

权力是组织的障碍，主动变革才是出路。

逻辑六：人的激励

权力结构之外，不被激励是另一个暗礁。

对一个人绩效影响最大的是他的动机。参阅：B=MAT 在 Scrum 中的运用。

以下对动机的描述并无完备，只是列出常见的一些。

工资

工资这个东西，从公司的角度是成本，从员工的角度是生活的期盼，从两者关系的角度是交易。

要在这个问题上有所提升，员工需要创造更大的价值，公司需要在整个价值流中消除浪费，大家从创造的价值中分享收益。

奖金

从公司的角度，奖金是业绩完成超出预期的部分，从员工角度，奖金是对生活的改善。工资对应一个人的职责和能力，而奖金对应一个人对团队合作的贡献。

福利

福利包含可以物化的部分和不可物化的部分，比如弹性工作制和假期。

公平

要有广为接受的游戏规则。

关系

要有相对平等的关系。

逻辑七：ScrumMaster

ScrumMaster 是工作方式的化身。参阅：系统的化身—敏捷教练的人设。

ScrumMaster 所要做的如下：

逻辑与招式

ScrumMaster 需要精通精益敏捷的逻辑和招式。

获得授权

ScrumMaster 需要获得组织的授权，成为 Scrum 的化身。

建立流程

进而建立 Scrum 工作方式。

解决问题

还需要解决背后的各种障碍和问题。

逻辑八：与 PMBOK 对照

最后，我们从 PMBOK 五大过程组和十大知识领域的角度来检视一下敏捷。

五大过程组：

启动过程组 ：作用是设定项目目标。在 Scrum 当中，目标不是一次设定，而是分层和逐步调整，预测性和适应性并重。PO 负责产品愿景，团队负责迭代目标。
规划过程组 ：作用是制定工作路线。在 Scrum 中，有长期的产品路线图，中期的发布计划，短期的迭代计划，和每日计划。
执行过程组 ：作用是让团队按计划执行。Scrum 的做法主要有两点不同，第一是通过上述的五层计划，增加了适应性。第二是全员参与计划和执行，计划的人就是执行的人。
监控过程组 ：作用是测量项目绩效，并且尽量做到防患于未然。Scrum 当中的进度监控主要通过迭代燃尽图和发布燃上图，质量监控主要通过 DoR 和 DoD 来內建质量。
收尾过程组 ：作用是了结项目。在 Scrum 中，收尾划分到每个迭代，通过迭代评审和迭代回顾进行，一方面可以快速获得反馈，另一方面可以持续改进。

从五大过程组的角度来看，敏捷是把传统的大项目变成一个个小项目，大环套小环，把航母变成一艘艘快艇。每个小环依然有完整的五个过程，只是做法有所不同。

从每个小环中的学习，可以帮助增强大环。

参阅：1986 年第一篇关于 Scrum 的论文及內建（Built-in）思想。

十大知识领域：

整合管理 ：其作用是把所有方面贯穿起来。在敏捷当中，产品导向重于项目导向，产品列表是贯穿各种事物的线索。
范围管理 ：其作用是做且只做该做的事。在敏捷当中，范围被视为一个可变的要素。参阅：Scrum 合同模式：付费止损，免费变更。
时间管理 ：其作用是让一切按既定的进度进行。在敏捷当中，关注点放在流动和趋势，而不是严格的时间表。
成本管理 ：其作用是算准钱和花好钱。在敏捷当中，基于迭代增量式的开发，对成本的测量会更容易。
质量管理 ：其作用是满足需求。在敏捷当中，通过采用完成的定义来內建质量。
人力资源管理 ：其作用是让团队成员高效率地和你一起干。在敏捷当中，通过 Scrum 团队建设，更大化地协同团队的生产力。
沟通管理 ：其作用是在合适的时间让合适的人通过合适的方式把合适的信息传达给合适的人。在敏捷当中，通过 Scrum 框架来引导沟通。
风险管理 ：其作用是防患于未然。Scrum 的五层规划和团队自管理有利于风险管理。
采购管理 ：其作用是当好甲方。敏捷的迭代增量式可以帮助做出更具适应性的采购决定。
干系人管理 ：其作用是和项目干系人搞好关系并令其满意。在敏捷当中，通过透明化提升信任。

从十大知识领域来看，敏捷采用的是一种更柔性更透明更授权的方式。

总结

本文的重点是精益敏捷的八大逻辑 。

逻辑一 是精益敏捷产生的 3C 环境。

逻辑二 是因之产生的三大核心问题和三大核心思路。

逻辑三 和 逻辑四 是三大核心思路在 PO 和团队身上的体现。

逻辑五 和 逻辑六 是两个暗礁：权力结构和人的激励。

逻辑七 是作为精益敏捷化身的 ScrumMaster 的作用。

逻辑八 是敏捷与 PMBOK 的简单对照。

八大逻辑涵盖了两个根本元素：逻辑元素或科学方法，权力元素包括个体和组织结构。

八大逻辑祝你成功地设计和应用精益敏捷。

扩展阅读

精益敏捷书单
敏捷教练 V 形六步法
精益思想第六原则
敏捷老教练解读中国式敏捷
精益学问体系
Scrum 解析：当西方遇上东方