《用户故事与敏捷方法》读书笔记3

• 用户故事验收测试

在掌握了创建用户故事的方法和编写方式后，如何将用户故事转变为实际可以使用的功能，那么就可以通过用户验收测试来为用户故事丰富更多的细节，同时让程序员目的更清晰的编写代码。写测试要在写代码之前进行，为了让程序员尽早了解信息，测试应该在编写代码前制定。客户和开发人员讨论的许多细节可以通过验收测试记录下来，同时充实很多用户故事的细节。

测试的两步流程：

 

这些验收测试的流程用来确保故事可以被正确、完整的实现。

验收测试提供了确认故事是否被完整实现的基本标准。有了这样的标准可以避免花太多或者太少的时间精力。在每轮迭代结束时都应该执行验收测试，测试也分为项目需要的所有不同类型，故事测试主要是功能性测试，其他类型的测试也应该考虑：

• 用户交互测试，确保所有用户交互组件如期工作
• 可用性测试，确保程序好用
• 性能测试，测量应用程序在负荷下的工作情况
• 集成测试，测试模块间的接口，同时测试一些主要业务的功能

 

用户故事的实践应用

对用户故事有了大体的理解后，接下来我们来对用户故事进行实际应用，我们可以通过用户故事来对软件的开发项目进行估算和计划。

• 估算与计划

开发计划的创建和发布通常需要以下步骤>>

 

 

 

 

 

1. 确定迭代的长度

a. 估算用户故事

用户故事的大小和价值可以通过故事点（story point）来衡量，故事点是故事复杂度、工作量或工期的相对估算。团队可以定义一个故事点为一个理想日的工作，也可以将一个故事点定义为一个理想周的工作。

b. 上线/发布的时间

大部分的软件项目的开发周期为2-6个月，我们可以通过两个问题来启动发布计划。

• 想在什么时候发布？
• 故事的优先级是什么?

理想情况下，开发人员可以和客户谈一个日期范围，而不是具体的日期。为了计划一个发布，客户需要排列故事的优先级，把故事分为高、中、低这三类优先级类型是很有用的。

2. 排列用户故事的优先级

价值是衡量用户故事优先级最重要的标准，也就是故事对客户的重要性。DSDM（敏捷开发模型中的一种Dynamic Systems Development Method）中排列优先级的方法——MoSCow，必须有（Must have），应该有（Should have）可以有（Could have）、这次不会有（Won't have this time）。

 

 

 

 

 

必须有的功能指系统的基本功能，应该有的功能指重要，但短期内有替代解决方法的功能。可以有的功能指如果没时间就可以在发布中不予考虑的功能。列为“不会有的功能”指客户期望拥有，需要在后续发布中实现的功能。

我们还可以通过其他的维度来为故事排列优先级，可参考的要素如下：

-从故事点到预计工期

-根据成本安排优先级

-根据架构需要安排优先级

（混合优先级，在确定故事优先级时遇到问题，可能需要分割故事，对独立的故事排列不同的优先级）

3. 迭代计划

迭代计划会议的内容如下：

• 讨论故事
• 从故事中分解出任务
• 开发人员承担每个任务中的职责
• 讨论所有故事，并且接受所有任务后，开发人员单独估计他们承担的任务

迭代计划是发布计划的进一步计划，在迭代计划中，团队讨论故事，客户负责对迭代中包含的故事排列优先级，然后开发人员从故事中分解任务，估算及确认任务大小，并承担所有故事的任务。直到最后交付任务，提供他们创造出的最大商业价值。

a. 迭代的长度

开发团队和客户会共同选择适合项目的迭代长度，通常为1-4周。在项目开发期间，尽可能坚持固定的迭代长度，这有利于团队保持固定的节奏和开发速度。

假设项目有100个故事点，若估算的速率是每轮20个故事点，那么则预计需要5轮迭代。客户和开发团队协作选择20个优先级最高的故事点，把他们放入第一轮迭代。再将次高优先级的20个故事点放入第二轮迭代，如此直到分配完所有的故事。

b. 迭代的速率

在一轮迭代中所完成的故事点就是项目的速率。为项目做计划时，可以用已知的速率，也可以设想一个速率。速率是一个有效的管理工具，在每轮迭代结束和迭代中采取一定的方式监控和保证团队合理的速率很重要。

可以通过以下三种方法获得速率：

①使用历史值

②执行一轮初始迭代，并使用该轮迭代的速率

③猜测

使用历史速率是一个很好的选择，但只适用于在团队刚做过类似项目的情况下。当团队进行过几轮迭代后，对于项目开发的工期会获得更多经验，为每轮迭代计划和实际完成的故事点画图是检测实际和计划速率的好方法。