主题：【原创】敏捷开发为什么能敏捷 -- 代码ABC

通过观察和一些交流发现国内许多号称实施了敏捷开发的团队大多不是真正的敏捷。经常遇到一些令人无语的场面。比如：和他们将迭代、讲User Story、讲点数什么的都很好，末了大多会问那么测试该怎么写呢？

……

我认为在没掌握测试驱动开发的情况下谈论任何敏捷过程都是没有意义的。敏捷开发之所以能够敏捷其核心是代码本身是敏捷的，也就是代码本身可以快速地响应变化。编写测试不仅仅在于测试令软件修改后的正确性验证得到保证，更在于先行的测试迫使程序员做出松耦合的设计，在代码的中间插入各种隔离措施。让我们修改程序的时候不至于发生牵一发而动全身的事故。而还只是测试提升代码敏捷性的其中一个作用。

敏捷开发扬弃了早期英雄程序员的概念，但是回归到开发以程序员为主的概念。敏捷团队强调程序员的主动性，程序员应能主动花时间修改糟糕的设计。而这种主动性是建立在测试驱动的基础上的，否则在项目进度压力下除非万不得已，没有人愿意花时间冒险修改已经完成功能实现的代码，那怕这个修改看上去是那么轻而易举。而这种修改在敏捷团队中几乎是家常便饭，这些时间和风险投资的回报就是代码的敏捷性。

只有代码具有敏捷性，敏捷过程才能真正体现其价值。这些过程协调了项目各方的关系，令工作有序地进行，并且将代码的敏捷性转换成项目的收益——这才是真正的敏捷。

兄台可否多谈谈这方面的心得体会什么的？

通用的玩意儿全都重型的，想想一元二次方程通用公式，一般都不大爱用

但还是一个scope里面哦

工程师不需要对编程语言进行专门训练了，基于对物理过程的理解和数理方程的描述就可以了

和手工代码相比，它的代码效率当然不算高，但我觉得吧，这个有点类似于算盘和计算器的发展（不晓得这个比喻是不是恰当）

敏捷团队强调程序员的主动性，程序员应能主动花时间修改糟糕的设计－－－－－个人认为这句是我最喜欢的。但是这样的程序员不好找啊！各行各业都一样，认真负责的人真的不好找！

一个敏捷项目应该有易于重构的特性，自动测试是必须的，否则在修改的代码不知道会不会影响项目其他部分的情况下，一个肯“主动花时间修改糟糕的设计”的程序员带来的可能是一场灾难。

原文说了，没掌握测试驱动开发的前提下谈不上敏捷。而使用测试驱动开发后，就必须具备主动修改代码的精神和能力。

易于重构的特性不是一下子就冒出来的，是在测试驱动下逐步修改出来的。而且通常也只是针对具体的项目需求易于重构，不是放诸四海皆准的。

程序员的素质通常取决于其所在的团队。敏捷开发本来就有提升程序员素质的作用，但组建这样的团队不容易。许多公司连培训都要选择非工作时间，很难想象他们能容忍团队建设的挫折。

代码兄有没有具体点的措施，比如如何创建并维持这样的团队？

作为一个项目经理，如果有成本意识的话，多做几次比较，自然会趋向TDD

很简单啊，因为找错误花的时间最长，改代码就是分分钟的事情，一个是重大特性先写测试，一个是找出问题后补写测试

TDD最大的好处是不用操心，修改的范围哪些需要回归和验证了，一切一目了然

问题是敏捷团队，甚至只是TDD模式的建立是需要时间和其他资源开销的。更不用说期间还涉及项目管理模式的变更，因此现实比较令人无语。有些极端的项目经理或领导无视上述问题，只会说——你们不是搞敏捷吗，那赶快把那些东西赶出来！要快！