用户故事与敏捷开发方法，用户故事和敏捷方法 pdf

敏捷开发-用户故事地图

这些便签组成了一级用户故事，Jeff Patton称为用户任务（user tasks），它们组成了用户故事地图上的 “行走的骨骼” （the walking skeleton） 部分。

分类用户故事：将用户故事按照主题或相关性进行分类。 组织用户故事：将分类后的用户故事按照时间顺序或优先级进行排序，并将它们放入一个用户故事地图中。

可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。

用户故事源于敏捷开发，但其基本理论与上述方法相同，即剖析用户使用产品的所有活动轨迹和任务完成轨迹。用户故事地图的关键作用在于助力团队协作，即确保团队成员从产品开发到新版本迭代的整个过程中都处于同一平面上。

我们通过这种一目了然、格式一致的故事地图，让项目组所有人都获得足够的信息，让项目有一个明朗的开发流程，如图5-20所示。用户故事地图作为一种有效的需求工具，可以做到多角色、多视角。

相关问答

Q1: 用户故事与敏捷方法之三---什么时候使用用户故事?

比如：一个业务价值高的故事估算出来要4周完成，1个或者多个业务价值中等的用户故事只需要1天就可以完成。客户团队可能会将业务价值中等的这个故事排出更高的优先级，先做。

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

用户故事应该小到能够在一次迭代中完成。可测试的用户故事能够避免造成结构不良、过于复杂或是依赖于其他故事等问题，导致迭代失败。 为了保证无法离开迭代（通过测试）的故事不进入迭代，可以采用“先写测试”的方式。

Q2: 如何使用敏捷方法进行产品规划?

1、敏捷最佳的估算方法就是打计划扑克(Grenning2002)，计划扑克把专家意见、类比和分解结合到一种令人愉快的估算方法中，可以产生快速而可靠的估算。估算的目的在于合理性，而不是准确性。

2、敏捷估计与规划的一个关键原则是先估计出规模然后推算出持续时间。 速度修正估计误差 随着开发小组在项目的用户故事上取得进展，他们的速度在最初几次迭代中就会显示出来。

3、建立产品愿景的技巧，除了上面所示范的简单模版之外还有如下方法：用户角色模型、狩野模型（卡诺模型）、产品路线图、设计思维（Design Thinking）等等。在建立了初始的愿景之后，团队会使用愿景做为统一的目标。

4、在敏捷项目实施过程中，产品人员会不断的提出各种版本需求。统一采用工具对这些需求进行管理。且包含详细的交互设计和验收标准。不仅可以减少后期开发人员的沟通成本，也可以减少需求维护的成本。

Q3: 谈谈敏捷中的用户故事

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

2、通过SM、PO、客户团队达成一致，本次发布计划预计包括用户故事： A、B、C、D、E A用户故事的估算是一个理想周(5天)，团队总共7人。总共任务点数=5天*7人=35点。 B用户故事的估算是两个理想周(10天)，团队总共7人。

3、黄色的便签的第一行包含了最小化的用户故事，如：写邮件只包括发件人，收件人，标题，内容和发送取消按钮。其他如支持RTF，HTML格式，添加附件，从通讯部获取联系人邮件地址等，都不在此行，放入更靠下的便签中。

4、使用故事的过程 过去是瀑布，强调文档编写完再设计，所有细节设计完成后进入开发，开发完成后进入测试。

用户故事与敏捷开发方法的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于用户故事和敏捷方法 pdf、用户故事与敏捷开发方法的信息别忘了在本站进行查找喔。