Being Agile！敏捷团队的DoD-京东云开发者社区

## 亲，你的工作完成了么？

#### 情景：上线后的产品，出了个小问题
**同学A **：小C, XX 需求上线后有个小问题，但我们需要尽快改一下 
**同学C ：**那个需求我已经做完了，我现在在别的项目上，没有时间，而且那产品其实也不是我们负责的，你找别人吧！
**同学A :** . . . . . . . . ． … … ）＆ … … ％￥￥ 3 ￥＃ @

**大家猜猜看，小 A 后面要协调的人与事的路径有多长？**

在敏捷中，有个名词是DoD，是 Definition of Done 的缩写，表现形式是一组定义清晰的检查项，对一个任务／迭代／版本进行检查，都通过了，才称之为“完成”。

讨论“完成”这个概念，背后隐含一个名词叫做“职责”，“职责”的定义决定了某个角色工作的”完成”的定义。举个例子，产品经理的职责是负责向用户交付可用的产品？还是负责向用户和团队交付产品方案？前者的完成定义是，向客户能提供验收后可用的产品，而后者的完成定义是产品方案通过客户和团队评审的产品方案。再拿情景中的案例来说，小C认为的职责是开发需求，他的完成定义则为在工期内完成需求上线。很多时候我们容易把问题定性为“没有责任心”，其实这可能是一种懒政，当我们的脑海里出现“责任心”三个字的时候，需要先把团队的职责和DoD翻出来读一读，看看需不需跟进纠偏！

**所以，在定义DoD之前，一定要把团队中的角色与职责先共识准确。**

#### 敏捷团队的DoD，有以下几个维度：

**一、版本的DoD：**发布一个新的版本时的完成定义，可以包括： 
1. 在灰度环境内产品已验收完毕。 
2. 对集团和区域的使用用户培训已经完成。 
3. 版本发布后逐步部署到全国无问题。

**二、Sprint的交付DoD：**即一个迭代完成的定义，可以包括： 
1. 所有的 Userstory 都得到 PO的验证。 
2. 回归测试用例 100 ％通过。 
3. 新增测试用例无严重以上的缺陷遗留。

**三、交付阶段中的DoD：**即从需求提出到需求交付全流程中，各阶段的完成定义，以 coding 为例：
1. Userstory的功能已经实现 
2. 单元测试通过
3. 代码已提交到分支上且通过代码扫描

**四、每日工作的DoD**，还是以Coding为例：
1. 每天下班前至少要提交一次代码
2. 新增代码必须要有单元测试
3. 每天晚上触发静态代码扫描和自动化回归测试

DoD由团队自行定义，共同决策，别忘了前面提到到大前提：职责的清晰。DoD的定义完毕后，展示到看板上或者团队空间里，ScrumMaster要引导团队，严格遵守这些规则。

#### 问答环节
**问题：**我们使用过一段时间的看板，前问答环节期任务比较好记录，累积一定之后任务多且内容有些混乱，所以大家都不用了，请问有推荐有效使用看板的方法么？

**答：**首先当团队选择停止使用看板后，会采用什么方法来管理任务呢？ projeCt ? Excel？的确，看板并不一定是必须的选择，但往往是，看板被停止使用后，大家又退回到自己只关注自己的部分，看不到他人的工作内容，又变成了以管理者为中心的状态。

看板的另一个价值是通过透明化一切，将团队潜在的障碍浮现出来，当任务多且混乱的时候，正是我们要去察觉有哪些问题需要改进的机会。是不是我们做了过多的承诺？是不是某个环节返工太多？或者是团队对看板管理规则执行不到位？还是在除了看板，团队还有其他的管理手续，导致大家总觉得是在额外投入工作量维护看板？所以，需要你看看真正发生了什么呢？还记得敏捷的十二原则中“持续改进”么？只有持续改进，我们才增强敏捷的能力。

------------

###### Being Agile 京东物流技术发展部效能提升部
###### 作者：效能提升部 宋宁
![](//img1.jcloudcs.com/developer.jdcloud.com/8f0c52e5-49af-4ad4-ab58-7c28f112187020210107111536.png)