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