Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Site: http://sempsalon.wikispaces.com/
Email: semp.salon@gmail.com




         敏捷之用户故事演练(一)

          滕振宇 (Daniel Teng),...
滕振宇
李丁山




 爱好旅游,摄影,音乐,太极,
 运动
本次活动安排
• 软件开发的困境与挑战
• 敏捷框架Scrum的简单介绍
• 用户故事
软件开发的困境
成功的项目?




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

   Agreement
     Far from
      Requirements                               Anarchy




                          ...
可预见的范围



也称为“不确定锥形”

                    计划的准确性




             time
为什么软件开发如此困难




     事物总在变化

…而且,我们对未来给出越多的预测,我们就
     会面对越多的不确定性…
为什么软件开发如此困难
像航海者不能看见超出水平视线以外的东西
(除非非常的大),我们无法了解和计划将
来所有的事情
为什么软件开发如此困难
     并且,在没有任何绝对
     确定性的条件下,我们
     没法事先知道一件事情
     可能有多困难,或需要
     多长时间
敏捷框架SCRUM
Scrum框架
团队角色
团队角色
• 产品所有者 (Product Owner)
• 开发团队 (Team)
• ScrumMaster
敏捷的计划
Just In Time - 适时的详细计划




每日   Sprint     发布      路线图   愿景


详细            计划的详细程度         粗略
五层的敏捷计划
用户故事
什么是用户故事
• Card – 卡片
  – 一般来说用户故事是写在记事卡片上
  – 卡片上可能包括了一些说明和估算的信息
• Conversation – 对话
  – 有关的具体信息是通过和产品拥有者的交谈沟
    通得出的
• Co...
用户故事的目的
•   用户的需要
•   对产品的描述
•   计划的对象
•   对话与沟通的基点
•   延迟对话的机制
不同人员之间的沟通边界




         Jeff Patton
用户故事的格式

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

                  作为 一个购书者,我
                  能够看到其他购书者
                  的评价...
具体信息在哪里?
• 作为一个购书者,我可以取消我的订单
 – 如果已经发货,是否可以取消
 – 全部退款还是部分退款?
  • 退到信用卡还是留在支付宝
  • 如果已发货,是否要承担运费
 – 是否需要跟会员确认?
  • 怎样确认?
 –...
具体信息
• 作为验收的条件
 – 确保贵宾会员可以全额退款
 – 确保一般会员收取5%的违约费
 – 确保一般会员在发货后不能取消订单
 – 确保如果已经发货,收取相应的运费
 – 确保发出确认邮件
 – 确保书店店主得到通知
具体信息 (二)
• 分解为更小的故事
 – 作为一个贵宾会员,我可以在发货后取消订单
 – 作为一般会员,我可以在货未发出前取消订单
 – 作为一个书店店主,我会受到邮件确认取消
用户故事的类型
• 史诗   作为一个购书者,我可以在线购买图书


       • 银行卡支付
• 主题   • 支付宝支付
       • 货到付款
       • 邮政转账
• 故事   作为一个购书者,我可以使用我的VISA卡在线...
用户故事的类型
    用户故事 – Sprint    高

    主题故事 – 发布

                          价值

                    优先级   成本
史诗故事 – 里程碑      ...
Just In Time – 适时的需求分析

 史诗       史诗   史诗         史诗
                     Product Vision




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

...
分解用户故事
•   根据所处理的不同数据
•   根据操作类型
•   根据功能的独立性进一步划分
•   根据功能性需求和非功能性需求
•   根据更加细化的需求优先级
根据处理数据的不同分解
•   按照书名查询
•   按照作者查询
•   按照关键字查询
•   按照类别查询
根据操作类型分解
• 作为卖家,我可以添加新的图书
• 作为卖家,我可以编辑图书
• 作为卖家,我可以删除图书
根据功能独立性分解

编辑图书信息

检查用户权限   检查用户权限

 记录日志     记录日志
根据功能性与非功能性分解

在线查询并购买图书

30秒内可以返回查询      30秒内可以返回查询
    结果              结果
支持100,000个在线用   支持100,000个在线用
       户         ...
根据优先级分解
•   作为用户,我希望能够用我的用户名和密码登录系统,以使我可以开始使用
    系统

o 如果用输入正确的用户名和密码,则能够正常登录系统;
o 如果用户连续三次输入错误的用户名或者密码,则该用户的账号将被锁住;
o 如果...
INVEST

       独立的




              可以商议的
                       有价值

                  小的




可估算的
                     ...
为什么是用户故事
•   将关注点从文字转到口头交流
•   文字不够准确
•   更容易理解
•   支持迭代开发
•   计划刚刚好
•   支持所有人一起设计
•   关注目的而不是实现
用户故事与用例
• 范围
• 完整性的级别
• 生命期
• Use cases 更加可能包含有关用户界面的详
  细信息
• 目的
    – Use case的目的是在用户与开发团队之间形成文档化的协议
    – 用户故事的目的是帮助发布和...
用户故事与IEEE-830需求明细
• 十分关注细节,容易出错,费时
    – 难读
•   很难排优先级
•   很难了解全部
•   可行性不高
•   先写需求
讨论


     问题
收获        建议
     行动
谢谢
Upcoming SlideShare
Loading in …5
×

Semp活动 敏捷之用户故事研讨会(一)

4,134 views

Published on

上海SEMP沙龙系列活动资料,关于敏捷用户故事的介绍

Published in: Technology, Business

Semp活动 敏捷之用户故事研讨会(一)

  1. 1. Site: http://sempsalon.wikispaces.com/ Email: semp.salon@gmail.com 敏捷之用户故事演练(一) 滕振宇 (Daniel Teng),李丁山 (Mike Li)
  2. 2. 滕振宇
  3. 3. 李丁山 爱好旅游,摄影,音乐,太极, 运动
  4. 4. 本次活动安排 • 软件开发的困境与挑战 • 敏捷框架Scrum的简单介绍 • 用户故事
  5. 5. 软件开发的困境
  6. 6. 成功的项目? 美国国防部的项目审查显示,早期使用瀑布模式开发的软件项目, 有75%以失败告终,有些开发出来的产品根本没有被使用过,只有 2%的软件产品无需大量 修改就能被正常使用。
  7. 7. 开发过程中面临的挑战
  8. 8. 系统的复杂度 Agreement Far from Requirements Anarchy Complex Complicated Agreement Close to Simple Complicated Close to Far from Certainty Technology Certainty Graph taken from Ralph Stacey’s “Complexity and Creativity in Organizations”
  9. 9. 可预见的范围 也称为“不确定锥形” 计划的准确性 time
  10. 10. 为什么软件开发如此困难 事物总在变化 …而且,我们对未来给出越多的预测,我们就 会面对越多的不确定性…
  11. 11. 为什么软件开发如此困难 像航海者不能看见超出水平视线以外的东西 (除非非常的大),我们无法了解和计划将 来所有的事情
  12. 12. 为什么软件开发如此困难 并且,在没有任何绝对 确定性的条件下,我们 没法事先知道一件事情 可能有多困难,或需要 多长时间
  13. 13. 敏捷框架SCRUM
  14. 14. Scrum框架
  15. 15. 团队角色
  16. 16. 团队角色 • 产品所有者 (Product Owner) • 开发团队 (Team) • ScrumMaster
  17. 17. 敏捷的计划
  18. 18. Just In Time - 适时的详细计划 每日 Sprint 发布 路线图 愿景 详细 计划的详细程度 粗略
  19. 19. 五层的敏捷计划
  20. 20. 用户故事
  21. 21. 什么是用户故事 • Card – 卡片 – 一般来说用户故事是写在记事卡片上 – 卡片上可能包括了一些说明和估算的信息 • Conversation – 对话 – 有关的具体信息是通过和产品拥有者的交谈沟 通得出的 • Confirmation – 验证 – 用验收测试来确认实现的正确性
  22. 22. 用户故事的目的 • 用户的需要 • 对产品的描述 • 计划的对象 • 对话与沟通的基点 • 延迟对话的机制
  23. 23. 不同人员之间的沟通边界 Jeff Patton
  24. 24. 用户故事的格式 作为{ 谁 }, 我希望{做什 么 }, 以 { 达到什么目 的} 作为 一个购书者,我 能够看到其他购书者 的评价,以帮助我决 定是否购买,
  25. 25. 具体信息在哪里? • 作为一个购书者,我可以取消我的订单 – 如果已经发货,是否可以取消 – 全部退款还是部分退款? • 退到信用卡还是留在支付宝 • 如果已发货,是否要承担运费 – 是否需要跟会员确认? • 怎样确认? – 不同的会员,是否有不同的标准,比如VIP
  26. 26. 具体信息 • 作为验收的条件 – 确保贵宾会员可以全额退款 – 确保一般会员收取5%的违约费 – 确保一般会员在发货后不能取消订单 – 确保如果已经发货,收取相应的运费 – 确保发出确认邮件 – 确保书店店主得到通知
  27. 27. 具体信息 (二) • 分解为更小的故事 – 作为一个贵宾会员,我可以在发货后取消订单 – 作为一般会员,我可以在货未发出前取消订单 – 作为一个书店店主,我会受到邮件确认取消
  28. 28. 用户故事的类型 • 史诗 作为一个购书者,我可以在线购买图书 • 银行卡支付 • 主题 • 支付宝支付 • 货到付款 • 邮政转账 • 故事 作为一个购书者,我可以使用我的VISA卡在线 支付所购买的图书
  29. 29. 用户故事的类型 用户故事 – Sprint 高 主题故事 – 发布 价值 优先级 成本 史诗故事 – 里程碑 风险 知识 低
  30. 30. Just In Time – 适时的需求分析 史诗 史诗 史诗 史诗 Product Vision 详细的用户故事 详细的用户故事 详细的用户故事 用户故事(多数情况下是史诗)会以迭代的方式逐步被细化成更 多更小粒度的用户故事,包含更多的细节的信息,但只在需要的 时候
  31. 31. 分解用户故事 • 根据所处理的不同数据 • 根据操作类型 • 根据功能的独立性进一步划分 • 根据功能性需求和非功能性需求 • 根据更加细化的需求优先级
  32. 32. 根据处理数据的不同分解 • 按照书名查询 • 按照作者查询 • 按照关键字查询 • 按照类别查询
  33. 33. 根据操作类型分解 • 作为卖家,我可以添加新的图书 • 作为卖家,我可以编辑图书 • 作为卖家,我可以删除图书
  34. 34. 根据功能独立性分解 编辑图书信息 检查用户权限 检查用户权限 记录日志 记录日志
  35. 35. 根据功能性与非功能性分解 在线查询并购买图书 30秒内可以返回查询 30秒内可以返回查询 结果 结果 支持100,000个在线用 支持100,000个在线用 户 户
  36. 36. 根据优先级分解 • 作为用户,我希望能够用我的用户名和密码登录系统,以使我可以开始使用 系统 o 如果用输入正确的用户名和密码,则能够正常登录系统; o 如果用户连续三次输入错误的用户名或者密码,则该用户的账号将被锁住; o 如果用户的登录请求被拒绝,则一条通知信息需要发给该用户,告知有人尝 试以他/她的信息登录系统
  37. 37. INVEST 独立的 可以商议的 有价值 小的 可估算的 可测试
  38. 38. 为什么是用户故事 • 将关注点从文字转到口头交流 • 文字不够准确 • 更容易理解 • 支持迭代开发 • 计划刚刚好 • 支持所有人一起设计 • 关注目的而不是实现
  39. 39. 用户故事与用例 • 范围 • 完整性的级别 • 生命期 • Use cases 更加可能包含有关用户界面的详 细信息 • 目的 – Use case的目的是在用户与开发团队之间形成文档化的协议 – 用户故事的目的是帮助发布和迭代计划的制定,是作为占位 符,为有关详细用户需求的对话服务的
  40. 40. 用户故事与IEEE-830需求明细 • 十分关注细节,容易出错,费时 – 难读 • 很难排优先级 • 很难了解全部 • 可行性不高 • 先写需求
  41. 41. 讨论 问题 收获 建议 行动
  42. 42. 谢谢

×