《用户故事与敏捷开发》阅读笔记01
今天，按照阅读计划，我读了《用户故事与敏捷开发》的前三章，这本书有很多东西都读不懂，所以我的理解也很局限，而且也不知道对不对。书中对用户故事的定义是描述了对用户、系统或软件购买者有价值的功能，通过后面的阅读我认为其实就是客户对软件要求实现的功能。用户故事一般写在卡片上，而且是由客户来写，主要内容是对软件功能需求的描述。通常会在背面有一些注释，用来记录需要测试的项目，其实是提醒软件开发者对软件一些情况的考虑以及处理。故事不能太大，但也不能将写入所有细节，这都不是正确的故事卡片，书中已经给出了准确的卡片模版。故事是贯穿整个开发流程的，因此故事是迭代的，软件开发者一般会根据故事对客户的价值来安排故事的优先级顺序，每个故事的完成也代表了开发人员的速率，。在不同的开发环节，开发人员也需要对故事进行规划、处理，而故事的完成往往会要让客户测试，以便验证是否合乎客户要求，同时也有助于客户及时提出新的要求。
这本书第二章名为“编写故事”；顾名思义，这章主要介绍了如何编写故事，也就是客户如何更加形象的将需求表述给开发人员，或者是开发人员如何正确的整理客户的故事卡片。
一个优秀的故事应该有以下六个特征：独立性，可讨论性，对用户或客户有价值的，可估计的，小的，可测试的。独立的就是尽量避免故事间的依赖；可讨论的，故事是由客户编写的，但他们不懂软件开发，必然会不合理的地方，这就要求一些故事是客户与开发人员商量决定；对用户或客户有价值的，一些故事是客户想不到的，但对客户是有用的，需要考虑的；可估计的，开发人员必须对每个故事有一定的时间估计；小的，经过对故事的分析后，必须制定合理大小的故事；可测试的，对于已完成的故事必须能够测试，让用户尽早提出建议。
对于第三章用户角色建模，用户角色，也就是会使用到我们软件的人员，但应该是多少类，而不是多少个。书中给出了进行用户角色建模的步骤，其实也很好理解，首先列出所有可能会使用到我们软件的人员，整理最初的角色集合，也就是将使用功能有重叠的角色放在一起，整合角色大部分使用功能相同的角色变为一个，最后根据角色特征提炼角色，开发相应的功能模块。对于第三章最后介绍的两个额外技术，虚构人物，极端人物，我并不是很理解。