禅道需求管理规范_禅道需求管理流程

 

1 版本记录

 

2 目的

目前存在需求描述不明确，录入、评审不规范等问题，本文档的目的是通过需求管理规范化，确保团队的成员在项目过程的做符合项目目标的事，以便提高团队的整体效率，及时完成项目的目标，交付可用的产品。

3 阅读对象

研发中心全体人员。

 

4 需求管理规范

4.1 需求管理流程

禅道软件设计的需求有两个字段来跟踪它的变化，一个是需求的状态字段，一个是需求的研发阶段字段，下面来看下这两个字段。

需求的状态及状态管理

需求状态(status)字段，总共有四种状态，分别是草稿(draft)、激活(active)、已变更(changed)和已关闭(closed)。对应为需求的流程操作共有：创建、变更、审核、关闭、激活，其状态流转图如下：

 

 

 

需求的状态约定如下：

1) 录入需求时必须要勾选“需要评审”，即需求默认处于草稿状态

2) 草稿状态的需求由产品线负责人审核，审核通过后处于激活状态。

3) 若需要变更的需求变更后会变成“已变更”状态

4) 产品发布后，由产品经理关闭需求，变成“已关闭”状态。

 

需求的研发阶段

还有一个阶段(stage)字段，用来描述激活的需求在研发过程中所处的阶段。目前总共有未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。

需求的研发阶段是如何变化的呢，一种方案是通过编辑操作，来修改研发阶段（已立项之后可手动选择需求所处的阶段）。另外一种方案，就是在创建任务的时候，设置好任务的类型，比如开发，测试。禅道会根据不同类型任务的变化来自动计算需求的研发阶段，其规则如下：

1. 如果需求没有关联到项目，也没有关联到计划，则需求的研发阶段是"未开始"。

2. 如果需求关联到了计划，还没有关联到项目中，则需求的研发阶段是"已计划"。

3. 如果需求关联到了项目中，但还没有分解任务，则需求的研发阶段是"已立项"。

4. 如果需求关联到了项目中，且进行了任务分解:
如果有一个开发任务进行中，并且所有的测试任务还没有开始，需求的研发阶段为“研发中”。
如果所有的开发任务已经完成，并且所有的测试任务还没有开始，则为“研发完毕”。
如果有一个测试任务进行中，则视为“测试中”。
如果所有的测试任务已经结束，但还有一些开发任务没有结束，则视为"测试中"。
如果所有的测试任务已经结束，并且所有的开发任务已经结束，则视为"测试完毕"。

5. "验收"阶段是需要产品经理手工来进行确认的。

6. 如果需求关闭，且关闭原因是“已发布”， 则需求的研发阶段是“已发布”。

4.2 需求开发指引

在禅道中，默认提供了一个需求的模板：作为一名<某种类型的用户>，我希望<达成某些目的>，这样可以<开发的价值>。这个模板是scrum开发里面的用户故事(user story)的写法。

 在这个模板中，总共有三个元素：

角色：需要进行用户角色划分，不进行用户角色的划分，会影响对产品功能的设计和定位，从而导致产品往往是给一个用户角色开发的，就是产品经理自己

要做的事情：平常只关注了要做的事情

价值或者原因：需要强调，如果忽略开发的原因或者价值，会让开发人员感到困惑。他们可能并不理解这样做的原因或者目的，不理解的需求实现起来自然会有问题。

 

一个编写良好的用户故事是敏捷开发的基础。它们应该相互独立，详情应该便于开发者和用户进行沟通，应该对用户有价值，应该对于开发者来说尽可能的清晰以便进行估计，应该短小，通过预定义测试用例的使用确保它是可以测试的。

 

根据以上原则，不同的用户故事可参考下面的写法：

操作故事：如“查看请求”

-作为一个会议主席，可以查看到哪些用户在请求发言或主讲，以便及时处：理授权或拒绝，达到管控会议的目的。

文件故事：如“购物车”

-购物车用于存放客户有购买意向的产品，以便客户在购买多种产品时不需要多批次重复购买。

增强一个操作：如“高亮显示发言次数最少的用户请求 “

-实现后，作为一个会议主席，可以在查看请求时，突出的看到发言次数最少的请求，以便优先给他授权，达到一个尽量多的人发言的开会目的。

增强一个文件：如“增加编辑购物车“

-实现后，用户可以在购物车里选择清理掉暂时不购买的产品。

重构：界面及交互方式更改 

-实现前，不同的客户端界面不统一，交互方式也有差异；实现后，所有客户端使用统一的交互原型，以达到用户体验一致，增强产品的品牌统一风格。

缺陷：如“有多用户同名时无法登陆的问题”

-在不同企业存在相同的用户名的用户时，用户无法正常登陆，导致用户无法进入系统正常使用BOSS各项功能。

 

除了上面基本的模板之外，在撰写用户故事的时候，可以参考INVEST原则

· I dependent(独立的):一个用户故事对于另一个用户故事应该是独立的（尽可能的）。故事之间的依赖性使得增加了计划编制，确立有限级，故事估计这些工作非常困难。通常，可以通过组合用户故事或者分割用户故事来减少依赖性。

· N egotiable(便于沟通的):一个用户故事是便于沟通的。一个故事的卡片是包含故事详情的简短描述。这些详情是通过讨论阶段来完成的。一张还有很多详情的卡片实际上减少了和客户的会谈。

· V aluable(有价值的):每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

· E stimable(可估计的):开发者需要去估计一个用户故事以便确定有限级并对故事进行规划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

· S mall(短小):一个好的故事应该在工作量上短小，描述具有代表性，而且不超过2-3人周的工作量。超过这个范围的用户故事，将会在划分范围和估计时出现很多错误。

· T estable(可测试的) :一个用户故事是可测试的来用于确认完成，记住，我们不开发不能测试的故事。如果你不能测试那么你永远不知道你什么时候是完成了。一个不可测试的用户故事例子：软件应该是易于使用的。

需求和原型图、需求设计文档的区别

传统管理模式中，很多产品经理都在用原型图软件设计原型图或者非常完整的需求设计文档。设计完之后，交给设计人员进行页面设计，然后由开发人员合并代码。那么原型图和用户故事之间的关系和区别是什么呢？

· 和user story相比，原型图或者需求设计文档是一个整体，可以给人宏观的把握。这是原型图的优点。比较直观。

· 它是一个整体，所以就没有办法进行分解。你不可能分解成，做页面导航条，做页面的中间部分等。

· 没有分解，所以原型图也就没有办法进行优先级的排序。比如页面部分，有的很重要，有的不重要。但在原型图里面是体现不出来优先级的。

· 没有分解，自然也就无法进行跟踪。你没有办法得知原型图完成了多少。

· 过于死板，给设计人员和开发人员留下的发挥的空间太少，最后演变成被动执行。

· 需求设计文档规定的比较细致，会让产品经理陷入太多的细节，对整体的把握会减弱。

· User story与文档化的需求相比，开发人员面对的就不再是文档化的功能点，而是可追溯的，易跟踪的以及结构化的功能点

虽然相比较于用户故事而言，传统的原型图或者需求设计文档有一些不足，但在实际的开发过程中，二者可以相辅相成。可以将原型图作为设计文档，上传到某一个产品相关的文档库中，和用户故事相互配合，是一个最好的方案了。

4.3 需求录入规范

将需求录入禅道时，需要遵守以下规范：

1) 调研清楚用户提出问题背后的需求，将需求分解成为一个个用户故事。

2) 录入前，先在禅道中查找该需求的关键词，以避免录入重复的需求。

3) 明确需求的分类及对应的产品模块，如果不确定，可以找研发一起讨论。

4) 需求描述需要规范，需要把具体用户、用户愿望、用户的价值说明清楚。

务必将需求、用户的愿望、任务区分开。

如下图，是一个愿望的描述，需求所创造的价值不清晰。

 

规范的描述方式：

。

5) 验收标准需要产品经理描述清楚，前置条件是充分理解用户的需求及解决方案后来确定的。

每条需求的创建者，务必把验收标准描述清楚，这样可以把需求的输出给说清楚，同时也可以体现该需求实现的可行性有高度的保障。

6) 需求的优先级按以下规则：

a) 重要&紧急，列入1级；

b) 重要&不紧急，列入2级；

c) 不重要&不紧急&不确定，列入3级；

d) 其他列入4级。按1:5:2:2的比例来分配，开发的计划基本都是从1级和2级提炼出来。

7) 产品线负责人需要及时关注未进入开发的需求，并及时调整需求的优先级。

8) 如果需求的描述不够规范清晰，可以通过“编辑”或“备注”进行完善修改。如果是导致实现上的变更，需要走变更流程。详见下面的章节。

4.4 需求评审规范

因为涉及到需求录入是否规范、对需求的理解是否准确的问题，所以每一条需求都需要产品线负责人进行审核。如果不符合要求，则需要重新录入或修改。

1) 如果是符合产品年度规划、版本计划、实现方案明确的由产品线产品经理审核。

4.5 需求计划规范

1) 需要明确到两个版本计划，当完成第一个版本的需求后，产品经理需要明确下个版本的计划，并组织研发团队进行评审。

2) 版本的计划要在项目启动前落实，产品线产品经理通过邮件的方式，把该版本的计划描述清楚，通知团队成员及相关人员知悉并确认。

 

4.6 需求关闭规范

需求完成了功能验证之后，需要将其阶段变为“已验收”，

 

待产品发布的一周后，要将相关的需求状态设为“已关闭”。

4.7 需求变更

需求的变更分为两种，一种是需求评审前的变更，一种是需求评审后的变更。两种需求变更的说明如下：

1) 评审前的需求变更直接到禅道的需求的变更里面修改即可。只需要在需求的备注部分说明清楚。

2) 评审后的需求变更需要在禅道中走需要变更的流程，并更新项目需求规格书上的相应需求。

禅道中需求变更的流程：