# 需求的注意事项 #### 一、禅道中需求的写法 在禅道中，我们默认给大家提供了一个需求的模板：作为一名<某种类型的用户>，我希望<达成某些目的>，这样可以<开发的价值>。这个模板是借鉴自scrum开发里面的用户故事(user story)的写法。只不过我们使用了相对比较中性的概念。 在这个模板中，总共有三个元素：角色，要做的事情，价值或者原因。我们平时在写需求的时候，往往会忽略角色和价值原因这两个元素，只关注了要做的事情。其实这有很多的问题。不进行用户角色的划分，会影响对产品功能的设计和定位，从而导致产品往往是给一个用户角色开发的，就是产品经理自己。:)而忽略开发的原因或者价值，会让开发人员感到困惑。他们可能并不理解你这样做的原因或者目的，不理解的需求实现起来自然会有问题。 #### 二、需求的INVEST原则 （1） I dependent(独立的):一个用户故事对于另一个用户故事应该是独立的（尽可能的）。故事之间的依赖性使得增加了计划编制，确立有限级，故事估计这些工作非常困难。通常，可以通过组合用户故事或者分割用户故事来减少依赖性。 （2）N egotiable(便于沟通的):一个用户故事是便于沟通的。一个故事的卡片是包含故事详情的简短描述。这些详情是通过讨论阶段来完成的。一张还有很多详情的卡片实际上减少了和客户的会谈。 （3） V aluable(有价值的):每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。 （4）E stimable(可估计的):开发者需要去估计一个用户故事以便确定有限级并对故事进行规划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。 （5）S mall(短小):一个好的故事应该在工作量上短小，描述具有代表性，而且不超过2-3人周的工作量。超过这个范围的用户故事，将会在划分范围和估计时出现很多错误。 （7） T estable(可测试的) :一个用户故事是可测试的来用于确认完成，记住，我们不开发不能测试的故事。如果你不能测试那么你永远不知道你什么时候是完成了。一个不可测试的用户故事例子：软件应该是易于使用的。 一个编写良好的用户故事是敏捷开发的基础。它们应该相互独立，详情应该便于开发者和用户进行沟通，应该对用户有价值，应该对于开发者来说尽可能的清晰以便进行估计，应该短小，通过预定义测试用例的使用确保它是可以测试的。 #### 三、禅道里面的需求和原型图、需求设计文档的区别 传统管理模式中，很多产品经理都在用原型图软件设计原型图或者非常完整的需求设计文档。设计完之后，交给设计人员进行页面设计，然后由开发人员合并代码。那么原型图和用户故事之间的关系和区别是什么呢？ 和user story相比，原型图或者需求设计文档是一个整体，可以给人宏观的把握。这是原型图的优点。比较直观。 它是一个整体，所以就没有办法进行分解。你不可能分解成，做页面导航条，做页面的中间部分等。 没有分解，所以原型图也就没有办法进行优先级的排序。比如页面部分，有的很重要，有的不重要。但在原型图里面是体现不出来优先级的。 没有分解，自然也就无法进行跟踪。你没有办法得知原型图完成了多少。 过于死板，给设计人员和开发人员留下的发挥的空间太少，后演变成被动执行。 需求设计文档规定的比较细致，会让产品经理陷入太多的细节，对整体的把握会减弱。 虽然相比较于用户故事而言，传统的原型图或者需求设计文档有一些不足，但在实际的开发过程中，二者可以相辅相成。禅道从1.2版本中，已经增加了文档库管理。可以将原型图作为设计文档，上传到某一个产品相关的文档库中，和用户故事相互配合，是一个好的方案了。