写点什么

如何消减敏捷开发协作中的「认知偏差」?| 敏捷之道

作者:LigaAI
  • 2022 年 7 月 29 日
  • 本文字数:2287 字

    阅读完需:约 8 分钟

如何消减敏捷开发协作中的「认知偏差」?| 敏捷之道

在敏捷开发中,让所有成员保持目标统一、步调和节奏一致非常重要,但是在团队协作中,认知偏差却在所难免。需求在不同环节中流转,是否存在某种途径能保证所有成员的理解一致,将偏差最小化?


今天跟大家介绍敏捷开发中共识建立的两大神器: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.scrumalliance.org/Article/definition-dod

2. https://www.linkedin.com/pulse/definition-ready-dor-vs-done-dod-brian-will


发布于: 4 小时前阅读数: 30
用户头像

LigaAI

关注

新一代智能研发协作平台 2021.02.23 加入

AI赋能工作场景,想要做最懂开发者的智能研发管理平台~

评论

发布
暂无评论
如何消减敏捷开发协作中的「认知偏差」?| 敏捷之道_程序人生_LigaAI_InfoQ写作社区