硝烟中的Scrum和XP-我们如何实施Scrum 9)演示 10)回顾 11)休整
9 怎样进行sprint演示
Sprint演示[DEMO]或者叫sprint回顾[REVIEW]是Scrum中重要的环节, 却很容易被低估;
为什么坚持所有的sprint结束于演示
一次不错的演示带来的影响:
- 团队的成果得到认可, 成员们会感觉很好[正能量...];
- 其他人了解到你的团队在做什么; [透明度]
- 演示可以吸引相关的人的注意, 并得到重要反馈; [老板and客户, 都来提提意见]
- 演示是一种社会活动[social activity], 不同的团队可以互相交流, 讨论各自的工作; [如果是个运作健康的系统中, 讨论能改进各自的流程]
- 做演示会迫使团队真正完成一些工作, 用以发布(即使是测试环境) [beta版本]; 如果没有演示, 得到的可能总是99%完成的工作; 有了演示的流程, 也许我们完成的工作会变少, 但它们是真正完成的; 这样比得到一堆貌似完成的工作要好, 而且后者可能会污染下一个sprint;
如果一个团队是被逼者做演示, 尤其在没有完成多少工作的情况下, 演示会变得令人尴尬; 这样会伤害一些人, 但是这是苦口良药, 在下一个sprint, 团队就会真正试着完成一些事情; [最好还是每个sprint都安排好有东西能交付吧]
Sprint演示检查列表
- 确保清晰阐述了sprint目标, 如果在Demo桑有些人对产品不了解, 可以话几分钟进行描述;
- 不需要花太多时间来准备演讲, 需要演示的是实际工作的代码产生的功能;
- 保持演示的快节奏, 不需要多少修饰;
- 关注业务层次, 不用管技术细节, 重点是"做了什么", 而不是"怎么做的"
- 可能的话, 让参与者自己试验一下产品; [green hand来操作常常会发生意想不到的bug, crash之类的 +0+]
- 把重点放在重要的US上, 对于细碎的bug fix和小feature可以描述一下, 不一定要每个都仔细演示, 因为那样Demo太长, 会分散参与者的注意力;
处理"无法演示"的工作
e.g. 提高系统的可扩展性, 能够容纳10000个客户的并发请求;
给出测试环境的配置方法以及测试报告;
[US必须是可测的, 既然通过了测试, 那就可以使用测试的方法来演示, 如果要花很长时间的测试, 那就把测试报告展示出来]
---sprint演示 End---
10 怎样做sprint回顾
为什么要坚持所有的团队都要做回顾
确保回顾会议能够进行; 由于某些原因, 团队常常不愿意做回顾 [觉得没啥可说的?]
回顾会议是将sprint做改进的最佳时机; 每个人都有机会讨论和提出想法, 如果没有回顾会议, Scrum团队可能会不断地犯相同的错误;
如何组织回顾
- 根据讨论的内容范围, 设定时间 1~3个小时;
- 参与者: PO, SM和整个团队;
- 找一个会议室或者舒服的场所, 在不受干扰的情况下讨论就好; [找个屋顶平台, 边吃边讨论 ^-^]
- 不要在团队房间中进行回顾, 周围的spec, board, 电脑等会分散注意;
- 指定某人当秘书; [记录, 一般就是SM了]
- SM向大家展示sprint backlog, 在团队的帮助下对sprint做总结, 包括重要事件和决策;
- 轮流发言, 每个人有机会在不被打断的情况下讲出自己的想法: 好的方面和需要改进的方面;
- 对预估生产率和实际生产率进行比较, 如果差异比较大, 分析原因;
- 会议结束前, SM对记录的建议进行总结, 得出下个sprint需要改进的地方;
回顾会议没有太正规的结构, 只要抓住主题: 怎么样在下个sprint做得更好;
1) Good 下一个sprint应该保持的;
2) Could have done better 哪些地方需要改变;
3) Improvements 关于将来如何改进的具体想法;
1)和2)回顾过去, 3)是展望将来;
团队通过BrainStrom得到的所有想法逐一写在即时贴上, 放到墙上或桌面上, 使用"圆点投票"来决定下一个sprint会着重进行哪些改进; [使用圆点贴纸或者小磁铁等可以计票的工具]
根据投票情况选出重要的几个进行改进, 在下一个回顾会议中跟踪查看这些改进的执行情况; 每个sprint关注其中几个重要的改进就可以; [把所有的项目都在一个sprint中进行会分散太多的精力]
在团队间传播经验
在sprint回顾中的到的信息常常很有价值, 可能是在团队和团队之间共性的问题;
- 可以找一个人参加所有的回顾会议, 充当知识桥梁, 将信息共享;
- 可以让每个Scrum团队都发布sprint回顾报告, 但很多人可能根本不会去读;
充当"知识桥梁"的人: 应该是一个很好的倾听者; 如果回顾会议陷入沉默, 他应该问一些简单而目标明确的问题, 刺激团队讨论; e.g. "如果重新开始这个sprint, 你觉得哪些事情应该用其他方式来做?" 他应该资源花时间参加所有团队的全部回顾会议; 他应该有一定的行政权力, 如果一些团队有一些改进建议, 不在团队的权利范围, 他可以帮助实施; [Manager?]
是否改变
很多时候, 只要能清楚地指出问题, 在下个sprint, 这个问题也许会自行解决 [人们意识到了, 就会有所改变]
把sprint回顾的结果贴在墙上, 让大家看到会更有效;
sprint中引入每一个变化, 都会让团队付出一定的代价, 在变化之前先考虑不改变流程, 问题是否能简单解决; e.g. "团队内部的交流太少了" [不一定每次都要改变团队行为, 有些问题意识到就可以了]
回顾中发现的问题示例
- "我们应该花多些时间, 把US拆分成更小的条目和任务" 每天的例会上可能有人会不知道今天做什么, 要在会后找出具体的任务;
Move 无; 团队可能在下一次planning会议上自己解决这个问题, 如果不行, 就延长planning会议时间;
- 太多的外界干扰
Move 1) 下个sprint减少投入程度, 合理计划;
2) 在下个sprint上把干扰的原因记录清楚, 谁或哪里来的干扰, 占用多少时间, 然后再寻求方案;
3) 把干扰因素转给Scrum Master和PO, 让他们handle;
4) 指定团队中的某位作为"守门员", 所有的干扰要经过他处理, 其他人可以把注意力集中在项目上;
- 过度的承诺, 最好只完成了一半工作;
Move 无; 下次planning团队不会再过度承诺;
- 办公室的环境太吵;
Move 1) 试着创建更好的环境, 或者把团队搬到合适的开发环境; [小黑屋或者大宾馆]
2) 如果无法改变环境, 就只好降低投入程度, 注明是因为环境原因导致的, 希望PO开始联系管理者解决这些问题;
---sprint回顾 End---
11 Sprint之间的休整时刻
实际生活中, 在不断冲刺的过程中, 需要间歇性的休息; 弦绷得太紧效果反而会差;
除了休息之外, Sprint演示和回顾之后, 团队和PO都会有一堆信息和想法需要消化, 如果立刻进入下一个sprint的planning, 团队没时间把手上的信息和经验学习整理, PO也没有时间调整US和设定优先级别;
(较差)(较好)
>在sprint回顾之后, 下一个sprint计划会议之前最好留一些时间进行调整;
(更好)
"实验日"LAB DAY, 是一种方式, 在这天开发人员基本上可以想做任何感兴趣的事, 学习新工具, API, 认证, 讨论, 开发自己的项目(From Google) [不过现在好像在Google也开始淡化了, 没有老板愿意付钱给你做自己的事情...]
安排实验日可以让开发团队得到自然休息, 同时了解前沿知识, 也属于一种福利; (每月一次)
(实验日)
在公司里面可能有很多Scrum团队, 他们的sprint时间是不同步的, 那样就只能随机定一个固定日子作为实验日; 如果所有产品的sprint进行了同步, 都有相同的开始和结束时间, 那就可以选择两个sprint之间的日子当LAB DAY了; [基本不可能...Sprint过程中可能会因为客观原因有调整, 当然, 如果老板规定好时间, 不考虑影响效率, 那或许能做到]
---sprint休整 End---