文档首页 > > 理论实践> 持续规划与设计>

DoD,真正把事做完

DoD,真正把事做完

分享
更新时间:2021/02/27 GMT+08:00

DoD, Definition of Done

Scrum最重要的概念之一,就是对每个Sprint Backlog条目要有非常明确的Done的定义。譬如,对一个典型的编码任务而言,对其Done的定义应该涉及如下几个方面:

  • 设计文档必须经过评审。
  • 功能应该完全实现(包括错误处理、性能、可靠性、安全性、可维护性及其他质量标准)。
  • 代码符合编码标准。
  • 有UT并测试通过。
  • UT的代码覆盖率(Code coverage)>80%。
  • 至少有一个人做过代码评审(Code review)。
  • 代码已经提交。

只有这样,我们才容易对两件事情达成共识:其一,如何做才算完成一项编码工作?其二,shippable quality(可交付的质量标准)到底意味着什么?如果这些定义不清晰,以后你会花更多的时间和精力,并且修正会更难。

通过敏捷,我们期望在较早的阶段就给出高质量的交付,而不是依赖于最终阶段的长期"稳定",如果我们在前期就尽一切努力预防Bug,长远来看,我们会更省时间,发布得更早。对每一个任务都明确定义Done是非常关键的。

面对现实,Quality Sprint(质量冲刺)

如果一切遵循计划,并能对每个组件持续集成,那么,专门的Sprint用来做Bug修复将是某种意义的反模式。但是我们应该面对现实,大型软件项目通常都需要复杂的集成,存在后期发现的未知因素。对于一个几千行代码的小项目,可以不需要专门的错误修复阶段,但对大型项目却不可避免,都需要一个所谓的Quality Sprint(质量冲刺),集中在修复Bug上。在这个Sprint,要继续沿用敏捷方法,在产品发布之前不再开发任何新功能,直到ZBB。ZBB就是Zero Bug Bounce(零缺陷反弹)的缩写。是产品不再有Bug的一个时间点。在这个点,开发团队可以声称他们的产品质量达到最高,从此以后,才可以开发新功能。

有一些团队做了一个折中,那就是对Bug进行分级,比如分成Critical(关键)、Major(重要)和Minor(次要)等级别,然后要求能够发版的软件必须是“Zero Critical, no more than 5 Majors.(零关键缺陷,不超过5 个重要缺陷)。”

在修复Bug的阶段,可以不采用Scrum的实践,但是如果采用,会更有价值。一个软件项目的发布周期很长,历史积累下来的Bug一定不少。对每个Bug根据其重要性设定优先级,并放到Sprint Backlog后,开发人员和测试人员就可以协同工作,确保修复较高优先级的Bug。

Scrum不应被认为是一种“额外开销”,Scrum本身是一个轻量级的框架过程,尽管任何过程都会带来某种程度的“额外开销”。单就修复Bug,并仍采用Scrum而言,可以带来几个好处:第一,每天站立会议可以确保更好的交流与合作。第二,收集Bug修复统计数据,有利于在未来做出更好的计划(如平均每个Bug的修复时间,用到未来的Bug修复时间估算)。第三,经常回顾,让团队不断提高。第四,团队可以在Sprint内部根据情形,自主调整优先级。第五,团队继续把注意力放在重点事情上,并且可从Scrum Master处获得帮助。

敏捷软件开发的实质

一切回归自然,按照事物本身的发展规律去做:开发团队也不会为了追赶进度,而牺牲软件的内在质量;市场团队也会重新认识客户需求的价值所在,做好优先级排序,而不会不明就里地要求全部完成。这样的开发过程才是合理的,才是软件开发的本质。

DoD的要点

  1. 为Sprint中任务给出明确的Done定义是非常重要的。不过即使遵循这个最佳实践,但最终仍然会有集成问题,会存在Bug,还有后期的需求变更。所以,对于大型复杂产品,在正式发布前,单独计划1~2个Sprint,专门做Bug修复,也是合理的。
  2. 关于完成/DoD的例子,通常需要从以下几个维度考虑:
    • 需求/用户故事DoD
      • 用户故事的描述及拆解符合INVEST。
      • 用户故事有验收标准AC(Acceptance Criteria)
    • 开发任务DoD
      • 代码已经提交到代码库
      • 代码通过单元测试
      • 代码经过Code Review
      • 代码通过集成测试
    • 迭代DoD
      • 所有代码通过静态检测,严重问题都已修改
      • 所有新增代码都经过Code Review
      • 所有完成的用户故事都通过测试
      • 所有完成的用户故事得到Product Owner的验证
    • 发布DoD
      • 完成发布规划所要求的必须具备的需求
      • 至少完成一次全量回归测试
      • 符合质量标准(Quality Gate),所有等级为 1、2 的缺陷均已修复;3、4 级缺陷不超过10 个
      • 有发布通知(Release Notes)
      • 有用户手册
      • 产品相关文档已全部更新
      • 代码已部署到发布服务器上,并冒烟通过
      • 原始需求提交人完成UAT
      • 对运维、市场、客服的新功能培训已完成
  3. 完成的定义(DoD)及团队工作协议必须是团队共同讨论出来的,团队愿意共同遵守的原则,一旦确定,团队就应共同遵守。

DoR与DoD

除了文中提到的“完成的定义”(Definition of Done,DoD),还有“就绪的定义”(Definition of Ready,DoR),两者有什么区别呢?

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

  • Clear(清晰),用户故事描述清晰。
  • Feasible(可行),用户故事可以放入一个迭代。
  • Testable(可测试),验收条件得到定义。

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

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

最初DoD只有一级,即研发迭代完成,用户故事可以被视为完成的标准。逐渐出现了多级的DoD,针对每一个研发阶段,有了这一阶段的DoD标准,例如从亨里克·克里伯格(Henrik Kniberg)的看板启动示例(Kanban kick-start example)图中可以看到,有分析阶段的DoD,开发阶段的DoD,验收测试阶段的DoD等;典型的Kanban是拉动的过程,后一阶段拉取上一阶段完成(Done)的工作时,会检查相应的DoD是否完成,因此上一阶段的DoD事实上就是下一阶段的DoR。越往前的DoD越偏业务,然后是偏技术实现,越往后的越要加入运维和非功能性要求。

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

本文内容节选自《敏捷无敌之DevOps时代》,作者:王立杰、许舟平、姚冬(清华大学出版社)。

分享:

    相关文档

    相关产品