用户故事与敏捷方法读后感（一）

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

在前六章中主要讲的就是编写用户故事，书中提供了一种节省时间和消除重复工作的需求管理方法，通过用户故事与敏捷方法，对开发更优秀的软件，起着积极高效的推动作用。软件开发起始于需求收集和分析。传统的方式客户获得的只会是开发人员根据他们对文档的理解所开发的软件系统，这可能并不是客户真正需要的，这种情况下软件的成功无从谈起。用户故事是敏捷实践中一个十分重要的环节，有助于我们高效地收集客户真正的需求。用户故事由卡片，交谈，确认三方面组成，卡片记录故事描述，其具体表现形式为作为角，我想要什么活，以至于实现怎样的商业价。在用户角色建模时，进行头脑风暴列出角色集合，然后整合角色，提炼角色。在描述活动时，首先我们应当去搜集故事，搜集方式有用户访谈，问卷调查，观察使用情况，故事编写工作坊。很多时候，我们接触的并不是实际用户。编写用户故事时，用户**不如实际**理想，甚至更是错误信息的**，客户团队需要通过与用户**合作，了解真实用户的需求。商业价值是否被实现是由测试来体现的，在故事卡片背面写下我们的测试要点，并不断补充新的测试内容，以形成全面测试。客户并不能给出详细测试，但可以详细的指出一些测试，用于验证故事的实现是正确的。如何编写好的故事，需要遵循一定的规范。例如故事应当独立，尽量避免依赖。故事应当是可讨论的，避免过早确定细节。故事应当易于理解，使用商业语言去写，而不是技术语言。使用主动语态编写，谁可以做什么。故事应当进行分割或合并，使得大小适宜。故事一定要是可测试的。

故事卡的主要目的是用来提醒开发人员和客户团队对功能进行讨论的，也仅仅只是一个提醒，不要加入太多的细节并以此取代对话，以至于使它看起来像个需求文档。用户故事并不是万能的，如果我们确实有写文档的需要，尽管放心的去写。