硝烟中的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---