关注敏捷开发领域的程序员，对Fred George并不陌生，他是有近40年经验的国际敏捷领域大师级专家、咨询师、架构师。2011年3月中旬，他再次来华访问。值此良机，记者采访了Fred George，让我们一起分享他关于敏捷开发的精彩见解。
记者：很多人为了编写易变更的代码，在采用敏捷时，抛弃许多习惯用法，由你的经验出发，这样做是否属于重造*?
Fred George：这一行为实际是从传统编程转向面向对象编程。我目前的编程方式也有所不同，并且这个新方式与敏捷方式是兼容的。比如我曾经写过大的Java应用程序，那里面平均一个方法只有不到3行的实际代码，平均一个类使用不到25行的实际代码。我也曾经用有1400个类的新系统来替换只有72个Java类的系统。这只是不同风格的编程方式罢了。
因此，如果你打算写大的类和大的方法时，你会发现它们将很难被改变，这也往往会阻碍敏捷程序的进展，让程序员感到沮丧，导致项目失败。如果你写小的类，每个类只做一件事情，并且不允许其他的类插手这一事情，那么程序修改起来就会变得更加容易。任何变动都不会触及其他类，它们将在修改中完好如初。
记者：敏捷开发者可能这样想，工具不能让你变得敏捷(尽管有所帮助)，管理体系也不能让你变得敏捷(也会有所帮助)。敏捷的成功，植根于士气高涨、充分授权的工作者身上，是否体现了敏捷的实质?
Fred George：对，完全正确。敏捷并不是关于工具或者管理的，而是关于程序员在做他们认为正确的事情。我最近开始探讨一些敏捷中必要的信任转移的话题。传统的思路是，客户提出他们想要的，一大群BA抓住这些要求进行细化，随后PM将其分成小任务，分配给各小组，小组长再进行进一步划分。在此过程中，客户和程序员之间经历了多重分离。客户的零散需求可以被程序员一一满足，但是客户本人却始终不能与程序员沟通!
敏捷尝试着在客户与程序员之间建立持续的对话。在双方精彩观点双向流动的过程中，信任关系也确立起来了。然后，正如您所说的士气高涨、充分授权的程序员就开始理解问题的实质，并为客户提供快速、持续的解决方案。
记者：如能得到准确的数据支持，敏捷实施能够更好地开展下去，请问如何量化敏捷方法的实施?另外，敏捷实践下的程序员工作指标又将如何衡量?
Fred George：我过去常探讨关于如何衡量一名程序员的问题。很多衡量技巧并不是与客户价值相关联的，因而相当复杂。敏捷技巧中的结对编程，使这个问题变得更加复杂。再加上敏捷管理方法，往往会将最困难的问题分配给最好的程序员，将最简单的问题交给新手。这样看来，什么衡量法才能奏效呢?
如果你确实想要知道一名程序员的价值，去问问跟他合作的其他人的意见吧。观察伙伴对待他的态度。最好的程序员就是那种人人都抢着跟他搭配的程序员，反之，人人避而远之的那位就是你应该抛弃的对象了。谁承担了难度最大的卡片并且准时交付任务?谁是其他程序员寻求帮助的对象?通过细致的观察，对一个最好的程序员的判断结果就是显而易见了。尽管去问你的团队吧!
记者：TDD被很多敏捷开发者奉为圭璧，但也有很多开发者避之唯恐不及，请问您如何看待之中的差别?此外，测试真的能保证敏捷的实施成功吗?
Fred George：TDD是敏捷的奠基石，尤其对新的敏捷团队来说，更是如此。如果有团队避开了它，那可能是没能真正理解它的价值。
写测试代码首先达到了以下几个目标。第一，它保证了你已做好写代码的准备了。如果你心中没有计划的话，很难写出测试代码来。反之，如果你写不出测试代码来，可能是你做的计划还不够。第二，最好的代码应该是那种设计出来为其他代码所用的。
而测试代码则成为此代码的第一使用者，并且通常能带来清晰的界面。第三，测试能告诉你什么时候该停止写代码。程序有时候很容易被写过了头，也就是说，为了解决可能的未知情景，很可能写出来的代码超出实际需求。这不仅会耗费过多时间，还会产生过多冗余代码，也可能会带来更多漏洞，这都是我们不希望看到的。最后，一大堆自动形成的测试能告知你何时破坏了哪些原有代码。
TDD有如此多的优点，为何仍有些团队不愿意采用呢?通常来说，这种团队可能是没有足够的时间。殊不知，这种团队会写过多的代码，产生更多难于发现的漏洞，生成繁复的界面。这种额外的代价是看不见的，相比之下，TDD显然更经济。
对于新团队来说，他们通常对TDD持怀疑态度。但是当他们亲眼看见我使用它在同等时间内写出了比他们多三倍的代码时，他们开始考虑，然后尝试使用，最后，基本再没有抛弃过它。
TDD不能保证成功，但是缺少它却往往能导致失败。
记者：对于未来几年敏捷开发的发展，您希望看到哪些新方向?有何建议?
Fred George：我提倡无*主义编程方式。它支持敏捷方法的所有原则，但是提倡抛弃许多常见的操作实践。我认为它是自然而然的、敏捷和精益方法的进化，虽然有些同事喜欢称它为后敏捷方式。它也是Facebook所采用的模式，并取得了成功。
简单说来，这个方式就是要求企业为它们的系统设置一些目标，然后在无人监控的情况下，由程序员实施完成所有细节。错误当然不可避免，但是程序进展的奇妙节奏与当今网络社会的需求相当吻合。他们要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，快速的失败远胜过预防错误。这当然对客户与程序员之间的信任关系提出了更高的要求。
记者：对于精益等敏捷方法的流行，你持如何的看法呢?这是否是一种新的吸引眼球的管理风尚呢?
Fred George：我认为精益只不过是敏捷的另一个时髦术语。20世纪80年代，我读硕士时就学习了精益(当然那时候它的名字还不是这个，而是Just In Time，简称JIT)。到了1990年代，我将它应用于敏捷项目的编程中。现在新专家们将这种方式称为精益，但它其实还是我一直惯用的敏捷方式。
但是为老的思想贴上新的标签还是很有价值的，它会因此获得更多受众，导致更多的人采用更好的方式。所以看到TDD被重新命名为DDD(领域驱动设计)或者BDD(商业驱动设计)，是件很有意思的事情，但无论如何，给新的转变赋予新的名字还是有价值的。
记者：目前中国也出现了很多敏捷教练的角色，您对这一趋势如何看待?
Fred George：我不信任敏捷教练这一角色，我觉得这种类比是不对的。体育领域中的教练辅导运动员如何表现更出色，但是他们自己不需要身体力行。教练本身都是年纪比较大、反应比较迟钝的。
事实上，程序员们在目睹敏捷做法的过程中获益。顾问需要和他们一起写代码、写测试、部署系统。而许多敏捷教练仅仅告诉你做什么内容，然后坐在一边看着，保证你确实在按照他的要求做。程序员们对此会持怀疑态度，一旦教练离开，他们就马上放弃了这种实施。
敏捷顾问不同于体育中的教练，敏捷的推崇者应当坐下来与团队一起工作，并且身体力行引导团队。程序员不会太老或者太迟钝；但对敏捷教练，会有太懒，不愿动手的说法。