一、概要
本文介绍了东软集团汽车电子业务的某项目通过九个月的敏捷辅导过程，在项目的交付效率和交付质量上取得的成果。具体达成了以下几个方面的目标:
1、打版周期缩短75%。
2、任务按期达成率提高20%。
3、团队成员开发能力显著提高。
4、团队测试用例通过率提升10%。
5、团队沟通效率大幅提升。
6、培养内部敏捷教练一名。
二、项目背景
2017年初，由某中心负责人发起的敏捷辅导需求，希望针某产品线进行敏捷辅导。主要是从任务管理相关的问题进行改善，具体改善目标需要跟团队进行确定。
团队初期状况
该项目是面向汽车开发车载设备以及内嵌的软件系统。涵盖硬件、软件、操作系统、第三方供应商等多方面的项目内容，我所辅导的团队主要负责产品中的软件部分功能研发。
该产品团队历时多年，产品型号和版本不断向前演进，开始平台化开发，由于继承了过去汽车电子生产制造开发的经验，团队一直采用瀑布式的矩阵管理。开发产品线由多个模块小队组成，每个产品都涉及各个模块小队的支持和配合。同时从大的产品线角度，产品管理、需求管理、硬件设计开发、软件研发、产品测试等环节都各自管理各自的阶段形成一个大的瀑布结构。
随着团队开发的推进，团队管理中的一些问题开始凸显，在2017年3月第一次接触的时候我们参与了团队的一次规划讨论会，团队集中在讨论关于版本管理以及发版相关的问题，同时也表示目前团队的状态疲于奔命，而且不知道目前有多少任务沉在水下，大家只能集中精力处理好目前紧急的任务。同时团队还经常被各种客户依赖打扰，无法专心前进。
团队痛点：
会议时间长且低效，并行任务多，临时任务频繁，质量问题严重。
痛点分析：
矩阵式管理结构下的沟通不畅。任务并行，临时任务多，增加交付压力，任务负荷高，导致无心关注质量，代码质量差，缺陷多。
三、现状调研
基于以上掌握的基本情况，开始进行了逐步的深入调查，进行调研访谈，并设计后续的辅导方案，敏捷导入和辅导细节。
导入敏捷-精益思想
面对以上提到的各方面的问题，以及近期迫切希望改善的痛点，初步进行了试探性的小规模的导入培训。培训重点是实现以下几个简单的目标：
1、让大家了解精益-敏捷思想
2、结合敏捷精益的一些理念，来看目前团队的现状和主要冲突
3、找到几个大家都关注的问题，一起来讨论，分析当下有没有可以尝试着做出改变
最初找到了几个大家关注的焦点问题：
1、太多任务被打断，作业并行
2、临时任务频繁、都是高优先级
3、会议效率低，浪费时间
根据以上问题，大家进行了深入的讨论并提出了一些可行的办法尝试改变，包括：
1、提前告知可识别的问题及资源依赖
2、临时任务优先级管理
3、日常开发任务管理
4、提高会议效率，限制会议时间，明确会议目的及加强会前准备
同时大家也达成了共识，希望在后续的工作中，对以上让大家头疼的问题进行关注和改善。
深入访谈
与导入培训同步进行的调研工作就是团队成员访谈，根据之前的接触以及在培训中大家的反应、与产品负责人和项目经理的沟通，确定了几个在团队中的关键成员进行一对一的访谈。包括经验丰富的产品经理、开发骨干、集成小组、开发组长等角色。重点访谈当下他们的状态，希望这个项目在哪些方面有一些改变，为了做出这些改变，他可以做一些什么，对这个项目，每个人都有什么想法和建议。
通过访谈，基本了解了项目的现状和痛点，以及大家最关心的问题。访谈的过程中，逐渐发现了一些在冰山下面的东西。在培训和会议的过程中，大家碍于各种限制和不希望太突出，而没有直接表达的各种想法都在访谈过程中挖掘出来了，包括对项目的期待，曾付出的努力，希望这些努力如何转化成交付的能力，对于目前一些问题的深刻思考等等，与冷冰冰的集体会议相比，面对面的访谈更有激情和期望，也更有建设性的观点和思考。在客户关系的改善、重新建立信任关系、问题处理的流程、开发模式调整、新工具引入等方面都提出了独到的见解。
四、辅导方案及目标
基本辅导方案：导入敏捷思想及精益看板管理，敏捷会议，提高沟通效率，实施精益看板，提升交付能力，有效的管理临时任务，组织开发骨干进行开发技能工作坊，带动开发能力提升，内部培养1名初级敏捷教练。
在这个过程中产品负责人也提出了很多期望和建议，由于管理这个产品已经很长时间了，希望借这个机会成为新的起点，让团队成员有一个新的转变。最终确定下来以下几个目标:
1、强化任务管理能力，建立周期性的任务梳理和跟踪流程。
2、对临时任务进行重点管理，对临时任务进行跟踪管理，识别，标记跟进。
3、提高团队的整体交付能力，度量指标体现在lead time的缩短。
4、提高产品线对客户需求的应变能力和适应能力
具体的措施行动措施，决定从小处开始，比如最简单的早会、之后逐步引入其他实践和工具，培养团队敏捷意识。鉴于目前的状态，组织结构调整不在考虑方案之内。近期交付压力依然很大，希望能小步先跑起来。
五、辅导起步
从一个点开始
我们常说如果给我一张白纸我肯定能规划好，但是往往事与愿违，这个团队也有着很特殊的背景，在访谈中了解到，这个团队曾经有一个敏捷教练带着大家玩敏捷，开站会，用看板，热闹了几天，等到敏捷教练离开团队的时候，这些都没再继续，总结说来就是这一套只能装装样子而已，毫无意义。
重新建立信心成了一个拦路虎挡在面前，因此最迫切的是找到一个点，让大家重新相信敏捷和精益是实实在在的东西，而不是口号和形式。按照团队负责人的说法就是，如果2017年底团队还在坚持做敏捷，那就算成功了（当时是在2017年3月初）。可见信任都需要重新培养。所以第一个改变就是从早会开始！早会习惯能建立起来，是这次辅导的需要打响的第一枪。
看到转变建立信心
团队之前也每天开一个沟通会，通常是在下午4点30分左右，在会议室开30-50分钟的一个沟通会，参会者是：产品经理、项目经理、开发组组长、产品线负责人。在参与了几次之后，大概了解了常规的过程和模式，以及为什么需要开这么长时间。所以和团队在早会问题上达成了一个新的共识，我们尝试换一个方式，看看会不会更好。在大规模敏捷实施框架中也都有早会的一些建议和模式。我们采用了2级早会的模式，需要确保必要的沟通和信息同步有效传达，同时能大幅提高会议效率。一，小组内先开一个内部早会，形式和Scrum的站立早会形式相同。每个人回答三个问题，然后把收集到的问题和依赖汇总给出席下一个站会的代表，这个代表不是必须某个特定的人来，由每个团队至少出一个代表出席下一个大团队的站立早会。
和第一个站立早会不同，第二个站会是团队代表、项目经理、产品负责人参加的，产品经理可以自行选择是否出席。每个站会都是15分钟内结束，只同步依赖，提出问题，不对具体问题进行讨论，对需要展开给全员了解的信息明确如何获取以及具体的负责人。
在早会制度的建立过程中，最先遇到的挑战是，由于加班比较多，大家早上可能没办法准时参加早会，为了确保珍惜大家的时间，团队全员做出一个承诺，就是尽可能准时参会，遇到特殊情况无法参会的需要在微信群请假。
为了大家能准时参会，还借用了其他敏捷教练在早会制度中采用的迟到罚款制度，每个早会迟到的人都会被罚款1元人民币，而且必须是硬币，最先做出表率的就是产品线负责人，被罚了1元，当众交款。看似简单的规则由于达成了一致的承诺和检查措施，惩罚措施，很快得到了良好的执行，也这是早会制度的一个小技巧，娱乐性和趣味性十足。
后续大家建立了早会的习惯之后，这个措施不再那么有效了，团队内自己发明了一些更有趣的规则，让早会变的轻松有乐趣。让每次早会的时候大家都玩起了奔跑吧兄弟！
在这个过程中，敏捷教练的引导和支持很重要，让大家明确早会的目的，提高早会效率。非常重要的一点是，如何建立团队信心，打破既有的走过场的魔咒。通过早会大家开始建立了可以转变的信心，我们是玩真的！
同时早会的有效进行大幅的提高了沟通效率，每个人都从中获得了收益。这也早会制度能得到大家支持原因，并保持至今。
六、引入看板实践
在建立了早会制度之后，日常跟进的任务基本浮现出来了，大家发现了很多之前没关注的，被遗忘的任务，就是我们常说的水面下的冰山。同时开始以精益的思想为指导，提高团队交付能力，缩短交付周期。
看板管理
团队早期使用过看板，团队称之为贴字条，把任务贴上去，挪来挪去。除了浪费时间也没什么意义。既有经历让团队认定，这玩意不可靠。在初期导入简介精益的时候，我把看板的知识也一起做了概述，让大家有一个新的认识。看板，不只是小纸条，还能发挥更多的作用。就好像一把武器，看似都一样，但是想让武器发挥威力，需要对武器有正确的认识，并且能正确的使用它。我们采用了分步走的策略，不是第一步就把看板都用对，而是通过逐步完善的方式，让看板根据团队的使用节奏逐步演化。
具体步骤为：
1、简单的任务板。在看板上黏贴简单的任务条，只有任务名和优先级等简单信息，通过移动任务条的位置标记状态，团队根据优先级处理看板上的任务。这时候我们不区分计划任务和临时任务。只有todo，doing，done。
2、完善任务条信息。让团队提出任条的标准应该是什么样的，还需要补充哪些信息，方便任务的跟踪和梳理。这个阶段任务的更多信息也反映在任务条上了。结合看板中编码/需求/调查/bug任务的统计，每日通过累计流图的方式呈现给全员，透明的展示了项目的整体状况以及各个Team的进展情况，让团队任务可视化。
3、细化看板流程，明确各阶段的DoD（完成的定义）。开发组内的独立任务往往需要很多个阶段才能交付，这样任务在doing停留的时间很长，而且可能涉及到不同的人参与，因此把任务流程进行细分，按照任务实际交付的流程重新设计看板的流程，标记任务所处的阶段，以及该阶段任务完成的标准，使任务状态在看板上更清晰，容易识别跟进，方便团队沟通。发现和识别阻碍以及阻塞。
4、标记资源，限制WIP（在制品）。过去任务多，并行严重，工作效率低，不停的切换任务，同时跟进好几件事。我们采用每个成员最多只有3个代表自己的头像贴，每开始参与一个任务就把头像贴，贴在对应的任务上，如果资源区这个人的头衔贴都用完了，就不能开始新的任务。同时对应的看板阶段也启动WIP限制，对应的阶段最高的WIP限制不高于该阶段人数的1.5倍取整。通过WIP限制来优化任务的流动性，减少任务并发。
5、临时任务管理。临时任务的规则是：临时任务进紧急通道，临时紧急任务每个看板最多只能有一件插入。也就是说每个团队最多只有一个人可能在某个时间点突然被影响，中断手上的工作，跟进临时的紧急任务。紧急任务不能并发。在临时任务的问题上，团队内也一直有很大的争议，产品方主要观点是临时任务必须优先对应，没有商量的余地，客户方要求高于一些。开发团队一侧长期受临时任务之苦，只能被动对应。即然采用了看板管理，那临时任务就必须有规则，所以我们当时做了一个实验，就是先让每个团队只接受一个临时任务的方式进行管理，跟踪2周，看看临时任务的发生概率，以及是否有临时任务因限制，导致无法及时处理而导致问题发生。和预测的正好相反，不但没有发生重大问题，临时任务的发生概率还降低了。
6、停车场管理。当任务出现搁置或暂停时，先放入停车场。定期对停车场中的任务进行跟踪，停车场中的任务需要有依赖描述，什么原因被移入停车场，以及检查时间点，确保任务不会变成废弃车辆在停车场成了钉子户。
7、管理流动性。根据看板上任务的状态来提高任务的流动效率，包括推进任务前进，尽早移除障碍，生成累积流图。通过分析累积流图的状态，关注各团队及整体的流动效率，Lead Time。
在使用看板的同时，关注团队的交付能力的变化情况。关注流动效率，从而提高交付能力，在这个阶段团队的交付效率有了大幅提升，同时团队成员的工作积极主动性也有明显的改善。
七、建立迭代开发模式
使用看板之后任务管理明显有了进步，同时团队也逐渐形成了稳定的交付节奏。维护起发布管理的集成看板。
同期团队开始建立迭代反馈的机制。从过去以交付版本为开发节奏，改为更短交付周期的开发方式，包括以周为周期进行任务管理和产品版本构建（这一活动以前虽然也没隔一段时间进行，但是很少正式以周期进行管理和验证），形成稳定的节奏。每周都会梳理下周的任务清单，并由团队来进行团队任务集体估算，并与产品经理进行沟通达成一致。每两周进行一次团队回顾，进行团队反思学习。不断冲刺前进，停下来回顾反思学习，再冲刺。迭代前由产品及需求方提出产品线的任务清单。
PM制定的工作计划
各小组对各自任务的估算
迭代接近尾声时进行内部演示和评估，对需求进行验收确认。并开展小组回顾和大团队集体回顾。
团队回顾会议。参加者有产品经理团队、项目经理团队，开发组全员、集成小组、产品负责人，共同就前面的2周进行回顾，找到大家都关注的问题或成果进行分析或学习，产生切实可行的改善措施，指定负责人进行跟进。产生改善项的跟踪表。
八、持续改善
习惯的建立
大约经过半个月时间的早会制度，团队基本可以高效的完成早会活动，同时充分利用早会时间进行依赖告知、问题同步和计划会议外临时问题的协调。
在这一过程中也发生了一些有趣的问题，比如作为项目经理和产品经理，产品负责人的角色。从管理心态转变为支持服务心态，不再是任务的发号施令人，而是成为推动者、支持者、协调者。团队中的产品经理喜欢把问题反复强调，描述细节，早会发言时间过长，大家就发明了，一分钟限制，不管有多少事情，要在一分钟内表达完毕，就像我们说的电梯演讲，超时人员要接受团队的一个小惩罚，像这样的小而有趣的事情让团队成员逐渐养成了参与，思考，改善，行动，反思的习惯。从早会、到看板、计划会议、回顾会议、迭代梳理等环节，大家都开始出现了转变，不再是传统思维，只是听命令，开始更多的思考和互动，并且以交付为目标，集思广益一起推动。
团队持续改善
在敏捷辅导进行到2个月的时候，团队内的看板的使用逐渐流畅起来，行累积流图数据上也可以看出，任务并发逐渐下降，交付速率开始提高。同时大家都体会到团队士气开始出现转变。在敏捷辅导的过程中，可以感受到很多变化，例如大家参的积极性，计划会议上的积极沟通，回顾会议上的积极参与，思考等等。团队设计和达成了一些新的规则，包括：任务管理流程，各团队间的交流接口，明确的交付标准，各任务阶段的DoD（完成的定义），计划会议输出标准等。这些共识的达成，都是团队自发的，通过团队自身改善意识的建立，逐渐体现出来。
九、总结与反思
敏捷辅导的变化
经过9个月的敏捷辅导工作，产品线的交付数据统计如下。
整体作业状况：
从整体作业状况可以看出自从引入敏捷开发两个月之后，从八月份开始作业整体完成量150件/月，投入开发的作业量95件/月，残作业与进行中的作业以每月55件递减。形成稳定的交付节奏。
测试用例通过率：
总结达成了以下几个方面的目标:
沟通效率提升：团队内沟通效率提高，过程改善等方面能力显著提升，仅早会一项改善节省成本11个人月。
任务管理能力：个别团队任务完成率100%，提升任务完成率提升20%。团队专注迭代目标，临时任务减少70%。
交付能力提升：交付周期提升75%。降低反馈周期，提升交付能力。
代码质量提升：通过推动项目成员代码质量意识，加强代码质量管理过程，消灭findbug问题3000+件。
测试质量提升：整体测试用例通过率提升近10%，quick check问题数降低50%，进一步提升交付质量。
人员能力提升：培养敏捷教练一名。
更多的反思和挑战
在辅导取得一定效果的同时，也引发了更多的思考。包括：
如何在同类型产品线的敏捷快速拓展和复制？
如何培养团队内的敏捷教练，进行自我造血？
如何解决目前依然是矩阵式管理模式必然存在的一些依赖限制？
如何转变交付模式，变被动为主动，引领客户需求？
如何进一步提高交付能力？
开发团队如何通过提高自身能力应对产品不确定性带来的挑战？
这些都是我们希望通过团队自身的思考和集体支持一起面对的挑战。
本文来自微信公众号“东软卓越效能社区 ”（ID：neusoftecoe），作者 王磊。
管理圈经授权转载，如需转载请联系原作者。
粤公网安备 44010602010970