作为一个<角色>，我想要<活动>，以便于<商业价值>。

• 描述用户故事

好的用户故事讨论的是为谁做和为什么做，而不仅仅是做什么。作为Who，我想要What，以便于Why。 使用贴纸或卡片编写--讨论--确认，随后录入到DevCloud成为工作项，针对每一个测试要点都应该变成完整的测试用例；

• 如何拆分用户故事（以脑图的形式进行）

以“Epic>Feature>Story”进行层级拆分：战略需求-对用户有价值的功能-对一个功能进行用户场景；   场景：细分并且能在一个迭代内完成，Story通常需要满足INVEST原则：Independent（独立的），Neogotiable（可讨论的），Valuable（对客户/用户有价值的），Estimable（可估计的），Small（小的），Testable（可测试的）。     正文：   传统的瀑布研发模式基于三个假设：

• 用户准确的知道自己想要什么。
• 开发人员能够完全理解用户在说什么。
• 需求在研发过程中不会发生变化

用户故事来描述需求 用户故事的目的在于以更快的速度、更少的消耗来应对现实世界需求的快速变化。 华为以往也用需求规格说明书以及用例的形式，但这样的方式非常乏味、容易出错、编写耗时，而且说真心话没人愿意去读。   采用用户故事的好处在于：通过与客户沟通来获取需求，通过与用户协作来澄清需求，通过频繁的发布来确认需求。

• 用户故事强调对话而不是书面沟通。
• 故事更容易被客户和开发人员理解。
• 用户故事大小适中，适合做迭代计划。
• 用户故事鼓励重要的事情先做。
• 鼓励推迟决策，延迟考虑细节。
• 支持随需求而变的开发。

用户故事通常按照如下的格式来表达：三段式的用户故事，核心是从用户角度出发描述问题，站在用户的立场思考问题。

• As a <Role>, I want to <Activity>, so that <Business Value>.

作为一个<角色>，我想要<活动>，以便于<商业价值>。 好的用户故事讨论的是为谁做和为什么做，而不仅仅是做什么。作为Who，我想要What，以便于Why。有了Who、Why、What的信息，How就变得呼之欲出了。 DevCloud支持工作项模板，在“设置 > 项目设置”中，可以看到如何将用户故事的三段式，预置在Story的工作项模板中，也可以根据需要自行定义描述信息。 关于用户故事，Ron Jeffries用3个C来描述它： 关于用户故事，Ron Jeffries用3个C来描述它：

• Card（卡片）：我们在用户故事编写工作坊中使用贴纸或卡片编写，随后录入到DevCloud成为工作项，展现方式可以是卡片、列表或树状结构。卡片代表需求而不是记录需求，详尽的需求内容可以用其他文档表述。
• Conversation（讨论）：讨论的过程建议是面对面的，如果与DevCloud的成员一样，分布在不同地域，可以通过电话或IM工具（华为内部用eSpace，可以聊天，也可以语音、视频）进行，将重要的结论写在工作项提供的讨论功能中。简单的讨论可以直接通过工作项的讨论进行，但需要牢记的是，文字的讨论永远无法取代面对面或是电话的沟通。
• Confirmation（确认）：用户故事并不具备契约性质，达成协议的验证要点是测试的依据，用来验证用户故事是否符合用户的期望。在用户故事编写工作坊中，验证信息可以写在故事卡片的背面，随后录入工作项。针对每一个测试要点都应该变成完整的测试用例，测试用例会与需求进行关联，由此完美的将3C结合在一起。

在DevCloud中的用户故事：

• 卡片是用户故事的展现形式，我们会切换到迭代视图的卡片模式，通过拖动卡片完成状态更新。
• 讨论是沟通的方式，不要让讨论的内容蒸发掉，讨论过程中最大的浪费就是大量的信息随后被遗失掉了。我们通常在Story工作项的评论中记录讨论结果，或是直接在评论中进行讨论，并用@通知他人。
• 确认是验收方式，验收信息可以填写在描述信息中，也可以在项目设置中在Story工作项的模板中添加一个属性字段完成，具体实现方式不一，并且实现起来非常灵活，所以并未做进预置的项目模板中。

一个用户故事工作项，事实上是一个需求的入口，以条目化或是卡片的形式展现，同时可以进行多方位的关联。

• 由验收信息生成的测试用例，会关联到工作项的“关联用例”中。
• 在对话和沟通的过程中会产生的有用信息，可以通过Wiki（知识共享）、Docman（文档协同）来保存，并且可以关联到Story工作项。
• 可以将现有的文件添加为工作项的附件。

如何创建和收集故事？

• 用户访谈
• 故事编写工作坊
• 问卷调查
• 观察

用户故事编写工作坊是捕获需求最有效的方式，原则是：数量优先而不是质量优先，鼓励大家输出，而不要去评判某个故事的好坏；深度优先而不是广度优先，先把一条路走通，而不要中途跳到岔路上。用户最可能做什么？可能会犯什么错误？会有什么困惑？会需要什么信息？在工作坊里最好用贴纸，便于交互，随后再整理到工具平台上。 如何拆分用户故事 以“Epic>Feature>Story”进行层级拆分：

• Epic通常是公司重要战略举措或者巨大的需求，例如做一个电商网站就是一个Epic。
• Feature通常是在Epic之下，对用户有价值的功能，用户可以通过使用特性满足他们的需求。比如“电商网站”的 “门店网络查询功能”，特性通常会通过多个迭代持续交付。
• Story通常是对一个功能进行用户场景细分，并且能在一个迭代内完成，Story通常需要满足INVEST原则：Independent（独立的），Neogotiable（可讨论的），Valuable（对客户/用户有价值的），Estimable（可估计的），Small（小的），Testable（可测试的）。
• Story又可以继续拆成Task

战略、功能、需求、任务等的在具体项目中很难进行归类，也可以简单的按月、周、日、小时为单位进行判断，通常一个Epic可能会跨多个Release交付，Feature跨多个Sprint，Story需要在一个Sprint中完成，而Task通常是更短小以小时至多以天计。 在DevCloud中，从Epic>Feature>Story的拆分，可以在“项目规划”里以脑图的形式进行，一目了然。 也可以在工作项页面中，以树状关系来展现和拆分。 非功能性需求以及技术类需求 当非功能性需求欠缺太多，就背负了技术债务，需要通过定期的技术类活动进行清理。

• 典型的非功能性需求包括：性能、可移植性、可扩展性、可用性、易用性、可维护性、可重用性、可操作性、安全性、容量等。
• 技术类需求的例子包括：重构、搭建持续交付流水线、测试自动化活动、环境的维护与搭建、架构改造等。

通过新增字段可以标识不同类型的需求，更好的方式则是采用Tag标签。善用标签和过滤器的结合，可以实现非常强大的功能，关于过滤器的使用技巧，我们可以单开一个主题来讨论   有关用户故事的一些零散建议 纸质卡片、贴纸，还是电子工具？

• 在需求收集和引导的前期，例如需求编写工作坊，建议采用纸质卡片，便于交互，并且卡片的有限文字空间保证了我们不会过早进入细节。
• 当需求收集告一段落，统一将需求录入到DevCloud平台，需求不只是Card一个维度，多方位的信息需要有工具平台来支撑和记录。同时平台也提供了团队成员之间的协同，DevCloud团队异地的协同场景就是基于DevCloud平台进行的。
• 进行故事优先级排序时
• 不要着急给用户故事添加细节，遵循Kent Beck提出的最后责任时刻原则（Last Responsible Moment），团队要等到开始实现软件特性前才写下特性的具体细节，优先级排序，近期、中期、长期需求的详略程度。