菜鸟Scrum敏捷实践系列（二）用户故事验收

 

菜鸟Scrum敏捷实践系列索引　　

菜鸟Scrum敏捷实践系列（一）用户故事概念

菜鸟Scrum敏捷实践系列（二）用户故事验收

菜鸟Scrum敏捷实践系列（三）用户故事的组织---功能架构的规划

 

一、用户故事的状态：

　　用户故事推荐定义五种状态，分别是“构思”、“已批准”、“开发中”、“已完成”、“已验收”。

只有符合项目组规定的验收标准，才能置为“已验收”状态。

 

　　二、用户故事验收标准 

　　由团队决定验收标准。 该标准可包括：

　　　　•已完成所有任务（开发、测试和记录）

　　　　•正在运行和通过所有验收测试

　　　　•无开放缺陷

　　　　•产品负责人已验收

　　　　•可交付予用户

　　在每次迭代期间按此标准完成所有故事。

用户故事验收标准的录入：

 

     三、编写用户故事六原则-INVEST 

 

　　一个好的用户故事应该遵循INVEST原则

　　独立性（Independent）

　　要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

　　可协商性（Negotiable）

　　一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

　　有价值（Valuable）

　　每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

　　可以估算性（Estimable）

　　开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

　　短小（Small）

　　一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

　　可测试性（Testable）

　　一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

转载于:https://www.cnblogs.com/effapp/p/4689603.html