《用户故事与敏捷开发》阅读笔记02
这周读了《用户故事与敏捷开发》的第四至七章，第四章讲述的是如何搜集故事，也就是如何正确的去找到用户需求。作者明确指出“引用”和“捕捉”是不合用的。所谓“引用”和“捕捉”，我想是通过用户对功能的表述，开发人员从中获取需求信息吧。如果是这种方法来获取需求，正如作者所说，用户不会知道所有的需求，所以只靠着这方法是远远不够的。对于故事编写的数量以及程度，作者认为故事不需太多，只要将大体功能需求写出即可，因为一个用户故事可以在今后演变为更小的，更有用的多个故事。对于搜集如何故事，作者给出了四个方法：用户访谈、问卷调查、观察、故事编写工作坊。用户访谈是大多数团队用的方法，它的关键是选择正确的受访者，而提问是获取用户本质需求最有效的办法，但提问问题需要技巧，我们需要开放式问题和背景无关问题。问卷调查是一种有效的办法来获取需求，但单向沟通具有既有特点和时间滞后的缺点，所以作者并不推荐使用。观察需要我们和用户在一起，通过他们工作时的具体情形来获取需求。故事编写工坊是开发人员、用户、客户、产品客户和其他对编写故事有帮助的人共同参加的会议。
第五章，与用户代理合作。在这一章主要讨论了不同类型的用户代理。因为在实际开发中我们很少接触真正的用户，而更多的是接触用户代理，作者指出了用户代理分别是开发经理、销售人员、领域专家、市场营销团队、以前的用户、客户、培训师和用户支持、业务分析师和系统分析师时应注意的问题。不管用户代理是谁，我们都可能遇到下面几个问题，能接触用户但访问受限，此时我们应该请求准许启动一个用户顾问团体，有数量不限的实际用户组成。当实在不能接触到用户时，必须求助于用户代理时，一种有效的办法是使用多个用户代理。不管任何时候，即使我们知道用户的想法，也不能忽略用户代理，自己写需求，而当设立客户团队时，我们要注意实际用户总是优于用户代理的。
第六章，用户故事验收测试。故事验收测试可以充实很多用户故事的细节。验收测试提供了确认故事你是否被完整实现的基本标准，这是确定什么时候哪件事做完了的最好的办法。一般来说测试要在编写代码前就制定好，而且一般由客户定义测试内容，测试的数量一般由是否还能为故事增加价值和使它更加清晰来决定，测试的类型主要是功能性测试，作者还举出了其他几个类型的测试：用户交互测试、可用性测试、性能测试、压力测试。
第七章，优秀故事准则。想要确定用户故事必须考虑每一个用户角色，了解用户使用我们软件的目的，当面临一个大的故事时，通常我们需要将它分成较小的故事，很多时候我们要根据实现时间来确定故事的规模。作者提醒我们不要过早地用户界面涉及，有些需求并不是故事。在编写故事时，我们还要注意，在故事中要包含用户角色，故事市委一个用户编写的，以主动语态，由客户编写，不要对故事卡片编号，不要忘记意图，也就是故事卡是用来提醒开发人员和客户团队对功能进行讨论的，要尽量简洁。
