敏捷团队转型
敏捷团队转型背景
故事一：
以前在一个很有激情的团队中一起干一番事业。每一个人各自发挥各自的特长，将每一期项目在不加班的情况下准时上线。
后来公司在年后財务原因倒闭。团队解散后每一个人到了不同的公司。工作后都发现原来非常多公司。包含某些大公司。没有使用敏捷开发导致公司存在非常多问题，加不必要的班。效率低，代码质量不高。团队之间协调能力差，团队内部没有热情。甚至沮丧、悲观。
年后又一次在一家算比較成熟的、知名的某视频互联网公司入职后，发现公司内部问题也非常大，甚至一个迭代完毕后没有总结会议。
代码混乱。不规范。Bug非常多，甚至更改Bug效率非常低。
于是探索敏捷团队转型之路，想又一次找回当初那个团队的气势、状态。
传统方式与敏捷方式的PK
一、传统方式 VS 敏捷方式
一、传统方式
管理者：管理者努力“控制”团队
工作的表现方式：
1、制定具体的工作计划， 并做出具体的工作安排
2、指令性工作方式
3、监控过程
4、基于复杂规则的管理
团队成员:听从安排的独立贡献者
工作的表现方式：
1、被动等待主管下指令安排工作
2、独立工作为主、协作少
3、以文档和邮件为主要沟通方式
4、仅仅关注个体任务“做完”。不关注团队目标
5、能力相对单一，学习动力不足
二、敏捷方式
管理者：管理者努力“激发”团队
工作的表现方式：
1、通过目标来牵引团队自主工作
2、帮助团队提供资源，排除故障
3、营造团队自我管理的工作氛围
4、作为教练辅导团队进步
5、基于简单原则的原理。原则简单但必须被遵循
团队成员:团队成员是“全方位的积极參与者”
工作的表现方式：
1、共同參与计划制定和任务安排(原型评审、项目评估)
2、团队协作贯穿工作始终
3、面对面交流是基本的沟通方式
4、关注团队目标，共担责任。(传统方式中团队成员没有团队目标概念。完毕工作任务即可，
然后就闲着没事干。迭代速度太快导致也不考虑下优化代码等等的)
5、能力要求更广，主动学习适应岗位要求
故事二：
在增加工作后，发现他们更改bug效率极低，一些与測试沟通交流就能非常快解决的，他们缺少沟通意识。
像一些闪退，组员给測试打包的时候常常关闭日志功能。或打上混淆包，致使一些崩溃的bug非常难重现、以至于解决不了，禅道上Bug居高不下。原本在他们下个星期迭代会议上提出总结的几大问题，结果那个迭代会议就是产品一来屁颠的讲了一通问我们明确没，好散会。
于是我私下向组长请示，我们上个迭代开发问题挺多的，大家开个会总结总结。讨论下怎样提高工作效率，组长兴致的让我讲了下，然后没有开会下文，本来是一个团队共同提高的一个会议，组长也没有这个意识去推进。
相同的曾经的老同事在新的公司遇到了相同的问题，他认为组长也没有这个意识要引入敏捷开发模式，尽管工作非常闲，但年轻人都不会安于安逸，于是他找到老大提出要离职，老大问原因，朋友跟他讲了如今公司面临的问题。以及我们之前公司的团队状况及工作热情生气。他们老大也认为非常震撼。于是要求挽留整改工作实施敏捷开发。
故事对照及实践总结一:敏捷开发的推进须要高层管理者引起高度的重视、认识到问题才干使开展进行
万事开头难，假设你成功说服你们高层意识到公司问题。并决心要改变，那么你就能够实施敏捷开发了
敏捷团队转型-八步曲
一、思想动员:
方法：
· 1、领导动员讲话
2、敏捷松土
3、成功团队成员现身说法
4、各级主管承诺
目标：
1、上下同欲
2、跃跃欲试
3、信息满满
误区：
1、领导强压
2、走过场
二、差距分析
方法：
· 1、人力技能分析
2、代码架构差距分析
3、环境和工具分析
目标：
1、技能差距清晰化
2、代码架构差距清晰化
3、环境和工具差距清晰化
误区：
不重视，投入分析人员能力不足， 导致分析不深入。无实际指导意义
三.一、环境和工具准备
方法：
· 1、成立环境(配置库、CI环境、必要硬件)，专项改进小组
2、成立工具选型和开发小组。 完毕开发环境。代码静态检查， 持续集成工具和架构评估检查工具
3、环境和工具分析
目标：
1、环境改造全然适应敏捷开发须要2、建立与敏捷开发相适应的工详细系
误区：
1、没有投入足够能力的人，关键瓶颈没有识别出来。 实际开展的敏捷的时候，严重阻碍项目运作三.二、敏捷实践技能准备。技术能力准备
方法：
· 1、依据能力差距。组织系统化培训，能够引入外部资源
2、交叉宣讲，检验培训效果。技术实践最好结合代码样例进行
3、项目開始执行之后继续抓紧人 员技能培养工作不放松、在工作中培养高手
4、环绕重构、 測试驱动和持续集成所 须要的更高设计和编写能力。
进行系列化的培训和研讨，强调实战演练， 并在工作中不断锤炼。能够採用一对一帮扶，
以及结对轮换等方式
目标：
1、全部的人员对敏捷核心实践 都有实际应用经验， 基本可以运用于实践开发
2、全部成员具备熟练重构，測试驱动 和持续集成等活动的关键设计和编码能力
误区：
1、由于进度或者人力原因， 准备度不足，导致初期混乱程度激增2、仅仅注重敏捷实践的流程和实践的形式。 而忽略技术能力的跟上，有形而无实
四、确定开发过程和准备应用的实践
方法：
· 1、邀请敏捷专家，骨干，管理者參加
2、结合环境、工具、人员的准备度和 敏捷实践之间的支撑关系，
定制开发模型和应用实践
目标：
定出适合自己的实践集误区：
1、试图将敏捷开发及其套在瀑布开发过程上，导致不得其利，反受其害2、太过于激进，不考虑实际情况， 导致实践开展困难，质量长时间上不去 打击信心
3、过于保守，选择实践太少， 破坏实践间的系统性。导致效果不明显
4、过于理论化和完美主义， 导致定制的过程和实践不具现实可操作性
五、敏捷实践
方法：
· 1、严格依照已经定下的开发原型开展， 拿不准的实践不要盲目修改，
多请专家协助， 达成基本一致再修改不迟
2、出现故障，多讨论，多征集意见、 及早暴露问题越好，不要掩饰问题。虚假繁荣
3、领导要持续关注。排解困难。 多肯定，有好多进展及时激励
目标：
1、达成开发目标
2、团队掌握敏捷核心理念和实践 。提升团队能力和信心
误区：
1、实践出现困难就动摇。 对原因未做深度分析就轻易放弃2、管理者信心不足。不能给团队以 坚定信心。激励太少，团队士气低落
3、太过激进，对团队成员不适宜的情形。 耐心不足。招致团队成员内心反抗。推行受阻
4、觉得敏捷是银弹能解决全部问题 ，一旦出现故障都归咎于敏捷
六、回想评估与调整改进
方法：
· 1、对实践方法进行效果评估，总结亮点固话下一次迭代
2、识别改进点给出改进方案，在下一迭代中试行
3、环境和工具分析
目标：
1、针对出现的问题形成能够改进的措施
2、发扬好的思路和方法，让团队保持信心和热情
3、环境和工具差距清晰化
误区：
1、走过场。总结不深入， 关键点遗漏或者改进措施不得力。团队成员带着疑虑和不满进入下轮迭代
七、激励表彰
方法：
· 1、及时表彰优秀实践方法贡献者。 优秀实践运行者，
团队合作表现突出者。 牵引团队主动。积极、共享和协作，
保持团队持续的士气和信心
目标：
1、优秀者得到认可。正确导向得以确立，团队士气高昂
误区：
1、不重视激励，流于形式，树立不了标杆。牵引作用丧失2、激励太泛滥。价值贬值，激励效果差
八、项目结束总结
方法：
1、对整个项目运作进行总结，评估总体敏捷实施效果2、形成本产品的敏捷实施推荐模型。逐步推广应用到其它版本号
目标:
1、形成适合本产品的敏捷开发模型
2、培养出敏捷教练(非常高层次了，团队起码磨合4次迭代才是合适机会開始培养)
误区：
1、草草收场。推荐模型没有输出或质量差
2、教练没有培养出来
故事三:每一次迭代问题就越少。框架越成熟，基本上没有bug。所以自然而然的不用加班。一天 8小时。然后一起去看看电影、吃吃饭、谈谈互联网
敏捷开发中个一些概念及要点
