owner是什么意思

本文部分内容,节选自—— 《敏捷无敌之DevOps时代》第18章 ”DoD,真正把事做完“

本文部分内容,经授权,节选自“侬家铺子“的文章: DevOps成长路线——DoR vs DoD

上文翻译自:https://www.linkedin.com/pulse/definition-ready-doTTtjAqAr-vs-done-dod-brian-will

一、DoD 与 DoR

一个迭代是固定时间的循环,依次把迭代backlog上高优先级的任务变成产品增量。但是,要把事项顺利拉到当前的迭代中,如何定义用户故事“已经准备好”是很重要的——把没有完成或没有细化的用户故事放到迭代中,会在开发阶段产生问题,因为它遵循一个古老的原则:“进去的是垃圾,出来的也是垃圾”。如果开发基于没有充分细化或定义的用户故事来开发,他们不太可能产出高质量的代码。

一个“准备好”的backlog事项应该是清晰的,可行的,可测试的:

  • “清晰的”意味着所有的Scrum团队成员对该条目达成了共识。通过协同编写用户故事,对高优先级事项添加验收标准,有利于需求的澄清。

  • “可测试的”意味着能通过有效的办法决定该条目是否符合期望。验收标准可确保每个故事都能被测试。

  • “可行的”意味着根据DoD,该条目能够在一个迭代中完成。否则,条目需要进一步的分解。

简单的讲,DoR定义了一些标准,用户故事在开始估算或者进入迭代前,必须先符合这些标准。

owner是什么意思

“DoR”关注用户故事级别的特性,“DoD”的关注点则在迭代或者发布层面。本质上,“DoD”代表着迭代或者发布的验收标准。它清楚的列出了为完成产品增量,开发团队必须要达到的要求。

二、DoR是什么

DoR是一个待办(backlog)是否能够被团队接受,认为可以作为开发候选所需要达到的最小要求,是团队针对PO的要求。

一个DoR的例子:

  • Clear,用户故事描述清晰;

  • Feasible,用户故事可以放入一个迭代;

  • Testable,验收条件得到定义 。

需要注意的是,DoR只需要针对产品待办列表PBL中高优先级的需求进行,通常是准备能够满足两个迭代的即可。PBL越是近期会做的,需求越清晰,越是符合INVEST原则;越是暂时不会做的,不需要花太多精力去澄清和拆解。

而DoD则相反,是PO针对团队的产出进行验收的最低验收标准,文中已经给出了样例。

最初DoD只有一级,即研发迭代完成,用户故事可以被视为完成的标准。逐渐出现了多级的DoD,针对每一个研发阶段,出现了这一阶段的DoD标准,例如从Henrik Kni原由网berg的Kanban kick-start example图中,分析阶段的DoD、开发阶段的DoD、验收测试阶段的DoD等;典型的Kanban是拉动的过程,后一阶段拉取上一阶段完成(Done)的工作时,会检查相应的DoD是否完成,因此上一阶段的DoD事实上就是下一阶段的DoR。

越往前的DoD越偏业务,然后是偏技术实现,越往后的越要加入运维和非功能性要求。

2.1 DoR的一些例子

  • 用户故事是清晰的

  • 用户故事是可测试的

  • 用户故事是可行的

  • 用户故事已定义

  • 用户故事验收标准已定义

  • 用户故事依赖已明确

  • 用户故事已由开发团队做过粒度划分

  • Scrum团队已接受UI原型设计

  • 指定场景下的性能指标已明确

  • 指定场景下的可扩展性指标已明确

  • 指定场景下的安全指标已明确

  • 验收用户故事的人已明确

  • 团队都清楚用户故事所表达的意思

三、DoD是什么

“DoD”是开发团队和PO对每个用户故事需要做什么的协定 – 通常在公司层面统一标准,以保证交付质量一致。

“DoD”通常会说明:

  • 用户故事所处的系统环境(哪个版本的Linux、Android、iOS或者浏览器)?

  • 需要输出什么样的文档(自动生成的Javadoc,还是完整的终端用户手册)?

  • 有什么质量要求(用于演示的基本功能,还是一个功能完整,健壮的APP)?

  • 有什么安全要求(无安全要求,还是从代码评审、代码扫描到网络安全配等各方面都要求做安全审查)?

  • 有什么扩展性要求(10个并发,还是10万个并发)?

本质上说,“DoD”是基于验收标准的协议,PO在迭代结束时同它来验收产品增量。

请注意,针对迭代和发布阶段,DoD标准可能会不一样。中间迭代的DoD,比起临近发布的几个迭代,要求不会那么严格。

3.1 DoD的一些例子

  • 代码已完成(所有代办事项已经完成编码)

  • 代码已注释、已提交。版本库当前版本能正常运行

  • 结对检视已完成(或者采用结对编程),代码符合开发标准

  • 构建没有错误

  • 单元测试全部通过

  • 部署到测试环境并通过系统测试

  • 通过UAT(用户验收测试)并签字确认符合需求。

  • 任何编译/部署/配置变化都已实现/记录/沟通。

  • 相关文档/图表已完成或已更新

  • 任务剩余的小时数已设置为0,任务已关闭

3.2 DoD,通常需要从几个维度考虑

为Sprint中任务给出明确的“Done”定义是非常重要的,但即使你遵循这个最佳实践,最终仍然会有集成问题,会存在Bug,以及晚期的需求变更。所以,对于大型复杂产品,在正式发布前,单独计划1~2个Sprint,专门做Bug修复,也是合理的。

关于DoD的例子,通常需要从几个维度考虑。

1)需求/用户故//www.58yuanyou.com事DoD

  • 用户故事的描述及拆解符合INVEST;

  • 用户故事有验收标准AC(Acceptance Criteria)。

2)开发任务DoD
  • 代码已经提交到Git;

  • 代码通过单元测试;

  • 代码经过Code Review;

  • 代码通过集成测试。

3)迭代DoD
  • 所有代码通过静态检测,严重问题都已修改;

  • 所有新原由网增代码都经过Code Review;

  • 所有完成的用户故事都通过测试;

  • 所有完成的用户故事得到Product Owner的验证。

4)发布DoD
  • 完成发布规划所要求的必须具备的需求;

  • 至少完成一次全量回归测试;

  • 符合质量标准(Quality Gate),譬如所有等级为1、2的缺陷均已修复;3、4级缺陷不超过10个;

  • 有Release Notes;

  • 有用户手册;

  • 产品相关文档已全部更新;

  • 代码已部署到发布服务器上,并冒烟通过;

  • 原始需求提交人完成UAT;

  • 对运维、市场、客服的新功能培训已完成。

Tips:DoD及WA必须是团队共同讨论出来的,团队愿意共同遵守的原则,一旦确定,团队就应共同遵守。

四、DoD和DoR应该上墙

无论是用物理的Kanban、TaskBoard,还是电子的,建议将定义清晰的DOD,显式的张贴出来。下图就是很好的例子,便于所有人对齐想法,并且在板子上进行挪动时,无论是挪到Done的专题,还是拉到下一个状态,都可以随时看到DoD的标准,提醒所有人遵守并检查。保证每个人对一件工作是否完成有一个统一的认识,交付和接纳时时也保持清晰的交接界面。

owner是什么意思

五、DoR和DoD另外的用法

DoR和DoD的本意是创建一份简明的文档,用于在项目干系人,PO和开发团队间达成一致。但是,随着越来越多的工作被外包或分包, DoR和DoD也更多的用于合同协议和SOW,用以清楚、准确阐述对于需完成工作的期望。

DoR和DoD是很实用的项目范围商议工具因为它们定义了期望和双方的职责;DoR帮助客户产出良好的用户故事,为开发团队所用;DoD帮助交付伙伴根据整体项目需求产出可工作的产品增量,而不仅仅是特定的用户故事功能。

六、小结

DoR和DoD就像流水线上的两道关,一个管进,一个管出。我们不像牛那么厉害,吃的是草,挤出的是奶。对团队来说,第一道关更加重要,正如作者说的,进去的是垃圾,出来的也是垃圾。没有DoR的把关,后面的持续改进,工程实践效果都不TTtjAqA会太好。

ACE葫芦兄弟集结,带来系列课程【IDCF训练营|ACE JIRA实战训练营】, 现在购买可享受团购优惠价哦~

内容版权声明:除非注明原创否则皆为转载,再次转载请注明出处。

文章标题: owner是什么意思

文章地址: www.58yuanyou.com/baike/19334.html

相关推荐