issue_ticket该怎么写.md

Issue Ticket该怎么写

所谓的Issue Ticket，其实就是工单，我们用它来记录需求和缺陷，然后跟踪它们的完成和解决情况。说咱们的开发是Issue Driven并不为过。

Issue的生命周期伴随开发任务生生灭灭，在整个过程中会经手不同的人，从这个角度讲，Issue本身也是沟通信息的载体。由此，Issue Ticket本身的书写也就很重要了。

需求

任务分配

对于需求类的Ticket，尽量避免将Ticket本身当做沟通和讨论的工具。当需求本身很模糊时，用Ticket反而效率更低。此时，最重要的反而是跟相关人员线下沟通，讨论清楚。在双方都理解一致之后，再利用Ticket作为记录。简而言之：Ticket != 沟通。

需求类Ticket一个现成的好的模板就是“用户故事（User Story）”：作为一个<角色>, 我想要<活动>, 以便于<商业价值>。

• 角色，谁要使用这个功能。
• 活动，需要完成什么样的功能。
• 商业价值，为什么需要这个功能，这个功能带来什么样的价值。

除此之外，如果还有以下内容，则效果更好：

• UI原型
• 业务流程图
• 相关公式的描述和定义
• 相关表格，如报表
• 明确的完工标准

对于如何撰写用户故事已经有大量的文章可以参考，此处不再赘述，这里只强调其中的几点：

• 保持每个Story短小
• 可测性，即如何判断是否完工

任务完成

任务完成后，工作者需要提交完成情况的报告，其中需要包含的内容：

• 简述设计思路，以及该设计对于系统其他方面的影响。
• 结果展示
• 自动化测试报告，通过检查Spock/Geb测试报告，可以很方便的确认任务是否完成且考虑是否周到。
• 如有必要，还需有压力测试报告。

错误

任务分配

对于错误类Ticket的书写，相对比较简单，这里总结如下：

• 所属系统功能模块
• 所属版本
• 是否平台相关，这里的平台包括：PC、Mobile和浏览器，同时需结合这些平台的版本考虑。
• 操作步骤 + 堆栈信息 + 错误截屏，必要时可能还需要：
  • 内存导出文件
  • 引起错误的相关数据文件
  • 日志信息
  • 监控平台相关信息
• 优先级

如果能够提供导致错误复现的程序，则效果更好。

任务完成

当错误解决之后，报告内容很关键，它们需要有：

• 错误分析：原因、分析和解决的说明。
• 如果是程序错误，需要提交相应的自动化测试代码，以完善现有的自动化程序库。

总结

从知识管理的角度来讲，Issue Ticket就是关于项目的知识，若认真对待，随着时间的积累，它本身就能成为一个优质的知识库，给项目管理带来积极的影响。反之，不仅浪费时间，还会反伤自身！

最后提醒各位小朋友，记得随时改任务的状态哟，;)