前言：eTP已经试点敏捷做完了五轮迭代，一直想记录下自己和团队一起敏捷转型的历程体会，却难能静下心来，所以格外珍惜这难得清静的下午尽快落实笔下，用于自勉和总结，也希望给同样在敏捷转型起步的朋友一些分享
从我自身来讲，最初对敏捷是有严重的偏见和认识误区的：敏捷就是快速的交付发布，我们的业务没有那么高的发布诉求为什么要走敏捷，这个误区一直带到我所负责的ETP试点敏捷，在此要感谢PMO团队组织的敏捷培训，让我意识到敏捷能给产品带来的巨大转变，并下定决心将ETP敏捷转型进行到底
以前对于敏捷认识误区纠正：
敏捷两周迭代不等于两周上线：敏捷迭代的周期就是团队的运作节奏，就如同项目的心跳，稳定的交付节奏帮助团队稳定的交付产品。产品的发布周期可以和迭代周期不同步的
敏捷就是提高效率：提高效率并不是敏捷的核心，而是敏捷转型带来的效果之一。敏捷的核心是拥抱变化,快速响应
敏捷给ETP团队带来了什么？
1、 团队氛围和作战能力提升,
ETP团队氛围的提升是由产品一体化和敏捷转型合力带来的效果，以前BA和实施独立运行，采用文档和需求串讲形式交接一个版本的大量需求，项目版本周期长，到后期才发现一些需求问题， BA承受由于需求实现周期长的业务压力，开发承受着开发后期需求变更带来的压力，造成开发和BA相互指责的情况。敏捷强调团队，荣辱与共，出现问题整个团队共同解决问题。经过三轮迭代ETP整体的团队面貌有较大变化，在回顾后上特性团队每个人都提到团队氛围和效率的提升。
2、 从前端到后端更关注业务价值
敏捷团队要在较短的迭代周期内完成，这就要求每次放入迭代的需求一定是最能体现价值的。比如ETP在迭代过程中就出现很多story业务提出后，由于价值排序不断后移，随着业务方案的变化，这些需求被取消或者被更好的方案替代或者整合，试想如果瀑布模型将这些需求在最初全部纳入将会给公司和组织带来多大的浪费。
3、 产品质量的提升，快速响应业务变化，业务满意度的提升
回顾我从入职以来做的项目都是以交付为目的，如何快速准时的交付需求，虽然组织和我们一直强调质量，但是在大量需求堆积到一个版本，用户的想法变化带来频繁的需求变更，团队长期的加班，诸如此类导致的很多质量问题，相信是每个IT人都深有感受，高质量的交付用户满意的产品显得那么的奢侈。ETP敏捷转型，在迭代计划会团队成员都充分了解story，评估各自的点数，利用团队力量来提早发现可能存在的风险，每个迭代都按照团队velocity设置必须完成的story和挑战的story，开发完成一个story后给测试人员演示进入测试，测试通过后由BA进行验收，每轮迭代2周给用户演示，可以快速获得用户反馈,2周的需求响应速度，产品质量的提升以及用户参与度的提高带来了用户满意度提高。
ETP敏捷的过程是产品持续改进的过程，过程中我们不断地回顾总结每一轮迭代的不足，通过改进看板跟踪问题的解决和闭环。对于个人而言也深深影响自己的工作方式，不仅仅是埋头做事，而是不断思考，不断改进。说一千到一万的经验都是别人的，只有自己尝试才能有所体会。
