船长的 “ 持续改进” 抓手

不以解决问题为目的的敏捷就是耍流氓，这句话你同意吗？

不要说因为敏捷要求这么做，所以我们就这么做！

不要整天把“敏捷”挂在嘴边，只要不停的去解决问题就好！

只要今天比昨天好，这不就是进步吗？

为了能够不停的解决问题，就要不停的去发现问题，找出问题的根本原因，制定行动计划！

这是什么？这就是回顾啊！

然而很多小伙伴最容易抛弃的就是回顾会，因为它不直接产生代码，不直接贡献于眼前的交付物，在所谓的时间紧张的情况下，唯一牺牲的就是回顾会！

回顾（会）的成果是最实实在在的抓手！这个成果包含但不限于如下几点：

• 问题

• 根本原因

• 解决办法

• 行动计划

• 责任人

• 期限设置

你要确保每个迭代（或者定期）都能拿到这个单子！为确保落到实处，注意以下几点：

• 所有的问题集中存放，统一维护，每个迭代的问题都维护到一起，并混合排优先级，就像是维护Backlog一样。

• 确保问题解决了就不再犯，稳步前进！

这样做的好处是：

• 很多问题不用重复提出，节省时间！

• 容易监控有些问题是否重复出现！

• 容易看到我们曾经提出过哪些问题，解决了哪些问题，能够看到我们的进步，也能够做各种分类和统计。

我们的功能需求用任务板来跟踪，同样的，改进项也要用“改进看板”管理起来！

在墙上或白板上贴出改进项，设置状态栏，实时挪动卡片，以体现改进项的落实情况。

To Do这一列是空的，就是SM的问题！SM的重要责任之一就是牵头和团队一起识别改进项！

Done这列卡片的数目长时间不增长，也是SM的问题！SM的重要职责之一就是推动团队的持续改进！

说一千到一万，“改进看板”搞的如何，非常大程度上体现了SM的工作绩效和状况！

那么我们改进的怎么样，距离我们的改进目标还有多远？这就要用到度量了！

有些小伙伴以前困惑不知道度量什么，现在知道了吧！你要查看哪些改进项的改进效果，就做相应的度量！千万不要为了度量而度量！

所以我辅导团队的时候，我一般不会给出大量的标准度量模板去给团队填写，这样大家就有可能不动脑筋了！

我一般会问团队一堆的问题，引导团队自己考虑从哪些维度评估或者评价团队的工作状况，或者需要解决团队的哪些问题，从而自己找到度量方法以观察改进效果。

一旦通过度量结果，看到我们的改进取得了不错的正向效果，我们就可以对过程进行相应修改，将其制度化，成为组织过程资产的一部分！当然有些修改只适用于特定的团队，有些是适用于更广泛的组织，要慎重归类，以防有出现副作用！

重复第2-5步，永远不要停歇！

无论你是在使用传统方式还是用敏捷方式开发，定期回顾，你一定会越来越好！

这也是敏捷的精髓之一！