前言
近几年敏捷开发犹如旋风一般刮过国内的软件开发公司，不管是一线互联网大厂，还是大型国企亦或是二三十人的小公司几乎都已经或试图尝试敏捷，但搞多的团队绝大多数都失败了。本周作者结合自身团队经验说一下在导入敏捷之前需要做的几件事。其实这类题目已经差不多写烂了，但大多都是集中在理论上，实际使用遇到不少问题，所以这篇文章讲的主要是实施层面，至于原理有时间再讨论。
启动的开始之前
敏捷活动的推动者的身份极为重要，如果你是一名开发者，想要尝试推广敏捷模式，你成功的几率极为渺茫。如果你是一名团队管理者，那么你成功的几率比一名普通的开发者要高一个数量级，但还是不高，保守估计不超过3成。如果你是一家公司的高层，能够协调各种组织级的问题，同时拥有乐于挑战经验丰富的开发团队，那么恭喜你你离真正的敏捷并不遥远，但比较讽刺的是这样的公司本身就应该是相对敏捷了，并不需要大幅转型。
为什么对于大多数传统企业来说实施敏捷怎么这么难，因为敏捷开发不仅仅是一种软件开发模式和方法学，更是一种对于团队文化甚至是组织形式的转型。如果还想不到那么可以尝试着回答下面几个问题。
1.你的组织如何评定团队的绩效？团队有没有KPI指标
2.你的组织如何评定员工的绩效？
3.项目经理或负责人对于项目团队成员的绩效有无直接发言权？
4.软件团队是否拥有足够的测试运维基础设施？
5.你的团队愿景是什么？
要做的事
思考为什么导入敏捷
关于敏捷对于你意味着什么，这个问题永远需要仔细的思考，如果你不确定，那么你可以停下来，再想想。
征求支持
这一点在初期极为重要，无数人倒在这一步。支持分为三个方面:
1.上级的支持。由于敏捷活动一般都是由喜欢新事物和挑战的技术人员发起的，而上级的支持对于解决敏捷与组织流程的冲突中扮演着至关重要的作用。
2.一线技术人员的支持，敏捷开发是由一线的技术人员实施的，因此寻求他们的支持和理解将为敏捷转型提供来自基层人民群众的呼声。
3.敏捷教练的支持，要导入敏捷最好还是有一个教练或导师来辅助，这样可以避免走不少弯路。
确定项目
一般敏捷导入都会选择先在试点项目上试验，再逐步推开的模式。万事开头难，一个好的开始将极大的推进整个转型过程，选择试点项目最好选择，规模适中，失败影响较低的项目，不能选太小的，太小的项目无法体现出优势更无法有利于推广。
确定团队
选择的团队也是很有讲究的，最好选择团队气氛较为活跃，对于新生事物能够保持兴趣，同时勇于挑战，成员技术水平较高，并且责任心较强，成员要包括从设计，开发，测试。注意开始的团队人员不宜过多，以5~7人为佳。
环境准备
为开发团队准备一个独立的房间，开放式开发环境，并且清空一面墙作为任务版，再搞一两个白板即可。
同时最好有配合开发的持续集成系统，版本管理系统以及bug管理系统等。
结论
目前大部分将敏捷的资料大多集中在敏捷的形上，但比起方法来讲团队文化也许更能决定团队效率。形敏而神不敏是一场注定的悲剧。