敏捷？敏捷?敏捷 ……

如果你根本就没有尝过某一卷冰淇淋的甜头，你就跟别人说这个很甜，我相信这个是很难让人信服的.只有他去尝过太才会确定是不是甜的，说不定他觉的很苦很涩。

并不是书上说的都是对的。敏捷是一种思想。而实际上敏捷方法是一系列的实践，比如TDD,Refactoring,Continuous Integration等等，这些都是久经考验的技术实践，而且，这些技术很多时候都是一环扣一环的，你不会写测试，怎么TDD？你说你不TDD，我只写测试，可是你设计的系统更本就没法测试，写一个测试要花你很多很多时间，你还会继续么？重构，常常听到很多人在耳边想起，可是，他们却不知道重构的基础是有详尽的Test Suite，听他们这么说，我只能这样理解，他们根本就没看过Martin的名著重构，因为他们都从不写测试用例的。无法可想，实际我们现在已经有了很多很多的测试用例了，只可惜，这些用例都没有用，一但运行，红了一大片，而且很多测试都达不到目的，实际上我们当前项目有些member居然把测试用例当作炫耀的资本，“看看，我们写了多少测试…”，但他却没问他自己，“你浪费了多少时间….”。

没有用的测试用例远比没有测试用例还要糟糕，因为那不但浪费时间还浪费金钱……如果你做某一件事情不会给你带来好处，我相信你绝对不愿去做，当然，如果可以给你带来炫耀的资本，我想你还是会去做的。

不是每个人都像Kent Benk那样迷恋绿色条的，当然习惯TDD的也很快就恋上那绿色条的。中国的开发人员太虚太浮了（当然并不是所有），至少我现在感觉周围的很多人都是这样.两个方安放在一起，都没测过，就说这个方案性能没有那个方案好，你以前有过这方面的经验么？你测过么？都没有，那你简直就是在放屁，想当然的。

不要想当然了，你不去做你永远都不知道的。

OO技术已经这么多年了，可是又有多少人能合理很好也运用？做一样东西不去弄清楚就瞎掰瞎侃。

其实最终还是人的问题，如果你跟一个一年级的小朋友说：1 x 100比100个1加起来要方便快捷，可是他认为100个1加起来要方便快捷，而且那个小朋友不信任你，因此他就是不认同你的观点，那你还能怎么办？我想只能无语了。敏捷开发里很重要的一点就是信任，你要信任你的搭挡，信任他们，很郁闷的是，我在一次和同事的聊天中提到，每人都应该信任项目组的所有人，我却没想到的是后来在一次开会中，居然说我认为他不信任…….遇到这样的同事（应该算是TeamLeader吧）我无法可想，当时唯一的想法就是辞职。两个人之间都已经失去了信任还在一起做什么？即便在一起也做不出什么东西出来。

事实上敏捷开发设计很多技术，如果你要敏捷，你需要具备很多技术底蕴，像OO，模式，TDD，重构，持续集成，还有更重要的思维方式等等,其要要敏捷不是一件容易的事，并不是你什么时候想敏捷就敏捷的。

人，软件开发绝对是人。一个项目如果失败，多数情况下一定是人的问题。务实点，一个人务实点总是好的.。

每个人都会犯错，只要犯错就要付出代价的.

敏捷绝对就是一种思想，而不是一系列的方法或者实践。这一点无数次的被传道士们重复，并且无数次的出现在传道书中。难道真的是那些人都是宗教人士？不！并非你TDD了你就XP了，即使你再加上重构、持续集成、现场客户、隐喻以及其他的种种方法，你就是agile了。
为什么17个软件方法学家讨论的结果是一个宣言，而不是一个方法——哪怕是一个最佳实践也好？原因在于agile从另外的一个角度开始看问题——也就是我们有了新的立场，agile的立场。
当然一切问题都是人的问题，但是我们需要真的理解究竟是什么人的问题。有那么多人在说agile是有门槛的，就好像绅士们有礼貌的拒绝一项服务。然而从根本上说敏捷是一种思想，从而使你只能拒绝敏捷的种种做法，但是聻不能拒绝敏捷。当然任何人都可以说我们没有实现xp的基本条件，比如你是在使用最基本的asm编程，而你的环境没有提供最基本的测试环境，编译也非常缓慢，代价昂贵。但是你无法去倔强的拒绝和客户合作，无法去拒绝优先的提供可以运行的程序，无法拒绝合作，无法拒绝拥抱变化。

不错，敏捷的确是一种思想，"并非你TDD了你就XP了，即使你再加上重构、持续集成、现场客户、隐喻以及其他的种种方法，你就是agile了。 ",的确如此，这些原则和实践应该只是敏捷的当前的一部分而已，相信不端发展，敏捷的原则和实践会越来越多，实际上，在我看来敏捷会不断的拥抱接受促进项目走向成功的原则和实践.所以目前来说，重构、持续集成、现场客户、隐喻等等这些技术会使你更敏捷，当然实际上你到底是不是敏捷由你的思想决定.....

我觉得人必须达到一定水平才容易接受敏捷思想。因为敏捷给人的直觉是主动、多做、多交流，而要让大家都有这样的热情，恐怕不是那么容易。