敏捷改进中的隐藏循环

　　今天团队应邀请去参加了他们的敏捷目标讨论会。团队最近重新进行了人员重组，招收了一些新人加入。大家坐在一起，商量下一阶段团队的敏捷改进目标是什么。

　　会议做了精心的准备，Master引章据典，罗列了很多很多的改进方向，敏捷方法，度量指标，实践方法等等。不过大家在讨论改进目标的时候，往往举出的例子都是做一些具体的工作。或者是做一些用户已经要求过的功能，或者做一些团队自己认为的减少Bug的工作，如空指针的预防，或者是一些功能的性能提升。Master做了一些引导，说要有一些数据指标，于是要求大家录入工时，做一些质量统计，把JIRA提供的图表都要用上等等。

　　讨论了一会，团队自己感觉这样的一个点一个点的去改进，看不出团队最终要达到什么目的。于是询问到底应该怎么设定目标。

　　现场手绘了一个草图，包含了两个循环。一个是简化之后的精益创业循环（迭代循环），另一个是（经常被大家忽视的）改进循环。见下图：

　　上面的迭代循环就基本上相当于之前团队进行的项目开发工作（无论是类瀑布式的，还是敏捷式的），在这个循环中只要能够保证进行充分的用户调研（访谈／脑暴）就基本能够保证做出的东西是用户想要的，在这个循环中进行正常的度量（如：进度，质量）和控制就可以保证循环基本可以转起来。很多的团队在改进过程中就只是把上面这个循环建立起来就认为自己完成了敏捷改进。

　　但实际上，一旦初步改进结束，教练退出团队之后。很快团队就会回退，直到最后只跑了一个敏捷的形式，虽然还在转迭代。但很难说那是真正的敏捷了。

　　为什么会这样？主要的原因就是这样的团队忽视了建立下面这个循环，改进循环。这个循环围绕着改进的Backlog开展。在回顾会议的时候，团队通过迭代度量的数据来判断是否需要进行RCA分析。如果需要的话，团队在下个迭代安排时间进行正式的RCA分析。通过RCA分析找出存在与价值流程、质量流程、进度流程和管理流程中存在的问题。通过这些问题，识别出主要的流程问题以及相应的改进措施和度量措施，并加入改进的Backlog。然后在下个迭代中启动改进。

　　在改进的过程中，不断的度量改进的效果。比如：

　　－迭代度量本迭代的剩余Bug数量，而改进度量则度量每迭代的Bug数量是否持续下降；

　　－迭代度量进度是否比计划延迟，改进度量是否Story／Bug的完成时间在持续缩短；

　　－迭代度量每迭代提交的多少价值点，改进度量衡量没迭代提交的价值点是否持续提升。

　　通过改进度量的持续进行，让团队可以实时了解改进效果。并将改进度量数据作为回顾会议的重要输入，通过对于这些改进数据的分析，团队来判断是否需要在价值提升、质量提高或进度加快这些维度上面进行RCA分析，或者直接得到改进措施。这样伴随着迭代循环，改进循环也持续旋转，有了这两个闭环的建立，团队才算完成了初步的敏捷改进。

　　所以，回到团队询问的问题：到底要设立哪些改进的指标？其实，敏捷改进不是设立几个改进指标就可以完成的，而是需要明确建立完整两个循环：迭代循环和改进循环。为了建立这两个循环，根据团队的实际情况，分阶段设立不同的改进目标和指标，逐步实施改进。最终达到完成建立这两个循环的目标。

　　那为什么敏捷改进没有达到Being　Agile的程度，一个可能的原因是忽视了改进循环的建立，另一个原因是团队的管理者没有给改进循环分配足够的资源，包括：时间，人员，设备和技能培训。

　　只想着建立迭代循环就得到良好的回报（质量提高，进度加快，价值提升）基本上是痴人说梦，南辕北辙了。