大咖专栏 | 我在DevCloud作需求

笔者在华为云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>.

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

三段式的用户故事，核心是从用户角度出发描述问题，站在用户的立场思考问题。

好的用户故事讨论的是为谁作和为何作，而不只仅是作什么。做为Who，我想要What，以便于Why。有了Who,Why, What的信息，How就变得呼之欲出了。

以往咱们上来就写需求的，每每注意到的是What（干什么），却忽略了Who（为谁作）以及Why（为何作）。

而Who-Why-How-What的逻辑模式，刚好也是影响地图的结构，有关影响地图，咱们找机会单独聊。

DevCloud支持工做项模板，在设置->项目设置中，能够看到如何将用户故事的三段式，预置在Story的工做项模板中，用户也能够根据须要自行定义描述信息。

​

咱们遵循Ron Jeffries提出的3C原则

关于用户故事，Ron Jeffries用3个C来描述它：

• Card，卡片，咱们在用户故事编写工做坊中使用贴纸或卡片编写，随后录入到DevCloud成为工做项，展示方式能够是卡片、列表或树状结构。卡片表明需求而不是记录需求，详尽的需求内容能够用其余文档表述。

• Conversation，讨论的过程建议是面对面的，若是你也是像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 如何识别用户故事的坏味道

如同低质量的代码会有Bad Smell，用户故事也同样会有坏味道：

• 若是你发现几十页上百项需求堆在Product Backlog里

• 若是你发现提交的需求，自始至终没人和你沟通，某一天忽然发现需求被实现了

• 若是你发现排在Product Backlog中段和后段的用户故事太过详尽

• 若是你发现你们依赖Product Backlog电子系统，而不是面对面进行沟通

• 若是你发现用户故事长得像需求规格说明书

• 若是你发现说不出故事的目标用户以及带来的价值

• 若是你发现很难为众多故事排优先级（不是高中低，而是惟一顺序）

• 若是你发现故事之间牵一发而动全身

有关用户故事的一些零散建议

• 需求要有时间点，多问一句”何时须要？”，你每每会发现对方其实内心没数，ASAP不是一个好答案，越快越好只能说明不信任。尽管会有顾虑，我依然会如实说“这个功能与一个月以后的某个活动相关，在此以前实现便可，但须要预留给我一周的时间进行验证和修复”。

• 进行故事优先级排序时，须要考虑成本，一个重要的需求，有可能由于成本太高而延后，另外一种方法是对其进行拆分。

• 不要着急给用户故事添加细节，遵循Kent Beck提出的最后责任时刻（Last Responsible Moment）原则，团队要等到开始实现软件特性前才写下特性的具体细节。优先级排序，近期、中期、长期需求的详略程度。

• 纸质卡片/贴纸，仍是电子工具？在需求收集和引导的前期，例如需求编写工做坊，建议采用纸质卡片，便于交互，而且卡片的有限文字空间保证了咱们不会过早进入细节。当需求收集告一段落，统一将需求录入到DevCloud平台，需求不仅是Card一个维度，多方位的信息须要有工具平台来支撑和记录。同时平台也提供了团队成员之间的协同，DevCloud团队异地的协同场景就是基于DevCloud平台进行的。

小结

故事是讲出来的，不是写出来的；故事的目的是激发沟通中的火花，用户故事之因此叫故事，是由于他要讲而不是要写的，沟通、协做并最终交付好的需求。

DevCloud的需求实践并不是最佳的，只是适应咱们自身团队以及产品/项目状况的折中之选。

本文不追求面面俱到的介绍有关需求以及用户故事的点，若是您有与需求相关的问题，请留言给我，我会集中回答。