阅读笔记05

阅读笔记05--用户故事与敏捷方法

第6章：用户故事验收测试 

验收测试可以用来记录客户和开发人员讨论的很多细节。验收测试记录了有关故事的一些假设，这些假设可能还没有和开发人员讨论过。验收测试提供了检查故事是否被完整实现的基本标准。验收测试应由客户来写而不是开发人员。验收测试应在程序员写代码之前就写好。如果新的测试对阐明故事的细节或意图没有任何帮助，就不用再写。FIT 和 FitNesse 是写验收测试的优秀工具，它们用的是我们熟悉的表格或电子表格格式。

 

第7章：优秀用户故事准则

为了确定故事，从每个用户角色使用系统的目标开始考虑。分割故事时，试着将它分割成货穿应用程序所有层面的故事。试着让故事的大小能够在使用后让用户感到可以去喝杯咖啡休息一下。如果有项目领域和环境的需要，可以用其他需求搜集或文档技术来补充故事。为单个用户编写故事。不要写“求职者可以删除简历”，而要写“求职者可以删除她自己的简历”。让客户，而不是开发人员，编写故事。

 

第8章：估算用户故事

用故事点估算故事，故事点是故事复杂度、工作量或工期的相对估算。应由团队估算故事，估算属于团队而不是个人。通过和其他估算进行比较来进行三角测量。团队是否使用结对编程对故事点估算没有影响。结对编程影响的是团队的速率，不是他们的估算。

 

第9章：发布计划

在计划发布时，有必要知道客户预期的大致发布日期和故事的相对优先级。故事应该以明确的顺序排列(第一个、第二个、第三个，等等)，而不是利用诸如“非常高、高、中等”模糊顺序的分组。发布计划故事的优先级由客户确定，但也要考虑开发人员的想法。使用速率将以理想日为单位的估算转换成日历日。估算团队的初始速率是很有必要的。

 

第10章：迭代计划

迭代计划是发布计划的进一步计划，但只在迭代即将开始时才开始做迭代计划。迭代计划中，团队讨论每个故事，然后从故事中分解出任务。任务的大小没有强制的范围(例如，3到5小时)。相反，从故事中分解出任关用来帮助估算或鼓励多个开发人员合作完成一个故事。每个任务都有开发人员承担。开发人员通过估算他们承担的任务，评估他们是否承诺过度。

 

第11章：测量并监控速率

计算速率时只考忠那些已完成的故事，即通过验收测试的故事。不要计算迭代中团队未全部完成的故事。为每轮迭代计划和实际完成的故事点数画图是监测实际和计划速率区别的好方法。不要在一两轮迭代后就忙着预测速率趋势。完成一个任务或故事所花费的实际小时数对速率没有影响。在大家都能看到的公共区域贴一些大而可见的图。