敏捷之道 | 如何消减协同合作中的认知偏差？
在敏捷开发中，让所有成员保持目标统一、步调和节奏一致非常重要，但是在团队协作中，认知偏差却在所难免。需求在不同环节中流转，是否存在某种途径能保证所有成员的理解一致，将偏差最小化？
今天跟大家介绍敏捷开发中共识建立的两大神器：DoR 和 DoD。
DoR 是什么？
DoR = Definition of Ready，即对「准备就绪」的定义，是敏捷开发中把控研发质量的第一道门。DoR 关注研发起点的质量，定义了用户故事可以被研发团队接受并进入开发阶段的最小要求，是需求准入的标准。
DoR 的价值在于，它规范了开发对象的质量底线，能够有效防止开发侧的资源、时间或精力的浪费：如果一个待开发的用户故事不符合 DoR 要求，那么研发团队有权将其退回，不在最近的迭代中开发它。
01 Garbage In, Garbage Out
引用 Brian Will 的观点：“用户故事「准备就绪」非常重要——将不完整或未优化的用户故事放入冲刺中会出现问题，因为它会遵循「Garbage In, Garbage Out」原则：如果开发人员处理的是不够详细或定义不充分的用户故事，他们就不会产生高质量的代码。”
Brian 认为一个「准备好的 Ready」待办事项应该是清晰、可行和可测试的。
清晰（Clear）意味着团队所有成员能够对同一个用户故事达成共同的理解。通过协作编写用户故事，并为高优先级添加验收标准，需求的清晰度可被提高。
可行（Feasible）要求用户故事能够依照 DoD 在一个冲刺中被完成，否则，该故事需要被进一步分解。
可测试（Testable）指用户故事可以使用某种方法确定其是否按照预期工作。验收标准确保每个故事都是可测试的。
02 DoR 的参考例子
用户故事符合 INVEST 原则
用户故事是清晰的
用户故事是可测试的
用户故事是可行的
用户故事已定义
用户故事验收标准已定义
用户故事依赖已明确
用户故事已由开发团队做过粒度划分
Scrum 团队已接受 UI 原型设计
指定场景的性能指标已明确
指定场景的可扩展性指标已明确
指定场景的安全指标已明确
验收用户故事的人已明确
团队都清楚用户故事所表达的意思
DoD 是什么？
DoR 关注待开发的用户故事，而 DoD 则更多地聚焦待发布的价值增量。
DoD = Definition of Done，译为完成定义，是用于把控研发质量的第二道门。它是需求准出的标准，通常呈现为一份清单形式的简短文档，定义了用户故事被视为「完成」所需要达到的最低验收条件，常由产品负责人 PO 和开发团队共同协商决定。
DoD 通过建立通用的标准，确保团队每位成员对价值增量的完成具有相同的理解，避免了团队内外潜在的认知偏差；同时，清单内容还能提升团队的信息透明度，辅助工作点数的评估和计划制定，推进故事的完成。
01 DoD 的内容范围
在敏捷开发中，「完成」意味着「无需进行更多工作，可直接交付」，因此 DoD 内容至少应涵盖设计、编码、集成、测试和记录等全套产品开发流程。
Brian Will 指出 DoD 通常会说明以下内容：
用户故事所处的操作环境和集成级别（哪个特定版本的 Linux、Android、iOS 或浏览器）？
需要输出什么级别的文档（自动生成的 Javadoc，还是完整的终端用户手册）？
有什么质量期望（用于演示的基本功能，还是功能完整且健壮的应用程序）？
有什么安全期望（无需安全审查，还是需要从代码审查、代码扫描到网络安全配置等各方面都要进行安全审查）？
有什么可扩展性期望（用于演示的 10 个并发，还是扩展至10 万个并发用户）？
02 DoD 的不同维度
Scrum 联盟按照需求的不同层次，将 DoD 分成三种级别：用户故事DoD、冲刺DoD 和发布DoD。
用户故事DoD
也称功能/需求DoD。它声明了故事可交付的底线，即用户故事应完成哪些事情才可以被判定为开发完成，达到可交付的标准。用户故事DoD 的制定可以从以下两方面考虑：
用户故事的描述及拆解符合 INVEST；
用户故事有验收标准，即 Acceptance Criteria。
冲刺DoD
或迭代DoD，定义了每个 Sprint 需要完成哪些事情，其输出才是可交付的。通常包含以下内容：
所有代码通过静态检测，严重问题都已修改；
所有新增代码都经过 Code Review；
所有完成的用户故事都通过测试；
所有完成的用户故事得到 PO 的验证。
发布DoD
发布DoD 定义了增量交付的最低要求，可以参考以下内容辅助制定。
完成发布规划所要求的必须具备的需求；
至少完成一次全量回归测试；
符合质量标准 (Quality Gate)，譬如所有等级为 1、2 的缺陷均已修复，3、4 级缺陷不超过 10 个；
有发布通知，即 Release Notes；
有用户手册；
产品相关文档已全部更新；
代码已部署到发布服务器上，并冒烟通过；
原始需求提交人完成 UAT；
对运维、市场、客服的新功能培训已完成。
此外，在子任务层面，敏捷团队也可以通过开发任务DoD 更好地规范任务完成，比如：
代码已经提交到 Git；
代码通过单元测试；
代码经过 Code Review；
代码通过集成测试。
03 DoD 的参考例子
代码已完成（所有代办事项已经完成编码）
代码已注释、已提交，版本库当前版本能正常运行
结对检视已完成（或者采用结对编程），代码符合开发标准
构建没有错误
单元测试全部通过
部署到测试环境并通过系统测试
通过 UAT（用户验收测试）并签字确认符合需求
任何编译/部署/配置变化都已实现/记录/沟通
相关文档/图表已完成或已更新
任务剩余的小时数已设置为 0，任务已关闭
Liga 总结
1. DoR 把控研发起点，是需求准入的标准。用户故事必须符合团队要求才能进入待开发列表。
2. DoD 把控研发终点，是需求准出的标准。它定义了价值增量交付的最低验收条件，适用于所有用户故事。
3. Garbage in, garbage out. 敏捷团队必须严格把控需求准入的标准，才能更顺利地推进后续工作，保证研发质量。
参考资料
1. https://resources.scrumalliance.org/Article/definition-dod
2. https://www.linkedin.com/pulse/definition-ready-dor-vs-done-dod-brian-will
往期推荐
点击👇下方名片关注 LigaAI
⭐星标置顶冲在敏捷第一线
⇙请在 PC 端点击阅读原文，访问 LigaAI 🏡
喜欢今天的文章，别忘了点赞👍鼓励哦~