作为一个强技术背景的敏捷教练，我会更关注于敏捷的最核心单元 – 敏捷团队。
我们理想中的敏捷，应当是 强、有力且具备柔活性。
理想的敏捷状态
现实中，即使高层培训的再有敏捷思维，敏捷理念，敏捷意识，而团队的能力，没有变化时，其敏捷状况如同改造前的美国队长，很多事心有余而力不逮。
现实中的敏捷状态如同改造前的美国队长
在SAFe 5.0中，敏捷企业的七大核心能力之一，便是 “团队与技术的敏捷力”， 忽略这个核心能力，只会造成更多的痛苦和加班。
团队的能力建设是个持续的且需要时间的。我经常在思考如何更好的解决这个问题，帮助团队开启追求技术卓越之路。
这篇分享，诞生于第一届SAFe中国大会 ，当时考虑到，参会的大部分人，或许没有太多的技术背景，那么如何把一个技术的主题，变成一个不需要太多技术背景的人都能理解，并且能够带回的组织中，开箱即用，就是这个分享的主要目标。
一开始，我以为会来听的人不会太多，出乎意料的是，这个分会场，几乎坐满了。
上海的敏捷之旅，来听的人也都坐不下。
很开心的看到，关注团队能力成长的伙伴很多。
也希望分享的内容，能帮助更多的团队走向技术卓越。
1. 背景 – “敏捷团队” 常见的有趣问题
产品 – 开发 – 测试 以为的 “理解一致”
需求的”理解一致”
在需求沟通宣讲的过程中，经常可以看到的场景是，产品拿着原型和PRD对着团队一顿Blablabla的讲，然后问团队有没有问题，此时团队可能会提一下问题，测试伙伴的问题通常会多一些；很多时候是一顿安静 “没问题”。 好了，大家达成理解一致了，过下一个需求 ….。
然后，测试伙伴去负责写测试用例， 开发去负责写实现，一切很美好，到了联调的时候，尤其是多团队联调的时候，这个熟悉情景就在重演：
让我们把视角从最外层向最内层逐级放大看看:
- 客户(用户) 收到交付的时候，会对PO说这不是Ta想要的或者与Ta的要求有出入.
- 视角放大， PO验收开发团队的交付是，会说这个功能与Ta的要求有出入，按常理说, 这应当blablabla…..
- 视角再放大, 测试人员在收到开发提测的功能，会说这个功能不满足测试用例，blablabla….
- 视角继续放大，开发人员之间，前端与后端联调的时候，接口的参数与行为与彼此的预期也不一致。
每天都能看到这个场景
容易被忽略的缺陷发现成本
缺陷发现成本的变化
本图取自 SAFe 认证课程 Agile Software Engineering 敏捷软件工程
那么开发 – 测试 谁更懂需求?
由于经验也好 认知也罢, 多数团队中
- 测试比开发更懂需求，更清楚要实现的功能
- 实际干活的人经常不太清楚应该干到什么地步
- 常常变成测试在指导开发交付工作, 反复提测 反复打回
- 两者不一致时，引入 PO 仲裁， 一定几率爆出前面的 “PO-开发-测试 理解一致”
工作量的估算
人天？
常规的工作量单位，大家都喜欢用人天，为什么呢，因为和时间关联在一起，做项目计划就方便多了。
敏捷中却不提倡用人天，原因有几点：
- 人天(人时) 属于绝对估算，而非相对估算
- 很难找到作为标准的基准人天，每一项工作，不同水平的人用的人天是不同的
- 那么估算的人天，是谁的人天
- 通常就演变成，谁估算的人天，就默认谁做。这个工作，未来大概率还是会有Ta来做。最后演变成工作预先锁定人。
故事点？
敏捷中，在估算上倒是蛮一致的说，要用 故事点 来作为相对规模的估算标准。
有一篇很好的参考文章 故事点
听起来很美，于传统的人天绝对故事对比，有了明显的改进，至少理论上把估算与实现的人分离开了。
然而，据我观察的不少团队，操作起来却很骨感。
原因也有类似的:
- 基准故事点，也一样没那么直观 好找
- 不同团队的基准故事不同，估算规则也就不同，团队之间也就失去比较基础
- PO、用户对故事点的大小，缺乏直观的感知，你告诉他 8 还是 5, 对于他来说就是一个数字
- 一个故事，给不同团队，便会得到有不同的估算故事点，PO就容易困惑了
关于估算这个事情，我会单独写一下我的经验和认知, 先挖个小坑，感兴趣可以发信息给我。
号称“敏捷团队”了，过程中小瀑布味道却还很浓
- Sprint的前半段集中开发，后半段集中提测，修BUG
- 前端后端协作与联调的等待与同步
- 业务流程中用户故事之间的批次串行和等待
这些问题，在我接触过的团队身上，比比皆是。
我自己带的团队很快能摆脱出来；
接受过我的咨询辅导的团队也获得有效的改进，有些用的时间长，有些用的时间短，取决于团队自身的进取程度。
这些差异，让我不断的反思，如何更有效的帮助团队，让团队具备走出困境的能力。
这便有了下面的内容：
2. BDD – Behavior Driven Development 行为驱动开发
定义:
行为驱动开发（Behavior-Driven Development）（简写BDD），在软件工程中，BDD是一种敏捷软件开发的技术。
行为驱动开发(BDD)是测试驱动开发的延伸，开发使用简单的，特定于领域的脚本语言。这些DSL将结构化自然语言语句转换为可执行测试。结果是与给定功能的验收标准以及用于验证该功能的测试之间的关系更密切。因此，它一般是测试驱动开发(TDD)测试的自然延伸。
BDD 作为一种设计方法，可以有效的改善设计，并在系统的演化过程中为团队指明前进方向。
这里面我认为最重要的是最后的那句话 “BDD 作为一种设计方法，可以有效的改善设计，并在系统的演化过程中为团队指明前进方向。”
然而BDD相当长的一段时间没有过多人关注，与 “它一般是测试驱动开发(TDD)测试的自然延伸。” 这个表述有着很大的关系。
基于技术认知的BDD
通常大家对的BDD的认知，是在技术维度上的，包括我。
常见的一个BDD例子, 用BDD来驱动一个技术类的行为
推导出来的测试用例
这会有什么问题呢？
多年前，我看到BDD时，也是很兴奋，也练习了类似这个的例子。结果是，做完了，我便将BDD放到一边去了。
原因很简单：
- BDD说要业务人员参与，你认为业务人员会参与(或去看)一个技术实现类(Class) 的行为吗？
- 本身不会写单元测试的人，他玩不转这个BDD测试
- 能写这个BDD测试的人，他本身也具备单元测试TDD的能力和基础
那么，我既然能TDD，为何不直接直接写单元测试，比起BDD来，更直接了当。
这便把BDD锁在了技术这个维度上，TDD本来就小众，结果是BDD就更小众了。
基于用户故事的BDD认知
直到我接触了敏捷、用户故事 和 敏捷实践 (1) – 我们是如何自动化App验收标准里面发生的事情。
让我对BDD有了不同的认知， 那便是 —-
基于用户故事的BDD
既然是讲 Behavior 行为，那为什么要局限于技术维度呢？业务的行为应当是更合适的维度。
通过业务维度的BDD，我辅导的团队，通常能更好的前面的困境中走出来。
3. 用户故事与验收条件
既然BDD的行为，是从业务的行为开始，业务的行为，我们通常是借助 【用户故事】 来进行表达
用户故事
定义:
用户故事是从用户的角度来描述用户渴望得到的功能。
一个好的用户故事包括三个要素：
- 角色：谁要使用这个功能。
- 活动：需要完成什么样的功能。
- 商业价值：为什么需要这个功能，这个功能带来什么样的价值
示例:
作为 购书者
我要 根据作者姓名模糊查询书籍
这样(so that) 方便我找到要的书籍加到购物车
做为一名 极客
我想要提交我今天的工作日报
以便于其他人了解我的一天工作情况
关于用户故事的编写，又将会是另一篇分享的内容，可以先参考 【敏捷反思之三: 用户故事是否可以不写 “So that” ?】
验收条件 (Acceptance Criteria – AC)
之前将 Acceptance Criteria – AC 翻译为验收标准， Scrum中我们有 DoD (Definition of Done 完工标准), 为了避免混淆，Ethan 老师提议统一翻译成 验收条件 。
验收条件定义:
验收条件就是一系列可以接受的验收条件或者业务规则，且与功能或feature相互匹配和满足，同时也能被产品负责人和相关人接受。
验收条件可作为验收测试用例的具体例子。这也是我们常说的实例化需求，也是为了避免误读，让抽象的需求变得具体和可测试。
一个用户故事包含若干个验收条件，包括快乐路径（Happy Path）与异常场景（Exceptional Scenario）
验收标准是 最小化的、 无分支的 用户故事
用来 限定工作范围
最后的两点是我补充的
(验收条件可以作为后续要填的第三个坑)
验收条件的格式:
团队做敏捷转型，一开始就会遇到的两个拦路虎，用户故事 与 验收条件。
验收条件写的如何，甚至可以用来评价一个团队的需求分析和协作的水平如何。
要让团队接受通过验收条件来进行需求分析和确认，改变工作习惯，不是一件容易的事情。
需要让大家了解验收条件具有哪些作用，能够让大家在更好的理解和接受。
验收条件的作用
- 以用户的视角表达业务交互过程.
- 为PO与用户的需求理解上提供场景化、具象化的沟通和明确 (实例化需求)
- 有助于用户体验友好性的识别和改进
- PO与团队需求共识的标准和记录
- 可视化一个用户故事的粗细粒度
- 开发与测试对功能实现与质量的共识
- 作为结对工作的基础
- 自动化测试用例
- 需求完成边界的限定
- 比单纯故事点更为直观的工作估摸 估算标准
- 活文档
- 用户手册(帮助 FAQ)的素材
- 一个更公平透明的甲乙方的定价标准(敏捷合同的基础)
当然，还有其他作用，后面再补充吧。
我曾经开玩笑的说，我应该是第一个把验收条件的作用挖的最深的。
验收条件编写的实战技巧
在团队开始学习编写验收条件的前期，经常收到的反馈，便是：
- 验收条件编写很耗时, 写一个用户故事的验收条件，要一个小时 甚至更长
- 场景容易遗漏 尤其是异常场景
- 验收条件编写质量层差不齐, 不知道如何有效编写
在辅导过程中，我总结了一些编写的实战技巧，加速团队的能力变化：
- 先写快乐路径的场景标题
- 完成一个快乐路径的具体内容
- 以复制粘贴+微调的方式，快速完成剩余的快乐路径
- 对着快乐路径上的步骤，写成可能需要处理的异常路径标题
- 再以复制粘贴，完善每一个异常路径的具体内容
- 对验收标准进行价值排序
通过这种方式，能够大大提升编写验收条件的效率，场景完整性识别。
4. 基于用户故事的BDD
常规的BDD过程
基于用户为中心的BDD过程
用户故事和验收条件 与 BDD正好无缝结合
上面的验收条件，已经是很多新手团队在入门阶段时，写的算不错的了。但是，如果用这个进行开发，里面依然坑很大。
所以，验收条件需要明确化，向前一步，便是可以人工测试的验收条件。
可人工测试的验收条件
前一个验收条件，我们只能知道 在哪 要做些什么事情。 但是事情具体怎么做，是没有画面感的。
上面的可人工测试的验收条件，我们甚至可以通过验收条件中的步骤，反向推导出 UI原型 (最基本的交互元素)
这里讲一个好玩的真实故事:
我在18年的时候，帮助一个基金公司孵化的一个产品 – 约伴活动, 这个产品当时是外包给深圳某大厂中的一个小团队(产品经理 后端 前端 测试 各1名, 共4人，利用业务时间兼职接的单)， 预期工yu三个月，结果，到我接手的时候，实际已经干了七八个月了，每次交付的时候，一堆Bug，外加一堆实现与需求不符的改进问题。
我观察了两次交付之后，叫他们说，把测试计划和用例拿给我看看，结果丢给我一个简单的功能模块的思维导图，告诉我，这就是他们的测试计划和用例，当时，我下巴都快掉下来了，他们还跟我说，他们厂(深圳最大的游戏场)，就是这么工作的。
这简直颠覆我的大厂的认知呀。几个人，都还是30左右岁的大龄资深从业者了。
然后还说，交付质量不好 测试不到位，是因为测试人手不足，测试只有一个人，测不过来，其他人有不知道该如何测，帮不上忙。
实现与预期不符，外包团队说是需求变更，基金公司说是他们需求没理解到位。这个问题从day one就有，虽各执一词，却彼此都没有拿得出手的边界证明，就这么每次交付的时候，重复着这个场景，就这么从原来预期的三个月，干到了七八个月都还没能上线。
我便喊停了开发工作，要求通过验收条件来界定交付范围，和清晰场景。训练了那个团队如何编写验收条件，用了一个多星期，把功能故事与验收标准全部梳理一遍，召集整体进行确认。 验收条件规定怎么做，就怎么做。做少了 偏了 就是外包团队的问题；基金公司提出验收条件之外的东西，就属于需求变更，可以重新谈费用。
其结果就是，有了验收条件后，人人都能够根据验收条件做测试，基金公司这边的另一个小团队也能投入帮忙做验收，两个Sprint，项目便交付上线。
可人工测试的验收条件实例：
再进一步，可人工测试的验收条件，便能成为 可自动化测试的验收条件
UI自动化测试
讲到UI自动化测试，常见的几个问题
- 谁来写？
- 谁维护？
- UI自动化测试什么时候写？
- 功能稳定后写?
- 功能开发完成后写？
- 功能开发过程中写？
- 功能开发前写？
- 什么是UI自动化测试脚本？
是RobotFramework的代码？
是Cucumber的代码?
我发现绝大多数人的UI自动化测试认知是错误的！
有效的做法是：
- 谁来写？—— (开发团队 + PO)
- 谁维护？—— (开发团队 + PO)
- UI自动化测试什么时候写？——应当是在 功能开发前写
- 什么是UI自动化测试脚本？——验收条件才是UI自动化测试脚本， 那些 RobotFramework Cucumber的steps，只能称为基础性支撑脚本。
验收条件 才是UI自动化测试脚本
BDD的UI自动化测试带来哪些收益
- 用户故事拆解验收标准完成，即测试用例也完成
- 不再是单纯依靠测试人员写，有效缓解测试人员的工作负载
- 测试用例团队共同维护，需求变更带来的测试用例维护成本，近乎为零
- 测试左移
- 由于自动化测试在开发人员实现功能前，就已经准备好开发过程中的自测工作量，最大可减少为原来的三分之一
- 迭代内交付质量至少可以提升50%+
- 相同功能的用户端(Web App 小程序 H5 …) 越多，增加的工作量近乎为零
- 每个迭代都能自动化跑全回归，而非妥协式的局部回归
验收条件自动化的示例：
运行录屏 B站传送门 工作日志验收标准自动化录屏
测试金字塔模型？
这些模式的演变过程，可以再来一篇文章解释 (坑继续挖).
5. 单团队的用户故事BDD是如何进行的?
Scrum团队的开发节奏
其中，PO-开发-测试每日 “协作” 的基础便是用户故事与验收条件.
敏捷团队，大家都知道要基于用户故事来进行开发和协作，道理都懂，很多团队呢还是在迭代前半部分集中开发，后半部分提测，迭代中的小瀑布很明显，这点大家都很容易识别出来。
玩的好一点的团队，能够一个故事一个故事的交付，这看起来似乎满足要求，但是，这些玩的”好”的团队，也依然普遍存在另一个瀑布模式，就是单个故事看起来是一个个交付，是可以了，但是整个业务流，却还是在最后的时间才能串联起来验证。然而满足业务流完整性才是交付的重点和目标。
因此，我们可以通过，用户故事地图，把用户故事的上下游可视化出来，通过上下游的依赖关系作为优先级，从而令到整个业务流程，在迭代的前半部分便能完整串联和验证，而不是把业务流程的整合风险放到最后。
这种方式，便正式基于用户故事为中心的BDD。哪怕你没能做的验收条件的自动化，全靠人手测试，我戏称为 人肉BDD，也已经能为团队带来50%+的能效提升。
6. 多团队的基于用户故事BDD
单团队中的内部依赖等待问题，在多团队中，N倍存在，而且还容易造成很大的计划 沟通 协调 同步 成本。
解决的方式，依然以透明依赖，并且反过来，用依赖来驱动多团队的协作.
在SAFe中，PI活动能够有效帮助我们一起识别这些依赖。
通过更高视角的用户故事地图，来识别并规划团队间的故事优先级
持续的通过依赖顺序的反转，来打通多个团队直接的业务数据流。
7. 总结
我们做了这些，至少要知道，团队和组织，从中能获得哪些帮助和收益，有回报才能继续。
这上面的收益，是具备叠加效果的。
也就是说，
仅做到了第一、二点，团队的能效便能提升 20%~30% 以上，这两点还仅仅是改进了做事的方式，还没牵涉到团队技术实践(eg. TDD)上的改变, 便能收获到的。
从团队实践的观察来看，快的团队，大概两到三个月能够做好这一点，慢的团队有四到五个月的。
你可能未必有直观的理解，提升 20%~30%是什么概念？
那么我给你个数据，我们每天的工作时间是 8小时，提升 20%~30% 意味在，多出2个多小时，意味着，你能够在原来996的事情，你能够在正常工作时间内完成。 在公司不再加码的情况下，你从需要996的时间才能交付的东西，变成了正常工作时间就能交付。
原来996的时间，你便可以用来学习，提升，改进，还技术债。
看，消灭996，是不是没那么难呢？
从上往下的每一步，都是团队成长的自然进程，而且，当前的每一步都是在团队当前的能力情况下，稍微努力便能达到的。
而且，当前的这一步，做到了，团队自然而然的，就会往下一步前进，因为，收益的正向反馈。
这条路径，正好是团队成长的快乐路径。
在这个过程中BDD TDD，也就是自然达成的。
我也多次在交流中表达，BDD TDD难，是因为 姿势不对， 路径不对，以及开发语言不对。
作者：周辉庆，Scrum中文网资深敏捷顾问和培训师，敏捷教练
