言之无物

我说的一切都是错的

DevOps成长路线之DoR & DoD

《DevOps成长路线之DoR & DoD》

原文地址:https://www.linkedin.com/pulse/definition-ready-dor-vs-done-dod-brian-will

全景图

Backlog是Agile和Scrum里一个关键的制品,分为产品和迭代两个层级。

产品级backlog就是项目的代办列表,也叫需求池。项目范围内的所有事项,无论颗粒度如何,都归入产品backlog,经过排序——意味着排名第1的比第5的重要,同样,第5位的比第23位的重要。事项顺序通常是由商业价值驱动,由PO和开发团队一起协商,最终由PO决定。

项目范围通过用户故事的方式来记录,会随着后续的需求探索而变化。产品backlog由PO负责,并持续更新。

产品backlog是迭代backlog的来源。如果说产品backlog代表项目的需求池,那么迭代backlog 就是针对下一个迭代约定的范围,也代表着开发团队的交付承诺。

一旦大家认同并作出了承诺,迭代backlog通常不会再改变,以保证开发团队能够兑现诺言。

开发团队按迭代backlog从上到下的顺序开发(从最重要到不太重要),如果工作提前完成了,就从产品backlog的最上面依次取出额外的代办事项,放到当前的迭代中。

如果事项在迭代结束前没有完成,就放回到产品backlog中,在下一个迭代计划会中重新考虑。

新发现的需求以用户故事的方式加到产品backlog中,在未来的迭代中考虑。

定义“已准备”(DoR) vs 定义“已完成”(DoD)

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

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

  1. “清晰的”意味着所有的scum团队成员对该条目达成了共识。通过协同编写用户故事,对高优先级事项添加验收标准,有利于需求的澄清。
  2. “可测试的”意味着能通过有效的办法决定该条目是否符合期望。验收标准可确保每个故事都能被测试。
  3. “可行的”意味着根据DoD,该条目能够在一个迭代中完成。否则,条目需要进一步的分解。

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

《DevOps成长路线之DoR & DoD》

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

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

“DoD”通常会说明:
1. 用户故事所处的系统环境(哪个版本的Linux,Android,iOS或者浏览器)?
2. 需要输出什么样的文档(自动生成的javadoc,还是完整的终端用户手册)?
3. 有什么质量要求(用于演示的基本功能,还是一个功能完整,健壮的app)?
4. 有什么安全要求(无安全要求,还是从代码评审,代码扫描到网络安全配置等各方面都要求做安全审查)?
5. 有什么扩展性要求(10个并发,还是10万个并发)?

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

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

DoR的一些例子:

  • 用户故事是清晰的
  • 用户故事是可测试的
  • 用户故事是可行的
  • 用户故事已定义
  • 用户故事验收标准已定义
  • 用户故事依赖已明确
  • 用户故事已由开发团队做过粒度划分
  • Scrum团队已接受UI原型设计
  • 指定场景下的性能指标已明确
  • 指定场景下的可扩展性指标已明确
  • 指定场景下的安全指标已明确
  • 验收用户故事的人已明确
  • 团队都清楚用户故事所表达的意思

DoD的一些例子:

  • 代码已完成(所有代办事项已经完成编码)
  • 代码已注释,已提交。版本库当前版本能正常运行
  • 结对检视已完成(或者采用结对编程),代码符合开发标准
  • 构建没有错误
  • 单元测试全部通过
  • 部署到测试环境并通过系统测试
  • 通过UAT(用户验收测试)并签字确认符合需求。
  • 任何编译/部署/配置变化都已实现/记录/沟通。
  • 相关文档/图表已完成或已更新
  • 任务剩余的小时数已设置为0,任务已关闭

DoR和DoD另外的用法

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

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

小结

DoR和DoD就像流水线上的两道关,一个管进,一个管出。我们不像牛那么厉害,吃的是草,挤出的是奶。两道关把好了,质量再不达标,团队就没有借口可找,只能从自身找原因,去持续改善。

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注