笔者在华为云DevCloud工作，传承了吃狗粮的文化。 DevCloud团队在践行精益敏捷DevOps的同时，借助DevCloud工具在实践中落地。 然后，我想讲述人们自己的故事，讲述DevCloud是如何制作敏捷DevOps的，于是产生了写《我在DevCloud》系列的想法。 现在计划的如下。
【我在DevCloud上有需求】
【我在DevCloud上报价】
【在DevCloud上制定了计划】
【正在用DevCloud进行开发】
【正在DevCloud上进行测试】
【正在用DevCloud进行检查】
【正在用DevCloud进行集成】
【通过DevCloud交货】
.
采用“我在DevCloud”作为系列主题有两层含义：
第一，DevCloud是笔者所在的团队，所以我要写下DevCloud团队是如何进行这些活动的
其二，DevCloud是笔者所在团队开发的DevOps工具链平台，我们将向您介绍如何在DevCloud上开展这些活动。
另外，需要说明的是：
这些实践方式，由DevCloud团队实践，因此具有一定的典范；
但不具有普遍性，各团队必须根据自身团队的业务特性、团队成熟度、流程及方法论解读落地实现
里面有很多优化的空间，没有最优的实践，只有合适的实践。
一般来说，软件开发是从收集和分析需求开始的，所以我们系列的第一篇是从需求开始。
传统的瀑布研发模式基于三种假设：准确知道用户想要什么，开发人员完全理解用户在说什么，需求在研发过程中保持不变。
但是实际上，这三个前提条件并不存在，为了交流而制作的产品容易像下图所示的蛋糕一样(笑)。
根据用用户故事描述需求的维基百科，用户故事的目的是以更快、更少的消费来应对现实世界需求的迅速变化。
DevCloud以用户故事的形式记录需求。 华为过去也使用要求规格书和用例的形式，但这种方式非常无聊，容易出错，制作起来很费时间，真心话谁都不想读。
采用用户故事的好处如下。
用户故事强调对话而不是书面交流
故事容易被顾客和开发者理解
用户故事大小适中，适合迭代计划
用户故事鼓励重要的事情先做
鼓励延缓决策，推迟考虑细节
支持按需开发
用户故事侧重于从传统文档到更实用的对话。 所有的文档看起来都很美，但很费时间和精力，没有人去看。 相反，它通过与客户交流来获得需求，通过与用户合作来明确需求，并在频繁发布中审查需求。
用户文章通常表现为以下格式：
As a Role，I want to Activity，so that Business Value。
作为角色，我想为了提高商业价值而活动。
三段论的用户故事的核心是从用户的角度描述问题，站在用户的立场思考问题。
好的用户故事不仅仅讨论做什么，还讨论为谁做和为什么做。 作为世卫组织，为了使世卫组织变得容易，我想要世卫组织。 有世卫组织、世卫组织、世卫组织的信息，世卫组织会想尖叫。
我们从以前就开始写需求，往往会注意到What (做什么)，但忽视了Who (世卫组织)和Why (世卫组织)。
世卫组织的逻辑模型，也正是影响地图的结构，我们找机会单独谈谈影响地图的问题。
DevCloud支持工作项模板。 设置-项目设置允许用户查看如何在Story工作项模板中预设用户文章的三级表达式，用户还可以根据需要自行定义说明信息。
根据Ron Jeffries提出的3C原则介绍用户故事。 Ron Jeffries用三个c描述它。
• Card、卡片，我们在用户故事制作研讨会上用贴纸或卡片制作，输入DevCloud作为工作项目。 显示方法有卡、列表、树等。 卡表示要求，而不是记录要求。 详细要求的内容可以在其他文档中表达。
转换，讨论过程建议面对面进行。 如果您也像DevCloud成员一样分布在不同的地区，则可以通过电话和IM工具(在华为内部也可以使用eSpace，通过语音、视频和聊天)进行。 将重要结论写入工作项目提供的讨论功能中，简单的讨论可以通过工作项目的讨论直接进行。 但是必须记住，文字讨论不能代替面对面和电话交流。
• Confirmation，确认用户文章不具有合同性质，达成协议的验证点是测试的依据，用于验证用户文章是否符合用户的期望。 在用户故事制作研讨会上
，验证信息可以写在故事卡片的背面，随后录入工作项。针对每一个测试要点都应该变成完整的测试用例，我们使用DevCloud的云测模块，具体测试的部分会在后续【我在DevCloud做测试】一文中介绍。测试用例会与需求进行关联，由此完美的将3C结合在一起。卡片是用户故事的展现形式，我们会切换到迭代视图的卡片模式，通过拖动卡片完成状态更新。
讨论是沟通的方式，不要让讨论的内容蒸发掉，讨论过程中最大的浪费就是大量的信息随后被遗失掉了；我们通常在Story工作项的评论中记录讨论结果，或是直接在评论中进行讨论，并用@通知他人。
确认是验收方式，验收信息可以填写在描述信息中，也可以在项目设置中在Story工作项的模板中添加一个属性字段完成，具体实现方式不一，并且实现起来非常灵活，所以并未做进预置的项目模板中。
一个用户故事工作项，事实上是一个需求的入口，以条目化或是卡片的形式展现，同时可以进行多方位的关联。
• 由验收信息生成的测试用例，会关联到工作项的”关联用例“中。
• 在对话和沟通的过程中会产生的有用信息，可以通过Wiki（知识共享）、Docman（文档协同）来保存，并且可以关联到Story工作项。
• 也可以将现有的文件添加为工作项的附件。
如何创建和收集故事？通常有几种方式进行用户故事的创建和收集，其中前两种是最经常采纳的：
• 用户访谈
• 故事编写工作坊
• 问卷调查
• 观察
用户访谈的关键是找到真正的用户，所以用户访谈之前是用户画像，也就是找到Who的过程。
“你们的确开发了我所说的功能，但它并不是我真正想要的”，用户往往不知道或很难准确表达自己想要的，所以沟通需要频繁，需要拿着不同阶段的产物进行确认；
说者无心，听者有意，会不会是自己主观臆断？说者有心，听者无意，会不会遗漏关键字？同理心说起来容易，做起来很难。
用户故事编写工作坊是捕获需求最有效的方式，原则是：数量优先而不是质量优先，鼓励大家输出，而不要去评判某个故事的好坏；深度优先而不是广度优先，先把一条路走通，而不要中途跳到岔路上。
用户最可能做什么？可能会犯什么错误？会有什么困惑？会需要什么信息？
在工作坊里最好用贴纸，便于交互，随后再整理到工具平台上。
观察用户真实使用产品的机会是难能可贵的，你会发现用户永远不会按照你设计的方式使用产品。
需求通常以Epic-Feature-Story进行层级拆分：
• Epic通常是公司重要战略举措或者巨大的需求，例如做一个电商网站就是一个Epic。
• Feature通常是在Epic之下，对用户有价值的功能，用户可以通过使用特性满足他们的需求。比如“电商网站”的 “门店网络查询功能”，特性通常会通过多个迭代持续交付。
• Story通常是对一个功能进行用户场景细分，并且能在一个迭代内完成，Story通常需要满足INVEST原则：Independent 独立的，Neogociable 可讨论的，Valuable 对客户/用户有价值的，Estimatable 可估计的，Small 小的，Testable 可测试的。
• Story又可以继续拆成Task，Task是实现层面的，无需遵循INVEST原则。
战略、功能、需求、任务等的在具体项目中很难进行归类，也可以简单的按月、周、日、小时为单位进行判断，通常一个Epic可能会跨多个Release交付，Feature跨多个Sprint，Story需要在一个Sprint中完成，而Task通常是更短小以小时至多以天计。
从Epic-Feature-Story的拆分，可以在项目规划里以脑图的形式进行，一目了然。
同样也可以在Epic或Feature视图中，以树状关系来展现和拆分。
NonFunctional Requirement，非功能性需求往往是决定产品/项目成败的关键，却往往容易被忽视。
当非功能性需求欠缺太多，就背负了技术债务，需要通过定期的技术类活动进行清理。
典型的非功能性需求包括：性能、可移植性、可扩展性、可用性、易用性、可维护性、可重用性、可操作性、安全性、容量等。
技术类需求的例子包括：重构、搭建持续交付流水线、测试自动化活动、环境的维护与搭建、架构改造等。
目前我们没有预置非功能性需求和技术类需求作为单独的工作项类型，不希望工作项类型过于膨胀而增加了使用的复杂性。
可以新增字段来标识不同类型的需求，更好的方式则是采用Tag标签。
善用标签和过滤器的结合，可以实现非常强大的功能，关于过滤器的使用技巧，我们可以单开一个主题来讨论。
如同低质量的代码会有Bad Smell，用户故事也一样会有坏味道：
• 如果你发现几十页上百项需求堆在Product Backlog里
• 如果你发现提交的需求，自始至终没人和你沟通，某一天突然发现需求被实现了
• 如果你发现排在Product Backlog中段和后段的用户故事太过详尽
• 如果你发现大家依赖Product Backlog电子系统，而不是面对面进行沟通
• 如果你发现用户故事长得像需求规格说明书
• 如果你发现说不出故事的目标用户以及带来的价值
• 如果你发现很难为众多故事排优先级（不是高中低，而是唯一顺序）
• 如果你发现故事之间牵一发而动全身
• 需求要有时间点，多问一句”什么时候需要？”，你往往会发现对方其实心里没数，ASAP不是一个好答案，越快越好只能说明不信任。尽管会有顾虑，我依然会如实说“这个功能与一个月之后的某个活动相关，在此之前实现即可，但需要预留给我一周的时间进行验证和修复”。
• 进行故事优先级排序时，需要考虑成本，一个重要的需求，有可能因为成本过高而延后，另一种方法是对其进行拆分。
• 不要着急给用户故事添加细节，遵循Kent Beck提出的最后责任时刻（Last Responsible Moment）原则，团队要等到开始实现软件特性前才写下特性的具体细节。优先级排序，近期、中期、长期需求的详略程度。
• 纸质卡片/贴纸，还是电子工具？在需求收集和引导的前期，例如需求编写工作坊，建议采用纸质卡片，便于交互，并且卡片的有限文字空间保证了我们不会过早进入细节。当需求收集告一段落，统一将需求录入到DevCloud平台，需求不只是Card一个维度，多方位的信息需要有工具平台来支撑和记录。同时平台也提供了团队成员之间的协同，DevCloud团队异地的协同场景就是基于DevCloud平台进行的。
故事是讲出来的，不是写出来的；故事的目的是激发沟通中的火花，用户故事之所以叫故事，是因为他要讲而不是要写的，沟通、协作并最终交付好的需求。
DevCloud的需求实践并非最佳的，只是适应我们自身团队以及产品/项目情况的折中之选。
本文不追求面面俱到的介绍有关需求以及用户故事的点，如果您有与需求相关的问题，请留言给我，我会集中回答。
转载于:https://juejin.im/post/5cf0dc505188254c5879f738