敏捷实践之回顾会

举报
Amy 发表于 2019/02/12 16:32:57 2019/02/12
【摘要】 回顾会是在Sprint结束时召开的关于团队自我持续改进的回顾复盘会议,通常在Sprint评审会之后,在下次Sprint计划会议之前展开。

  

 在现在的互联网时代下,传统开发方法已经不能满足快速变化的市场,在这样的市场驱动下,敏捷走进了人们的视野中,并被各大小企业认可和实践随之而来,也有各个领域的同事朋友们开始学习探索敏捷,成为敏捷专家或者敏捷教练。

 我在国企工作过,经历了传统开发方法的项目;也在互联网企业奋斗过,参与了敏捷方式的项目过程;也与各种企业客户接触过,了解到他们的疑虑和难处。目前我也加入了敏捷之旅,正在学习和不停地探索中,在这里分享一些东西,希望大家多多指教,有所收益。

 文字主要内容来自于个人敏捷转型实践、书箱文献和日常系列活动心得等的提炼总结和创作。此系列文字内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读,并按实际场景进行参考。

 如以上内容涉及版权或原创作者有不同见解之处,敬请及时告知,乐于接受并给予修正。

 

  

   

1 定义和特性说明 

1.1 定义 

1.2 特性说明 

1.2.1 明确会议基准 

1.2.2 建立约定 

1.2.3 设定时间盒 

1.2.4 自觉按时到场 

1.2.5 远离工作地点 

1.2.6 形成会议纪要 

1.2.7 确定改进项和责任人 

1.2.8 跟踪闭环 

1.2.9 展示改进效果 

2 案例说明 

2.1 常见问题 

2.2 解决 

2.3 主要收益 

定义和特性说明

1.1 定义

    回顾会是在Sprint结束时召开的关于团队自我持续改进的回顾复盘会议,通常在Sprint评审会之后,在下次Sprint计划会议之前展开

1.2 特性说明

1.2.1 明确会议基准

会议开始要宣读(或大家一起念)敏捷回顾最高指导原则:无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源,以及手上的状况,我们理解并坚信:每个人对自己的工作都已全力以赴

1.2.2 建立约定

    多说我,少说你们回顾的目的是在试图解决问题而不是为了指责。 

每个人都要发言。产品是大家的,人人都要参与。

不推卸责任。我不在乎你是否必须花2天时间解决生产问题,以至于不能做你的工作。我们关注怎样才能防止生产问题发生而再次干扰我们的工作?

1.2.3 设定时间盒

    时间盒是指一个固定的时间范围,会议时间建议不要太久,对于一个一周的迭代周期,建议回顾会的时间不要超过4小时

1.2.4 自觉按时到场

所有的团队成员需自觉按时到场,会议主持人要按照预定的时间按时开始会议,而不管是否有人还没到。对于迟到的人员要有一些惩罚措施,比如缴纳罚金或做俯卧撑等。惩罚措施和数量由团队成员事先共同商定,如果是罚金,如何支配也由团队共同决定。

1.2.5 远离工作地点

回顾会议的开会地点尽量选在远离办公场所的地方,营造一个轻松自由的氛围,例如可以在餐厅开,也可以在室外公园开,或者在会议室摆放一些水果点心都能达到效果毕竟,想改变整个团队的行为,暂时改变环境没什么坏处。

1.2.6 形成会议纪要

每次会议都要有记录人,会后形成会议纪要。如何写好会议纪要也是一门学问,样式可以参考下图:

会议时间


会议地点


主持


参会人员


记录人


会议主题


会议内容

序号

类型

内容

责任人

完成时间

1

message




2

task




3

...




 

1.2.7 确定改进项和责任人

在问题全部讨论完成后,团队需要确定改进项的优先级,然后选出本次迭代必须要改进哪些事项(建议一次迭代改进2-3点即可),并指派具体的团队成员负责落地,下次会议对这些改进点进行跟踪。

1.2.8 跟踪闭环

回顾会中确定实施的改进点,一般会放入下一次迭代的待办列表中,在下一个回顾中,跟踪这些改进的执行情况。

1.2.9 展示改进效果

    对比改进前后的效果,让团队真实体验到改进的好处,自我感觉到荣誉感,并激发团队自主改进的潜力。

案例说明

2.1 常见问题

1) 产品负责人和客户需要参加吗

2) 会议上一片寂静,怎么办?

3) 多团队项目一起开回顾会议,会浪费时间?

4) 回顾会可以集中在一个单一的主题吗

2.2 解决

1) 通常情况下,不建议产品负责人和客户参与Sprint回顾会,这样会让团

队成员感觉到压抑,不能毫不保留的表达自己的想法但是如果本次会议中讨论的主题需要产品负责人或者客户协调解决,就需要邀请产品经理和相关干系人参加,切身体会到问题的影响,尽快帮助团队解决障碍。

2) 大家一片寂静,不知道说什么。这个时候,作为敏捷教练,你是一个引

导者,一定要耐得住安静,等待大家的回复终于有人回复了,慢慢的大家越说越多,就都参与进来了。

3) 多数回顾会应该是单一团队的。这样能保证时间、隐私性和集中,使

这一个团队更好改善自己的工作但有时更多项目中人参与的回顾会也是有益的,我认为每季度开一次频度正好

4) 大多数回顾会应该允许融入任何主题,虽然你偶尔会想提前定义一个整

个团队想改善的话题。例如,你可以用回顾来使团队的会议更高效,或用来进行持续的部署,或是改变团队用的合作工具。偶尔像这样集中回顾,花时间在重要的主题上进行更深入的讨论

 

2.3 主要收益

1) 激励团队成员,对一些好的实践进行承认和肯定

2) 帮助团队挖掘优秀经验并传承

3) 避免团队犯重复的错误

4) 营造团队自主改进的氛围


【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。