华为敏捷DevOps实践：产品经理如何开好敏捷回顾会议

你们好，我是华为云DevCloud项目管理服务的产品经理 恒少：）

做为布道师和产品经理，出差各地接触客户是常态，常常和华为云的客户交流、布道、技术沙龙，可是线下交流，覆盖的用户总仍是少数。我但愿借助线上的平台，和用户持续交流华为在研发效能提高上的思索和考虑。

<恒少出品，必然妥妥干货，一定理论联系实践>，由于软件无银弹，探索始终在路上

-----------------------干货分割线--------------------------------------

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

全员都参加的回顾会议，其实就是但愿能经过全员视角，全员的观点来回顾作的好的，作的很差的，改进之。从敏捷宣言，到敏捷的诸多实践（如Scrum），到DevOps，都一直提倡回顾这种形式。

其实回顾这种形式，并非敏捷/DevOps专属的，在华为最先的CMM流程中，也有相似的活动。有时候团队碰到域郁闷，痛苦的时候，还会主动自发的开。

因此，回顾，我一直认为这是人类做为一个智慧物种相比其余生物的一个重要区别。我有的时候回经过回顾会议来判断这个团队会不会成功。最极端的，若是甚至都没有人想着要约你们一块儿回顾，这个团队极大几率要88了。

华为内部不只研发交付团队，连一线的市场团队，在重大的市场项目，交付项目的过程当中都会按期进行回顾会议，算是华为内部这么多年积累的一个很好的实践。

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

1.不是“回溯”。“顾”和“溯”一字之差，在中文的语境中，却会致使变成刨根问底。

2.不是“批评与自我批评”。“批评与自我批评”是一个很好的形式，可是会致使团队陷入一种没必要要的紧张和犯错感。

3.不是“问责和处罚”。软件的不肯定性，不可见性，复杂性，易变性决定了软件开发过程总会有些磕磕盼盼，咱们提倡的是改进，不是惩罚

从华为这么多年的实践来看，上面的三种状况都出现过，因此提醒你们要当心。

这么些年实践过来，咱们发现出现以上状况，也是由于步子走得太快，低头玩手机^_^，忘了“回顾”的初心：

1.For a better future;

2.Learn from past;

3.Take action in present.

回顾会议的基本原则

1.对事不对人。举个例子，咱们能够说“代码评审不充分，因此代码缺陷较高”，不能说“某帅哥评审不认真”，固然夸人帅仍是能够的哈^_^。

2.聚焦于下次可否作得更好。还举一样的例子，咱们能够说“这个迭代代码评审不充分，下个迭代咱们怎么才能保证更充分的评审”。

3.从系统角度思考改进，而非我的。咱们能够说“团队的工做安排上，导向上是否是不重视代码评审？”。

回顾会议的Step by Step

1. 肯定参与人（Who）

a)团队全部成员都参加。

b)领导是否参加，试状况，若是领导参加利大于弊，就邀请，不然仍是算了^_^

c)若是是重大的项目发布或项目结束的回顾会议，还应该叫上全部对项目有付出的成员。

d)建议指定一个会议引导人，能够是敏捷教练，也能够是团队成员轮流（团队成员建议熟读本文）

2.选择合适的场所（Where）

a)若是条件容许，离办公位尽量远一点，避免有同窗中途又回去处理工做了

b)尽量不要使用传统会议室的布局，围坐一个大桌子那种很差。能够拉几把椅子围成一个半圆形。

c)须要有白板，或者墙壁能够贴个大白纸

 3.准备回顾的内容（What）

a) 准备上个迭代的客观数据，特性、需求、缺陷等数据，若是使用了像DevCloud这样的敏捷管理工具，准备数据其实很快的，甚至不用特别准备，现场打开就能够，相似以下这样

b) 团队成员上个迭代的感觉，能够认为是主观数据的收集。

c) 每日站立会议的要点。每日站立会议中都会提出并跟踪解决一些问题，回顾这些问题也能够帮助咱们审视过程当中的状况。恒少以前专门写过如何开好站立会议的实践文章《华为敏捷 /DevOps 实践：如何开好站立会议》，能够参考。

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

  4. 回顾会议的过程（How）

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

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

c) 提出看法——咱们如何才能作得更好。能够经过头脑风暴，全员参与，有不少种分类的方法，以下图中是分为“Good”（下个迭代哪些好的方法能够继续保持），“Could Better”（下个迭代能够哪些地方能够作得更好），Improvements（新的改进的具体想法）。能够采用“有限投票”的方式，每一个成员有5票（好比小磁贴或直接记正字），你们共同团队层面须要重点改进的。其实投票未排进Top的改进，若是不须要组织和团队来推进，我的也能够实施的改进，也应该支持。

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

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

来自实践中的一些坑和雷

1.不锲而不舍。那什么几天打鱼，几天晒网的可不行。恒少，恒少，就是能锲而不舍，哈哈。

2.理想主义。团队级的回顾会议应基于现实，而非理想，或者说理想能够有，诗和远方也能够有，可是回顾会议仍是应接地气。

3.沉迷于细节。程序员有的时候特别认真，容易把问题引入到技术细节，这样会致使议题发散。

4.只开会，没有吃的，好饿。皮一下，为了调节会议氛围，能够准备些吃的，补充能量，大脑才能激发

最后的最后，每一个迭代回顾会议，都不要忘了感谢辛苦码代码的本身，也不要忘了感谢为了心中教堂而努力的全部团队成员。