背景

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

问题分析

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

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

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

解决措施

估算有这么些重要的意义，以下关于估算的内容是针对认可估算有意义，但是做不好的情况下给予的估算解决方案。

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

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

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

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

理解需求误区图

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

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

 卡片

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

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

• 用户角度

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

• 系统角度

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

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

用户故事卡片模板图

 对话

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

 确认

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

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

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

作为一个用户，我希望看到某个地址附近的餐馆的公正的评论，这样可以决定去哪里吃饭。

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

再来看另外一个例子：

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

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

接收标准参考内容图

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

参考附录

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

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

----------------------------------------------

作者随笔

作为敏捷推广者和马拉松爱好者，聊聊敏捷与马拉松。

一个胖子想变成瘦子，方法很多，比如无氧器械、疯狂单车、要命波比跳，当然还有马拉松。

近年来马拉松被炒得火热，引得大家蜂拥而至。马拉松看似简单，实际上一个优秀的跑者是需要长年的基础训练和日积月累的跑量。有些人参加拉松是为了赶时髦，全凭三分热度，急于求成。往往前者已达终点，后者却在半路怀疑人生，早早弃赛。

敏捷转型就像马拉松一样：

理论实践vs基础训练，

稳定速率vs平稳配速，

定期回顾vs适时补给，

持续改善vs健康奔跑，

团队稳定vs跑得长久，

个人有所长，团队全功能vs个人跑得快，群体跑得远。

如果没有夜以继日的“内功”修炼，想要一朝练成“碧海潮生曲”，无疑是天方夜谭，必以失败告终。

原文来自：https://bbs.huaweicloud.com/forum/thread-36923-1-1.html