【DevCloud·敏捷智库】如何利用用户故事了解需求

摘要：这篇文章主要解决由于不能很好地理解需求而估算作很差的问题，在这里能够了解下如何利用用户故事了解需求。

背景

不少团队在应用敏捷开发时，对估算常常感到困惑。这里所说的估算是指产品列表条目（PBI, Product Backlog Item）的估算 。好比，估算以什么标准进行？开发、测试的工做量都要估算进去吗？又好比，估算出了预计工时，可是实际工做中这个预计工时常常不许，为何还要估算这个预计工时呢？还有，作估算管理时，实际工时也会常常被使用，但不少团队成员不按实际状况作实际工时的更新，它的意义何在？

问题分析

为何作估算呢？在规划和管理产品开发过程当中，咱们须要回答一些重要的问题，例如：“将要完成多少个特性？”“咱们何时作完？”在使用敏捷时，为了能回答这些问题，咱们须要估算产品的工做量大小并测算工做速率。有了这些信息，用特性集的估值除以团队速率，咱们就能推算出产品开发的持续周期了。

从小目标来说，作好了估算也能够很好的理解需求，帮助团队成员认领任务。换句话说，团队成员经过估算过程（持续沟通、确认）达成对需求的理解一致，明确完成定义是最重要的。

团队之因此作很差估算，首先是由于没有足够细化需求，更不了解敏捷估算的几个重要核心概念 ，即：“团队估算”、“估算不是承诺”、“要准确，而不是精确”和“使用相对值，而不是绝对值”。其次是不了解估算的正确方法 。这篇文章主要解决由于不能很好地理解需求而估算作很差的问题，在这里能够了解下如何利用用户故事了解需求。

解决措施

估算有这么些重要的意义，如下关于估算的内容是针对承认估算有意义，可是作很差的状况下给予的估算解决方案。

如何更清楚的了解和细化需求是第一步，细化需求和估算是一对儿不能拆分的“鸳鸯”。而后再学习准确的估算，解决估算的各类困惑。

要想准确的估算，先要了解和细化需求，同时了解需求很好的一种描述方法，即User Story。而后了解故事点以及什么是估算及估算的核心概念。基于以上了解后再研究估算方法的实践，最后选择适合的估算方法完成估算活动。能够参考以下示意图便于理解。本篇主要介绍如何了解和细化需求，后面几篇会分别介绍估算核心概念、故事点、估算实践方法和完成估算等内容,即：《如何估算第一篇：利用用户故事了解需求》、《如何估算第二篇：估算的核心》、《如何估算第三篇：估算故事点》和《如何估算第四篇：常见估算方法》。

如何了解和细化需求，要先从用户故事开始聊起。什么是用户故事？用户故事是可用于陈述业务价值的一种简便格式，适合各类PBI,特别是特性。用户故事的制做方式旨在帮助业务人员和技术人员双方都能更好的理解需求。

一个编写良好的用户故事是敏捷开发的基础。编写用户故事的过程就是了解需求，一点点细化需求的过程。需求了解清楚了，必定程度上讲估算的工做就已经完成了一大半，在不了解需求的状况下，估算也是没有意义的。需求的了解是渐近明细的，不少状况下用户的角度看是一种状况，开发人员角度看是另外一种状况，这种误解在需求了解阶段常常出现，以下图。

咱们一块儿看看，为何说用户故事写好了就了解需求了呢？一个良好的用户故事应该是相对独立的、详情应该是便于开发者和用户沟通的、应该对用户是有价值的、应该对于开发者来讲尽量的清晰以便进行估算的、应该短小的、经过预约义测试用例的使用确保它是能够测试的。以上的特色具有了，相信写出来的用户故事是在了解了用户最初的需求基础之上。其实，这些特色有一个名称“INVEST原则”，是极限编程（英语简写XP,是敏捷开发方法之一）中对用户故事拆分的指导原则。INVEST原则用于评估用户故事，也就是说，好的用户故事应该具有INVEST特性：即独立的（Independent）、可协商的（Negotiable）、有价值的（Valuable）、可估算的（Estimatable）、大小适合的（Small）和可测试的（Testable）。

用户故事到底是什么呢,如何才能写好用户故事？极限编程（XP）的创始人之一Ron Jeffries给出一个简单有效的方法来帮助咱们理解用户故事。他将它描述为3C：卡片、会话和确认。了解了3C也就大概清楚了怎么样才能写好一个用户故事，以及为工做量估算作好基础准备工做。

1.卡片

卡片很是简单，最初能够写在便利贴上，有一个通用的格式，以下面用户故事模板图，即写明用户种类（即用户角色）、这类用户想要达成什么（目标）以及用户为何想达成目标（收益）。

用户故事标题的命名也是有讲究的，在辅导团队过程当中发现有些团队的用户故事名称不统一，容易对团队形成困扰。例如，有的名称太长，甚至是长长的一段话；有的过短，不能清晰的识别用户核心内容是什么；有的没有价值，就是普通的任务（Task）。建议采用统一的动宾短语写出较好的用户故事标题：

• 用户角度

描述从用户角度看到的功能。例如，查看详细信息、新增查询、删除货品等。

• 系统角度

描述从待开发的系统的角度要实现的功能。例如，推送合同信息、发送用户订阅信息等。

固然，你也许会有个疑问。这些标题都没有主语，好像也不太能快速识别用户故事的核心内容。Of course，若是你想更清楚表达，也是能够加上主语的。好比，新注册用户查看详细信息、库存管理员查询商品号、HR系统群发助手发送订阅信息等。不过，更想说的是，更详细的信息建议在卡片内容中说明，由于里面写明了用户种类（即用户角色）、这类用户想要达成什么（目标）以及用户为何想达成目标（收益）。用户故事标题仍是以简单、明了为主。

2.对话

在对话中讨论需求细节。开发团队、产品负责人（PO, Product Owner）利益干系人在对话中发现并探讨需求的细节。用户故事仅仅是进行此对话的承诺。用户故事的一大好处就是它能把关注点从写做转移到会话。对话开启了一个更丰富的信息交换与协做形式，从而确保正确描述需求并使每一个人都能理解需求。对话不只仅是靠口头交流，还能够并且常常借助于文档，也可得出能够记下来的一张用户界面草图或业务规则的一份详细阐述。

3.确认

用户故事还要包含确认信息，也就是咱们常说的接收标准（AC, Acceptance Criteria）。有了接收标准，开发团队才更清楚要构建和测试什么，产品负责人也能够确认用户故事的实现是否符合预期。这些定义的接收标准也能够看做是高一级的接收测试。固然，开发故事的时候不会只有这几个测试，这些与故事挂钩的接收测试之因此存在，是由于从产品负责人的角度看，它们是捕获及沟通讯息、肯定故事是否已经正确实现的重要方式之一。

咱们了解了用户故事和它的3C原则，如今来看看怎么写一个好的用户故事，来更好地分析和理解需求。

咱们知道了用户故事的模板内容，看着很是简单，然而越简单的东西，反而越容易让人放松警戒，而后照着模板内容写出来的并非一个很好的可以理解需求的故事。举例，一个餐饮点评网站的用户故事可能会这样写：

做为一个用户，我但愿看到某个地址附近的餐馆的公正的评论，这样能够决定去哪里吃饭。

其实，这就是一个典型的质量不高的用户故事。写出高质量的用户故事的关键在因而否可以准确地描述用户但愿获取的价值。这个观点只对了一部分，就像上面的故事同样。你们可能会问，既然用户但愿获取的价值都描述清楚了，为何客户还不接受呢？主要缘由是你高估了本身的理解能力和表达能力，同时也高估了客户的理解能力和表达能力。如上面提到过的理解需求误区图，客户的角度看需求是“6”，需求调研人员角度理解的是“9”，这也是常见的需求理解问题。

再来看另一个例子：

做为一个在国贸工做，午休时间短，又追求健康饮食的公司白领，我但愿看到某个地址附近的餐馆的客观的评论，这样能够决定去哪里吃饭。

可见，第二个故事中，感受好多了。仔细看看差在哪里呢？熟悉需求调研的伙伴儿们都知道，需求调研是从了解客户是谁开始的，须要弄清楚产品须要得到什么样的客户的承认和接受，利用“对话”原则，充分沟通。这个故事描述了用户的特征，站在用户角度思考，更可以提高最终交付物为客户接受的可能性。同时，还要定义清楚什么是“接收标准”，与客户确认清楚具体的条件。这个故事的接收标准能够参考接收标准参考内容图：

如今能够了解怎么写好用户故事，以及如何更好地理解客户需求了。对需求有了更好的理解，接下来须要再了解一下估算的核心，《如何估算第二篇：估算的核心》以便更好地完成估算。

做者：华为云社区专家｜黄药师

参考附录

1. Kenneth S. Rubin. Scrum精髓[M].北京：清华大学出版社。

2. Mark C. Layton. 敏捷项目管理[M].北京：人民邮电出版社。

点击关注，第一时间了解华为云新鲜技术~