硝烟中的Scrum和XP-我们如何实施Scrum 5-8
5 怎样让别人了解我们的sprint
让整个公司了解team在做什么, 这件事情至关重要; [或者让相关的人知道, 让管理者知道, 公司太复杂时, 透明度有时候会变成某种缺点]
使用sprint信息页:
有时会把每个故事该如何演示也包括进去; Sprint计划会议一结束, SM就创建这个页面, 放到wiki上, 给整个公司发一个邮件; [给相关的所有人发邮件, 创建wiki作为history]
wiki上会有个dashboard页面, 链接到所有在进行中的sprint;
SM会把sprint信息页打印出来, 贴到团队房间外面的墙上, 大家都能了解团队的情况;
sprint到尾声时, SM会把demo的时间告知每个人 [again, 相关的人]
---让别人了解sprint内容 End---
6 编写Sprint Backlog
Scrum Master应该在sprint计划会议之后, 第一次daily meeting之前完成sprint backlog;
Sprint backlog的形式
有很多方式来保存sprint backlog, e.g. JIRA, Excel(模板, 自动生成燃尽图), 任务板(手画燃尽图)...
管理sprint backlog最有效的形式是-挂在墙上的任务板;
找一面无人使用的墙面, 贴上大白纸(2*2~2*3平方米), 或者可以使用白板; 如果使用贴纸记录任务, 别忘记固定好它们;
[任务可以由上到下按优先级排]
Not Checked Out: 还没开始的任务; Check Out: 今天正在进行的任务; DONE: 完成的任务;
BURNDOWN: 每天在daily meeting以后可以手动更新燃尽图; UNPLANNED ITEMs: 计划外的产物, 暂时放这里;
Next: 如果所有的US都在sprint结束前做完了, 可以在这里添加新的任务;
你也可以添加你所需要的列; e.g. "等待集成测试", "已经取消"等等, 要添加上去的列最好是必须的, 否则只会把白板变复杂却没多大帮助;
例1 sprint开头: 在大的团队中, 有时某个任务会一直停留在checked out状态, 却没有更新, 我们需要记住是谁认领了这个任务, 加上标签, 记录是谁check out了任务; [写上名字]
例2 sprint中间: 有些US完成, 有些正在进行, 有些还没开始, 在sprint中没有计划到的条目会被放在任务板的右下角; 在sprint回顾会议的时候应该记下这些条目;
燃尽图如何发挥作用
这张图包含的信息:
- Sprint第一天 8/1, 估算剩下有70个故事点要完成, 实际上就是整个sprint的估算生产率;
- 8/15 还剩下15个故事点, 和表示趋势的虚线对比, 团队的工作状态还沿着正轨, 按照这个情况能在sprint结束时完成任务;
在时间线x轴上, 应该把周末的时间点去掉, 因为加班不应该算在计划内;
任务板警示标记
通过观察燃尽图, 可以大致了解到sprint的进展状态; SM应该确保团队会对这些警示标记作出反应;
1) 当曲线大大高于趋势线, 需要采取措施, 把一些backlog item移出这个sprint; [或者加人, 或者加班...]
2) 当曲线大大低于趋势线, 需要增加一些backlog item到这个sprint中; [或者做一些技术故事相关任务]
3) 任务应该先从优先级高的开始做 [优先级可以按由上到下在板子上排列]
4) unplanned item太多的时候, 这个sprint可能会趋向失败;
该怎样进行跟踪
或许可以每天给任务版拍一张照片作为记录; [使用JIRA, Rally系统的话就自动有记录, 虽然查询起来比较慢]
对于历史和细节可能不需要太详细的跟踪, sprint完成后重要的工作已经交付; [应该集中注意力在下个sprint, 当然有些改进可以在retrospective meeting上提出]
天数估算 vs. 小时估算
大多数的Scrum书中, 是以小时而不是天数来估算时间, 通用方程是 人/天 = 6 个有效的人/小时 (velocity)
但是由于一些原因, 使用人/天会更合适:
- 人/小时的粒度太细了, 会导致许多 1~2小时的任务出现, 引发微观管理;
- 发现实际上每个人还是按照人/天的方式在思考, 只是填写数据时乘上了6, 得到人/小时;
- 两种不同的单位会导致混乱, 成员可能会不确定应该以小时还是以天来估算;
使用人/天作为所有时间估算的基础(故事点), 最小值是0.5, 小于半天的任务要么被移除, 要么和其他任务合并, 或者直接就给0.5的估算值;
---编写产品Backlog End---
7 怎样布置团队房间
设计角 许多有趣和有价值的设计讨论, 很可能都是在任务板前面发生的;
站到设计角前面, 看看文字和图表, 然后使用计算机用最新的build试验一下, 就可以得到系统的概况;
Design Wall是一块白板, 有设计草图, 有设计文档(顺序图, GUI原型, 领域模型...)
让团队坐在一起
- 互相听到 所有人可以彼此交谈, 不必离开座位或者大声喊;
- 互相看到 能看到彼此, 能看到任务板 (可以看到大概的内容)
- 隔离 如果团队突然进行激烈的设计讨论, 团队外的人可以少受打扰; 外部的影响也不容易打扰到团队;
"隔离"不一定要封闭空间, 只要有像格子间那样屏蔽大多数格子外部的空间和噪音就可以;
如果是分布式团队, 那就只好使用技术辅助工具 -- 视频会议, 网络摄像头, 桌面共享等;
让产品负责人无路可走
PO应该离团队很近, 既方便团队成员找到他讨论问题, PO也能随时走到任务板前面; 但是PO不适合和团队坐在一起, 因为PO的关注点和团队是有区别的, 他关注的不是实现细节;
让经理和教练无路可走
运作良好的Scrum team应该会凝聚在一起, 进行自我管理; 经理和教练需要的是提供team所需的一切, 在发现可改进的地方时, 找出Scrum Master进行指导;
---布置团队房间 End---
8 怎样进行每日例会
在固定的房间, 固定的时间, 或者直接在任务板前面开每日例会效果更好; 一般站立会议, 控制时间在15分钟;
怎样更新任务板
一般是在每日例会的时候更新任务板, 这样每个人可以在描述已经做的事情和将要做的事情的同时, 移动任务板上相应的即时贴; 如果说到了未经计划的条目, 就需要新写一张即时贴; 估算的时间的更新可以写在即时贴上, 划掉旧的, 写上新的时间;
或者是SM在成员描述时帮忙修改, 或者在会议开始前就更新好任务板, 只要订好规则, 坚持执行就可以;
无论sprint backlog是什么形式, 都要尽力让整个团队参与到sprint的更新的工作中; SM自己维护sprint backlog的话, 每天要去咨询大家各自的剩余工作估算时间;
缺点:
- SM花太多的时间用在管理之类的工作上, 而不是为团队提供支持, 消除障碍;
- 团队成员对sprint backlog的关心度下降, 意识不到sprint的状态, 缺少sprint的反馈, 团队整体的敏捷度和集中度都会下降
如果sprint设计的好, 每个人都应该很容易在上面做修改;
daily meeting结束, 就需要有人计算出剩余工作的时间估算总和, 在sprint燃尽图上面画上新的点;
处理迟到的情况
弄个存钱罐, 对于迟到的人罚钱 [一次一块钱 :)], 无论迟到是什么理由(除了事假病假之类的无法参加);
罐子里的钱可以用作team building经费; [一个或几个sprint活动一次, 或者在retrospective meeting的时候买的吃的~]
处理"不知道今天该干什么"的情况
在meeting上SM可以标记一下哪些人没有后续任务, 先听其他人讲完, 然后和大家在任务板上检查是否所有条目都已经同步过了, 保证每个人都清楚每个条目的含义, 如果没有人需要帮忙(结对编程), 也没有任务可以进行, 就请人添加更多的任务上去, 确认"不知道今天做什么"的成员明白下一步的任务;
可以从Next区域中拿出US放到Not checked out队列中, 调整一下daily meeting[确认每个人的工作], 告诉PO, sprint backlog已经调整了;
如果团队还未达成目标, 但是有些成员不愿做些有用的工作, 尝试的策略:
1) 羞辱式做法: "如果你不知道该做什么, 建议你回家去, 或者找个地方看书, 等别人有需要帮忙" [直接skip, 不适合Chinese, 或者是地球人, 只有互相非常熟的team可能可以这样开玩笑]
2) 守旧式做法: 简单地给他们分配个任务 [这个其实是最简单有效的]
3) 施加压力: "你们可以放松点, 我们会站在这慢慢等, 知道你们找到可以帮助我们的任务为止" [有点自作聪明, 对老油条完全无效]
4) 奴役试做法: "你们今天可以干干杂活, 倒咖啡, 清理服务器, 做午饭..." [大概会有用要么, 老外思路有点怪]
如果有人常常需要SM这么做, 就应该考虑是否找他单独辅导, 如果辅导没有效果, 就需要考虑把他从团队挪走或者找一个人和他结对, 充当"牧羊人";
---每日例会 End---
