NO.106 需求的状态、研发阶段及注意事项。

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

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


二、需求的研发阶段
需求还有一个阶段(stage)字段，用来描述激活的需求在研发过程中所处的阶段。目前总共有等待、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。
那么需求的研发阶段是如何变化的呢？一种方案是通过编辑操作，来修改研发阶段。但我们更提倡另外一种方案，就是在创建任务的时候，仔细设置任务的类型，比如开发，测试。禅道的程序会自动根据不同类型任务的变化来自动计算需求的研发阶段，其规则如下：
如果需求没有关联到项目，也没有关联到计划，则需求的研发阶段是"等待"。
如果需求关联到了计划，还没有关联到项目中，则需求的研发阶段是"已计划"。
如果需求关联到了项目中，但还没有分解任务，则需求的研发阶段是"已立项"。
如果需求关联到了项目中，且进行了任务分解:
如果有一个开发任务进行中，并且所有的测试任务还没有开始，需求的研发阶段为“研发中”。
如果所有的开发任务已经完成，并且所有的测试任务还没有开始，则为“研发完毕”。
如果有一个测试任务进行中，则视为“测试中”。
如果所有的测试任务已经结束，但还有一些开发任务没有结束，则视为"测试中"。
如果所有的测试任务已经结束，并且所有的开发任务已经结束，则视为"测试完毕"。
"验收"阶段是需要产品经理手工来进行确认的。
如果需求关闭，且关闭原因是“已发布”， 则需求的研发阶段是“已发布”。

三、需求的注意事项
1、禅道中需求的写法
在禅道中，我们默认给大家提供了一个需求的模板：作为一名<某种类型的用户>，我希望<达成某些目的>，这样可以<开发的价值>。这个模板是借鉴自scrum开发里面的用户故事(user story)的写法。只不过我们使用了相对比较中性的概念。
在这个模板中，总共有三个元素：角色，要做的事情，价值或者原因。我们平时在写需求的时候，往往会忽略角色和价值原因这两个元素，只关注了要做的事情。其实这有很多的问题。不进行用户角色的划分，会影响对产品功能的设计和定位，从而导致产品往往是给一个用户角色开发的，就是产品经理自己。:)而忽略开发的原因或者价值，会让开发人员感到困惑。他们可能并不理解你这样做的原因或者目的，不理解的需求实现起来自然会有问题。 

2、需求的INVEST原则
除了上面基本的模板之外，在撰写用户故事的时候，可以参考INVEST原则：(摘自http://duweizhong.blogbus.com/logs/112151436.html)
I dependent(独立的):一个用户故事对于另一个用户故事应该是独立的（尽可能的）。故事之间的依赖性使得增加了计划编制，确立有限级，故事估计这些工作非常困难。通常，可以通过组合用户故事或者分割用户故事来减少依赖性。
N egotiable(便于沟通的):一个用户故事是便于沟通的。一个故事的卡片是包含故事详情的简短描述。这些详情是通过讨论阶段来完成的。一张还有很多详情的卡片实际上减少了和客户的会谈。
V aluable(有价值的):每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
E stimable(可估计的):开发者需要去估计一个用户故事以便确定有限级并对故事进行规划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
S mall(短小):一个好的故事应该在工作量上短小，描述具有代表性，而且不超过2-3人周的工作量。超过这个范围的用户故事，将会在划分范围和估计时出现很多错误。
T estable(可测试的) :一个用户故事是可测试的来用于确认完成，记住，我们不开发不能测试的故事。如果你不能测试那么你永远不知道你什么时候是完成了。一个不可测试的用户故事例子：软件应该是易于使用的。
一个编写良好的用户故事是敏捷开发的基础。它们应该相互独立，详情应该便于开发者和用户进行沟通，应该对用户有价值，应该对于开发者来说尽可能的清晰以便进行估计，应该短小，通过预定义测试用例的使用确保它是可以测试的。

3、禅道里面的需求和原型图、需求设计文档的区别
传统管理模式中，很多产品经理都在用原型图软件设计原型图或者非常完整的需求设计文档。设计完之后，交给设计人员进行页面设计，然后由开发人员合并代码。那么原型图和用户故事之间的关系和区别是什么呢？
和user story相比，原型图或者需求设计文档是一个整体，可以给人宏观的把握。这是原型图的优点。比较直观。
它是一个整体，所以就没有办法进行分解。你不可能分解成，做页面导航条，做页面的中间部分等。
没有分解，所以原型图也就没有办法进行优先级的排序。比如页面部分，有的很重要，有的不重要。但在原型图里面是体现不出来优先级的。
没有分解，自然也就无法进行跟踪。你没有办法得知原型图完成了多少。
过于死板，给设计人员和开发人员留下的发挥的空间太少，最后演变成被动执行。
需求设计文档规定的比较细致，会让产品经理陷入太多的细节，对整体的把握会减弱。
虽然相比较于用户故事而言，传统的原型图或者需求设计文档有一些不足，但在实际的开发过程中，二者可以相辅相成。禅道从1.2版本中，已经增加了文档库管理。可以将原型图作为设计文档，上传到某一个产品相关的文档库中，和用户故事相互配合，是一个最好的方案了。