敏捷开发宣言的发表，在接下来的十年里催生了一大批优秀的项目，其中包括驱动测试开发，用户中心设计，迭代式开发，简明代码，代码重构，持续集成，以及备受争议的云电脑。我个人是敏捷开发的坚决支持者，与我来说它带来的益处是无可争议的。(尽管还是有很多愚蠢网站确实在争论这一点。)
但是关键是，刨除其中包含的利益，尽管不是每个IT公司都能真正实施敏捷开发，还是有一些有组织，有计划，个人特色明显的特征会使得敏捷开发变得危险无疑。自由的巨大代价是你不得不忍受伴它而来的义务。
你的IT团队真的准备好进行敏捷开发了吗？在一下的问题上给自己打个分。
• 这项计划合理吗？ 认真考虑你准备实施敏捷计划的部分，想想这真的是适合敏捷开发的项目吗？比如说，如果此项计划包含大量使用瀑布算法的代码或者必须依赖一些不能现代化的工具和基础，那么你就要在别的地方动动脑筋了。如果此项计划本质上就必然以爆炸性的或者大刀阔斧的项目发布，那么你就需要组建一支经验丰富的敏捷开发团队。
• 对于插件功能以及开发进度的预期是否合理？ 不要把事情搞到不拿枪顶着脑门就搞不出来好插件这种地步。
• 再次自我拷问，这个项目合适吗？这个项目是否陷入困劲？是否有可达成目标？是否过时或者已经入不敷出？是否困于时局？先将这些问题摆平再展开敏捷开发。
• 开发人员适合敏捷开发吗？敏捷开发计划需要大量团队成员的工作，这就会对那些团队中的内部使用者造成困扰。这些使用者代表被告知实情后是否还能积极参与且灵活得适应来学习新的习惯？这些使用这代表是否确切知晓其中的商业程序，不会提出这在商业上是怎么运作的这种问题。他们基于你的预算以及开发日程能够真心相信计划在技术上的可行性吗？他们是基于个人意愿为了团队的成功投入时间还是不情愿而为之？想想迪斯尼乐园吧：使用者们必须至少能够达到这种理性程度才够资格坐上敏捷开发的火箭。
• 焦点会一直停留在商业价值上吗？ 敏捷开发意味着进行短小精悍，含金量高，速度快的传递过程，反复进行高速高质传递，并建立信任。如果你的公司要求使用诸如要求文件，平均功能点成本或者每克罗茨的缺陷数等等这些条件，敏捷开发这一传递过程就会变成粗糙而低劣。
• 上层的管理者真的领会敏捷开发了吗？ 一些主管人员会忍不住详细查看周进度报告，询问具体任务的负责人，要求规划中期重复升级日程，在开发还没有完成之前庆祝即将完成的希望。他们甚至还人文敏捷开发就意味着他们能在项目的任何时段不计后果得要求更多特性。关于这个话题，有一系列迪尔伯特的漫画：如果你看到你的老板在你身旁，而且他确实就在那儿，此时你最好不要进行敏捷开发。
• 你的计划是否有足够的投资？若果投资者在讨论你的计划的价值以及不断投资扩大商业成果，你的项目就走上了正确的轨道。如果他们谈论的都是固定预算，明确的产出，以及诸如妥协退让和改变适应这样的话语，你的计划根本连一点儿机会都没有。
• 你的IT团队能力够吗？ 敏捷开发是很难的，直面这一点吧，它要求相当强的能力。真正将实行一定规模的敏捷开发的公司，比如ThoughtWorks or Salesforce.com，他们的员工比一般公司的员工聪明，而且不仅仅是聪明，那是一种要么进行下去，要么就去死的精神，他们可以偶尔为了稳定，简洁的代码正业工作。开发者们必须视感良好，思维灵活，集中精力用最少量的代码满足开发需要。开发者们不能只是被动得听从使用者的意见，更应该主动在交流中提出有价值的意见。擅长敏捷开发的公司多善于招贤纳士，且不轻易开除员工。请诚实得问问自己，这一点是否能做到。
• 你是否已有成熟且合理的开发进程计划？由于云计算可能占用多个供应商的服务，开发者将必须协调多钟语言，数据库，以及基础工具层。所以，这就意味着可用的工具中最好用的可能是支离破碎的。无论是反漏洞，命令管理，代码部署，还是错误记录，你的团队将必须在他们大量的开发工具中寻找最合适的。所以在面对诸如平行开发，持续统计，部署检查以及实时错误纠正这些内部开发过程时，你的团队就必须纪律严明，反应迅速。
• 你的团队对将要开发的项目态度正确吗？ 开发一个足够好的用户界面很容易，尤其是在预算下工作。敏捷开发团队要使用的用户开发界面将是一次性的，且18个月后很可能就不得不更换，即使是今天来看一切正确。对于大部分用户界面计划，完美主义都是价格不菲的。
采用敏捷开发需要综合开发能力，技术积累，内部信任，投资充裕以及持久坚持。敏捷开发相对亦长期开发有巨大的战略优势，但前提是你能在短期内完成它。请谨慎得选择项目，投入最好的员工，并给他们学习的空间和犯错的机会，且试着说服管理层让他们尽可能少干涉。若果这些听起来跟你的公司和计划不太符合，还是再慎重考虑一下吧。
