前言
禅道内设置的任何字段/分类，一定不要有 其它 。其它代表的是你对这个故事/BUG/任务并不了解，如果你确实能够了解它，那你就应该知道它并不属于其它。
并且一旦存在其它，在目前可选项没有合适的时候，大概率会选择其它。这时，模块、状态、类型等字段/分类维护起来就没有任何意义。
一、禅道基础设置
1.1 后台管理 - 必须设置
全局设置 - 需求概念，设置为「故事」。
自定义 - 流程 设置为「项目 产品 迭代」 和 「故事点」。
系统 - 模式 设置为「轻量级管理模式」。
系统 - 功能设置 ，去掉通用看板选项。
1.2 后台管理 - 非必须设置
全局设置 - 代号，设置为「否」。如果有保密需求可以保持默认的「是」。
自定义 - 产品、自定义 - 执行、自定义 - 看板的已关闭都设置为「禁止修改」。
自定义 - 故事、自定义 - 任务、自定义 - BUG、自定义 - 用例、自定义 - 测试单 的「优先级」可以调整为「紧急且重要」、「紧急不重要」、「重要不紧急」、「不重要紧急」。
自定义 - 故事 的「关闭原因」可以只设置四个：「已完成」、「重复」、「推迟到后续迭代」、「已取消」。
自定义 - 任务 的「类型」可以设置为：「设计」、「开发」、「需求」、「界面」、「运维」。
自定义 - 任务 的「关闭」可以设置为：「已完成」、「已取消」。
自定义 - BUG 的「严重程度」可以设置为：「影响全部用户的主要功能/数据」、「影响部分用户的主要功能/数据」、「影响全部用户的次要功能/数据」、「影响收费用户的次要功能/数据」、「影响免费用户的次要功能/数据」、「影响内部服务的执行效率/资源占用」。
自定义 - BUG 的「类型」可以设置为：「功能异常」、「数据错误」、「UI 错位 / UI 异常」、「无法访问」、「操作流程 / 设计问题」、「安全漏洞」、「性能问题」。
二、禅道名词解释
经过上述设置后，整个禅道内就剩下 产品、项目、执行、测试、Devops、文档、BI、组织这八部分。
（一） 产品
就是正常的产品，比如支付宝是一个产品、chrome 浏览器也是一个产品。
在产品的描述中需要确定以下几点：
- 主要功能：这个产品提供的主要功能是什么，或者换个角度，这个产品是为了解决什么问题？
- 客户/购买者画像：这个产品的主要客户群体是谁，他们有着什么样的特征，比如偏好、使用时间、付费倾向等等。
- 用户/使用者画像：这个产品的主要用户群体是谁？是否和客户群体是一样的，有相同的画像和特征？如果不是，那他们有着什么样的特征？
- 主要平台：分别在哪些终端上有相应的客户端，并备注好相应的地址。比如小程序、手机app、web + wap 网页、pc 客户端。
- 支撑系统：主要是支撑整体业务的管理系统，并备注好相应的地址。比如：管理后台、客服系统。
1. 模块
产品下会有不同的模块，这个模块等同于我们说的功能模块。在敏捷里，功能模块的划分是根据客户角度来定的。
比如一个最简单的支付系统，是分为用户管理、账务管理（含支付、账单等等）、统计管理（财务流水概览、财务余额变动等等）两大模块。而这些模块的具体描述只用描述用户使用层面的功能及限制，无须描述具体的接口规范、接口参数、调用方式、接口限制等等。
但是，如果有第三方接入的情况（第三方需要调用你的接口），那这时候，接口也是归属在相应的模块下的。比如，用户登录这个接口也是归属于用户管理模块下的。
当然，也可以对模块进行细分。那这时，就需要使用子模块了。这里也需要注意一点，一旦出现子模块，任何故事/BUG/任务都必须归属最底层的子模块，上层的子模块或顶层的模块下不能存在任何的故事/BUG/任务。
2. 故事
2.1 用户故事
故事就是敏捷里面的用户故事，你可以理解为用户需求。但是这个故事需要与普通的用户需求进行区分。
虽然叫做用户故事，但是首先我们需要区分这个故事里谁是用户？即使用者和购买者的侧重。
如果是 X 买，Y 用，这种情况下 X 一般是 Y 的管理者或领导者。
这时候，从产品销售的角度来说，要以 X 角度来明确用户故事。从产品体验来说，要以 Y 角度来明确用户故事。
但是有很多时候， X 角度与 Y 角度之间是相冲突的。考勤就是一个很好的例子，而一旦发生冲突，我们就要以局部价值与整体价值大小综合判断应该偏向 X 还是 Y。实际应用中，其实往往是偏向于 X ，因为对于商业来说利润是价值的重要体现形式。
如果是自己买，自己用。比如视频网站会员，那用户/使用者和客户/购买者是同一个人/群体，那我们就只需要确定用户的需求并提高使用体验即可。
那这个用户故事只需要从用户的角度，应该是怎样的 展示和交互形式，应该有什么限制就可以了。
用户故事最终还是要落盘为记录，记录的基础格式是我是一名 xxx 样的用户/客户，我需要 xxx，以达到/获得 xxx。
当然，基础格式里面能够概括的信息很少，主要是某一角度的用户/客户的需求概述。所以我们可以增加详细描述，比如有什么样的限制，或是多角度阐释用户/客户的需求。
一个简单的用户故事，只需要调研、收到反馈或根据数据猜测后就能得出。但是一个具体的用户故事（包含但不限于使用方式、展现形式、限制、测试要求等），往往需要多方沟通、评审才能够准确得出。
当然，还有最重要的一点：用户故事要足够小，小到不能再拆分。比如用户管理这个主题不能算是一个有效的用户故事，但是用户管理下的用户登录却是一个有效的用户故事。足够小的用户故事能带来更快的迭代、更多的交付成果以及更灵活的项目推进。
2.2 故事点
而有了准确的用户故事后，我们就能够对用户故事评估故事点。故事点代表的就是工作量，所以准确的评估故事点就能准确的把控开发进度。
而故事点的评定不允许单单某一方来进行评定，而是要相关利益方都来参与评定。比如开发一个用户登录，并不单单是只要开发来评定，项目负责人、产品经理、设计等相关干系人甚至客户、用户都需要来评定具体故事点。
故事点建议采用斐波那契数列前八位，即1、3、5、8、13、21、34、55。
故事点的衡量标准可以以最小故事为依据，比如用户登录只需要数据的验证并安全拿到 token 就行，它的故事点是 1 ，用户注册因为涉及到多个服务的调用、数据的验证及安全，它的故事点可能就是 3 。
也可以以难点和问题的数量及难度来进行计算。比如用户图像搜索涉及到图像特征提取（计3）、图像特征数据与原始图像的关系存储（计1）、图像特征高性能比对（计3），那 3+1+3 = 7，7 接近 8 就按 8 算难度。
记住：足够小的用户故事，也方便进行故事点评估哦。
3. 计划
计划是一个项目推动的重要衡量标准，他还有个名字叫做里程碑。更短的迭代计划、更快的最小交付，能够使我们避开很多过时开发或无效开发（开发后发现不是想要的或脱离实际，然后返功或废弃）。
计划需要记住三个重点：
- 计划只有完成、未完成、取消三种状态，不存在完成百分之多少的状态。完成百分之多少只能代表进度，不能代表结果，而计划需要的是结果。
- 每个计划代表着至少一个结果的产出，计划产出的结果就是这个计划的价值。
- 计划需要尽可能的短且快，但不要太短或太快。短且快是为了能更快的迭代和持续地最小交付成果。建议采用 2 - 4 周为一个计划周期。
计划周期内能完成的任务也可以通过故事点评估，通过对团队历史每计划周期内平均故事点完成情况，可以推测出每个周期大约安排多少故事点任务比较合适。这样在人员、资源没有变动的情况下，每个计划周期内能完成的任务就可以预计，同样也能推导出整体的项目进度。
一个用户故事可能会贯穿多个计划，如果是因为工作量过多，则需要重新评估这个用户故事是否是拆分为了最小用户故事。对于因为预估失误或其他的干扰原因，则需要去重新确定每个计划周期内能完成的故事点数。
4. 发布
发布比较重要的是版本以及描述，因为名称一般是与版本号保持一致，而版本的标准可以参考 semver。
这里需要注意的是版本、发布与计划的关系，两次发布之间并非是单纯的版本号递增的关系，而发布并不代表着一个计划周期完结。
一个小版本号的递增代表是解决了一个BUG，一个中版本号的递增代表增加了一个功能，一个大版本号递增则代表是进行了某种程度上的重构（不向前兼容）。
每次发布则代表是一个目前程度上的稳定版本或者半稳定用来内测或公测的版本。
一个计划周期内可能完成一次或多次发布，而两次发布之间可能会有一个或多个版本。
如果一个计划周期内没有任何一次版本发布，则需要评估是计划周期过短还是单个用户故事拆分不够彻底。
5. 文档
敏捷并不提倡先完善文档，但是不代表敏捷不需要完善的文档。完善的文档可方便后续的开发、维护。
而针对一个产品/项目，它的文档中不应该包含接口、代码逻辑、数据库等和代码工程关联特别紧密的文档内容或是 编码规范、设计规范 等规范性文档。
和代码工程关联特别紧密的文档内容应该出现在代码工程中，比如 ：
-
README 来介绍这个代码工程具体是做什么的、使用了什么技术栈、依赖服务有哪些、每个代码工程目录分别是做什么的。
-
接口文档，则完全可以根据代码自动生成或是手写后，使用相应的文档框架部署为一个服务，这样既省事也省时，且能确保文档与代码实际一致。
-
数据库的文档，每个表的具体字段使用注释标注，每个表的具体用途及表关系使用一个单独的 md 文档进行描述，如果使用 ER 图则一定要放上可供修改的源文件，方便数据库更新后对数据库关系文档进行更新。
而诸如编码规范、设计规范这种规范类文档，既然是规范，就不太可能是同样基础语言的情况下，一个项目一个规范，那这类文档需要放置在公共文档区而非某个产品/项目下的文档内。
一个产品/项目下的文档，应该放置如产品的详细描述、各类调研报告、项目整体架构设计、各类内部服务地址、活动素材、公告留存等等。
可以简单的总结为：
- 如果一个文档的内容只适用于某一个代码工程的，那就把它放在相应的代码工程下。
- 如果一个文档的内容是可以适用于某一个产品的全局或细节，或包括了两个以上的代码工程，那就放在这个产品下。
- 如果一个文档的内容是可以适用于多个产品或者可以跨产品适用于多个代码工程，拿它就是是关于一些共识的内容，则应该放在公共文档。
（二） 项目
聊项目前，我们要先区分产品和项目的概念。产品是一个大的概念，比如支付宝这是一个产品。
项目是一个涵盖在产品内的概念，比如支付宝这个产品并非只有 APP 和 网页这一系列客户端，它还会有后台管理系统、客服系统、商户系统、OpenAPI 等，而这些每个都是一个独立的项目。
而项目与代码工程的关联则往往是一对多的关系，每一个项目都至少会关联一个代码工程。基础的项目会做前后端分离，有的项目有不同的客户端，比如后台管理系统可能会有移动端（ Android 和 Ios ）、网页端（Web 和 Wap），这就涉及到多主分支开发，或者将其划分为同一项目下的不同代码工程内。
（三）执行
执行是用户故事的实施步骤，用户故事讲的是从用户/客户的角度来看，需要哪些服务。而任务则是分配给不同的开发人员、规定指定的技术栈及架构、工程设计。
而对于不关注任务具体是如何实施的情况下，就可以完全按用户故事建立任务。
用户故事中往往涵盖了前端、后端开发，所以用户故事转为任务时也可以转为多个子任务分配给指定的前端和后端。
同样的，任务有一点：不存在完成百分之多少，只存在完成、未完成、取消。
三、流程
（一）产品创建及研发流程
首先需要创建并产品，之后创建产品下的模块。模块可以使用前缀 + 模块名的方式，前缀可以是项目名或其他区分规则。
创建产品和模块后，就需要创建项目。项目的管理方式选择 Scrum 敏捷方式，启用迭代即可。
创建项目后，就进入到正式的迭代过程中了。迭代过程分为故事创建、计划创建、计划与故事关联、开发、测试、交付发布 六个阶段。
整体迭代过程释义如下：
- 我们需要用户故事才能明确开发什么。
- 创建迭代计划并确定当前计划周期应该完成那些用户故事，不列入当前迭代计划的用户故事视为挂起状态创建。
- 根据任务故事创建执行任务并开始开发。需要注意，在开发期间，和最终结果直接相关的备注在用户故事下，和最终结果无关但是和开发相关的备注在开发任务下。
- 开发完成后进行测试，测试中的问题在用户故事下备注并反馈。
- 测试无问题后，可以打正式版本并发布交付。
- 当整个计划周期内任务完成或计划周期结束后再根据实际情况创建新用户故事或调整用户故事。之后就可以开启下一轮的迭代了。
对于非新需求开发中发现的BUG（即历史开发结束后的BUG）处理流程，参见下面。
（二）BUG 修复流程
