团队实施敏捷，经常会遇到的一个问题是：“实施敏捷对个人能力要求高吗？”其实不止是正在实施的团队，国内各个敏捷社区、论坛 上也充斥着这样的论调：“实施敏捷对能力要求太高了，如果团队成员的能力达不到一定的程度，还是不要实施敏捷的好”。
为什么大家会有这样的问 题？有些是实施中确实遇到的，更多的则是臆测推断出来的；在大家把问题统统归结为“个人能力”之前，我们还是先澄清一下能力的范围，是指在开发过程中，团 队各种角色（BA、QA、DEV、PM）由于自身角色能力不足，导致团队无法交付、时间拖延或者产品质量低下。我们先来看看出现的一些确实出现过或者凭空 臆测的典型问题：
某团队开发速度很慢，大大低于预期。为什么呢？多数开发人员对随用的语言和框架不熟练；
我们团队要采用TDD方 式编写自动化测试，除了开始一个月，后面大家很难坚持，一定是大家能力不行；
项目的Bug太多了，开发人员经验太少；
...
这 些问题都很奇怪，如果不采用敏捷，难道就不会出现上面的问题吗？当大家转而使用传统的开发方式时，上面的问题难道就会自动消失吗？
丰田精益生产方 式中一个经常用的隐喻是“湖水和岩石”。大意是指湖水太深，你无法发现阻碍当前生产的主要原因，只有把湖水讲下去，才能发现真正的岩石在哪里。在精益生产 中，湖水是指“库存”，而在软件开发中，对应的湖水则是“迭代周期”。
我们举一个例子，当发现“项目严重延期”时，通常已经是交付时间，不过开发 人员最近一直加班，也挺辛苦的呀。不过如果你是项目经理或者客户，你知道开发人员的时间都花到哪儿了吗？如果采用迭代式交付，每两周一个迭代，完成一定的 特性，你可能第一个迭代就发现问题了：开发人员Java语言的经验太少，光是IDE、构建环境就装了好几天；接下来的迭代你发现了更多的问题：开发人员根 本没有开发过web，每天上班就是在学习Web开发，加班时才是在干活...
我们可以抱怨团队开发人员能力不够，不过这关敏捷的什么事儿？本来大 家都知道的事情，只不过敏捷让它暴露的更严重更突出罢了，谁还会任由你“掩耳盗铃”呢。
如果你知道项目中可能存在问题，如果你想改进一下 当前的流程，为何不试试敏捷呢？把湖水（迭代周期）降下来，把岩石露出来，你会发现很多很多的问题。多数问题都跟能力有关吗？可能吧。不过能力都怨敏捷 吗？我不信。
某团队开发速度很慢，大大低于预期。为什么呢？多数开发人员对随用的语言和框架不熟练；
我们团队要采用TDD方 式编写自动化测试，除了开始一个月，后面大家很难坚持，一定是大家能力不行；
项目的Bug太多了，开发人员经验太少；
...
这 些问题都很奇怪，如果不采用敏捷，难道就不会出现上面的问题吗？当大家转而使用传统的开发方式时，上面的问题难道就会自动消失吗？
丰田精益生产方 式中一个经常用的隐喻是“湖水和岩石”。大意是指湖水太深，你无法发现阻碍当前生产的主要原因，只有把湖水讲下去，才能发现真正的岩石在哪里。在精益生产 中，湖水是指“库存”，而在软件开发中，对应的湖水则是“迭代周期”。
我们举一个例子，当发现“项目严重延期”时，通常已经是交付时间，不过开发 人员最近一直加班，也挺辛苦的呀。不过如果你是项目经理或者客户，你知道开发人员的时间都花到哪儿了吗？如果采用迭代式交付，每两周一个迭代，完成一定的 特性，你可能第一个迭代就发现问题了：开发人员Java语言的经验太少，光是IDE、构建环境就装了好几天；接下来的迭代你发现了更多的问题：开发人员根 本没有开发过web，每天上班就是在学习Web开发，加班时才是在干活...
我们可以抱怨团队开发人员能力不够，不过这关敏捷的什么事儿？本来大 家都知道的事情，只不过敏捷让它暴露的更严重更突出罢了，谁还会任由你“掩耳盗铃”呢。
如果你知道项目中可能存在问题，如果你想改进一下 当前的流程，为何不试试敏捷呢？把湖水（迭代周期）降下来，把岩石露出来，你会发现很多很多的问题。多数问题都跟能力有关吗？可能吧。不过能力都怨敏捷 吗？我不信。