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