继续继续~~~
同学们都知道软件项目的过程其实就是一个不断踩坑和填坑的过程，这些踩过的坑，有的是前人留下的，有的是自己挖的，不管是哪里来的坑，如果不赶紧填上，自己以后踩了不算，还会连累后续接手的团队遭殃。所以我把这一式命名为 那些天 我们踩过的坑。而填坑动作，在我看来就是持续改进，所以这一式要讲的是敏捷项目中持续改进的实践方法。
需要先声明一下，这篇文章里提到的回顾形式，除了复盘会，其他都是来源于《敏捷回顾实战》这本书，这本书的中文版还没有出版，是圈里一个叫王存浩的同学自己组织一群有热情的小伙伴们翻译的，翻译完了之后又很无私的分享给其他圈子里的同学们。而我非常有幸的成为了这个翻译版的第一批读者。
这是参与翻译这本书的同学们：
翻译：王存浩，周嘉敏，余旭峰，杨莹，李希兰，朱明，钟明，徐亚平，
王如夫，卜夙，黄雅琴，杨贵，周伟峰，陆炜，陈艳艳
编辑：陈艳艳，王存浩
审校：王存浩
就我个人的认知而言，在项目中贯彻持续改进是敏捷项目中最重要的实践，没有之一。持续改进是敏捷项目的灵魂，没有落地持续改进实践的项目，没资格被称作为一个敏捷项目。如果没有持续改进，一个项目即使在成员足够牛X，领导足够睿智，市场足够宽容，资金足够充裕，运气足够好的情况下，它最多也就是一个达成目标的成功项目，但它绝无可能成为一个成就伟大产品，伟大团队的伟大项目。
然而，再就我个人的经验而言，持续改进又是在一个项目中最难落地的一个实践。它难不是难在改进，而是难在持续。在之前的很多项目中，我也定期的组织回顾会，通常的历程是这样的：第一次，大家找到很多改进点，然后去改进；第二次，还是能找到一些改进点，但是比第一次会少；到了第三次，最多第四次，基本就找不到改进点了；然后连续几次回顾会都不再有改进措施出现，再加上本来工作压力就不小，这件事情对团队而言也就没有动力再持续下去了。
基于这个情况，我思考得出的结论是，如果发现不了改进措施，那么团队就会对回顾活动产生心理疲劳而不再重视，那自然也就难以持续了。然后我再审视以前那些改进项，我发现这些改进项针对的问题都相对比较明显，比如说某些逃逸的BUG，某一次沟通障碍，容易造成曲解的DOD，不合理的work calendar，或者一些缺失的规则，等等。当这些问题都改进了之后，对团队而言，确实是没有明显存在的问题了，那自然也就提不出改进措施了，提不出改进措施，那自然也就难以持续了。所以，我又得到另外一个结论，要持续改进，我们需要发现更多的问题。
有了这样的思考，我就尝试去发现项目中各种潜在的问题，但是坚持了没多久就知道这样做不对，因为如果我陷入到项目的具体事务和细节，哪儿还有时间去引导和帮助团队成长呢，况且团队的知识总和一定会比我更多，我应该激发团队成员自己发现问题的意愿。只有更多的人真正的去寻找问题的时候，我们才能发现更多的问题。
那又如何去激发团队的这个意愿呢？光靠说是没用的，持续改进这四个字已经被叫了几十年了，早就审美疲劳了，必须要有具体的行动才行。
我首先尝试的是在我所在的团队里（10个人，各自负责不同的领域和项目）定了一个规则：任何人，任何时候都可以针对一个具体的问题发起复盘会，复盘会的过程很简单：第一步，按照时间顺序重现历史；第二步，针对每一个时间节点上发生的情况，通过“如果我们当时做了什么可以改变现状？”和“我们当时应该做什么？”这样两个问题得到针对这个环节的改进措施；第三步，收集每个环节出现改进措施，作为针对这个具体问题的整体改进方案。
这个实践也利用了一下同伴压力，我们会把团队中所有的改进方案都记录下来并公开，让每个人都看到团队里哪些人发起过多少复盘会。
我们期望通过复盘会机制来达到三个目的：
不放过任何一个问题，即使我们能发现更多的问题，但是如果这些问题都从指缝间溜走的话，那发现问题也没有意义了。
激发发现问题的意愿，利用同伴压力激发团队发现问题的意愿。
养成发现问题就及时改进的习惯，我们希望通过这样的规则，可以让团队成员把持续改进落实到行为习惯上。
就目前效果而言，总体上还不错，自制定这条规则的2个月以来，在不同的项目中已经发起了8次复盘会，总共已经有20多条改进措施。
但是这样还不够，我们需要更多的人员参与到这个游戏中来，我们需要更多的发现问题的手段，我们需要把持续改进作为项目日常的一部分去执行，把它变成一件不做就觉得哪里不舒服的事情。然后，《敏捷回顾实战》这本书让我如获至宝。
《敏捷回顾实战》这本书里，总共列了大概100种开展回顾会的实践形式，我针对每种形式都脑补了一下，坦率的讲，并不是所有的形式我目前都认同，有可能这些形式确实不适合我当前所处的环境，也有可能是我的认知和理解还没到达那个境界，具体哪种形式适用，哪种形式不适用，每个人都会有自己的判断，我的判断只能代表我自己的，所以还请有兴趣的同学们自行去阅读这本书。你们可以找到“敏捷回顾实战”这个群，加入后请王存浩发一份电子版给你们，他人很好，应该不会拒绝。
以下内容大多来自于《敏捷回顾实战》，不是我的原创内容，只有点评部分是我的个人见解。
回顾形式-1 画出迭代
简介：通过玩“你画我猜”的游戏让团队成员理解其他成员对上个迭代的感受。
方法：让团队成员每个人通过画画的方式画出
迭代期间自己的感觉如何
自己觉得最了不起的时刻是什么
自己觉得最大的问题是什么
自己最渴望什么
每个成员不必画出所有的主题，自己挑选一个或几个就可以，都画好了之后把所有人的作品都展示出来，轮流让大家猜自己画的是什么。这种隐喻的方法可以帮助团队开辟新的视角去发现问题和达成共识。
回顾形式-2 幸福柱状图
简介：创建一副幸福柱状图来引导团队讨论
方法：准备一张活动挂图，水平画一条幸福指数线，从1到5标上刻度
每位团队成员根据自己的幸福感，准备一张贴纸，写上自己的意见，贴在相应的刻度上
如果意见中有值得讨论的点，可以随即开始讨论
如果后面的同学有同样的幸福指数，就往上放，形成一个柱状图
点评：团队成员幸福感是敏捷中一个重要的指标，没有幸福感，就不会有创造力。这个形式从幸福感出发去发现问题，非常有创意。
回顾形式-3 期望的结果
简介：每个成员说出各自对于回顾会期望的产出
方法：团队中每个成员说出他期望的回顾会的目标，就像开会总要有个会议结果一样。比如：
我希望每次都能有个很棒的行动事项
我想讨论一下单元测试上的争议，并希望今后达成一致的理解
我期望回顾会上可以完成一份糟糕模块的整理计划
...
点评：每个团队成员对回顾会结果的期望的背后，就是那些不易发现的问题。
回顾形式-4 行动事项表
简介：评估和分析具体的行为
方法：创建一个表格
每个参与者在每一列上贴上贴纸，贴纸上描述项目过程中具体的行为，表明应该怎样对待这个行为。之后对每种行为做简短的讨论，比如：
为什么我们要停止这么做？
为什么值得进一步去做？
为什么我们的意见不统一？
达到我们的期望了么？
点评：在原文里这个方法是用于对上次回顾会制定的行动事项进行分析和评估，但是我认为这个方法可以扩展到平时项目中所有的行为上。从行为的维度提供一个发现问题的机会。
回顾形式-5 故事奥斯卡
简介：团队提名获奖用户故事（需求）并选出获奖者。
方法：把迭代完成的故事都贴到一张白板上，创建3个类型的奖（画3个框），比如：
最佳用户故事
最烦恼的用户故事
第三种类型可以留给团队自己去定义
团队要提名某个故事获得某个奖，就让团队把这个故事放入对应的框里。然后对每一个奖项框里的故事进行投票，最后选出获奖者。对于每一个获奖者，问团队：为什么这个故事可以获得这个奖？让团队呈现整个完成故事的过程，并发现哪些环节做的不错，哪些环节还可以改进。
点评：从实际完成的故事入手让团队回顾和发现问题，很好的思路。
回顾形式-6 个体期望
方法：给每个成员发一张纸，纸分成上下两部分，上半部分再划成左右两部分，左边写上团队成员可以期望我做什么，右边写上我期望团队成员可以做什么。每人完成上半部分之后，把纸传递给右手（左手）边的人，收到纸后先看纸上的内容，然后在下半部分写上对纸的主人的期望，并签名。
重复上面过程，知道纸回到原主人的手里，每个人阅读纸上别人的留言，并分享自己的发现。
点评：这个形式可以帮助团队成员更多的了解其他成员的期望和他愿意贡献的力量。也可以发现彼此期望之间的差异，这种差异其实也是问题的来源。
回顾形式-7 四分法
简介：用于识别令人厌烦的事情
方法：先画一个大正方形，分成两列，左边是无趣的，右边是有趣的。然后让团队在便签上写下他们认为有趣的和无趣的事情，贴到相应的列里。然后再让团队成员回忆一下这些事情花费的时间，也写到便签上。接着再在正方形的中间画一条横线，横线以上表示用时短，横线以下表示用时长，这样正方形就分成了4 个象限。再根据每个便签上的时间把便签移动到对应的象限。在“无趣”且“时间长”的象限里的事情，就是将来要攻克的对象。
点评：无趣的事情没人喜欢，还要投入很多时间的无趣事情，就是项目里面的定时炸弹，用这个方法对找出并解决这些定时炸弹应该很有用。
回顾形式-8 写下不可言说的事情
简介：通过静默交流了解彼此
方法：
原则：在整个活动中保持安静，只写不说，活动结束后立刻销毁所有纸张
步骤1：给每个人发一张纸，每个人在纸上写下平时没人敢说的禁忌
步骤2：把纸传给左（右）边的人，阅读者写下自己对上个人的禁忌话题的注释
步骤3：继续传，继续写，直到纸张传回到作者手上
步骤4：作者阅读别人的注释，然后销毁纸张
点评：大家可以表达出平时不敢说的话，并且可以看到别人对这个问题的看法，想想就刺激！这个过程中SM和PO可以不参与在这个过程中，给团队更大的安全感，况且这个形式的重点在于让团队成员通过别人的视角审视压在自己心里的那块石头，所以SM/PO不参加也没关系。不过这个方法在刚组建的团队，或者氛围，士气不怎么好的团队里不要用，很容易会放大团队成员积压在心中的不满和抱怨。
回顾形式-9 阿拉丁神灯
简介：探索团队的愿望
方法：假设有一个阿拉丁神灯，现在请每个人都向精灵许3个愿望：
为自己许一个愿
为团队许一个愿
为客户许一个愿
然后每个人陈述自己的愿望，大家用投票的方式选出最好或者最欣赏的愿望。
点评：这个形式可以发现团队成员内心的愿望，只要是和项目目标有关系的，满足这些愿望就可以作为下一步的改进行动。
回顾形式-10 学习愿望清单
简介：用于发现团队的学习目标
方法：分发纸和笔，每个参与者写下他/她希望团队其他成员学习的内容（不要列出人的名字）。当每个人都完成了，收集和统计所有的学习内容，选择频率最高的前三项作为学习目标。
点评：敏捷团队一定是个学习型组织，然而目前新兴技术那么多，更新的又那么快，要准确的找到一个团队应该投入时间去学习的东西确实不是一件容易的事情。通过这个方法可以从团队成员的需求去找到应该学习的东西。
回顾形式-11 我们怎样去摧毁下个迭代
简介：逆向思维，避开危险
方法：分发纸和笔，提问每个人如何把下个迭代/发布变成一个确定性的灾难，每个便签上写一个方法。当所有的人都写完后，把便签收集起来一起阅读和讨论。接下来就用相反的行动去保证迭代/发布成功。
点评：这波操作我喜欢！
回顾形式-12 打造你自己的Scrum Master/Product Owner
简介：通过团队视角去打造完美的Scrum Master/Product Owner
方法：
每个人描述完美的SM/PO表现出的特征。让大家写在便签上，一个便签一个特征，写完后每个人各自介绍
用同样的方法，描述完美的SM/PO需要知道团队哪些方面
用同样的方法，描述你自己应该怎样帮助SM/PO，才能让他杰出的完成工作
点评：让SM/PO了解团队的视角和想法，也让团队能相互了解自己应该怎么做才能发挥SM/PO最大的作用。
回顾形式-13 假如我是你
简介：找到每个子小组提高的方法
方法：把团队分成各个子小组，比如BA/开发/测试，每个人只能属于一个子小组。每个人都写下自己认为会对其他小组会造成负面影响的行为，一个便签一个行为。然后每个人轮流读出自己的便签，并交给受影响的那个小组，受影响的小组通过讨论对每个便签做出评分，评分从0（不是问题）到5（是个大问题）。这样每个人就能知道其他人的理解和想法，然后从中选出下个迭代要改进的部分。
点评：可以有各种各样的手段去达到充分沟通，加深理解的目的，这种方法可以从审视自我出发，了解团队其他成员的想法。
以上是我第一批准备采用的回顾形式，列出来供同学们参考。我认为这一顿猛如虎的操作能非常完美的满足通过更多的手段去发现更多的问题这个目的，而且这些实践易于理解，易于执行。当然这并不是说其他实践不好，第一批找到13种形式已经够丰富了，换着花样玩至少能玩上大半年。然而实际效果到底怎样，也得真正用了之后才能知道。
持续改进几乎是所有管理思想的重要内容，PDCA戴明环，丰田的KAIZEN，TOC里的改进五步法，6 SIGMA，CMMI，ITIL，等等等等。对企业而言，持续改进是成本最低，收益最高的实践。然而有多少企业，有多少组织，真的的把持续改进做好了呢？
我基于自己在软件行业里的实践，基于自己有限的认知，对于持续改进这件事做了这样的总结：
别挂在嘴上，行动起来
激发团队成员的改进意愿，是管理者最重要的职责
简单的规则，轻松的氛围，越是重要的事情，越是需要举重若轻
问题是改进的源泉，管理者需要去寻找更多发现问题的方法，手段和形式
持续改进的最高境界是从来不讲，但是一直在做
粤公网安备 44010602010970