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