硝烟中的Scrum和XP-我们如何实施Scrum 4)制定spring计划 (Part 2/2)

为何使用索引卡

大多数sprint计划会议上, 都会讨论产品backlog中的US细节, 对US进行估算, 更新优先级, 确认细节, 拆分等等;

如果把Excel或JIRA, Rally上的backlog投影, 由PO或ScumMaster讲解, 让团队和PO讨论同时在电脑上修改, 团队有时会失去集中力, 投影也不容易看清细节;

要有更好的效果[参与度和实体卡片能提高集中力], 可以创建一些索引卡[便签纸], 贴在墙上或放在桌上;

这样的体验比计算机和投影仪更好:

1) 大家参与了索引卡的修改排放, 既能保持长时间会议中的清醒, 也可以更集中注意在会议的进展上;

2) 更多的参与感, 是投影的方式做不到的;

3) 多个故事可以同时由多个人编辑;

4) 重新划分优先级更快, 移动索引卡比修改文档快得多;

5) 会议结束后, 索引卡可以直接贴在任务板上[white board];

可以手写索引卡, 或者使用脚本从产品backlog中生成可打印的索引卡;

refer to http://blog.crisp.se/author/henrikkniberg

Note Spring会议结束后, Scrum Master会手工更新Excel中的产品backlog, 反应US索引卡中发生的变化;

这样给管理者增加了一些麻烦, 但是使用了实体索引卡可以提高sprint计划会议的效率, 这样还是值得的;

重要性 Importance字段, 打印时和产品backlog所记录的重要性是一致的; 将它放到卡片上可以帮助排序(最重要的放在左边, 或者上边) 当卡片被放到墙上, 可以暂时忽略它的重要性评分, 根据他们摆放的相对位置, 来确定彼此间的重要性; 在会议结束后按照planning meeting的结果更新backlog就可以;

把US拆分成Task后, 时间估计就相对容易, 也会更准确;

可以把团队分成不同的二人组, 让每一组同时拆分各自的US; 使用索引卡[便签纸/即时贴]更方便, 直观;

Note 我们不会吧任务拆分的内容放在产品backlog中;

1) 任务拆分的随机性比较强, 在sprint中常常会发生变化和调整, 保持产品backlog的同步会花费很大精力;

2) PO不需要关心实现层面的细节;

任务拆分时的即时贴可以和故事索引卡一起, 在sprint backlog中直接重用;

定义"完成" [Definition Of Done]

PO和团队需要对Done有一致的定义; e.g. 代码check in以后, US算完成了么? 还是部署到测试环境中, 经过集成测试组的验证才算完成?

我们尽可能使用"随时可上线", 有时也会这样定义"已经部署到测试服务器上, 准备进行验收测试";

开始的时候使用的是比较详细的检查列表, 现在常说的是"如果Scrum团队中的QA说可以, 那这个US就算完成", 这样责任就到了测试人员身上, 他们需要保证团队理解PO的意图, 要保证US的"完成"情况可以符合大家认可的定义;

不能把所有的US都一概而论; e.g. 查询用户表单, 操作指南, 这两个US的处理方式有很大差异; 对后者Done的定义可能是简单的--"被运营团队认可"; 所以, 按日常认识的一些标准可能会好过正式死板的检查列表;

如果常常对怎样定义Done感到困惑, 较好的办法是在每个US都添加一个字段, 起名为"DOD" [critical]

使用计划纸牌做时间估算

估算是一个团队活动, 通常每个成员都会参与所有故事的估算;

-在计划的时候, 一般还不知道谁会来实现哪个US的哪个部分; [有些时候有人对这块实现很熟练, 可能会把这块的Task交给这个人]

-每个US一般有好几个人参与, 包括不同类型的专长 (UI设计, 编程, 测试等)

-团队成员必须要对US内容有一定的理解才能进行估算; 要求每个人都做估算, 就可以确保每个人理解每个条目的内容; 这样为大家在sprint中相互帮组奠定基础, 有助于US中重要的问题被尽早发现;

-每个人对US做估算, 经常会发现对US估算结果的差异, 可以尽早发现问题进行讨论;

让整个团队进行估算, 通常对US理解最透彻的人会第一个发言, 这样会严重影响其他人的估算;

计划纸牌, 可以用来避免这种情况;

每个人都会拿到一套卡片, 在估算US的时候选出一张表示他的时间估算(按故事点的方式表示), 在所有人完成估算后同时展示, 这样每个人都会进行思考, 而不是依赖其他人的估算结果;

如果估算之间有巨大差异, 团队就会就此讨论, 试图让大家对故事内容达成共识; [可能是对US深度或广度的理解不一致, 也可能是有问题被忽略了]

Solution: 可能会进行任务分解, 在重新估算, 这样的循环可能会往复进行, 知道时间估算趋于一致, 每个人对US的估算都差不多相同;

Note 团队成员对US的估算需要考虑US所包含的全部工作时间, 不只是"他们自己负责的部分", 测试人员不能只估算测试工作;

Note 估算的数字不是线性的[可以用Fibonacci数列], 因为一旦时间估算值太大, 精度就很难把握;

这样可以避免人们对估算精度产生错误的印象; 如果一个US的估算值是差不多20个故事点, 到底是20, 18还是21其实没有关系; 我们需要知道的是它是一个很大的US, 较难估算;

需要进行更精确的估算, 就把US分拆, 去估算更小的US; 不需要把2和8加起来变成10这样的估算, 直接直观地选择已经定义好的数字;

特殊卡片:

- 0 代表 US已经完成了, 或者这个US没有多少内容, 一行code就能搞定, 无需测试;

- ? 代表 对US完全没有概念, 没有任何思路;

- 咖啡杯 代表会议太久了, take a break;

明确故事内容

在sprint的demo会议上, 团队展示的新feature不是PO想要的, 这是很糟糕的情况;

很难做到PO和所有团队成员对每个US都有完全一致的理解, 可以使用一些简单的技术识别出明显的误解, 首先确保每个US的字段都被填写好(具有高优先级, 需要在这个sprint中完成的)

e.g. 团队错误理解了US的范围, 以为"增加用户"是需要一个web界面来增加, 删除, 移除和查询用户, 但是PO只是想通过手写SQL操作数据库来添加用户, 不同的理解可能相差20个故事点, 需要PO和团队讨论来达成共识;

这种情况下, 可以通过"如何演示"的角度来讨论US的需求, "如何演示"可以使用精简, 容易理解的方式来描述: "Step1, Step2...最后验证Point1, Point2..."; 使用精简的方式描述既容易发现对于US范围的误解, 又可以控制planning时间;

把故事拆分成更小的故事

US不应该太短, 也不该太长(适合估算); 

如果有一大堆0.5个故事点的US, 可能已经浪费了太多时间, 从管理的角度和效率的角度都是不合适的;

如果有一堆超过40故事点的US, 到最后只能部分完成, 没法为公司带来任何价值, 只会增加管理成本; 如果生产率是70, 而优先级最高的两个US都是40个故事点, 那就很难做计划;    

如果只选一个条目, 完成承诺的工作后, 会有不少的空闲时间, 导致承诺不足 under-committing; 如果两个都选上, 最后无法完成允诺的工作量, 就会导致过度承诺 over-committing;

通常保证故事的大小在2~8人/天之间, 一个普通团队的生产率大约是40~60, 那么每个sprint可以完成大约10个US, 也可能是5~15个, 在这个范围内是比较好控制的;

把故事拆分成任务

US是可以交付的东西, 是PO所关心的; Task是不可交付的, PO不关心task的内容;

US拆分成更小的US:

把US拆分成Task:

一些有趣的现象:

-新组建的Scrum团队不愿意花时间来预先把故事拆分成任务; 有人会觉得这像是瀑布式的做法; [有些瀑布式团队习惯了谁做谁拆, 在sprint开始后自己来做理解和预估, 觉得开会太花时间, 但是没有task breakdown, planning对于流程控制和风险预估的部分都将难以把握]

-有些故事大家都理解的很清楚, 预先拆分还是随后拆分都一样简单; [要保证每个人理解的一致, 需要大家在一起过一遍, 并且留下记录]

-拆分常常可以发现一些会导致时间估算增加的工作, 最后得出的sprint计划更贴近现实; [sprint讨论的意义所在]

-预先拆分可以给每日例会的效率带来提高; [每个人更明确工作任务, 方便SM对sprint的更新条目]

-可能拆分不够精确, 一旦开始具体工作, 事先的拆分结果也许会发生变化, 但我们依然可以得到以上种种好处;

将sprint计划会议的时间放到足够长, 保证有时间进行任务拆分, 如果时间太长, 就不再继续; [sprint会议要有time box, 低优先级的放弃拆分?]

实践TDD(测试驱动开发Test deriven development) 每个故事第一任务是"编写一个失败的测试", 最后任务是"重构"(提高代码可读性, 去除重复)

定下每日例会的时间地点

Sprint计划会议的必要的产物: Sync-up meeting确定的时间和地点;

下午开例会你需要在早上记起昨天开会说过要做的事情, 上午开例会需要记起昨天做了什么; [其实都是废话, 随便记下几个字就能想起来]

选择的时间一般是大家都能接受的最早的时间; [不会影响日常工作, 也不会太早或太晚的时间就行, 太早起不来, 太晚班车来不及]

最后的界限在哪里

如果planning的时间不够, 该砍掉哪些事情?

优先级列表:

优先级1:  sprint目标和demo日期; 这是启动sprint最起码的准备; 团队有一个目标, 一个结束日期, 可以马上根据产品backlog开始工作;

优先级2:  经过团队认可, 要添加到这个sprint中的故事列表;

优先级3:  Sprint总每个User Story的估算值;

优先级4:  Sprint中每个故事的"如何演示" [DEMO]

优先级5:  生产率和资源计算, 作为sprint计划的实现核查; 包括团队成员的名单以及每个人的承诺(用以计算生产率) [每个人take的tasks]

优先级6:  明确daily meeting固定举行的时间地点; SM可以在会后确定, 以邮件通知所有人;

优先级7:  把US拆分成任务; 拆分也可以在每日例会上做, 这样会稍稍打乱sprint的流程; [这样会增加例会时间, burning down chart也非常不准确]

技术故事

有的US是一个技术故事, 非功能性的条目, 是需要完成但又不属于可交付的东西, 和任何US都没有直接关联, 不会给PO带来直接的价值; [Algorithm?]

e.g.

安装持续构建服务器 [continuous integration] 可以节省开发人员大量的时间, 到迭代结束的时候, 集成也不太容易出现重大问题;

编写系统设计概览 开发人员常常忘记系统的整体设计, 写出不一致的代码, 团队需要有一个描述整体概况的文档, 保证每个人对设计有同样的理解;

重构DAO层 [Database Access Obect - Java] 混乱的DAO代码和结构带来的是本来可以避免的bug, 每个人的时间都在被无谓的消耗, 清理代码可以节省团队的时间, 提高系统的健壮性;

升级JIRA(bug跟踪工具) 当前的bug太多, 系统很慢, 升级节约大家的时间;

按照一般的观点, 很难确认这些是US, 或者是一些和任何US都没有关系的task, 优先级是多少, PO是否该参与都难以界定;

几种处理方式:

和别的US一样, 当作第一等级的US; 但这样PO在对产品backlog划分优先级的时候无法确认优先级, 技术故事往往会因为某种原因被设置低优先级; 有些时候PO的做法是对的[有优先级很高的US需要完成], 但这只是少数情况; PO往往不能对此作出正确的选择;

1) 试着避免技术故事; 努力找到一种方式, 把技术故事变成可以衡量业务价值的一般故事, 有助于PO作出正确的权衡;

2) 如果无法转变成普通故事, 就尝试把这项工作当作某个US中的任务; e.g. "重构DAO层"可以作为"编辑用户"的一个任务, 因为这个US涉及到DAO层;

3) 如果上两种都不行, 那就定义一个技术故事, 用另外一个单独的列表存放, PO能看到它, 但不能编辑它; 用"投入程度"和"预估生产率"这两个参数来和PO协商, 从sprint里取一些时间来完成技术故事;

在PO参与的情况下, 需要说服PO, 完成技术故事是为了加快开发效率[增加生产率], 或者完善产品质量[减少bug数量], 而不是对于sprint无意义的事情, 让PO了解完成技术故事的重要性;

如果PO有开发经验或者更多的实践知识, 比较容易沟通和听取意见, 建议让PO知道所有的事情, 让PO制定工作的优先级, 透明也是Scrum的核心价值; [反之, 团队也要尝试说服PO给时间提高内部质量]

Bug跟踪系统 vs. 产品backlog

Excel来管理backlog不错, 但是需要一个bug跟踪系统, Excel并不适合; [spring planning用Excel也比较有效率] 

使用JIRA, Rally之类的系统跟踪bug;

如何把系统中的issue带到sprint计划会议上:

1) PO打印出JIRA中优先级高的条目, 带到sprint计划会议中, 和其他US一起贴墙上 (也暗示了这些issue和其他US相对的优先级)

2) PO创建一些指向JIRA条目的故事; e.g. 修复后台报表错误: bug序号Jira-112, Jira-113...

3) bug fix被当作sprint之外的工作, 团队会保持一个足够低的投入程度(例如50%), 保证他们有时间来修复bug; 简单地假设每一个sprint, 团队都会用一些时间来修复bug;

4) 把产品backlog放到JIRA上(放弃Excel), 把bug和其他US同等对待; [bug和US可以被过滤, 是两种不同的条目类型]

[Bug由系统自动Track比较方便, Excel太费劲, DEV可以在系统中设置邮件提醒, QA可以发mail提醒有高优先级的bug;]

Spring计划会议完成

sprint计划会议是Scrum中最重要的活动, 在会上投入更多的努力, 保证会议顺利完成, sprint后面的工作就会更加轻松;

---制定Sprint计划 End---