和Dave Thomas谈开始实施敏捷时的困难
今年敏捷中国大会举办成功，看到各界对敏捷开发的支持，同时相信还有很多公司和团队对开始实施敏捷开发感兴趣。不过亦如很多大师提到，实施敏捷开发是不容易的事情，在敏捷中国大会上InfoQ中文站编辑Steven Mak有幸跟Pragmatic Programmers（《程序员修炼之道》）作者Dave Thomas就此问题做了深入的问题：
InfoQ中文站：从今年敏捷中国大会上的热烈情况可以看到敏捷开发在中国很受欢迎，不过同时亦有不少团队在实施上遇到困难，您会给他们什么的意见呢？
Dave：实际敏捷开发本身就是不容易的，敏捷讲求纪律，作为敏捷开发人员你必须要比自己惯常地更有纪律，是发由内心的纪律。另一方面，公 司担心失去控制权，传统的做法可能是：“六月前好完成这个！”，但较为实在的敏捷方法则是：“这两周来能完成什么？”，所以是个人以及办公室政治两方面的 问题。
要成功实施敏捷方法一定要由个人开始，我不认为任何人可以单凭空喊“我们来敏捷吧！”就可以开始实施敏捷。任何公司都不能阻止个人成为一个敏捷的开发人 员，你可以先个人使用敏捷方法中推荐的实践，习惯使用他们，并建立所需要的纪律。这样做下来，效果一般则会很显注，会得到公司的注目，可能会跟你说“做的 很好，你是如何做到的？”他们会问你如何做到和为何这样做，那你就可以从这里开始引入。
我知道在美国有公司使用同样的方式做了大一点规模的实施，他们从小团队开始着手建立敏捷开发环境，不用跟公司讨论这方面的实施，因为从公司角度，团队还是 开发同样的东西，过了一段时间，如果实施得宜的话，公司就会注意到这团队：“为什么突然就能准确地交付软件？”，这是管理人员感兴趣的事情，所以我认为与 其跟他们说敏捷有多好，还不如示范给他们看，这是很大的诱因。
（笔者按：Jeff Sutherland曾经也提这类似方法，可参考InfoQ上 “Jeff Sutherland on Scrum and Not-Scrum”的视频）
InfoQ中文站：刚才提到由个人做起，不过以我所知在中国很多的实施都是由上至下，由管理层发指示进行改动的，对于管理人员，公司的准备程度上有什么因素需要注意呢？
Dave：考评准备程度这方面我也不太熟识，敏捷开发跟其他方法有一点是很不一样，就是你不能强制让别人敏捷起来的，人们还是需要有渴望才 行。其中一个重要因素是在公司内部推销，让公司所有人都希望采用，这毫不容易，你能做的也只是将信息传递出去，但是只有你自己做得到才能有效推销出去。
另一个问题是向更高级的管理层推销，甚至是顾客。在中国我有联系过的公司当中，很多都是替外国公司做软件的，得要考虑一下他们希望什么，他们对什么有兴趣。
看看印度的软件业，他们很多走向 CMM（笔者按：CMM已经更新成CMMI），而且利用这个作为市场推广之用：“我们真的很专 业，我们是CMMI五级！”，如果想跟他们竞争，你也可以去拿CMMI第五级别，又或者以另一种方式：“我们做过研究，CMMI不一定能及时适当地替顾客 增值，我们会以敏捷开发方式……”，透过这方法让公司从中突围而出，用作宣传方法。在离岸开发中很多投诉的问题就是沟通很差，但敏捷开发迫使我们有更多沟 通，使敏捷成为公司的优势。
这可能没有正面回答问题，在准备程度考评上，除了亲自尝试之外，我也不知道有什么容易的方法，但如果使用得宜，会有很大满足感的。
InfoQ中文站：有人说要成功应用敏捷开发，需要很好的开发人员才可以，你觉得如何呢？
Dave：我实在很爱这论点！虽然我完全不明白这是什么逻辑，但十分有趣。
“如果我想应用敏捷开发方式，那我就需要好的开发人员”，那是不是如果我采用其他方法就可以用差的开发人员呢？我从来都不认为在什么情况下可以接受低劣的开发人员。
当我去做顾问服务的时候，看到他们公司开发人员，我希望我可以跟他们说：“炒掉30%的开发人员”（但我从来未说过），因为这样其实可以提升效率，我不认为你可以期望在没有好开发员工下能做到什么好东西。
但不要误会，好员工跟巨星是有分别的，一班大师级的开发人员只会花时间在争吵，你需要的是良好的配合，一些好的，一些大师，也需要初级员工以作培训。
任何好的开发过程的核心都是好的员工，在其他行业也不例外，试想想你去到医院，里面有不好的医生那可不可以呢？无论什么行业，你都需要好的员工。
更重要的问题是，我们如何找到好的开发人员？
我们这个行业，从来都没有一个好的方法去培养好的开发人员。我们有大学教授理论，不过学校不知道什么是真正的软件开发，而入了行再重新开始学习编程，我认 为这是不当的方法，你需要一些大师，好的开发人员，和初级开发人员，而我们的责任是使初级的开发人员成为良好的开发人员。这是开发优秀软件的重要因素。
InfoQ中文站：James Shore写过一篇“Decline and Fall of agile”的文章，他提到很多开发团队只采用部份实践，如Sprints和站立会议，而不采用需要的工程实践以开发高质量的软件，你经验中有没有遇过这样的情况？
Dave：我常常看到有些公司只是用一两个敏捷实践就出来说在做敏捷，用各种借口不做其他的。这是不智的做法，方法学设计出来是一并使用 的，其中一个实践其实是另一个实践的安全网。如果没有全套使用，那么就会不平衡和充满风险，而且不知道项目是不是如期望中那样进行。就如节食一样，既不吃 蛋糕，也不吃蔬菜，这是个平衡的问题。
其实这是敏捷变得普及的后果，有人认识到了敏捷，而有部份人误解，然后操作错误，而我会更担心的可能还有人不了解什么是敏捷。
我不认为这危及到了敏捷的发展，因为这些人怎样也会做出疯狂的事情，这些人一直存在，而且一定会出问题，而不是任何方法学的问题。有些人喜欢向负面看，但我不认为这是问题。
敏捷社区可以做什么呢？分成两个问题来看，团队可以做什么？对于说这些话的人又可以如何？我不认为社区对以上问题有任何责任，过去十至十五年我都在帮助开发人员，让他们更能去享受工作，使开发工作更有乐趣，并且做得更好。
我们可以做的就是做的比现在更好，让别人也喜欢，并希望使用。要知道，去解决别人的问题最后只是浪费时间。
InfoQ中文站：程序员、作者、发行商，你最喜欢哪一个角色？
Dave：很难说最喜欢哪一个，这三个其实都是一样，因为我们发行书籍时采用的技巧跟编程一样，所有书籍都放在版本管理系统，有持续集成，单元测试，应用DRY原则（不自我重覆）等等。我们的发行系统就像开发软件，我得到同样的满足感。
编写书籍有点不一样，迭代短，重构，很密集紧凑，而且很费神。
我真的喜欢所有这些活动，否则我不会做，我通常喜欢写书的最初几个月和最后一个月，中间的是苦工。
InfoQ中文站：你最近在Blog上提到编写音乐，为什么你喜欢编写音乐呢？你如何比较编写音乐和编写代码呢？
Dave：我不知道我做的是不是音乐，不过我就是喜欢。我喜爱弹钢琴，希望尝试及学习，尝试找钢琴老师，有人问我：“如果你有三个月时间，你会想做什么？”，我就想学弹钢琴。
我太太就安排了钢琴课作为我的礼物，但是我还是学不了。我尝试又尝试，我的手确实无法做到弹琴所需要的，但我爱编写音乐，我的老师就帮助我在作曲，这几年我写了很多小段简单的音乐，得到很多乐趣。
我认为作曲和写代码两者有一定关系，但我不知道是什么。
你看看那些很棒的程序员，至少在我认识的当中， 我认为有至少一半是很好的音乐家，会玩很好的爵士乐，他们很享受即兴表演，协作表演，透过音乐沟通。
我自己有一套关于非言语沟通理论，一个关于模式的理论，在编写音乐的时候，会思考它的模式会怎样，整段音乐的架构，小模式、中模式、大的模式如何地互动。编写音乐最大的挑战是在这里开始了，你知道要把它容纳到更大的架构中，到后段需要想些点子出来，这是很有趣的思考挑战。
我认为编程也是同样的事情，虽然未必跟写书一样。当我编程的时候，我能想像到它运行时候的情景，我看到回路，看到方法之间的互动，像音乐演奏时很有动力，我想很多编程员都能同样看到。我想去问问别人他们看到的音乐和看到的编程是如何的，然后看看为什么会是这样的。
InfoQ中文站：你发行超过一百本图书，能选出三本你最喜欢的吗？
Dave：hm……“那个朋友你最喜欢？”，“你喜欢妈妈还是爸爸？”
我不打算说每一本书我都喜欢，但每一本书都有自己的性格，我们是家小公司，所以每本书的生产过程由开始到发行都能亲力亲为，每本书都会遇到的问题，作者花很大的努力去完成，而我亲身经历这过程，有如看着自己的子女成长一样，每本发行的时候，都会感到自豪，是一种感情。
我们很清楚做一本书出来要下什么功夫，我们为每一本书而自豪，而且很谦恭地感谢作者的信任让我们去发行该书。从作者观点来看，这是很大的事情，很可能花整 年时间去完成一本书，是很多的功夫，可能用上五百小时的工作，他们信任我们的工作流程，而每本书都很有趣，所以这不是我能回答的问题。
InfoQ中文站：最后是关于参与大会的问题，近年没有看到你参加什么大会，你近年的焦点放在那里？
Dave：我以前很常常出席大会，当 “Pragmatic Programmers” 一书面世那时，我一年出席五到十个大会，之后我参加了一个小型会议的系列﹣”No Fluff Just Stuff”， 差不多一年二十五个地点，差不多两年，我去很多不同的地方，出门的时间很多了，所以我一段时间没有再去大会。但又好像停了太久，我又很怀念他们，去年我参 加一个美国本地的Ruby大会，我只是去，没有演讲，我开始想起我喜欢大会的原因。我现在重拾参加大会的兴趣，但会比较挑剔一点，我很想去不同的大会，想 想如果每年去同一个大会，看到同一班人，同样的大会模式，那么过一段时间在大会上的所得就会减少。我现在的想法是参与不同的大会，并且从不同的参与人士中 学习。