Fred George访谈录：关于敏捷开发的精彩见解.docVIP

Fred George访谈录：关于敏捷开发的精彩见解 关注敏捷开发领域的程序员，对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：我提倡无政府主义编程方式。它支持敏捷方法的所有