登录 个人注册 企业注册 杂志订阅 | 我的需求 | 下载专区 | English
首页 > 专题 > 敏捷项目管理 > 敏捷回顾会议怎么开?华为PM这么说

敏捷回顾会议怎么开?华为PM这么说

返回>

2018年12月16日    作者:刘恒    来源:网络

A-A+

  开篇小故事:前几年,因为前某国家领导人“摆案头,读百遍”,一本叫《沉思录》的书在国内突然曝光度大增。《沉思录》是古罗马皇帝马可·奥勒写给自己的书,内容大部分是在鞍马劳顿中写的。其中有一句“我们所听到的不过只是一个观点,而非事实。我们所看到的不过只是一个视角,而非真相”。


  全员都参加的回顾会议,其实就是希望能通过全员视角,全员的观点来回顾做的好的,做的不好的,改进之。从敏捷宣言,到敏捷的诸多实践(如Scrum),再到DevOps,都一直提倡回顾这种形式。


  其实回顾这种形式,并不是敏捷/DevOps专属的,在华为最早的CMM流程中,也有类似的活动。有时候团队碰到郁闷、痛苦的时候,还会主动自发的开回顾会议。


  所以,我一直认为“回顾”是人类作为一个智慧物种相比其他生物的一个重要区别。我有的时候会通过回顾会议来判断这个团队会不会成功。最极端的,如果一个团队都没有人想着要约大家一起回顾,这个团队极大概率要凉了。


  华为内部除了研发交付团队,连一线的市场团队也包含在内,在重大的市场项目、交付项目的过程中都会定期进行回顾会议,这算是华为内部这么多年积累的一个很好的实践。


  必须鲜明表达的观点——回顾有三个不是


  1.不是“回溯”


  “顾”和“溯”一字之差,在中文的语境中,却会导致变成刨根问底。


  2.不是“批评与自我批评”


  “批评与自我批评”是一个很好的形式,但是会导致团队陷入一种不必要的紧张和犯错感。


  3.不是“问责和处罚”


  软件的不确定性、不可见性、复杂性和易变性决定了软件开发过程总会有些磕磕绊绊,我们提倡的是改进,不是惩罚。从华为这么多年的实践来看,上面的三种情况都出现过,所以提醒大家要小心。


  这么些年实践过来,我们发现出现以上情况,也是因为步子走得太快,低头玩手机,忘了“回顾”的初心:


  1.For a better future;

  2.Learn from past;

  3.Take action in present.


  回顾会议的基本原则


  下个迭代我们怎么才能保证更充分的评审”。


  3.从系统角度思考改进,而非个人


  我们可以说“团队的工作安排上,导向上是不是不重视代码评审?”。


  回顾会议的Step by Step


  1. 确定参与人(Who)


  a)团队所有成员都参加。


  b)领导是否参加,视情况确定,如果领导参加利大于弊,就邀请,否则就算了。


  c)如果是重大的项目发布或项目结束的回顾会议,还应该叫上所有对项目有付出的成员。


  d)建议指定一个会议引导人,可以是敏捷教练,也可以是团队成员轮流来做(团队成员建议熟读本文)。


  2.选择合适的场所(Where)


  a)如果条件允许,离办公位尽可能远一点,避免有同学中途又回去处理工作了。


  b)尽可能不要使用传统会议室的布局,围坐一个大桌子那种不好。可以拉几把椅子围成一个半圆形。


  c)需要有白板,或者墙壁可以贴个大白纸。

  

  3.准备回顾的内容(What)


  a) 准备上个迭代的客观数据,特性、需求、缺陷等数据,如果使用了像DevCloud这样的敏捷管理工具,准备数据其实很快的,甚至不用特别准备,现场打开就可以。


  b) 团队成员上个迭代的感受,可以认为是主观数据的收集。


  c) 每日站立会议的要点。每日站立会议中都会提出并跟踪解决一些问题,回顾这些问题也可以帮助我们审视过程中的情况。


  d) 准备一个规则,会议开始前贴出来或打印出来或投影仪投出来。规则是为了保证会议的纪律和效率,比如不能随便打断别人讲话,每人发言时长,会议时长(建议10~12人的团队,限定在1小时内)。


  4. 回顾会议的过程(How)


  a) 准备和引导——明确目标。重申回顾会议的目标和原则,让成员重拾回顾的“初心”,发布公示的回顾宣言,重申会议纪律,时长。准备和引导环节是让大家放下手机,进入回顾会议状态的必要环节,无论开过多少次,都不应该省掉。


  b) 数据、过程的回放——建立共同的全景。展示本迭代的度量数据,如果有使用类似DevCloud的敏捷管理工具,可以直接打开系统。全景的数据展示回顾,让视角更全面。对于一些“历经劫难”的迭代,可以画一个时间线,把这个迭代发生的重大的一些事件按照时间顺序展示出来,帮助团队成员回顾都发生了什么。


  c) 提出见解——我们如何才能做得更好。可以通过头脑风暴,全员参与,有很多种分类的方法,如下图中是分为Good(下个迭代哪些好的方法可以继续保持),Could Bette”(下个迭代可以哪些地方可以做得更好),Improvements(新的改进的具体想法)。可以采用“有限投票”的方式,每个成员有5票(比如小磁贴或直接记正字),大家共同选出团队层面需要重点改进的。其实投票未排进Top的改进,如果不需要组织和团队来推动,个人也可以实施的改进,也应该支持。

  

  d) 确定措施——想清楚就干,才有诚信。识别了重点的改进项,为每一个改进项指定计划,执行的措施,需要更高层面去解决的措施需要单独列出来,项目Leader会后要发挥“死缠烂打”的精神去骚扰领导了,同时每个改进措施都应该明确一个责任人,如果没有明确的责任人,大家都会认为是别人的事情。


  e) 结束会议——果断结束,绝不拖泥带水。将会议中达成共识的措施和计划整理记录下来,如果使用了敏捷管理的工具系统,可以直接输入到系统中,记录为Story或者任务。


  来自实践中的一些坑和雷


  1.不持之以恒


  几天打鱼几天晒网的可不行。


  2.理想主义


  团队级的回顾会议应基于现实,而非理想,或者说理想可以有,诗和远方也可以有,但是回顾会议还是应接地气。


  3.沉迷于细节


  程序员有的时候特别认真,容易把问题引入到技术细节,这样会导致议题发散。


  4.只开会,没有吃的,好饿


  皮一下,为了调节会议氛围,可以准备些吃的,补充能量,大脑才能激发。


  最后,每个迭代回顾会议,都不要忘了感谢自己,也不要忘了感谢为了心中教堂而努力的所有团队成员。


  作者|刘恒 华为云DevCloud项目管理服务产品经理

责任编辑:王兴钊

标签:敏捷
0
版权声明©
本网站所有内容版权归项目管理评论杂志社及相关权利人(本网站的资料提供者)所有,未经项目管理评论杂志社明确书面许可,任何组织及个人不得复制、转载、摘编本网站的内容,也不得在本网站所属的服务器上做镜像或以其他任何方式进行使用。凡未经许可擅自转载,均视为侵权行为,本网站将依法追究其责任。
热点:ppp    新能源    敏捷   
官方新浪微博
关于我们 - 广告服务 - 联系我们 - 诚聘英才 - 隐私声明 - 杂志订阅 - 在线投稿 - 下载专区 - 网站地图
项目管理评论 版权所有
有意与本刊合作者,请与项目管理评论联系。未经项目管理评论书面授权,请勿转载或建立镜像,否则即为侵权。
合作电话:010-58383379 E-mail:pmr@pmreview.com.cn 京ICP证13028000号-3

京公网安备 11010202007990号


PMI, PMP, PMBOK and the PMI logo are registered marks of the Project Management Institute, Inc.

技术支持:原创先锋_北京网站建设