敏捷团队转型

敏捷团队转型背景

故事一： 

曾经在一个非常有激情的团队中一起干一番事业，每个人各自发挥各自的特长，将每一期项目在不加班的情况下准时上线。

 后来公司在年后财务原因倒闭。团队解散后每个人到了不同的公司，工作后都发现原来很多公司，包括某些大公司，没有使用敏捷开发导致公司存在很多问题，加不必要的班，效率低，代码质量不高。团队之间协调能力差，团队内部没有热情，甚至沮丧、悲观。

年后重新在一家算比较成熟的、知名的某视频互联网公司入职后，发现公司内部问题也很大，甚至一个迭代完成后没有总结会议。代码混乱，不规范，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小时，然后一起去看看电影、吃吃饭、谈谈互联网

敏捷开发中个一些概念及要点

敏捷开发-迭代会议