前言
寿险售前系统是销售人员向客户展示我们的寿险产品，以便客户能够了解和决策购买，系统是否能够快速、清晰根据客户的不同需要展示客户感兴趣的解决方案将直接决定签单率。
寿险售前项目在9个月时间从无到有通过系列实践建立一支成熟敏捷团队，助力寿险在开门红中追加投保率和追加保费都创下佳绩。
组建团队，快速完成第一次交付
>>>改变项目开发过程：从瀑布到迭代
传统开发流程：
迭代开发流程：
>>>改变团队工作方式：和业务在一起工作
传统业务和研发分属不同子公司，需求传递和验收大部分情况下还是采取“隔墙抛过来”的模式，推动研发和业务在一起工作可以大大改善需求沟通效率和效果，可以快速让SA、开发、测试对需求的理解达成一致。
>>>改变需求产出方式：分阶段进行需求产出
ProductBacklog中可随时录入新的需求，并定期对需求进行优先级排序。
提前2个迭代将ProductBacklog中的需求拆分为UserStory（用户故事），并形成StoryMapping，将优先级细化到UserStory粒度。
提前一个迭代让所有人对UserStory的理解达成一致，并形成UserStory的验收准则。
>>>改变需求验证方式：业务验收前置
业务参与到研发过程中来，在UserStory完成开发测试后立即进行验收，既可以形成并行度，也可以快速获取反馈，大大缩短了传统流程中UAT（用户测试）时间。
>>>改变测试开展方式：测试提前介入
测试提前到需求阶段介入，参与需求的理解过程，在迭代开发中，开发完成USerStory开发和自测后立即提供版本给测试人员进行功能测试，整个研发过程形成在开发-业务-测试多个角色间UserStory级别流动，提升项目交付效率。
通过改变协作模式，团队聚焦用户真正需要的功能，3个月时间从无到有发布了第一版产品，产品上线后两个月内重点功能访问量都突破10万人次（注：产品用户为公司销售人员，10万人次访问量已为同类系统中领先水平）。
优化运作，提升团队战斗力
>>>建立团队规则，并持续改进
经过多个迭代的运作，团队逐渐形成自己的运作规则，寿险售前项目形成的规则包括基本运作规则、看板规则、打点规则、迭代规则、质量守护规则。团队在每个迭代的回顾会上可能会更新已有规则或者建立新规则，但所有规则的变更都需要得到所有团队成员的认可
>>>打破角色边界，追求“一专多能”
在平安大部分研发团队中包括SM（ScrumMaster）、QA（敏捷教练）、SA（系统分析）、开发、测试等角色，在团队运作相对成熟后，开始鼓励团队成员学习其他角色基本技能，例如开发掌握SA技能，这样在某项工作成为瓶颈时能够及时进行补位，确保项目顺利进行。
>>>建立稳定的持续集成环境，全员关注质量
随着产品用户增加，质量也显得更加重要，售前项目团队基于Jenkins搭建持续集成系统，并引入自动化测试进行质量保证，同时建立团队质量守护规则，确保交付质量稳定。
在快速交付第一版本基础上，不断形成和优化团队运作模式，产品交付质量和速度都得到持续改善，STG缺陷密度降低到传统项目的50%，STG阶段缺陷修复时间占比降到传统项目的30%，并支持产品在开门红活动中追加投保率和追加保费都创新高。
团队升华，建立持续改进能力
>>>“真心话大冒险”，拉近团队成员间的距离
在经历了大半年的工作磨合后，团队成员之间的熟悉程度得到很大的提升，团队也组织一些活动来进一步拉近成员间的距离，例如我们举行“真心话大冒险”活动，通过引导团队成员之间正面肯定活动，让大家了解到自己给团队带来的正能量，也大大提升团队成员之间的信任感。
>>>轮流主持站会、总结会
在项目的改进后期，我们逐步放弃了专职SM角色，让所有团队成员轮流主持站会和总结会，让所有的人都具备改进意识并实际参与到改进中来，从而形成全员改进的氛围，建立团队的持续改进能力。
团队成长都会经历形成、震荡、正规、表现和完善几个阶段，并且团队在相对成熟后会由于面对问题的不同会在不同阶段间往复，所以团队形成自己的发现问题-解决问题模式后，团队将会持续走向成熟。
结语
产品是否能够取得成功最重要的原因之一就是团队，团队包括团队成员的技能和相互之间的沟通协作，当你拥有一支具备持续改进能力的团队的时候，产品成功只是时间的问题。（本资讯于2016-08-11首次发布）
