06用户故事与敏捷方法读书笔记一

第一章 概论
用户故事与敏捷方法 Mike Cohn
用户故事：3C（Card卡片、Conversation交流、Confirmation确认）
#Card：描述用户故事只记录对用户有价值的功能，与用户无关或者用户不关心的功能不需要写上去
故事很大的时候称为史诗故事（如：“求职者可以在网站上搜索工作”），可以将史诗故事分成更多的小故事，当有一个故事可以覆盖到每一个细节的时候我们可以停止分解，具体细节问题可以交由开发团队和用户进行讨论。
如：“用户可以查看搜索结果中每个工作的信息”这个故事就没有必要继续分解成“用户可以查看工作描述”、“用户可以查看薪水范围”、“用户可以查看工作地点”
在纸质卡片记录用户故事时，可以在卡片背面记录用户的期望用于作为测试故事的提示，测试描述的灵活度应该很高，用于传递用户故事的额外信息，便于开发人员理解用户的期望，当这些期望都被实现的时候，当前用户故事算是完成了

个人理解：相较于传统开发项目的流程，使用用户故事加大了用户在开发过程中的参与程度

组建客户团队来编写用户故事并确定故事优先级：客户团队应该由确保软件满足用户需求的所有人。包括测试人员、产品经理、实际用户、交互设计师

在用户故事编写会上编写完用户故事集合以后，客户团队和开发人员确定迭代长度（个人理解为一个周期，一周---四周的时间，完整的项目开发需要多个周期），每一轮迭***人员可以做多少事情称为速率。
对于用户故事集合，会将其分为很多堆，每一堆（一定数量的用户故事）代表一轮迭代，在正式开始进行开发以后，根据团队的实际开发速率对每一堆用户故事的数量进行调整，比如，当前一堆的开发难度较低，提前完成开发任务，可以将下一轮迭代的用户故事提到当前迭代，反之亦然。

发布规划：指确定项目时间表和预期功能集合之间达到平衡（项目进度推进与项目完成度应该相匹配）。
#确定故事优先级：在确定故事优先级的时候需要考虑（大部分用户客户对特定特性的渴望程度、小部分重要用户客户对特定特性的渴望程度、故事之间的关系）当客户团队与开发人员出现优先级确定矛盾时，最终应该以客户组织利益最大化的原则。同时在排列故事优先级时应考虑故事成本，故事的故事成本由开发人员给出，用故事点来进行描述。
迭代规划：涉及选择迭代包含的故事（每一个迭代应该实现的具体功能）
#确定故事优先级以后，开始为开发计划中的迭代分配故事，首先由开发人员给出一个预计速率，然后客户团队把故事分配到迭代中，每个迭代的故事点不能超过事先预期的速率。同时在迭代分配故事的过程中，可以在迭代临时跳过一个大故事，放入一个小故事以满足迭代中的故事点不会超过预期速率；除了该方法以外还可以将大故事分解为两个小故事。

验收测试：用来验证实现的用户故事是否符合团队的期望。

相比较于需求文档和用例，用户故事的优势有哪些：
#用户故事强调人与人的交流而不是书面形式的沟通
#用户故事可以同时被你和开发人员理解
#用户故事的大小适合做计划
#用户故事有利于进行迭***
#用户故事鼓励推迟考虑细节，直到你非常清楚的了解自己的需求

推迟细节很重要，对于一些最终需要但是当前并不重要的特性，可以先写下一个史诗故事占位，然后进行提炼，逐渐抛弃史诗故事用更小的更具体的故事替代它

收获：
用户故事是一种强调人与人交流、大小适合做计划、利于进行迭代开发并鼓励推迟考虑细节的需求描述方法。
用户故事的核心是3C原则：卡片（Card）、交流（Conversation）和确认（Confirmation）。
在编写用户故事时，需要注意写出对用户有价值的功能，不需要写无关或不关心的功能。史诗故事可以分解为更小的故事，便于开发团队和用户讨论。
组建客户团队来编写用户故事并确定故事优先级，以确保开发的软件满足用户需求。同时，需要考虑客户组织利益最大化的原则。
迭代规划需要在确定故事优先级的基础上为开发计划中的迭代分配故事，每个迭代的故事点不能超过速率，并且可以在迭代中跳过大故事或将其分解为小故事以满足预期速率。
验收测试用于验证实现的用户故事是否符合团队的期望。
相比需求文档和用例，使用用户故事的优势在于强调人与人的交流、方便理解和计划、有利于迭代开发并鼓励推迟考虑细节。