01用户故事与敏捷方法笔记之一

本部分重点描述前四章本人的读书感想，本部分属于第一部分——起步。

这一部分的简介中介绍：用户故事的目的之一是让大家交谈而不是写。第一部分的目的是让你尽快开始交谈。

第一章概要介绍什么是用户故事，如何使用故事。然后接下来的部分详细介绍了编写用户故事，如何通过用户觉得建模收集故事，在不能直接访问真实的最终用户是编写故事，测试用户故事，并用一章的篇幅介绍用户故事改进指南。

在这里，我会详细并着重强调对我有帮助的章节，并写出我的感想。

正如豆瓣中所言：软件需求是一个沟通问题。
软件项目具备不可控性，我们无法完美地预测软件项目，开发人员最艰难的时刻就是估计需要多长时间才能完事儿。而在平时编程中，每车次尝试这方面的估计，总是会和实际发生很大偏差。

怎么办？我们通常根据手头信息来做决策，只要我们别在项目开始时做一套包罗万象的决策，而是把各个决策分散到项目过程中。为此，我们要确保有一个获取信息的过程，越早越好、越频繁越好。

第2章 编写故事

一个优秀的故事应该具备六个特点（INVEST）：
独立的（Independent）
可讨论的（Negotiable）
对用户或客户有价值的（Valuable to Purchasers or User）
可估计的（Estimatable）
小的（Small）
可测试的（Testable）

编写故事过程中，我们应该尽量减少故事之间的相互依赖。一位股市之间的一来会导致问题的估计更加困难。至于消除方法，这就因人而异了，例如：分割故事。对大故事进行分解，对小故事则要进行合并，保证整个用户故事的合适。故事还必须是可测试的，成功的被测试才代表故事正确的被实现。这样，才算是一个好故事。

 

而在接下来的用户建模中，我们必须要对初始角色尽可能的收集，这就需要开发人员和用户一起参与。大家尽可能提出可能参与的角色。通常，我们还需要虚构人物（假想用户角色代表，使人物更生动、更具体）和极端人物（考虑那些与众不同的人，可能会让我们写出之前遗忘的故事）进行使用。通过这一系列的行为，便对用户需求中涉及到的用户角色进行了建模，利于我们后面的进一步的进程。