小组DOD
- 所有代码通过eslint静态代码检测；
- 所有代码的提交需要通过人工审核；
- A类bug（系统崩溃、闪退等）必须修改，其他bug由需求决定是否必须解决；
- 每个用户故事都通过测试用例验证；
- 产品开发完成后，通过PO、UE和UI的验证；
小组DOD的建立
起因
我们部门在18年的5月份开始引入敏捷研发模式，并不是自主引入，而是被公司的研发管理部引导开展，研发管理部主要就是负责在各个大部门开展敏捷推广，在这种情况下，我们部门三十多人被划分成了四个敏捷小组。
在敏捷小组成立之初，对于很多的机制都不甚熟悉，主要了解的就是计划会、每日站会、演示会和总结会，每个小组都在按照这个模式进行，好坏不论，但终归还是在逐步进行了。做的多了，看的多了，也就对敏捷研发有更深入的理解。对于DOD，其实一开始引导我们开展敏捷模式的master就已经给了一份公司的参考样例，只是当初大家对敏捷都不熟，DOD也就没人在意了。
在进行敏捷活动过程中，会遇到各种各样的问题，包括因开展敏捷产生的问题和实际开发过程中的问题，当然后者的比重更大一些。这些问题中有相当比例是和DOD相关的，当时大家对于DOD还很陌生，重申DOD的定义是有必要且必须的。DOD的建立过程是大家就某事达成共识的过程。
议程设计：
- 明确主题，建立小组的DOD。（1分钟）
- 什么是DOD，引导大家明确定义和理解。（15分钟）
- 在之前的多次迭代中，列出遇到了哪些和DOD相关的问题。（40分钟）
- 把这些问题归类。（10分钟）
- 对归类问题进行分析，做到什么标准，算是完成，列出标准。（15分钟）
引导过程
角色：master
- 阐明会议主题，建立小组的DOD。
- 设定五分钟时间，让大家思考什么是DOD。
- 每人发言，讲出自己对于DOD的理解。在探讨中熟悉DOD的定义及意义。
- 设定10分钟时间，让大家在纸条上列举在之前迭代出现的问题。
- 将这些问题呈现在屏幕上，引导小组成员对这些问题进行归类：
- 需求方面，需求文档不完善；用户故事划分不合理，用户故事没有设定优先级和验收标准；需求交底前没有做可行性评审（给出需求文档后，交底前，前后端开发人员商议）。
- 交互设计，在开发完成后没有找交互和UI进行验证；UE和UI在界面上出入大；对于修改的ui和ue需要统一放到svn上，不接受单独发给某人；需求交底前需要前端开发人员需要仔细研究查看，确定是否可行。
- 开发，代码质量差；开发自测力度不够；jira建立自任务后，至少需要开发和测试一起过一遍，避免任务有遗漏；自任务粒度控制在4h以内；每天提供测试包时，已提的指定的A类/B类bug必须修改。
- 测试，功能性问题找需求确认，交互类问题找UE；给开发提供用于自测的新增功能的主要场景测试用例（与用户故事关联）；执行测试前，已编写完成新增功能的测试用例；测试过程中，测试用例100%执行并通过验证（IOS、Android均需执行）；已修改的bug均复测通过
- 验证，测试环境验证完成所有用户故事后，上生产环境前：需求验证、UE验证和UI验证。
- 发布，测试环境，发现的bug全部修改。如遇特殊情况需遗留解决的bug，由需求确定是否可接受；生产环境，A类bug（系统崩溃、闪退等）必须修改，其他bug由需求决定是否必须解决，若需解决，则发版前应解决并复测通过。
- 针对这些列出的问题，大家重点找出与DOD相关的条目，并决定怎么算是完成：
- 对于代码，需要eslint静态检测和git提交时的人工审核。
- 对于bug，A类必须要修改，其他类型根据发版时间由需求决定当前发还是下期发。
- 每个用户故事都需要经过测试用例验证。
- 新出的功能需要UE、UI和需求共同验证后方可发版。
