用户故事与敏捷方法

第1章 概览

软件需求是一个沟通问题。
我们无法完美地预测软件项目，软件项目具备不可控性，开发人员最艰难的时刻就是估计需要多长时间才能完事儿。怎么办？我们通常根据手头信息来做决策，只要我们别在项目开始时做一套包罗万象的决策，而是把各个决策分散到项目过程中。为此，我们要确保有一个获取信息的过程，越早越好、越频繁越好。用户故事由此应运而生。

第2章 编写故事

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

第3章 用户角色建模
第4章 搜集用户故事
第5章 与用户代理合作

第6章 用户故事验收测试

1、在写代码之前写测试
2、集成测试框架
每轮迭代产生的可工作代码在接下来的迭代中可能遭到破坏，所以每轮迭代都要执行以往迭代的所有验收测试。这样，每轮迭代都要花更多的时间来执行验收测试。如果可能，开发团队应该自动化部分或全部验收测试。
3、测试类型
功能性测试、交互测试、可用性测试、性能测试、压力测试
4、测试的目的是发现并消除缺陷，没有必要追求100%的代码覆盖率或所有的边界条件。我们运用直觉、知识和经验来指导测试。

第7章 优秀用户故事准则

不要过早涉及用户界面
模板：我作为（角色），想要（功能），以此（商业价值）

第8章 估算用户故事

估算故事的最好方法具有如下特点：
无论什么时候获得有关故事的新信息，都允许我们改变之前的想法
适用于史诗故事（Epic）和小故事
不需要花很多时间
提供进度和剩余工作的有用信息
不太精确的估算也不会有太大问题
可以用来制定发布计划
团队可以商定约束估算只用一些预订的值：1/2，1，2，3，5，8，13，20，40，80

第9章 发布计划

第10章 迭代计划

讨论故事
分解任务：敏捷为人诟病的地方之一，是它没有像瀑布过程那样的前期设计步骤。这是事实，敏捷没有前期设计阶段，敏捷的特点就是做频繁的短期设计，一个故事的任务分解其实是即时设计中的一次短脉冲，而这些脉冲的集合取代了瀑布过程的前期设计阶段。

第11章 测量并监控速率

尚未全部完成的故事，不计算在速率中。
计算速率是用迭代开始前分配的故事点数。
计划速率和实际速率
迭代燃尽图：敏捷软件开发的一个优点就是项目开始时不需为项目需求写冗长完整的说明书。
迭代中的燃尽图（每日燃尽图）

第12章 用户故事不是什么

第13章 用户故事的优势

用户故事强调口头沟通
人人都可以理解用户故事
用户故事适合于迭代开发
用户故事鼓励延迟细节
用户故事支持随机应变的开发
用户故事鼓励参与性设计
用户故事传播隐性知识

第14章 用户故事不良征兆一览

1、故事太小
2、故事相互依赖
3、镀金：开发人员在迭代中实现了计划外的功能
4、细节太多
5、过早考虑用户界面细节

第15章 Scrum与用户故事

用户故事源于极限编程，不过也可以应用到另一种敏捷过程Scrum中。
Scrum是迭代和递增的
Scrum团队是自组织的。团队根据实际情况自主决定怎样完成剩余的任务。尽管在团队中某些人有特长，如测试人员和DBA，但团队同舟共济，如果需要完成测试任务但是没有空闲的测试人员，其他的开发人员也会参与测试。
Product Backlog
Sprint计划会
Sprint评审会
Daily Scrum：每个团队成员回答三个问题（昨天做了什么？今天打算做什么？有什么困难？）。目的是让每个人在自己以及同事面前做出承诺，不是向经理或者公司。