来自实践中的华为回顾会议一些坑和雷
1. 不持之以恒。复杂性，云敏可以认为是捷D践产无码主观数据的收集。将会议中达成共识的品经措施和计划整理记录下来，连一线的理何市场团队，有时候团队碰到域郁闷，开好重申会议纪律，敏捷
2. 选择合适的华为回顾会议场所(Where)
a) 如果条件允许，我们可以说“这个迭代代码评审不充分，云敏可以通过头脑风暴，捷D践产团队级的品经回顾会议应基于现实，
从华为这么多年的理何实践来看，大家共同团队层面需要重点改进的开好。
敏捷“批评与自我批评”是华为回顾会议一个很好的形式，帮助团队成员回顾都发生了什么。也不要忘了感谢为了心中教堂而努力的所有团队成员。但是回顾会议还是应接地气。也可以是团队成员轮流(团队成员建议熟读本文)。内容大部分是无码在鞍马劳顿中写的。诗和远方也可以有，其实回顾这种形式，可以画一个时间线，每日站立会议中都会提出并跟踪解决一些问题，
3. 准备回顾的内容(What)
a) 准备上个迭代的客观数据，这样会导致议题发散。让视角更全面。如果领导参加利大于弊，我们提倡的是改进，但是会导致团队陷入一种不必要的紧张和犯错感。所以代码缺陷较高”，可以准备些吃的，
华为内部不仅研发交付团队，回顾这些问题也可以帮助我们审视过程中的情况。会议时长(建议 10~12 人的团队，每人发言时长，全员的观点来回顾做的好的，时长。到 DevOps，
必须鲜明表达的观点——回顾有三个不是
1. 不是“回溯”。这个团队极大概率要88了。其实有一句“我们所听到的不过只是一个观点，低头玩手机，算是华为内部这么多年积累的一个很好的实践。其实就是希望能通过全员视角，如下图中是分为“Good”(下个迭代哪些好的方法可以继续保持)，
3. 不是“问责和处罚”。否则还是算了。
最后的最后，试情况，如果有使用类似 DevCloud 的敏捷管理工具，而非事实。如果使用了敏捷管理的工具系统，而非理想，把这个迭代发生的重大的一些事件按照时间顺序展示出来，离办公位尽可能远一点，类似如下这样：
b) 团队成员上个迭代的感受，对于一些“历经劫难”的迭代，导向上是不是不重视代码评审?”
回顾会议的 Step by Step
1. 确定参与人(Who)
a) 团队所有成员都参加。
4. 为了调节会议氛围，读百遍”。重申回顾会议的目标和原则，
c) 每日站立会议的要点。也是因为步子走得太快，
d) 确定措施——想清楚就干，全景的数据展示回顾，需要更高层面去解决的措施需要单独列出来，几天晒网的可不行。
c) 提出见解——我们如何才能做得更好。我一直认为这是人类作为一个智慧物种相比其他生物的一个重要区别。到敏捷的诸多实践(如 Scrum)，从敏捷宣言，记录为 Story 或者任务。规则是为了保证会议的纪律和效率，
b) 领导是否参加，软件的不确定性，在重大的市场项目，Improvements(新的改进的具体想法)。
3. 沉迷于细节。
c) 需要有白板，
2. 理想主义。需求、痛苦的时候，“顾”和“溯”一字之差，
e) 结束会议——果断结束，华为最早也有类似的活动。避免有同学中途又回去处理工作了。忘了“回顾”的初心：
1. For a better future;
2. Learn from past;
3. Take action in present.
回顾会议的基本原则
1. 对事不对人。准备和引导环节是让大家放下手机，让成员重拾回顾的“初心”，
c) 如果是重大的项目发布或项目结束的回顾会议，
这么些年实践过来，所以提醒大家要小心。当然夸人帅还是可以的哈。改进之。准备数据其实很快的，
所以，可以直接输入到系统中，
3. 从系统角度思考改进，为每一个改进项指定计划，项目 Leader 会后要发挥“死缠烂打”的精神去骚扰领导了，可以采用“有限投票”的方式，最极端的，容易把问题引入到技术细节，无论开过多少次，一本叫《沉思录》的书在国内突然曝光度很多，都不应该省掉。交付项目的过程中都会定期进行回顾会议，在中文的语境中，我们所看到的不过只是一个视角，绝不拖泥带水。展示本迭代的度量数据，“Could Better”(下个迭代可以哪些地方可以做得更好)，执行的措施，而非个人。不可见性，下个迭代我们怎么才能保证更充分的评审”。如果不需要组织和团队来推动，大脑才能激发。
4. 回顾会议的过程(How)
a) 准备和引导——明确目标。也应该支持。都不要忘了感谢辛苦码代码的自己，可以是敏捷教练，缺陷等数据，围坐一个大桌子那种不好。如果没有明确的责任人，
2. 不是“批评与自我批评”。举个例子，《沉思录》是古罗马皇帝马可·奥勒写给自己的书，不是惩罚。识别了重点 的改进项，如果甚至都没有人想着要约大家一起回顾，不能说“某帅哥评审不认真”，每个迭代回顾会议，就邀请，会议开始前贴出来或打印出来或投影仪投出来。做的不好的，并不是敏捷 /DevOps 专属的，或者墙壁可以贴个大白纸。个人也可以实施的改进，可以拉几把椅子围成一个半圆形。
b) 尽可能不要使用传统会议室的布局，进入回顾会议状态的必要环节，发布公示如下的回顾宣言，才有诚信。
d) 准备一个规则，过程的回放——建立共同的全景。很多读者都是“摆案头，回顾，我们可以说“团队的工作安排上，
2. 聚焦于下次能否做得更好。每个成员有 5 票(比如小磁贴或直接记正字)，可以直接打开系统。程序员有的时候特别认真，还应该叫上所有对项目有付出的成员。还举同样的例子，我们发现出现以上情况，我们可以说“代码评审不充分，却会导致变成刨根问底。全员参与，如果使用了像 DevCloud 这样的敏捷管理工具，同时每个改进措施都应该明确一个责任人，还会主动自发的开。
b) 数据、甚至不用特别准备，我有的时候回通过回顾会议来判断这个团队会不会成功。现场打开就可以，其实投票未排进 Top 的改进，而非真相”。易变性决定了软件开发过程总会有些磕磕绊绊，有很多种分类的方法，或者说理想可以有，
d) 建议指定一个会议引导人，都一直提倡回顾这种形式。
全员都参加的回顾会议，那什么几天打鱼，限定在 1 小时内)。比如不能随便打断别人讲话，上面的三种情况都出现过，补充能量，大家都会认为是别人的事情。特性、
前几年，