关于devops:Jira-Issue类型和工作流最佳实践

1. 概述

Jira Issue 分类和工作流是应用 Jira 治理事务的根底，并且 Jira 工作流波及度量相干指标的可实现性。因为公司外部的我的项目千差万别，每个我的项目团队的治理形式也千差万别。因而希图通过设计一套工作流满足所有人的需要根本是不事实的。希图这样做的结果，一个是设计出一个巨简单无比的工作流，被所有人吐槽。另一个就是利用势力压迫所有人应用一个规范的工作流，满足不了个性化的需要。这两种计划都算不上最佳的实际计划。一种可参考的计划就是定义出工作流中每个结点，让所有人在这其中进行抉择结点搭建本人的工作流。这样兼顾了标准化和灵活性。
如何设计出能笼罩所有的人需要的结点，而不会呈现脱漏。

1. 辨认我的项目中流程（项目管理、业务、产品、开发、测试、运维），并定义流程里的角色（XX 经理、XX 人员）。
2. 定义每个角色可能进行的动作。

这样就能定义出一份较完整的结点列表供不同我的项目团队进行配置应用。

2.Jira Issue 类型

2.1. 瀑布式开发流程

1. 用户故事
   有代码交付的需要
2. 工作
   非代码交付的工作项都能够归于工作
3. 缺点
   测试发现的问题
4. 故障
   线上零碎呈现的问题

2.2. 并行合作开发流程

1. 用户故事：多角色合作并行处理时，能够采纳子故事的形式实现。
   ① 业务子故事
   ② 需要子故事
   ③ 开发子故事
   ④ 测试子故事
   ⑤ 运维子故事
2. 工作
   ① 子工作
3. 缺点
4. 故障

3. 工作流节点命名标准

节点命名标准：角色 + 动作

3.1. 用户故事节点列表

规范的瀑布的软件流程能够应用这个流程。故障能够复用这个工作流。

用户故事规范的工作流：PROJECTID-USERSTORY-WORKFLOW

3.2. 工作节点列表

如果应用并行或者多人协同工作的用户故事、需要子故事、开发子故事、开发子故事、测试子故事、运维子故事、子工作能够复用这个工作流。

工作规范的工作流：PROJECTID-TASK-WORKFLOW

3.3. 缺点

因为 bug 有规范的流程，故采纳规范的 bug 解决流程。
缺点规范的工作流：PROJECTID-BUG-WORKFLOW

4. 工作流命名标准

工作流命名标准 ：我的项目关键字 -Issue 类型 -WORKFLOW。
例如:PROJECTID-USERSTROY-WORKFLOW。