4 制定Sprint计划
计划是Scrum中重要的一环; 是为了让团队获得足够信息, 不受打扰地工作, 增加团队的信心;
Planning的成果: 1) Sprint目标 2) 团队成员名单(时间百分比, part time) 3) Sprint Backlog(US列表) 4) Demo日期 5) DailyMeeting时间地点
产品负责人必须参加
因为每个故事都有3个互相之间有着强烈依赖的变量: Scope-Estimate-Impantance
范围和重要性由产品负责人设置, 估算由团队设定,
在Planning上讨论理解使得这三者调整优化;
会议开始后PO需要概括一下这个sprint希望达到的目标; 团队按照优先级逐一讨论Story, 估算时间; 团队和PO的估算想法可能不一致, 讨论之后会有更多的问题, 根据情况需要调整Story的优先级, 修改范围, 并且重新估算, 直接的协作方式是Scrum的基础.
PO没时间参加的情况下
1) 和PO沟通, PO的直接参与事关项目成败; 2) 在Team中找到某人代替PO作为代表参加会议, 并且需要PO和代表沟通到位, 同意让代表参加会议, 行使权利改变Story的优先级和范围; 3) 说服管理团队分配新的PO; 4) 推迟Sprint启动日期, 直到PO有时间参会, 同时拒绝承诺任何交付, 团队自行安排每日任务;
不能在质量上让步
第四个变量-质量;
外部质量是系统用户可感知的, Ex. 运行缓慢, 让人混淆的UI;
内部质量一般指用户看不到的要素, 系统的可维护性, Ex. 系统设计一致性, 测试覆盖率, 代码可读性和重构, etc.
内部质量优秀, 外部质量仍旧可能很差, 但是内部质量差, 外部质量基本也不会好到哪里;
外部质量可看作Scope的部分, 出于业务考虑有时会先发布一个系统版本, UI比较简陋; 之后会发布一个干净版本, 外部质量的程度由PO权衡.
内部质量则是必须保证的, 影响到整个项目的发展, Defect的数量, 程序的扩展性以及架构的稳定性;
内部质量是不可以讨价还价的, 牺牲内部质量节省下来的时间, 在将来会付出代价, 代码中隐藏的问题越往后越难以恢复;
可以先减小Scope或者简化功能, 把高级功能作为新的Story来整合工作时间, 或者降低其他Story的优先级来集中处理优先级高的;
无休止的Sprint Plan
原则-Scrum中的一切事情都有时间盒;
需要尽量控制时间, planning拖太久时间会降低会议效率, 也损失Sprint时间;
Sprint计划会议日程
在sprint计划会议之前制定好时间表, 减少破坏时间盒的风险;
e.g. 日程不是强制的, Scrum master可以根据会议进程进行调整;
Sprint计划会议 13:00 - 17:00 (每小时有10分钟休息):
1300-1330 PO介绍sprint总体目标, 概括产品backlog, 确定demo的时间地点;
1330-1500 团队估算时间, 必要时拆分backlog条目, PO在需要时修改重要性; 理清每个US的含义, 重要性高的backlog要填写"如何演示"
1500-1600 团队选择US放入Sprint, 计算生产率, 用来检查工作安排的基础;
1600-1700 安排daily meeting地点; 将故事拆分成任务;
确定Sprint长度
短的Sprint = 短的反馈周期 = 更频繁的交付 = 更频繁的客户反馈 = 减少在错误的方向上可能花费的时间[这个事先应该确定个大概时间] = 学习个改进的更快;
长的Sprint: 团队有充分的准备时间, 解决问题的时间, 减少压力;
PO喜欢短Sprint, DEV反之, 因此Sprint的长度是妥协后的产物; 一般使用三周; 符合敏捷性和开发惯性, 容易让团队进入状态(flow);
刚开始的时候可以试验Sprint长度, 并且在实践中调整到合适的时间长度; 选择了感觉合适的Sprint长度之后需要坚持, 直到让每个成员都有相似的节奏;
确定Sprint目标
为什么进行这个Spint? 需要制定一个从业务角度可理解的目标; e.g. 完成优先级最高的三个任务; 优化系统, 发布btea版本给用户; 添加后台系统支持...
如果有多个Scrum团队, 可以在wiki页面(或其他共享点)上列出所有团队的Sprint目标, 保证所有人知道工作的目的;
决定Sprint要包含的故事
Sprint会议要决定哪些故事需要在这个Sprint完成, 将这些US从Product backlog拷贝到Sprint backlog中;
Product backlog中的故事是按照重要性排序的; 应该按照团队的估算生产率(团队能在一个Sprint内完成的US点数)来选择优先级高的US;
Sprint backlog是Product backlog中部分US的一个映射, 表示团队在这个Sprint中承诺要完成的UserStory.
Note Sprint要包含多少US由团队决定, 不是PO或其他某个人;
PO如何对sprint放那些故事产生影响
如果PO希望故事D放到sprint里面
1) 可以重新设置优先级, 赋予故事D最高的级别, 团队就不得不将D放入sprint, 将C移出;
2) 或者, 更改范围, 缩小故事A的范围, 直到团队确信故事D能在这个sprint中完成; [缩小范围后需要新建US来跟踪被缩减的功能]
3) 最后, 还可以拆分故事; PO判断故事A中某些方面实际不重要, 将A分成A1和A2, 给予不同的优先级;
虽然PO在正常情况下[sprint进度, 客户要求, 上级压力...]不能控制团队的估算生产率, 他仍然有很多方式对sprint选择那些US施加影响;
团队怎样决定把哪些US放到sprint里面
用本能反应估算
如果sprint时间不长, 小团队可以根据直觉进行估算 (提问, 讨论, 统一范围)
用生产率计算来估算
1) 得出估算生产率;
2) 计算在不超出估算生产率的情况下可以加入多少US;
生产率是"已完成工作总量"的一个衡量方式;
Note 这里的实际生产率是建立在每个US的原始估算基础上, 在sprint过程中对US时间进行的修改都被忽略了;
这个数字并不精确, 但是有了它就可以有一个参照系数;
查看团队的历史, 根据过去几个sprint的生产率, 假定下一个sprint有差不多的生产率;
这项技术也被叫做昨日天气yesterday's weather; 使用该技术必须满足两个条件: 团队已经完成了几个sprint(得到统计数据), 团队以几乎完全相同的方式(团队人数,
sprint长度, 工作状态不变)进行下一个sprint;
复杂一点, 可以进行简单的资源计算: 假设一个4人团队3周的sprint(15workday), Lisa休假2天, Dave只有50%的时间, 把这些计算到一起...[可以使用excel模板统计数据]...这个sprint一共有X个人/天;
估算的单位是故事点, 差不多是理想化的人/天, 理想化的人/天高效, 不受打扰的一天, 但我们必须考虑各种因素, e.g. 把未计划到的工作添加到sprint,
生病请假等;
投入程度focus factor的概念:
投入程度用来估算团队在sprint中投入的百分比, 投入程度低就表明团队收到的干扰大, 估算的太理想化; e.g. 50 man-days * 50% = 25
得到合理的投入程度的方法是查看之前的sprint的值(取平均值), e.g. factor = 18 US points/36 man-days = 50%
把上一个sprint中完成的所有US的原始估算相加, 得到的就是实际生产率; [FocusFactor和Velocity(70%)]
昨日天气使用很方便, 但是要考虑到一些常识, 如果上一个sprint很糟糕的原因是大部分成员都生病, 那你可以假设这次运气不会那么坏, 给这个sprint提高一点投入程度; 如果团队最近安装了新的快速的持续集成系统[CI], 也可以提高; 如果有新成员加入, 需要把培训占用的精力计算进来, 反而可能降低投入程度...
如果是个全新的团队, 没有数据, 可以参考在类似条件下工作的团队的投入程度;
如果没有其他可参考, 需要猜测一个投入程度百分比, 在第一个sprint使用, 之后按照历史数据进行分析, 对投入程度和估算生产率作出改进;
新团队中默认投入程度通常是70%;
使用哪种估算技术
直觉反应, 昨日天气, 基于可用人-天估算和估算投入程度的生产率; 这些都可以结合使用, 讨论以及调整;
最后得出哪些US要放入sprint, 才是目标, 投入程度, 资源可用性和估算生产率只是用来达成目标的手段;