Download to read offline
Uploaded byMike Li
Semp活动 敏捷之用户故事研讨会（二）
文档介绍了敏捷开发中的用户故事演练，包括用户故事的定义、格式及类型，以及敏捷估算的方法和工具，如扑克牌估算和燃尽图。主要内容涵盖了团队如何通过对话和沟通来确认用户需求、估算工作量，并在迭代过程中进行有效计划。活动中还提及了发布计划的重要性和示例。
Semp活动 敏捷之用户故事研讨会（二）
- 1. Site: http://sempsalon.wikispaces.com/ Email: semp.salon@gmail.com 敏捷之用户故事演练（二） 滕振宇 (Daniel Teng)，李丁山 (Mike Li)
- 2.
- 3.
- 4.
- 5. 本次活动安排 • 基本概念回顾 –用户故事 – 敏捷计划 – 敏捷的估算 – 扑克游戏 – 燃尽图 • 有关发布计划的练习 • Scrum开发过程模拟演练 • 问题讨论
- 6.
- 7. 用户故事 • 3Cs – Card – 卡片 • 一般来说用户故事是写在记事卡片上 • 卡片上可能包括了一些说明和估算的信息 – Conversation – 对话 • 有关的具体信息是通过和产品拥有者的交谈沟通得 出的 – Confirmation – 验证 • 用验收测试来确认实现的正确性
- 8. INVEST的用户故事 独立的 可以商议的 有价值 小的 可估算的 可测试
- 9. 用户故事的目的 • 用户的需要 • 对产品的描述 •计划的对象 • 对话与沟通的基点 与边界 • 延迟对话的机制
- 10. 用户故事的格式 作为{ 谁 },我希望{做什 么 }, 以 { 达到什么目 的} 作为 一个购书者，我 能够看到其他购书者 的评价，以帮助我决 定是否购买，
- 11. 用户故事的类型 • 史诗 作为一个购书者，我可以在线购买图书 • 银行卡支付 • 主题 • 支付宝支付 • 货到付款 • 邮政转账 • 故事 作为一个购书者，我可以使用我的VISA卡在线 支付所购买的图书
- 12.
- 13. Just in Time- 适时的详细计划 每日 Sprint 发布 路线图 愿景 详细 计划的详细程度 粗略
- 14. 关注最重要的需求 用户故事 – Sprint 高 主题故事 – 发布 价值 优先级 成本 史诗故事 – 里程碑 风险 知识 低
- 15.
- 16. 估计规模，确定时间 在敏捷计划与估计中我们估计规模， 然后推算时间 ? 用户故事列表 用故事点估计 推算时间（计划）
- 17. 速度 - Velocity •代表团队在一次迭代中所能完成的故事点数 • 可用于估计完成剩余功能需要的时间，从而 预测可能的发布时间
- 18. 10 分钟 相对大小 —— 国家
- 19. 敏捷估算是相对估算 • 允许交付条件的不同 –比如谁来完成工作等 • 允许自修正的开发速度 – 比如对工具用熟练时速度变快，但故事的规模 应该是不变的 • 更容易在团队中达成共识 • 不同人的估算结果可以累加
- 20. 敏捷估算的单位 - 故事点(StoryPoint) 1. 强制使用相对的估算 2. 关注规模的估算而不是时间长度 3. 估算的结果可以汇总叠加 – 基于时间的估算是不能简单叠加的 4. 团队的单位 5. 与迭代单位不同
- 21. 扑克游戏 1. 产品解释用户故事 2. 团队一起讨论实现该故事需要做哪些工作 3.所有人分别估计 4. 所有人同时展示估计值 5. 给出最大最小值的个人分别作出解释 6. 直到整个团队对估计值达成协议
- 22.
- 23. 估计总是一个区间 Sprint 1 14 最后一次的速度 12 Sprint 2 13 平均速度 15 Sprint 3 20 Sprint 4 12 最差三次的平均速度 13 如果剩余功能的总规模为200 故事点，则还需要 多少Sprint可以完成？ 按最慢的平均速度 15 按最后一次的速度 17 按平均速度 14
- 24. Sprint计划 • Product Owner按照优先级从ProductBacklog 中取出用户故事作出解释 • 团队跟Product Owner澄清不确定之处 • 团队讨论可能需要的工作 – 考虑Done • 团队划分任务 • 估计任务 – 以时间为单位
- 25. Sprint Backlog Tasks Sprint Backlog Mon Tues Wed Thur Fri 用户界面编码 8 4 8 中间层编码 16 12 10 7 中间层测试 8 16 16 11 8 编写在线帮助 12 50 Points or Hours 40 30 20 10 0 Thanks to Mountain Goat Software, LLC Mon Tue Wed Thu Fri
- 26. 燃尽图 - Burndown •跟踪剩余的工作量 • 每日更新
- 27.
- 28.
- 29.
- 30. 发布计划 • 通常是关注2～3个月的发布目标 • 在一次发布开始时召开发布计划会议 •可以绘制发布燃尽图跟踪进度
- 31.
- 32.
- 33. 讨论 问题 收获 建议 行动
- 34.