前言
寿险保全组负责支持的是平安寿险的保全支持系统，是寿险后援的核心类系统，系统上线时间已近十年，系统体量大，技术债务重。团队因为每个版本交付的功能量达不到业务要求，需求从提交到上线周期时间超过两个月，而倍受业务质疑。
适逢公司需在传统保险类开发部门选择试点团队，保全组作为其中最复杂最有代表性的团队，在团队领导要求和团队意愿结合下，成为试点团队。
我们的努力
一:通过看板可视化当前进展，累积数据持续观察健康情况
经过与团队各角色多轮沟通，试点的改进目标定为透明团队进展，缩短需求交付周期，并开始改进的第一次尝试：
1.和团队一起，基于团队的当前实际情况作看板建模，建立看板及基于看板的站会和工作规则。
2.利用站会和看板，每日更新团队工作进展和所遇到的阻碍风险，团队内可视化进展。
3.持续累积工作量、实际工时等数据，绘制累积流图等，对干系人可视化进度。
二:透明工作项，分析各项工作量占比，提升有效开发工时
使用看板一段时间后，团队明确感觉工作进展透明度大幅提升，团队内协作更顺利。但在对看板上卡片数据做回顾时发现，开发人员在需求卡片上的投入明显不足，平均不到4小时，有些甚至更低，因而开始了第二次改进尝试：
1.在看板上透明所有工作项分类，并每日记录对应工作投入，定期分析各工作项占比，发现业务的电话、邮件事件严重干扰开发进度。
2.给定改进目标：开发工作占比必须持续提升至80%，促使开发有意识的引导业务使用事件通道等即有工作处理流程，减少干扰。
三：打破开发测试的部门墙，建立跨职能的交付团队
开发人员更专注需求开发后，开发效率提升明显。这时，开发和测试属于不同团队且工作在不同版本，造成的工作关注点不一致的问题就暴露出来了，需求大量在待测试堆积，无法快速流动，因而开始第三次改进尝试：
需求拆分为user story，并构建持续集成工作环境，开发和测试基于Story的颗粒度协作，以便测试可以尽早开始测试。
逐步减少版本并行程度，使开发测试能聚集于当前版本，减少工作切换。
四:改善需求提交节奏，优化与业务方的协作
此前团队与业务方的协作方式是由寿险公司的BA向真实的业务收集需求，并大致排期，之后再在版本约定的需求冻结时间点（上线时间的八周之前）统一提交给IT团队。这就人为造成需求提交至IT团队到上线至少需要八周的时间。此外，需求往往到最后的UAT阶段业务方才能看到，造成很多变更在最后时间点发生。在IT团队内部优化一段时间后，改进进入了深水区，必须改进与业务的协作方式，因而做了第四次改进尝试：
1.基本取消版本需求冻结时间要求，更积极的响应业务需求的变化。
2.将需求一次性提交，改为约定的分批提交，减少BA及业务团队一次性提交需求的压力，同时IT团队的工作压力更平缓。
3.按需求的颗粒度作需求的开发，开发完成后，及时给测试和业务方做需求演示，将需求变更可能和质量要求前移。
我们的成果
经过近半年改进，团队干扰类工作项工时从420人时/月下降至220人时/月，测试人员提前2周开始下个版本测试相关工作，Bug修复时效从平均12小时缩短到5.2小时，需求实现周期也有明显提升。
团队反馈内部工作协作更顺畅，工作压力更平均。领导对团队改进效果整体也较满意，并以此为范本，在寿险开发部内推进敏捷转型。（本资讯于2016-06-28首次发布）
