关于敏捷开发:如何消减敏捷开发中的认知偏差

在麻利开发中，让所有成员放弃指标对立、步调和节奏统一十分重要，然而在团队合作中，认知偏差却在劫难逃。需要在不同环节中流转，是否存在某种路径能保障所有成员的了解统一，将偏差最小化？

明天跟大家介绍麻利开发中共识建设的两大神器：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 定义了增量交付的最低要求，能够参考以下内容辅助制订。

• 实现公布布局所要求的必须具备的需要；
• 至多实现一次全量回归测试；
• 合乎质量标准 (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.scrumallian…
2. https://www.linkedin.com/puls…

理解更多麻利开发、项目管理、行业动态等音讯，关注咱们的 sf 账号 -LigaAI~ 或者点击 LigaAI- 新一代智能研发合作平台，在线申请体验咱们的产品。