敏捷开发-回顾会议
2017-06-22 14:52
393 查看
保持透明性、检视与调整是Scrum的三大支柱,
以此作为支撑我们才可以对整个开发过程进行持续的改善。
回顾会议是Scrum检视与调整的一个重要的环节,在这个会议上,ScrumMaster鼓励团队在Scrum过程框架和时间范围内,
对自己的开发过程进行改进,并确定什么样的调整可以使下一Sprint的效率更高、结果更令人满意和更易于工作。
回顾会议旨在对前一个Sprint周期中的人、关系、过程和工具进行检验。
检验要确定好的做法继续保持,以及需要摒弃或改善的做法。
这些包括:Scrum团队构成、会议安排、工具、“完成”定义、沟通方法和将产品Backlog条目转化成“完成”工作的过程。
在Sprint回顾会议的最后,Scrum团队应该确定将要在下个Sprint中实现的有效改进方法,并在接下来的Sprint中付诸行动。
然而,开好回顾会议,让其起到促进团队持续改善的效果并非易事。
要开好回顾会议对会议的形式、主持人的协调能力都有很高的要求。
如果回顾会议过于形式化和刻板则会使团队丧失参与的兴趣,
不利于团队成员说出真实的想法,也不利于发掘更有效的改进建议。
ScrumChina linkedin group(http://www.linkedin.com/groups?gid=3343227)
对此进行了热烈的讨论,也分享了不少有用的实践,许多参与者认为回顾会议应该保持轻松愉快的氛围,
让大家畅所欲言,在这里挑出其中的一些供大家参考:
Jingbin Liao:建议增加一个感谢环节,每个人都可以感谢其他人对我的帮助,感谢某某某对团队做出的贡献。
Kai Wang :我们的实践一般会再加一个问题:对于not working的,
我们要采取什么行动 如果这个sprint提的行动,到下一个sprint还没有执行,就加大一个字号,
到下下一个sprint还没有执行,就再加大一个字号,以此类推。
Hongquan Yin : 讨论什么不好,然后就要想出解决的方法。
另外反思会另外一点就是增进团队成员之间的情感交流,因为我发现在做scrum task的时候,更多的是就事论事,比较干燥。
Fred Liu :retrospective是对过程的反思,形式不固定,搞点活泼的也挺好,不过主题不要跑偏了。 说不定可以来点禅家的冥想
Mike Li :制作一些表情符,用这种方式让大家表达一下对Sprint的感受,高兴?沮丧?激动?无所谓?
Mark He : 个人觉得Retrospective最重要还是要能听到真话,Team和个人的Pain Point是什么,以便持续改进。
所以除了什么方面做的好,什么不好之外,一般我会在回顾会议开始加小环节,
总结通报上次会议定下来的行动列表,哪些做了,哪些还没有,没有做的联系人是谁,原因是什么,接下来会怎么做。
回顾会议的结尾,也会做个小结,根据会议内容列出行动列表,便于后期检查。
见过有Team开了会但是没有行动列表的,没有实实在在的解决问题,结果每次开讨论的问题都差不多,最后Team就皮掉了。
当然这个方法未必就一定好,只是个人几次实践下来发现效果还可以,至少Team知道确确实实重视他们的意见,也在不断改进,就会更加愿意说真话,良性循环 。
De Yi (Linda) Liu:我们的做法是(个人感觉很有效):每人发三张便签纸,
分别写下: – What to Keep – What to Change – What to Try
每张纸上不能超过三条。如果实在没有,也可以不写,或少于三条,但不能一张也不写。
(可以记名,也可以不记名,由Team自己决定) 然后把所有的纸条收集到一起,贴到白板上,总结出每一项的Top 3。
经过小组一致同意,确定下来。在新的Sprint中随时跟踪执行情况,并在下一个Retrospective的时候总结。
这样做有很多好处: – 每个人都得以发言 – 大家不会受到某些比较“积极”发言的人的影响 我们在使用这种方法前,往往只是Scrum Master或少数几个活跃的成员发言,其他人”默许”。
但是用了这种方法后,每个人都能提出很有建设性的建议。 另外,如果是记名的,还可以用来评选Sprint Champion。
比如谁的“What to try”的建议被采用得最多。
这又引出我们活跃团队气氛的一个方法:Sprint Champion。
我们的Scrum Team在Sprint Review、Plan、Retrospective时,都会评选不同的Sprint Champion。
经过实践,效果非常好。当然,Champion的内容要选择有利于Team work的项目,而不是突出个人贡献。
以此作为支撑我们才可以对整个开发过程进行持续的改善。
回顾会议是Scrum检视与调整的一个重要的环节,在这个会议上,ScrumMaster鼓励团队在Scrum过程框架和时间范围内,
对自己的开发过程进行改进,并确定什么样的调整可以使下一Sprint的效率更高、结果更令人满意和更易于工作。
回顾会议旨在对前一个Sprint周期中的人、关系、过程和工具进行检验。
检验要确定好的做法继续保持,以及需要摒弃或改善的做法。
这些包括:Scrum团队构成、会议安排、工具、“完成”定义、沟通方法和将产品Backlog条目转化成“完成”工作的过程。
在Sprint回顾会议的最后,Scrum团队应该确定将要在下个Sprint中实现的有效改进方法,并在接下来的Sprint中付诸行动。
然而,开好回顾会议,让其起到促进团队持续改善的效果并非易事。
要开好回顾会议对会议的形式、主持人的协调能力都有很高的要求。
如果回顾会议过于形式化和刻板则会使团队丧失参与的兴趣,
不利于团队成员说出真实的想法,也不利于发掘更有效的改进建议。
ScrumChina linkedin group(http://www.linkedin.com/groups?gid=3343227)
对此进行了热烈的讨论,也分享了不少有用的实践,许多参与者认为回顾会议应该保持轻松愉快的氛围,
让大家畅所欲言,在这里挑出其中的一些供大家参考:
Jingbin Liao:建议增加一个感谢环节,每个人都可以感谢其他人对我的帮助,感谢某某某对团队做出的贡献。
Kai Wang :我们的实践一般会再加一个问题:对于not working的,
我们要采取什么行动 如果这个sprint提的行动,到下一个sprint还没有执行,就加大一个字号,
到下下一个sprint还没有执行,就再加大一个字号,以此类推。
Hongquan Yin : 讨论什么不好,然后就要想出解决的方法。
另外反思会另外一点就是增进团队成员之间的情感交流,因为我发现在做scrum task的时候,更多的是就事论事,比较干燥。
Fred Liu :retrospective是对过程的反思,形式不固定,搞点活泼的也挺好,不过主题不要跑偏了。 说不定可以来点禅家的冥想
Mike Li :制作一些表情符,用这种方式让大家表达一下对Sprint的感受,高兴?沮丧?激动?无所谓?
Mark He : 个人觉得Retrospective最重要还是要能听到真话,Team和个人的Pain Point是什么,以便持续改进。
所以除了什么方面做的好,什么不好之外,一般我会在回顾会议开始加小环节,
总结通报上次会议定下来的行动列表,哪些做了,哪些还没有,没有做的联系人是谁,原因是什么,接下来会怎么做。
回顾会议的结尾,也会做个小结,根据会议内容列出行动列表,便于后期检查。
见过有Team开了会但是没有行动列表的,没有实实在在的解决问题,结果每次开讨论的问题都差不多,最后Team就皮掉了。
当然这个方法未必就一定好,只是个人几次实践下来发现效果还可以,至少Team知道确确实实重视他们的意见,也在不断改进,就会更加愿意说真话,良性循环 。
De Yi (Linda) Liu:我们的做法是(个人感觉很有效):每人发三张便签纸,
分别写下: – What to Keep – What to Change – What to Try
每张纸上不能超过三条。如果实在没有,也可以不写,或少于三条,但不能一张也不写。
(可以记名,也可以不记名,由Team自己决定) 然后把所有的纸条收集到一起,贴到白板上,总结出每一项的Top 3。
经过小组一致同意,确定下来。在新的Sprint中随时跟踪执行情况,并在下一个Retrospective的时候总结。
这样做有很多好处: – 每个人都得以发言 – 大家不会受到某些比较“积极”发言的人的影响 我们在使用这种方法前,往往只是Scrum Master或少数几个活跃的成员发言,其他人”默许”。
但是用了这种方法后,每个人都能提出很有建设性的建议。 另外,如果是记名的,还可以用来评选Sprint Champion。
比如谁的“What to try”的建议被采用得最多。
这又引出我们活跃团队气氛的一个方法:Sprint Champion。
我们的Scrum Team在Sprint Review、Plan、Retrospective时,都会评选不同的Sprint Champion。
经过实践,效果非常好。当然,Champion的内容要选择有利于Team work的项目,而不是突出个人贡献。
相关文章推荐
- Scrum敏捷开发从零开始(2):全员会议
- 敏捷开发 回顾
- 敏捷开发产品管理系列之五:预估会议
- 开发管理 CheckLists(17) -敏捷开发 SCRUM评估会议
- 开发管理 CheckLists(16) -敏捷开发 SCRUM全员会议
- 一个敏捷回顾-游戏开发
- 敏捷开发:如何通过回顾保持学习状态
- 敏捷开发产品管理系列之五:预估会议
- 敏捷开发产品管理系列之五:预估会议
- 【原创】敏捷开发方法中会议的明确定义
- 敏捷软件开发最佳实践之-Scrum站立会议
- 敏捷开发历程回顾
- 让敏捷的回顾会议变得有趣而高效
- 敏捷开发产品管理系列之五:预估会议
- 101与金根回顾敏捷个人:(13)敏捷个人和敏捷开发
- 敏捷软件开发-站立会议
- [转]敏捷十年简史回顾——影响敏捷开发历程的27件事
- 敏捷开发历程回顾
- 敏捷开发产品管理系列之五:预估会议
- 开发管理 CheckLists(21) -敏捷开发 Scrum Sprint评审会议