硝烟中的Scrum和XP-我们如何实施Scrum 4 (Part 1/2)

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, 才是目标, 投入程度, 资源可用性和估算生产率只是用来达成目标的手段;