云效使用指南：项目协作：工作项管理

需求、缺陷和任务统称为工作项。需求、任务和缺陷的区别：

工作项	定义	使用场景
需求	代表所需要解决的问题	用户需要借助产品实现某个目标，但是产品尚未支持
缺陷	当系统没有按设计运行的时候，即产生了缺陷	产品出现故障和问题，运行方式和结果不符合设计期望
任务	代表一个小粒度的活动	研发实现某个需求和解决某个缺陷，对涉及到工作拆解成一系列的任务，如搭建环境、编写单元测试脚本等

需求管理



录入需求


录入需求是比较简便的操作，只要点项目左边“需求”TAB，就可以发现新建需求的按钮，点一下按钮，然后填上需求的标题和正文，再点“保存”即可。
提示：

• 需求正文可直接按CTRL+V进行贴图
• 需求正文支持markdown方式编辑

团队在线上对需求进行讨论


在形成结论之前，可利用需求评论功能对需求进行讨论。所有讨论会完整记录下来，且实时发送邮件通知“指派给”和“抄送”用户（指派给和抄送用户可在需求详情页进行指定，发出评论的人不会收到邮件通知）。

需求进入迭代之前，对需求进行细化


一般来说，一个迭代一般是1-2周的周期，所以进入迭代的需求一般粒度不能太大，一般是从用户角度出发的端到端的小粒度功能，符合以下原则（INVEST）：

1. Independent，独立
2. Negotiable，可协商，不能定太死，开发过程可变通
3. Valuable，有价值
4. Estimable，可估算，不能估算意味着无法做相对准确的计划，一般是因为粒度还不够小
5. Small，足够小，一个迭代能够做完，不能跨迭代
6. Testable，可测试

如果需求太大，可以不断拆分直到符合上述标准。

和团队一起规划迭代


迭代一般由Scrum Master（迭代负责人）来创建和管理。每个迭代具体要排期哪些内容，Product Owner定优先级，研发团队根据需求估算、团队速率和可承受并发度等确定能做多少内容。

缺陷管理



用户在测试环境发现缺陷，提交缺陷


需求功能测试过程发现的缺陷在项目中直接录入，并且可规划到迭代中解决。

缺陷状态


缺陷状态如下：

• New: 新增加的、需要解决的BUG。
• Open: 正在定位问题，或正在解决中，或已经解决但未部署生效。
• Fixed: BUG已经解决，并且修改后程序已部署生效。
• Closed: 验证后，此BUG可以关闭。
• Reopen: 此BUG需要再解决。
• Later: 此BUG不在本项目的工作范围内，在后续版本中修复。
• Worksforme: 不能在当前环境中重现。
• Duplicate:和其它BUG描述现象重复。可以配置选择Duplicate状态时必填关联的缺陷ID。
• Invalid: 属于测试人员对测试需求的理解错误。
• External: 问题是由其他外部的原因引起，需要由外部处理。
• ByDesign：属于按照产品设计实现，不是问题。
• Wont’fix：问题确实出现过，但是由于产品改动已经修复或者功能废弃，问题目前已不需要解决

上述的状态可以划分为待处理、已处理、已关闭等三大类：

• 待处理：New、Open、Reopen
• 已处理：Fixed，Wont’fix，Later，Worksforme，Duplicate，Invalid，External，ByDesign
• 已关闭：Closed

已处理中的6个状态都可以视为问题处理人对此问题的处理意见。我们称它为：解决方案。
经过以上调整，我们就有了以下规则：

1. 所有缺陷最终都应该由缺陷验证者或者与之平级权限的人变更到Closed状态。非Closed状态的都被认为是活动的缺陷。
2. 解决者可以将“待处理”状态的缺陷置为任意“已处理”状态。

状态流转图如下图：

再用文字来解释一下上图的一个经典流程：

1. 测试（验证者）发现了问题。提交一个问题。（状态为New)
2. 开发（解决者）去解决。先Open或者直接选择一个解决方案。
3. 测试通过就关闭它。如果验证后不正确，那就Reopen。再返回到步骤2。

任务管理


任务代表一项小粒度的活动，可以来自于对需求实现的任务拆分，也可以单独创建。

从需求拆分任务




直接创建任务




个人维度管理工作项


点顶部”我的”，进入工作台，里面显示和当前用户相关的任务和其它工作项（需求、缺陷等）: