《硝烟中的Scrum和XP》第6章 我们怎样编写sprint backlog
- 2020 年 4 月 7 日
- 笔记
第6章 我们怎样编写sprint backlog
- ScrumMaster现在应该创建sprint backlog了。它应该在sprint计划会议之后，第一次每日例会之前完成
sprint backlog的形式
- 是我们发现管理sprint backlog最有效的形式——挂在墙上的任务板！
- 注意——如果你用贴纸来记录任务，别忘了用真正的胶带把它们粘好，否则有一天你会发现所有的贴纸都在地上堆成一堆
任务板怎样发挥作用
- 添加列这种类型的事情，“简单性”会发挥极大的作用；所以除非不这样做会付出极大代价，我才愿意让事情变得更加复杂
例1——首次每日Scrum之后 在首次每日例会之后，任务板可能会变成下图这样，“checked out”表示团队今天将处理这些条目的工作。在大团队中，有时某个任务会一直停留在"ckecked out"状态，因为已经没人记得是谁认领了这个任务。要是这种情况一再发生，他们就会在任务上加上标签，记录谁领了这个任务
例2——几天以后 可以看到，我们已经完成了“DEPOSIT”这个故事（它已经被签入了源代码仓库，经过了测试、重构等等步骤）。“MIGRATION TOOL”只完成了一部分，"BACKOFFICE LOGIN"刚刚开始，"BACKOFFICE USER ADMIN"还没有开始，还有3个未经计划的条目，放在任务板的右下角，进行sprint回顾的时候应当记住这一点
燃尽图如何发挥作用
- sprint的第一天，8月1号，团队估算出剩下70个故事点要完成。这实际上就是整个sprint的估算生产率
- 在8月16号，团队估算出还剩下15个故事点的任务要做。跟表示趋势的虚线相对比，团队的工作状态还是差不多沿着正轨的。按照这个速度，他们能在sprint结束时完成所有任务
- 我们没把周末放到表示时间的X轴上，因为很少有人会在周末干活儿。我们曾经把周末也算了进来，但是这两天的曲线是平的，看上去就像警告sprint出现了问题，这就让人看着不爽了
任务板警示标记
- 在任务板上匆匆一瞥，就可以大致了解到sprint的进展状态。ScrumMaster应当确保团队会对下图所示的这些警示标记做出反应
需要从sprint删除一些backlog
需要添加一些backlog到sprint
sprint进度一半了，忽略高优先级的事情
不在计划的事情干扰了正常的sprint计划
嘿，该怎样进行跟踪呢
- 在这种模型中，如果必须跟踪的话，那我能提供的最佳方式，就是每天给任务板拍一张照片
天数估算vs.小时估算
- 大多数都是用小时而不是天数来估算时间。我们也这样干过。我们的通用方程为1个有效的人-天=6个有效的人-小时
- 现在我们已经不这么干了，至少在大部分团队中如此，原因如下
- 人-小时的粒度太细了，它会导致太多小到1-2个小时的任务出现，然后就会引发微观管理
- 最后发现实际上每个人还是按照人-天的方式来思考，只是在填写数据时把它乘6就得到了人-小时。“嗯……这个任务要花一天。哦对，我要写小时数，那我就写6小时好了”
- 两种不同的单位会导致混乱。“这个估算的单位是啥？人-天还是人-小时？”
- 所以我们现在用人-天作为所有时间估算的基础（虽然我们也称之为故事点）。它的最小值 是0.5，也就是说小于0.5的任务要么被移除，要么跟其他任务合并，要么就干脆给它0.5的估算值 （稍稍超出估算不会带来很大影响）
