Site: http://sempsalon.wikispaces.com/Email: semp.salon@gmail.com

敏捷之用户故事演练（一）

滕振宇 (Daniel Teng)，李丁山 (Mike Li)

滕振宇

李丁山

爱好旅游，摄影，音乐，太极，运动

本次活动安排

• 软件开发的困境与挑战

• 敏捷框架Scrum的简单介绍

• 用户故事

软件开发的困境

成功的项目？

美国国防部的项目审查显示，早期使用瀑布模式开发的软件项目，有75%以失败告终，有些开发出来的产品根本没有被使用过，只有2%的软件产品无需大量修改就能被正常使用。

开发过程中面临的挑战

系统的复杂度

Technology

Anarchy

Simple

Complex

Far from Certainty

Close to Certainty

Req

uire

men

tsFa

r fro

m

Agr

eem

ent

Clo

se to

A

gree

men

t

Complicated

Complicated

Technology

Anarchy

Simple

Complex

Far from Certainty

Close to Certainty

Req

uire

men

tsFa

r fro

m

Agr

eem

ent

Clo

se to

A

gree

men

t

Complicated

Complicated

Graph taken from Ralph Stacey’s “Complexity and Creativity in Organizations”

可预见的范围

也称为“不确定锥形”

time

计划的准确性

为什么软件开发如此困难

…而且，我们对未来给出越多的预测，我们就会面对越多的不确定性…

事物总在变化

为什么软件开发如此困难

像航海者不能看见超出水平视线以外的东西（除非非常的大），我们无法了解和计划将来所有的事情

并且，在没有任何绝对确定性的条件下，我们没法事先知道一件事情可能有多困难，或需要多长时间

为什么软件开发如此困难

敏捷框架SCRUM

Scrum框架

团队角色

团队角色

• 产品所有者 (Product Owner)• 开发团队 (Team)• ScrumMaster

敏捷的计划

Just In Time - 适时的详细计划

计划的详细程度详细 粗略

每日 Sprint 发布 路线图 愿景

五层的敏捷计划

用户故事

什么是用户故事

• Card – 卡片– 一般来说用户故事是写在记事卡片上

– 卡片上可能包括了一些说明和估算的信息

• Conversation – 对话– 有关的具体信息是通过和产品拥有者的交谈沟通得出的

• Confirmation – 验证– 用验收测试来确认实现的正确性

用户故事的目的

• 用户的需要

• 对产品的描述

• 计划的对象

• 对话与沟通的基点

• 延迟对话的机制

不同人员之间的沟通边界

Jeff Patton

用户故事的格式

作为{ 谁 }, 我希望{做什么 }, 以 { 达到什么目的 }

作为一个购书者，我

能够看到其他购书者的评价，以帮助我决定是否购买，

具体信息在哪里？

• 作为一个购书者，我可以取消我的订单

– 如果已经发货，是否可以取消

– 全部退款还是部分退款？

• 退到信用卡还是留在支付宝

• 如果已发货，是否要承担运费

– 是否需要跟会员确认？

• 怎样确认？

– 不同的会员，是否有不同的标准，比如VIP

具体信息

• 作为验收的条件

– 确保贵宾会员可以全额退款

– 确保一般会员收取5%的违约费

– 确保一般会员在发货后不能取消订单

– 确保如果已经发货，收取相应的运费

– 确保发出确认邮件

– 确保书店店主得到通知

具体信息（二）

• 分解为更小的故事

– 作为一个贵宾会员，我可以在发货后取消订单

– 作为一般会员，我可以在货未发出前取消订单

– 作为一个书店店主，我会受到邮件确认取消

用户故事的类型

• 史诗

• 主题

• 故事 作为一个购书者，我可以使用我的VISA卡在线支付所购买的图书

作为一个购书者，我可以在线购买图书

• 银行卡支付• 支付宝支付• 货到付款• 邮政转账

用户故事的类型

用户故事 – Sprint

主题故事 – 发布

优先级

高

低

史诗故事 – 里程碑

价值

成本

风险

知识

Just In Time – 适时的需求分析

Product Vision

史诗 史诗 史诗 史诗

用户故事（多数情况下是史诗）会以迭代的方式逐步被细化成更多更小粒度的用户故事，包含更多的细节的信息，但只在需要的时候

详细的用户故事 详细的用户故事 详细的用户故事

分解用户故事

• 根据所处理的不同数据

• 根据操作类型

• 根据功能的独立性进一步划分

• 根据功能性需求和非功能性需求

• 根据更加细化的需求优先级

根据处理数据的不同分解

• 按照书名查询

• 按照作者查询

• 按照关键字查询

• 按照类别查询

根据操作类型分解

• 作为卖家，我可以添加新的图书

• 作为卖家，我可以编辑图书

• 作为卖家，我可以删除图书

根据功能独立性分解

编辑图书信息

检查用户权限

记录日志

检查用户权限

记录日志

根据功能性与非功能性分解

在线查询并购买图书

30秒内可以返回查询结果

支持100,000个在线用户

30秒内可以返回查询结果

支持100,000个在线用户

根据优先级分解

• 作为用户，我希望能够用我的用户名和密码登录系统，以使我可以开始使用系统

o 如果用输入正确的用户名和密码，则能够正常登录系统;o 如果用户连续三次输入错误的用户名或者密码，则该用户的账号将被锁住;o 如果用户的登录请求被拒绝，则一条通知信息需要发给该用户，告知有人尝

试以他/她的信息登录系统

INVEST

有价值

可测试

小的

可估算的

独立的

可以商议的

为什么是用户故事

• 将关注点从文字转到口头交流

• 文字不够准确

• 更容易理解

• 支持迭代开发

• 计划刚刚好

• 支持所有人一起设计

• 关注目的而不是实现

用户故事与用例

• 范围

• 完整性的级别

• 生命期

• Use cases 更加可能包含有关用户界面的详细信息

• 目的– Use case的目的是在用户与开发团队之间形成文档化的协议

– 用户故事的目的是帮助发布和迭代计划的制定，是作为占位符，为有关详细用户需求的对话服务的

用户故事与IEEE-830需求明细

• 十分关注细节，容易出错，费时

– 难读

• 很难排优先级

• 很难了解全部

• 可行性不高

• 先写需求

讨论

收获问题

建议

行动

谢 谢