帮助团队持续改善

从解决实际问题出发与提升团队的内驱力

    帮助团队的持续进步，是敏捷教练的一个重要职责。但是团队的成长不只是敏捷教练的事情，更需要团队所有成员的积极参与。我所面临的很多团队中都存在一个共性的问题：团队成员只关注自己的一亩三分地，很少有成员能够站在团队的角度去考虑问题，促进团队的持续进步。

    经验的积累、能力的成长基本上都是一个发现问题、分析并解决问题、确认改善效果、解决新问题这样的螺旋提升过程。一个非自组织的团队要完成这样一个过程需要强大的外驱力才能顺利完成，敏捷软件开发需要打造一个自组织团队，从一个非自组织团队向自组织团队转变的过程其实就是一个不断弱化外驱力、强化内驱力的过程。

    因此敏捷教练帮助团队持续改善可以从解决问题出发，帮助团队不断完善自身，同时提升团队的内驱力帮助团队走向自组织之路。

案例

    我刚加入所要指导的这个团队时，它是一个典型非自组织团队，严重缺乏内驱力。我只能通过自己不断地访谈、跟踪迭代过程、检查迭代结果来发现问题。

一、发现问题

    很快我就发现了团队存在一个严重的问题：PO、UE和开发工程师都只管埋头做新功能，对缺陷视而不见。在迭代回顾的时候我向团队明确提出了这个问题，要求改善，并在迭代回顾会议上帮助他们制定了改善计划：暂停开发新功能，花一个迭代将所有的遗留严重缺陷全部解决。但是到迭代计划会议的时候，看着他们做迭代计划我就楞了，他们不是在讨论如何集中精力解决缺陷，而是从backlog中选取一堆用户故事开始澄清、评估……迭代回顾会议白开了。

    计划会后我找到部分人员沟通才发现他们觉得遗留大量缺陷根本就不是什么问题，反正项目后期会有时间用来解决缺陷（典型的瀑布开发思想，回顾会议没有否决我的改善要求完全是为了照顾面子）。

二、让团队认识问题的严重性

    很显然，团队在瀑布开发模式的熏陶下，对“经常地交付可工作的软件”的重要性没丝毫感觉。强扭的瓜不甜，要解决迭代质量差的问题，首先要让团队从内心认识到高质量的迭代版本对项目开发的重要性。

在团队内寻找助手

    改变人的观念、习惯是一件很难的事情。敏捷软件开发相关的理念、知识、要求已经给他们培训很多次了，但是效果不理想。一个一个单独做说服工作，那得累死去。怎么办？

    一个好汉三个帮。团队10来个人，总能找到一个能帮助你的人。比如说对敏捷开发理解较深的人、与你有类似想法的人，或者这个问题的受害者，找到他。

    就这次的遗留缺陷过多的问题来说，对团队内谁的日常工作开展阻碍最大？是测试人员。过多的缺陷总是阻碍他们做更深入的测试，但是版本发出去后有缺陷总是说他们没有及时发现；一大堆的缺陷需要他们来管理；到项目后期为了复现并抓取随机性缺陷的log，总是让他们加班到深夜……因此我找到测试人员，与他做了一次深入交流，效果很理想，谈话结束后他恨不得从现在开始所有人都通宵解决缺陷。

扩大影响范围

    坚固的堡垒总是先从内部开始崩溃。仅仅找到一个帮手是不够的，要教会他如何在团队内发挥影响力，将问题的严重性、事情的紧迫感传递给整个团队。这次我们结合理论，从数据出发（横向对比、历史数据、市场投诉、合作团队投诉等等），推演未来。让团队目睹现状，想象项目延期、凌晨下班的痛苦未来。

    花了一天时间，我们一起整出了份漂亮的质量分析报告。接着，我和他一起拿着质量分析报告寻找其他的支持者，最后在迭代回顾会议上由测试人员做了一个声泪俱下的分享……

三、让团队自己寻找解决方案

    测试人员的分享威力很大，基本上所有人都开始认识到尽早解决缺陷的重要性，是时候开始对问题进行分析并提出解决方案了。上次我给他们的方案时停止开发新需求，花一个迭代的时间用来解决缺陷，继续用这个方案？不，教他们问题分析方法，如MECE分析法、头脑风暴，让他们自己找解决方案。一个小时后，他们找到了自己的解决方案：由测试人员将需要立马解决的缺陷进行标记、技术负责人组织代码审查……一套看起来行之有效的解决方案新鲜出炉。

四、方案成果分享并巩固效果

    又是一轮迭代过去，效果如何？成果显著。

    必须让团队保持这种势头，不断改善。怎么办？阶段性成果展示。再一次轮到我们的测试人员出场：数据对比分析，相对之前的进步明显；然后PO出场发表感言：昨天拿迭代版本给老板看的时候演示顺利，没死机，老板少了批评，多了建设性意；展望未来：零缺陷的迭代版本，碉堡死全公司其他团队……

    显然，要碉堡死全公司其他团队不是整风运动能做到的，需要的持续提升。怎么办？ 开始讨论如何巩固效果：将迭代质量分析作为一个固定的环节加入到迭代回顾会议中、每日站会的时候由测试人员报告缺陷情况……

五、解决新的问题

    几个迭代过去了，迭代版本质量得到明显提高，但是PO发现，项目的用户故事燃尽速度明显下降。怎么办？回到老路，不管缺陷？显然不行，但是如果问题不解决，团队在各种内外部压力下肯定会走回老路。提升开发效率迫在眉睫。老办法，理论加数据分析发现大家除了解决缺陷积极、制造缺陷也挺积极的，如果能降低制造缺陷的积极性，应该能大幅提高开发效率，大家都如是想。开始头脑风暴：测试驱动开发、设计评审、结对编程……一堆办法涌出来了。

    最后大家选择了一个性价比最高的解决方案，我们叫它测试点认定。很简单，就是测试、开发以及UE一起就用户故事进行澄清，在澄清的过程由测试人员主导提出开发容易忽略的地方，比如边界值、特殊使用场景等等，帮助开发人员在编码之前尽可能全面地考虑问题，减少制造不必要的缺陷。效果也很显著，总缺陷增长趋势明显下降，用户故事燃尽速度也上来了。

总结

    从上面的案例看，从解决实际问题出发、提升团队的内驱力来帮助团队改善的要点有哪些？

    1、你认为的问题，团队不一定认为是问题。要采用合适的方式让团队认识到问题的重要性，最好引导团队成员自己说出来。

    2、授人以鱼不如授人与渔。直接给方案，不如教他们如何利用敏捷思想结合其他领域相关知识，寻找适合他们自己的方案。

    3、阶段性成果展示很重要。阶段性成果告诉大家，我们的方向是正确的，我们的未来是可预期的，我们的付出是有价值的。

    4、饭要一口一口吃，问题要一个一个解决。就迭代版本质量来说，我们先解决缺陷修复的表层问题，再发现隐藏的软件设计质量不高的深层次问题，然后加以解决。

    5、轻量级的解决方案。测试驱动开发、设计评审、结对编程是能很好地解决软件设计质量问题，但是我们简单的测试点认定效果也不错，代价也不高。

    6、内驱力的产生需要外驱力的引导。敏捷教练要善于在团队内寻找突破点，寻找问题受害者是个不错的注意。要多关注团队内不同角色、不同成员各自工作中受到的阻碍与痛点，以此为突破口，引导团队自己想办法解决问题。