内容简介:零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。
零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。 了解详情
释放双眼,带上耳机,听听看~!
00:00
00:00
在之前文章中我们提到了,每个Sprint都要验收才能算结束,而验收标准遵循DoD原则。那么究竟什么是DoD原则呢?我们将在本文为您详细讲解。
一、什么是DoD?
当你有两个或更多的人参与同一个事情的时候,我们的“团队”就产生了,这时我们最重要的事情,就是要设定和统一团队的期望值;在本文中,这就是 “完成标准” 。
一个迭代做完后,团队要进行验收,来决定本个迭代是否完成。
但每个团队对于是否完成无法达成统一,有的认为编码完成,就表示任务完成了;有的认为还需要简单自测一下,确保功能可以正常使用;还有的认为需要把自动化用例写完并测试通过才算完成。
为了避免这个问题,在敏捷软件开发中,常用 Definition of Done“完成的定义” 来表示工作是否已完成,不同的活动有不同的完成定义。
首先要知道:所有的DoD都不是一成不变的,在随着时间的推移、经验的积累、成员的变更、项目的变更,我们的DoD也会有很大的不同,所以我们也需要定期地检查和改进。
二、DoD的分类
有了上面的思想准备,我们再来看下面的DoD定义,就会觉得并没有那么难了。
1. 迭代DoD
最典型的是迭代DoD,这也是最初DoD应用的地方。
常见的一些规则有:
- 所有代码通过静态检测,严重问题都已修改,静态分析的规则参见……
- 所有新增代码得到人工评审;
- 所有完成的用户故事都有对应的测试用例;
- 测试用例都已执行;
- 所有完成的用户故事得到Product Owner的验证。
2. 发布DoD
对于发布,一般就有更加严格的要求,发布DoD的典型条款有:
- 完成发布规划所要求的重点需求;
- 至少通过一次全量回归测试;
- 修复所有等级为1、2的缺陷;3、4级缺陷不超过20个。
3. 版本DoD
版本DoD就是针对每个版本上线前后的一些规则,比如:
- 产品文档已全部更新;
- 代码已部署到产品服务器上;
- 运维在验收测试环境上冒烟通过;
- 原始需求提交人对功能已经验收通过;
- 对运维、市场、客服的新功能培训已完成。
4. 每日DoD
其他典型的DoD有每日DoD,典型条款有:搭建每日构建环境,晚上自动静态代码检查、编译、部署和测试,每日修复前一日构建和测试发现的缺陷和问题。
- 下班前必须检入当天编写的代码,check in的backlog要填写清晰;
- 当天的代码必须在当天或者第2天邀请同伴进行代码评审;
- 检入的功能代码必须要有对应的单元测试(严格采用TDD);
- 每天晚上触发静态代码检查、自动化回归测试;
- 当天持续集成、构建环境中的问题,请当天解决。
5. 用户故事DoD
还有针对用户故事(或者用例)的DoD,比如:
- 用户故事最终的描述符合INVEST
- 用户故事得到测试用例的对应覆盖
- 用户故事得到对应的自动化测试用例
- 用户故事得到PO试用并初步认可
当测试集比较大的时候,无法在1天之内完成测试,可以开展每周全量回归自动化测试,这样就有每周DoD,典型条款有:
- 上上周发现的缺陷是否解决;
- 上周新增功能的自动化测试是否加入到每周测试集。
Tips:DoD 必须是团队在项目启动时共同讨论出来的,团队愿意共同遵守的原则,一旦确定,团队就应共同遵守。
三、DoD的实用价值
1. DoD是对软件有价值的活动的清单
DoD是一个简单的清单,包含了一系列的活动。
例如:编码、加注释、单元测试、集成测试、发行声明、设计文档等等,所有这些活动都能够给产品带来实际的价值。使用DoD,可以让团队集中在那些必须完成的事情上,同时让那些无用的,仅仅使软件开发变得复杂的活动被消除掉。
3. DoD是团队成员的主要状态参考依据
对于迭代最简单形式的汇报就只有一句话:“这个feature完成了”。
毕竟,一个feature或者一个product Backlog Item的状态只有两种:完成或未完成 。
DoD是对“feature完成了”这句话的最佳补充。使用DoD作为参考标准,团队成员可以迅速有效地让其他团队成员或PO了解状态。
3. DoD不是不变的
DoD随着时间会改变。
组织的帮助和团队能力的增加可以移除掉更多障碍,使得更多的活动可以包含到sprint或者feature的DoD中来。
4. DoD是一个可以被审视的列表
feature/用户故事在sprint plan meeting和sprint中都可以被拆分成task。
DoD可以用来衡量是不是所有的主要工作都被计划在内的(剩余的时间),而且,在一个feature或者sprint结束的时候,DoD可以用来考查是不是所有的必须的增值活动都已经完成了。
必须引起注意的是:DoD本身也是存在缺陷的。并不是所有的增值活动都可以应用到每一个feature上面,而DoD本身是一个大而全的检查事项的审核制度。团队需要基于一个feature来审视每项增值活动是否适用于这个feature。
比如说:追求用户体验对于web服务这样的feature来说可以加分,但是对于其他的一些feature来说就是不必要的了。
最后需要注意的是:对于验收标准,并不一定是由Product owner决定,要根据显示情况而定, 每个团队都要根据自己的情况选择合适的DoD原则 。
#专栏作家#
袁林,人人都是产品经理专栏作家。分享SaaS运营和企业管理/协作/办公的相关知识
本文原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自 Unsplash,基于 CC0 协议
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 面向对象基本原则(1)- 单一职责原则与接口隔离原则
- 面向对象基本原则(2)- 里式代换原则与依赖倒置原则
- 面向对象基本原则(3)- 最少知道原则与开闭原则
- 设计模式之软件开发原则(1)开闭原则和依赖倒置原则
- 面向对象设计原则之开闭原则
- 面向对象设计原则之开闭原则
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
游戏运营:高手进阶之路
饭大官人 / 电子工业出版社 / 2018-1-1 / 79.00元
《游戏运营:高手进阶之路》是一本系统的、成体系的、注重运营效能、强化系统思维、提升专业认知的书籍。《游戏运营:高手进阶之路》几乎完整覆盖了一个游戏运营人员日常工作中的方方面面,并从工作中具体的业务场景出发,归纳整理出各种解决问题的方法论。《游戏运营:高手进阶之路》为广大游戏从业者建立了完整的知识技能成长体系,包含两大岗位基本功—内容输出和协作推进,四大职业技能—活动策划、版本管理、用户运营、数据分......一起来看看 《游戏运营:高手进阶之路》 这本书的介绍吧!