就如同股票市场的多空双方一样，争论的双方都有足够的理由来验证自己的观点，然后真正成长为敏捷大师的人也的确是那些积极参与争论并倾听对方观点的人。 本文将收集一些开源社区关于敏捷争论的核心问题并表述笔者的个人看法，仅此而已。

1.敏捷是一种实践
敏捷打开了一扇变革的窗，让软件设计有机会紧贴着客户需求。变革的窗需要注入全新的，更有效的开发方式。
相信大部分敏捷实施团队都掌握了敏捷开发的架式：迭代开始之初会有迭代计划会议(Planning)；结束之前会有回顾会议(Review)；每天有Scrum meeting；程序员们按照TDD的方式编写代码；CI一旦呈现红色(Q-index)，就会有人肉提醒……看上去，我们的工作很成功，似乎一切都很顺利。

越到项目收尾阶段，困难逐渐接踵而至。发现当初想的很不周到；只实现的功能却没有考虑可读性，可扩展性。接口设计不统一，模块间集成变得很困难等等。很多项目甚至陷入到一发不可收拾的地步，至上而下思考的问题也从如何优美解决设计问题变成了如何把问题隐藏得更深。

敏捷是一种实践，但我们很清楚，虽然需要的这些实践，但只有这些实践还远远不够。
大家都“敏捷”了，但“敏捷”的结果还是会不同，其原因就是彼此对于代码理解依然存在差异。程序员的工作方式虽然“敏捷”了，但脑子里面对于代码理解可能依然停留在原有的模式下。敏捷需要杰出的分析和解决问题的能力，敏捷固然好，可是软件开发的内功才是提升软件开发能力的根本。敏捷同样需要架构师的强力支持和整体把关。

2.敏捷能带来生产力吗？
毫无疑问，敏捷是一种优秀的工作方法。然而工作方法和做事情是两个独立的概念。用不同的工作方法都可以把事情做好，只不过，付出的代价不同。软件业有很多孤 胆英雄的故事，而且很多故事发生在不敏捷的年代，他们肯定是不敏捷的。但是，你如果以此为例就说敏捷没有用，那就是典型的糊涂逻辑。就像博尔特可以跑到 9.69，但我们跑不了那么快。我们努力探寻的是提高普通程序员和普通的团队工作效率的方法。

实施敏捷是不是需要面面俱到？从来也不会说敏捷所有的敏捷实践都是必需的，但是任何一环的缺失都可会对实施的效果有影响：

• 不做重构，没问题，代码积累的问题通常需要一段时间才会暴露出来，项目活到那个时侯再去解决也不迟，如果运气好的话，有生之年还是能解决完的；
• 不结对编程，没问题，大不了多钻一些牛角尖，大不了一段时间之后，才发现有人写出无法想像的诡异代码；
• 不持续集成，没问题，希望市场给你只要有足够的时间合并与调试代码；
• 不写测试，没问题，反正有专门负责测试的人，而且我一点都不怕他们给我找bug
• ……

从我了解到的情况来看，领导们偏爱Scrum，因为它侧重管理，而真正实施起来，倒是那些实践更受欢迎，因为这才是对程序员立竿见影的部份，而真正产出代码的肯定不是那些领导。我是程序员，所以，我很清楚，程序员出身的人容易鄙视Scrum之类侧重管理的方法，鄙视的原因无非是觉得那些东西很虚。但是真正想做好的话，管理也是不可或缺的，因为程序员们往往是缺乏对项目进展的关注，容易陷入自娱自乐的境地，这就是管理起作用的地方。好像跑题了.......

3.敏捷，项目计划需要平衡

如果用一个词形容客户程序员，出现在我脑海中的第一个词就是，忙！忙着琢磨一个又一个方案，忙着编写一段又一段代码。
为什么会这么忙，原因很简单，要做的事非常多，压力很大。

这种压力并非一种特殊的现像，接触了很多人，从他们言语之中，我都可以清晰的感受到这种压力。正是这种压力的存在， 让程序员每天疲于奔命，应付各种各样的任务。其结果是，他们所要做的一切只是为了完成任务，很难有时间想想怎么把事情做得更好。念书时总结的一条基本规律是，以100分为目标的人，拿个80分总是不成问题的，而目标定在60分的，不及格通常是最后的结果。同样的道理，当他们仅仅把目标定位在完成功能，这也似乎变成了一种可望不可及的目标。

相对于传统的瀑布开发模型，敏捷需要更加充分的实践空间，尽量减小压力，让我们有机会在里面充分引入各种各样的敏捷实践。程序员也需要过程来实践各种敏捷的新理念，他们需要乐于其中。人在压力下，倾向回到自己熟悉的道路上。在巨大的压力之下，人们就倾向于放弃新知识，回到他们习惯的工作方式上。

所以一个不合理的工作计划，只会是一个恶性循环的开始。而且，越大的团队，这种伤害就会越大。

4.敏捷 != 敏捷实践

说起敏捷，会让人想起什么？
TDD、持续集成、结对编程、回顾会议……

当人们谈论起敏捷，首先进入大脑的词汇便是这些敏捷实践的名字。

所以，与人交流的过程，经常会有人告诉我们，我们已经敏捷了，我们搞过TDD，我们做过持续集成等等。然后，语重心长的说，敏捷不行啊！我们遇到了这样那样的问题，总之，都是敏捷惹得祸。

我们回过头耐心地去思考有哪些具体问题呢，下面就是一些经常得到的答案：
* TDD就是测试，浪费时间。
* 测试不好写，为了测一个函数需要设置好多东西，太麻烦了。
* 我们的持续集成每天都给我们发报告的。
* 结对编程就是两个坐在一起，太浪费时间了。
* ……

看到这里，我相信，单以敏捷实践而言，我们已经开始做了，但我们真的理解敏捷了吗？

推荐Kent Beck的书《Extreme Programming Explained: Embrace Change》。或许我们记住的只是那些实践。然饿真正更具价值的部分是那些价值观：沟通、反馈、简单、勇气和尊重:
* 当我们经常发现自己的理解和其他人存在不一致的情况时，也许沟通是最好的解决办法
* 当我们每天才得到一个报告时，我们也就失去了持续集成应有的快速反馈
* 当我们编写一个长长的测试用例时，我们如何还能保证简单
* 当我们准备放弃重构代码的念头时，我们是否需要勇气
* 当我们和pair争执得不可开交时，我们有没有想过尊重

对于敏捷而言，相比于敏捷具体实践的“形”，这些价值观才是“神”。正是有了这些价值观的驱动，我们才会考虑：
* 把测试和代码写得清晰易懂，因为复杂了，就不容易理解
* 不断重构代码，因为一旦腐烂，再想回到干净，就是一件困难重重的任务
* 选择尽可能的自动化，因为人工是繁琐的
* ……

总结：敏捷，只是一个开始；敏捷，在路上

敏捷，给了我们一个新的思考角度，由此，我们得以发现很多的问题。这不是敏捷的问题，而是既有工作方式存在的问题，只不过，敏捷让它暴露出来而已。借由敏捷的引入，努力消除这些问题，让软件开发向着良性的方向前进。

敏捷，只是一个开始，随着敏捷的深入，我们可以发现更多原本可以做得更好的地方。