本书讲解了如何去确定一个软件系统应该做什么还有软件需求调研人员如何与不同的人沟通。需求文档是重中之重，但是大量预先的需求收集和文档会很容易导致项目失败。最常见的是需求文档变成软件开发的目的。我们不应为了写文档而写文档。文档只是为了软件开发更为方便的一种工具，我们不应将大部分的时间浪费在无用的文档撰写上。同时大量的文档也会出现记录语言不准备的弊病。因此我们需要学习和研究，如何更加准确，简洁的描写出用户的需求。这也是这本书一直讨论的问题。

        用户故事能够合理的还原场景，使需求调研人员感同身受，这是我的理解，它代表了对用户有价值的功能。这时故事卡就是一种非常有用的工具。故事卡包含用户或者日客户有价值的功能的简短描述，是故事的可见部分，但客户团队和开发人员对于故事的对话更重要。在编写故事时，也有很多需要注意的点，比如故事必须要对用户或客户有价值，故事变为可用代码必须是可实现的。故事之间是独立的，他们之间并不会有很强的依赖性。有用户故事就有用户类型。这也是我们在项目开发中极易忽略但又特别重要的一点。大部分项目小组只考虑单一的用户类型，这是不可取的，会导致软件忽略原本需要的一些用户类型。软件写出来就是为了让人来进行使用的，没有了用户，软件的存在也就没有意义。        

        需求捕获就像出海捕鱼。鱼有大小之分，需求会随着时间也逐渐变化。需求调研人员需要做的就是将这些有捕捞价值的“鱼”使用各种各样的网捕捉起来，弃掉无用的鱼，也不能漏过任何一条有价值的鱼。而与需求调研人员合作的，便是用户代理。用户能够更好的为我们提供需求分析的案例，因此选好用户代理也是非常重要的

在一个大型项目中，尤其是有许多用户角色的项目，确定用户故事有时让人无从下手。我发现最好的办法是考虑每一个用户角色，了解用户使用我么软件的目的。

　　所以编写故事的时候注意以下几点。第一，根据实现时间来确定故事规模，逆向专注于最需要你关注的领域。通常，这意味着要把注意力放在那些即将发生的事情上，而不是放在更远的将来才发生的事情上。对股市而言，要基于故事实现的时间跨度，以不同的层次来编写故事。例如，对于下面几轮迭代的故事，它们的大小应该能够安排进那几轮迭代中，而对于更遥远的故事，它们可能会更大，但精准度则更低。第二，不要过早设计用户界面，一直困扰软件需求方法的问题之一是将需求和解决方案混在一起。也就是说，在陈述需求的时候，也显式说明或暗示了解决方案。最常见的情况是用户界面，这个应该放在最后边考虑。第三，不要忘记意图，不要忘记，故事啦的主要目的是用来提醒开发人员和客户团队对功能进行讨论的。既然仅仅是一个提醒，就要保持它的简洁性。加入需要的细节，以便联想到继续对话的切入点，但不要在故事卡上加入太多细节并以此取代对话。

　　接下来我们就需要着手估算用户故事了，首先一定要找到故事点。有一种可以满足所有这些目标的估算方法，即用故事点估算。故事点有个很好的特性是团队可以定义自己认为合适的故事点。一个团队可能决定定义一个故事点为一个理想日的工作。另一个团队可能定义一个故事点为一个理想周的工作。还有一个团队可能把故事点作为故事复杂度的测量。因为故事点有很多意义，有意Joshua Kerievsky认为故事点代表时间的模糊单位。

　　我们可以将一个故事点的工作量看做是一个理想日的工作。我们极少会有这样的理想日，但是用理想时间考虑故事有两个好处。第一，相对于用连续的时间估算，它更简单。用持续时间估算破事我们考虑对时间的各种可能性影响，例如，星期二全公司会议，星期三约了牙医，每天花几个小时回邮件等等。第二，相较于用完全模糊单位没用理想日估算故事点可使我们的估算拥有更好的依据。估算的主要目的之一是知道整个项目的工作量，所以最后我们总是要将估算换算成时间。显然，相较于完全模糊单位，用理想时间更简洁。

　　安排好故事点后，我们需要将汇集的故事点转换成项目的预计工程。答案当然是使用速率，迭代轮数等于理想日除以使用速率。