敏捷到底带给我们什么?

“敏捷”这个词包含的东西太多了，每个人理解都不一样。

把事情作对的方式很多，敏捷实践是其中的一种方式，它一方面带来了很多最佳实践，另一方面是一种新的思维方式。

关注问题，关注组织中的浪费，寻求方法进行改进。将敏捷实践看成做出这些改进，可以参考的集合。

如果一味的强调敏捷，就好像寻求银弹一样，在你还不清楚自己存在什么问题的时候，试图去寻找一个解决所有目前和预想未来可能存在问题的工具。

这，是不靠谱的。

敏捷---本是一种新的思维方式，却被国人更多的和谐化了，以至于过多的形式化，抛开政治目的以及角色，确实是一种最佳实践，但也仅仅是一过度罢了，试问真正做大敏捷的的有几个？大多选择的是一种权衡，一种介于敏捷于瀑布之间的权衡。

完全同意。

要说明的是：李晓没有在离开 ThoughtWorks 后以 ThoughtWorks 的名义作过咨询，也没有单独作过咨询，。我只是在一个非常简短的个人说明里面包含了自己仅有的工作经历而已。

之前赋闲在家有时间，一个朋友邀请，所以去了大概是楼主的公司做一次交流，讲个敏捷相关的题目，算是分享经验，没有物质交换。

不能说深谙咨询之道，只是想讲一个东西，讲明白并让受众可以立刻有所得以至于应用要怎么做。

至于 TDD，不是主要内容，随口带到，也是以符合主题的说法出现，不见得就如何如何。意外的是那个故事居然被记得，看来以后不能随口，因为内容简单概要，而上下文不见得被记得，又是临场说出，所以导致误解难免。
谈到对 TDD 的要求，其实哪里有一步到位的说法？我相信，每个人都有过程，只是这过程是长或短，更痛苦还是更快乐而已，我想对于一个不以 TDD 为必要条件的环境，开始在事后写点测试，是一个非常好的开端，一旦开始这么作了，你慢慢从中获得的快乐高于你付出的努力后，后面怎么做其实都不需要别人告诉你了。

有关 tdd 更多的想法是（最近从同事处得知），仿佛下围棋，假设有一个最佳盘面结果是按照最佳的过程得出的解，那么你落子的顺序和你的结果有关么？关系大吗？似乎一般都很有关系，而且关系大。
为什么要这么问？一般来说不见得每次或者说你能够按照最佳过程来落子，每盘棋总是有各种状况，那么，在这个过程中，你可能需要考虑的是，我如何做到落子的顺序最大限度不影响我得到的最佳结果。特别是当我已经落了一些子了的情况下才认识到最佳结果的具体形态。
如果这样考虑了，那么你可能从单一解转变到多解，过程略显次要，于是更容易得到好的结果。
如果你从这个角度出发，后写一些测试就不见得和 tdd 格格不入。当然我和同事讨论这个不是因为后写测试的问题。

”如果你是一个专业的程序员.那这要求就不算高“ 的说法我想也不算太恰当，也许更准确得说是，问题不是敏捷要求高，问题是做到专业要求高。有一个说法：问题不是你选择了什么，而是在你选择之后怎么做。TDD 自有它的磨难，不 TDD 也有它的磨难。所以，我不认为你选择 TDD 就能少些磨难，问题只是你当初的选择是为什么而已，更不要去说什么对开发人员要求过高，不选择 TDD 自然也能专业，经历磨难也在所难免。好吧，这个话怎么说我自己也觉得难以两全，也许我该把自己的意愿强加给人（假设我们在做 Java，我想我会说：有个东西叫 JUnit，必须用好它），然后有人反驳，然后我说，我认同你观点的存在也是正确的结果。

至于楼主的有关 “ 当tdd告诉你小步前行并把你改造为code-robot .当你觉得枯燥乏味看不到希望时给你看到每次原型演示的喜悦 "，以及 ”敏捷对资本家有利.说到底对你自己也有利..为什么不敏捷起来呢?.“
是快乐，我因为快乐所以选择它，而不是别的，我看到很多人，都是因为这个，包括做软件。