自从接触敏捷以来，已经在公司里帮助建立了不少的团队去实施敏捷，也参与了不少社区的交流活动，在这些实践和交流的过程中，感觉对于敏捷，还是有很多不同的理解，其中也包含了不少对于敏捷的误解，在这里和大家一起讨论一下比较常见的几条。
敏捷就是追求速度
一次在和几个朋友聊天的时候，有朋友说最近装了有线数字电视，他觉得开发数字电视频道服务的团队应该是采用了敏捷的团队，因为每隔一段时间，就会有新的功能发布，只是系统不稳定，不得不经常的重新启动机顶盒。
这无疑是个非常有趣的关于敏捷的理解，似乎敏捷就是关注软件功能的投放市场速度，而往往忽略质量。我想这是很多有关敏捷的理解中，比较典型的一种误识。如果我们重读一下敏捷的四句宣言以及12条敏捷原则，应该不难看出，敏捷实际是关注实现客户的价值，而这一价值体现在“可工作的软件”之中，这其实是对质量的要求，它意味着交付的软件是客户需要的并且质量稳定的，是同时对需求质量和开发质量提出要求。另外，因为市场的变化会促使客户重新调整需求，以获取最大的价值，因此敏捷强调“响应变化”，迅速调整策略，以帮助客户迅速对市场变化做出响应。所以，个人的理解，敏捷真正的含义应该是：
快速实现客户的价值（可用的软件）；
快速灵活的响应变化。
一个不重视质量，只关注简单堆砌代码的团队，不是真正的敏捷团队。
敏捷项目没有计划
敏捷项目团队确实不会，或者说，很少会在项目之初建立一份类似于WBS任务分解的进度表和甘特图，但敏捷项目依然是有计划的，和传统的进度计划不同，敏捷的计划不是关注在完成项目的一个个活动或者说任务，比如说需求分析、概要设计、详细设计，模块一编码等等，而是关注在客户的需要，关注客户价值的优先级，其计划的对象是用户要求的功能，例如用户故事，计划活动的产出是一个设置了优先级的用户需要的功能列表。敏捷计划分为以下几个层次：
愿景–制定产品的长远目标；
路线图–制定实现长远目标的分步实施计划；
发布–制定一次发布的目标，包含在一个发布中希望交付的需求清单，并设置了优先级；
迭代–制定一次迭代的目标，包含了在一个迭代中团队承诺交付的需求清单及为了达成目标而设置的工作任务；
每日计划–制定每天的工作目标，包含了团队中每个成员的工作任务。
其计划的过程是一个持续的过程，从项目开始时制定产品的愿景，到每个迭代开始时制定迭代计划，敏捷项目的计划不断的细化，不断的根据变化而调整，是Just-In-Time的计划。
敏捷只适用于小型项目和团队
敏捷实践确实很多发源于小型的项目团队，但并不是说敏捷只适合小型项目团队。其实，早期的Scrum项目就已经有在500多人的大型项目中成功实施的案例。可能是由于大多数的敏捷团队一般都希望在5～9人的规模，并且希望团队成员在同一个工作区域，所以很多时候被认为不适合跨地域，跨团队的大型项目的开发。
其实，5～9人的团队规模是一个类似于一个战斗小组的规模，这个团队小组负责完成一个共同的目标。对于一个小型的项目而言，可能只需要一个这样的战斗小组就可以了，而对于一个大型的项目，我们就可以建立多个这样的战斗小组来完成项目目标。在Scrum中，就有Scrum Scaling，通过把一个大型项目团队合理分解为多个小型的Scrum团队，每个团队都负责一个相对独立的模块或者功能，再配合其他的敏捷实践，比如持续集成，Scrum of Scrums等，加强团队之间的协作，从而确保项目的成功。所以，将敏捷实践应用于大型的、复杂的项目是完全可以的。
对于敏捷的误解，常源于主观臆断，而只要真正的尝试和实践过，不断的积累，就能体会其中真味，一己之见，权作抛砖引玉。
相关链接：
