今天很荣幸能够在亚太软件研发团队管理年会上采访到姜志辉先生，请姜先生先给我们介绍一下你自己？
我是一个喜欢写软件的人，喜欢软件行业的这样一个人，有些时候人很难找到自己和自己兴趣爱好相关的这样的一个行业，幸运的是我找到了自己，就是把我自己的兴趣、我自己的爱好和我自己的工作能够融合在一起的。所以如果要做一个自我介绍，我是一个快乐主义软件的消费者。
那目前我们也知道国内采用敏捷方法来开发软件的团队越来越多，但是我们也了解到很多团队只是注意到这个敏捷的一种形，而没有注意到它的神，所以说我们想了解一下你对此有哪些自己的想法或者建议。
我个人建议是这样的，要想能够应用敏捷必须有个思想上的转变，这个转变对于很多领导层来说非常的难。因为什么呢？因为需要在他的字眼里去除这两个字，“管理”这两个字，我认为在敏捷里边它有一个很重要的概念是领导，而不是管理。它更关注于人，更关注于人的本性，而且也关注于经济学，所以我个人认为，如果要学习敏捷，我认为应该有两点，第一点你要关注于人，关注于团队，第二个部分是关注于它背后的软件经济学，就像我做一个事情，怎么样做可能会更合理？
举个例子说，有很多人会有这样的一些误解，我前一段时间就有人问过这样的问题，说用了敏捷是不是不写文档了？这是一个误解。敏捷本身不是不写文档，它只是说做文档的目的是为了什么？是为了沟通。那么好了，就沟通这么一点来说，有什么样的方式能够更好的体现沟通呢？如果我们人很少，大家坐在一起，七八个人，三五人一个小团队，这个时候我们会发现，如果文档的目的是为了沟通，面对面的沟通、交流是最好的，所以这个时候应该取消文档。
但是如果我面对的可能是上百人的一个大团队，而且是分布式的，这个时候你会发现，如果面对面的沟通交流，效果不是那么好，其实不如文档的效果会更好，所以这个时候你会发现能够表达沟通意图的那个文档会比我们说的“沟通”，就是面对面的沟通交流会更好。所以敏捷关注的是背后的本质，它关注的是如何才能更好的达到实效，这是敏捷。
所以我说要想应用敏捷必须有两点转变，第一个点是对于软件团队基础建筑材料的不同，很多人把软件开发一直比喻成建筑，实际上不一样，它们的材料不一样。构建软件的基本材料是人。是人就有缺点，就会有弱点，所以应用敏捷、学习敏捷首先第一个是对人的认识，关注于人，关注于团队；第二点是可能要关注于敏捷背后的一些经济学，这是我个人的一些建议。
很好的建议，目前采用敏捷的团队很多也在用Scrum，很多人说，一提到敏捷，那就是Scrum，对于精益，对于XP，包括对于看板，对于Crystal却不是非常的了解，那你能不能简单给我们大家介绍一下它们各自的特点。
如果说介绍每一个各自特点，就像介绍每一个公司的每一个方法的招式一样，因为它们是实践。那么敏捷联盟之所以能够成为联盟，是因为有很多方法融合在一起。包括我们介绍这个敏捷的宣言，敏捷的原则，是因为在宣言这个部分，它们的价值观部分达到了统一。然后其次是在原则上达到了基本的一致，而在方法上它们各有各的不同，所以它们的关注点是不一样的，比如说Scrum它本身是一种开发框架，关注点是迭代的框架，严格的说，它是一个迭代闭环的关注点。
而水晶方法论，它可能关注的是一个什么概念呢？它可能更多的是关注如何能构建一个好的团队，一个团队它应该具有什么样的属性。包括极限，像Kent
Beck。他们在把自己的一些成功的实践拿出来和大家分享的这么一个方法集，尤其到了第二版，像极限编程的第二版，它提出它自己的价值观、原则还有实践。包括还有一些我们从日本的经济方法里边提练的一些方法，它们是方法不太一样，但是本质是一样的。
如果我个人应用的话，我的推荐是，如果要想使用敏捷，可以从Scrum开始，为什么？因为它是最简单、最轻量的一个管理方法，而且它是从管理入手的，但是如果要想应用的话，我个人建议，可以从极限编程入手。我们的开发团队，可以自己去应用，可以不通过管理层。比如说你使用测试驱动开发，你使用重构，你使用持续构建，我想管理团队不会说阻止你应用这些实践，所以一个团队，它可以不通过管理层，而使用这些的敏捷实践，最佳实践。
如果通过管理层，Scrum是一个可以推广的一个方法，而关注于团队的建设我个人认为像水晶方法论可能会更合适一些。但是它们背后的本质，那个才是我们最需要关注的东西，实践的手法是我们用来进行借鉴和学习并且需要加以改造的。
现在很多组织或者是企业都在，可以说在盲目的采用敏捷方法，以为它可以去解决传统方法的所有的弊端，遇到的所有的问题，但是你也知道，结果往往并不是非常的如意。那么您个人觉得敏捷无法解决的问题主要有哪些？
敏捷首先无法解决的问题是思想的瓶颈。因为很多人在使用敏捷的时候，原本的出发点就错了，比如说我作为一个管理者，我为什么要使用敏捷，我是为了提高生产效率，提高质量，说白了它就是期望以更低的成本，完成更高质量投资回报的这样的一种方法。它希望是这样一个东西，它本质的思想没变，换句话说，它一开始就把敏捷当作一个工具，它在本质上，在思想上没有发生改变。
比如说他们没有关注于背后的人，没有关注于以人作为基础的团队，也没有关注于软件经济学，没有关注这些最基本的价值观和原则，而一上来就使用这样的一些方法，所以我说这个是很多团队最糟糕的部分，任何没有达到团队思想统一的流程，都会沦为一种形式。所以我说，最难的部分是这样的：他们没有关注于底层的这个真正的背后的思想，而关注于它的方法，或者形式。那么我们说这是敏捷，是很多人在敏捷失败的最基本的原因，不关注于本质。
那么很多时候，我们的研发团队自己可能也是用了敏捷的思维，敏捷的方法。但是管理层却没有完成转变，所以说这种时候，常常会存在一些碰撞。那么在这个时候，敏捷团队的成员，或者是管理层应该是各自怎样，或者是去如何对待这种碰撞？
提到这个问题，我想起祖尔•索伯斯基在《祖尔说软件》里边，在博客里边曾经提到过这个观念，说如果作为一个计算，作为一个估算，程序员和管理者两个之间发生了冲突，这个时候怎么办呢？我记得祖尔•索伯斯基当时提出的概念是这样的，你给出你自己真实的想法，然后让时间去证明它。所以不管是一个开发者还是一个管理者，我认为争吵是不必要的，最好的方法就是实践。
举个例子说，对一个东西它是否能产生这样的效果，那我去实践，我是一个开发者，我用实践来说话，我用实践来告诉你，这样一个策略性开发，确实提高了我的代码质量，给了我一个更容易理解、更容易沟通，而且变化更灵活的这样一个代码，而我以后适应变化也非常的好，这个用事实说话。而作为一个管理者来说，它更应该关注的是结果，就是我做这样一件事情，它给我带来什么样的结果，而不是它所谓的形式，一定要放开。
因为作为一个管理者来讲，作为一个程序员来说，它首先是需要尊重，而尊重是建立在什么基础之上呢？是建立在事实的基础上的，所以我个人建议无论是一个程序员还是一个项目经理，当他们有冲突的时候，最好的方法就是用实践来证明你的观点。
证明给你的管理层？
没错。
那另外一个问题就是关于在日本剑道里面有，所谓有守、破、离三个方法。那所谓守，但是怎么来讲？就是在我们采用敏捷方法的过程中，其实大多数的组织和团队，还都是只能达到一个守的阶段？很少有能达到第二个阶段，就是破，那更不用说达到第三个阶段，达到离的阶段，那你认为应该如何做才能去达到第二个阶段，达到破这个阶段？
达到这个阶段有几种方式，第一种方式，我觉得你必须经过成千上万次的演练，就像我会投篮，我要有球感，我必须经过不断的投篮练习，不断的得到失败，从里面得到一些经验教训，这个是不可以越过的。所以我说，你要想达到破的境界，必须经过守这个阶段。但是如果老是经过守，我们的成本是不是太高了？所以有些时候我们可以请一些教练，就像宫本武藏在写《五轮书》的时候，他自己本身是一个剑道高手，为了达到更高的境界，他找禅师来帮助他找到剑术最高境界的本质，所以剑道最主要目的是能够战胜对方，就是在这一点上能够得到认识。因此我认为，通过教练，通过外部的一些环境，一些人员可以给我们提供帮助。
另外一个方式，就是能够不断的审视自己，反思、总结、改变，这很重要。比如说我今天用了这么一个招式达到这样一个效果了，那么好了，经过一段时间，我自己总结，我为什么能够做，我背后的目的是什么？不断地问为什么，不断地反思，不断地改进，不断地总结，所以我要说的概念是这样的：如果要想达到破的境界就必须经过守的境界，但是要从守达到破，不是你不经过思考的，我认为这种思考，可以寻求一些帮助，而反思改进是最好的方式。
自己要主动，有时候也要借鉴一些外部的力量？
外界的力量，可以借助一些外界的力量，因为外界的力量它看的可能更清楚，在你偏离方向的时候，它能帮你回到正确的位置上去。
对，这就是教练的作用。那我们也了解到像80/20法则这个在软件开发中是一个非常有趣的现象，也是一个有趣的经济学的问题，那敏捷团队如何才能真正交付客户价值？
尊重，首先是尊重，软件开发，我也一直在提到一个问题，软件开发是一种博弈。博弈有很多种，那么软件开发本身，它不是一种零和的博弈，什么是零和博弈？就是你牺牲某一个人的利益，以某一个人的付出作为代价来获得利益，当两个人加到一起的时候，它的结果为零。实际上有些时候，我们很多团队是这样的，有一段时间，我经常听到很多人提出这个问题，包括会间吃饭的时候有人提到这个问题。什么是好的软件？就是你做这么一个东西给用户，那么用户认为它很好，没有发现里面的问题，这就是一个好的软件。我们认为这个认识是错误的，这是一种零和博弈。一旦这种东西进入一种循环，一种恶性循环，往复的这样一个博弈，马上进入一种零和博弈，所以软件开发不是零和博弈，就是它不是说谁占了谁的便宜，或者谁的收益是以另外一个人的付出作为一种代价的，软件开发应该是一种非零和博弈，是双赢的。大家共同来完成这样一个事情，每个人在里边获得自己的价值，是这个样子。
那么在这个基础上，我们会发现，我们需要相互的不断的沟通，交流，反馈这样的一个过程。举个例子来说，我们在很多开发团队里边，用户会一直要求看我们的文档，或者看我们的进度，对我们进度进行评审。但实际上我们很多客户它真的会看你的文档吗？你的文档交付给它，我们大家都知道，我交付那个文档有些时候是没有任何意义的，而客户其实有些时候，拿着文档不看，那它为什么要求文档？实际上是对你没有信心。
找到一种安全感？
对，所以只要你能够通过一种方法，不断的给他建立信心，你们两个之间就会有尊重，那么有了尊重以后你们就会有了信任，有了信任就会有了沟通。那么你会发现，你们交互是双赢的，你交付给用户，通过反馈交付价值，而用户通过和你沟通，来创造符合它自己的更高的投资回报，是这样的一个过程。
那我们也了解到，快速反馈是敏捷的一个基本的要求，那为了做到快速反馈，当然最有效的沟通是最关键的，这个问题是怎样才能进行最有效的沟通？
有些时候确实存在着很多问题，就像一个优秀的歌手和它的制片人一样，一个电影的投资人和一个非常棒的电影演员(音乐人)，它们之间一定会有冲突，因为一个是追求艺术的，我是一个摇滚爱好者，我追求艺术，那些人根本不懂我的艺术。但是作为一个投资人来说，他要求的是商业回报，所以它们两个之间一定会有这样的一些问题。
同样的方式，我们也会有这样的一些问题。前两天一个朋友给我又推荐了一个笑话，这个笑话概念是什么样子呢？是这样的，就是天很热，夫妻俩，然后这个妻子在里边去洗澡，洗完澡之后，这个丈夫也钻进去洗澡了，妻子刚出来，门响得很急促，妻子就很着急，拿过一个围巾把自己给围上了，到了门口，有个男子，拿了800美金，看到妻子就说，如果你把那件衣服脱了，我把这个800美金给你，妻子犹豫了片刻之后把衣服脱了，拿了800美金。过了一会儿，丈夫出来了。丈夫说刚才是谁敲门啊？妻子说是谁谁来敲门了，他说那他有没有提到他还欠我800美金的问题。那么看了这个笑话以后，说明一个什么问题呢？就是要和你的合伙人和你的伙伴分享你们之间的知识，这样才能避免一些不必要的风险。
所以刚才我讲了两个东西，一个是什么呢？一个是音乐界里边你的投资人和演员(音乐人)之间它们有的冲突。那么另外一个，一个小笑话是夫妻之间的东西。但是不管怎么说都是在一起合作的人，那么合作的人之间总会有一些分歧，这是不可避免的，夫妻之间也会吵架。但是最关键的问题在于你必须和你的合伙人一起来分享，否则你们会发现你们失去的东西会很多。
举个例子说，如果我们两个人在一块开发，我加班加点，我自己闭关，通过一个月我终于解决了一个难度很高的问题，结果在我汇报的时候，其中有一个人对我说，那个问题在两个月之前早已经解决了，这就是我刚才说的，如果不沟通，那么你会发现，你们浪费的时间、人员、这种精力、成本这样的一些浪费。
那如何让这种沟通，彼此之间的沟通更加有效果一点或者更加有效一些？
我觉得首先要学会把一个团队建立成一个能够相互尊重的团队，某一个固定的方法可能很难。举个例子说我的团队采用的方法是什么，是以学习和游戏为主的这样的一个方式，不一定适于你的团队。举个例子说，我的团队每天下午的五点会在一起打游戏，但打的游戏一定不是单机版游戏，是团队合作游戏，比如说魔兽世界，比如说CS，好多。比如说在玩儿魔兽世界时，也需要几个人相互的合作。
那么这种合作，就是你的法师，你的战士，你的盗贼，还有包括你的牧师，它们之间一定要相互合作的。中间任何一个人不到位，你是很难完成这个关口。好的，如果失败的话，我们会发现最后我们这个游戏玩儿完了以后很多人就会总结为什么？谁没有到位，建立起这样一个相互沟通，团队相互之间的交流的这样一个氛围。包括我们一块去攀岩，一块去骑马，一块去爬山，这些方式都是帮助我们团队建立沟通，建立交流，建立团队的这么一个非常好的方法，我的团队是这样用的。
但是到了你的团队是怎么做得呢？我想应该有更好的方法或更好的实践，但是我坚决反对以硬性的条文来规定我们团队之间应该进行沟通的，否则就像我刚才说的就会变为形式了。
还是应该是一种自然的真诚的沟通？
对，自然的真诚的，最好的话就是团队之间建立起一个相互尊重的、相互信任的这么一种关系。怎么建立？可以从其它的游戏规则里面去学习，打游戏也好，打篮球也好，只要是一种团队活动就可以举行，只要是这样的一种以团队为基础的非零和的博弈，只要是这种博弈，都可以学习。比如说我们一起看篮球，比如说我们一起看橄榄球，我记得米卢在世界杯之前，给国家队看那个橄榄球的电影，其实你会发现我们的软件开发完全可以像那种以团队作为艺术的，非零和游戏里边的任何一款进行学习，找到相互沟通的方法和密钥。
很多东西其实都是相同的。另外一个问题是关于测试驱动开发的，我们也知道测试驱动开发是极限编程中十分重要的一个实践，从第一次系统提出TDD，到现在差不多也有十多年了，其中也是争论不断，但是很少有团队能够真正的去应用这个测试驱动开发，并通过测试驱动开发来去增强信心，你认为在这个整个的过程中，大家可能遇到的困惑，或者困境是什么，那开发的团队应该如何开始实践TDD？
没错，问题有几个，我不能全列出来。举个例子来说，有的人为什么使用测试驱动开发？因为测试驱动开发流行了，所以我使用测试驱动开发。为了测试驱动而测试驱动，这种东西一定会失败，同样的方式，为了敏捷而敏捷一定会失败。
第二个部分，很多人认为测试驱动开发是浪费时间的，浪费我的成本的，很多人在心里上去排斥它，就是一个问题。思想上没有达到认识，它不知道测试驱动开发给我们带来了什么样的好处，所以有一个问题，测试驱动开发到底给团队带来什么样的好处，这个在思想上一定要达成共识。举个例子说，我们说测试驱动开发本身它不是测试，它不是测试。我很多人说，测试驱动开发是白盒测试或者黑盒测试。测试驱动开发它不是测试，它是开发，它是设计。它有一个很好的一个闭环。
首先我来解释第一个问题，说测试驱动开发浪费时间，实际上把我们软件开发分成几个流程，需求、分析、设计、实现、测试，这么几个部分，如果再加上一个调试，什么部分最浪费时间？我想很多人会选择调试，会选择设计，会选择分析，但是少有人会选择开发，也就是编码，少有人会选择这个部分。因为编码仅仅是当你的思想成熟的时候，然后进行开发的，所以作为测试驱动开发来说，你可能只是加上三行或者是五行就可以完成这个部分了，因为测试驱动开发代码很少，所以你耽误的时间只是几分钟而已，但是你获得好处是什么，你会发现你好像几乎不需要调试了。
当然这个可能有点绝对，但是这是从我个人的角度来看，几乎不需要调试了。
第二个部分，它给了你一个立即进入状态的这样的一个规则，就像我们很多人说，比如说像我原来开发的时候，这个地方应该怎么进行设计？我会花很多时间去学习，我会去思考。在思考之前我会去学习，买一些书籍，或者查一些相关资料，看看哪一个方案更好，那么最后什么时候去决定这个设计呢，当时间到的时候，我没有办法了，然后我赶快仓促的给出一个设计来。但是你会发现测试驱动开发是一个什么概念呢，一开始以故事的方式，以用户使用的方式来描述出你的，你是应该怎么去用的，那么很快通过代码把它表述出来，通过这种代码，说明这个代码是应该这样设计的，所以它给了你一个方式。
就像我爬山的时候，在我的前方定了一个大长钉，我的目标在那个地方，而且我能快速前进，那么好了，当我快速前进的时候，我完成了一个部分，紧接着下一步，所以它非常符合人性，人性是什么？人总是希望能大踏步前进，但是人能够做的事情是小步前进，而且我们会发现如果我们不能飞翔，那就快速的移动我们的步伐，达到飞的状态，所以我认为这是测试驱动开发的本质。
另外一块，从面向对象的这个角度来说，它也非常好。比如说我们在软件开发里面讲过一个什么？叫做高内聚低耦合。高内聚怎么解决的？我记得Peter曾经讲过一个概念，说什么呢？DIY原则，你把你自己想象成这个对象，然后你在那个世界里面，在那个领域里边，你应该具有什么样的职责或者行为。那么好的，我们会发现，用测试驱动开发，能够封装意图，就是那个对象到底要干什么，它的意图跟行为是一致的，好的，用测试驱动开发来封装我的意图，然后用一些手法，比如说重构，比如说设计模式，来解耦对这个意图的实现，它是非常符合面向对象的原则的。
第三个部分，测试驱动开发本身又能够与持续构建很好的形成一个反馈的闭环，所以我们说，如果使用测试驱动开发，能够认识到背后的本质，它符合经济学，因为它能够形成一个测试闭环，能够快速的找到问题所在，来节省我们的成本。它符合设计本身、高内聚低耦合的原则。我们会发现测试驱动开发本身是从能够让你符合人性的这个角度来出发的，如果能够认识到，然后快速的去做一些实践，实践过程中不断地反思，不断地反思再去快速的使用。
那么我的建议是这样的，就是每一次使用不要把它当作一种形式，认真地去体会测试驱动开发的好处。当然了，刚刚使用的时候会有很多问题，因为改变一个人的习惯会非常非常的难，这个时候需要一定的勇气，就像我戒烟一样，我已经戒了三次烟了，到现在为止还是没有戒掉，所以改变自己的习惯，需要点勇气，不过有一个好消息是应用测试驱动开发比戒烟容易的多。
非常好的类比，最后一个问题是关于总结回顾的。我们也知道总结回顾是自我改善的一个基本的方法，许多团队都会定期，现在都已经习惯定期举行一些回顾会议，但是遇到的问题是，问题还是层出不穷，而且很多问题也是，你根本没有办法去好像是根治它们，那么作为您，如果说去面对这样的问题，您认为应该去如何去避免这种现象？
我觉得有一个很重要的问题是，很多团队它不断的回顾，不断的总结，但是从来不改进。我们团队有一个很重要的概念就是持续改进，反思改进，就是遇到了问题以后，我们找到问题，找到问题，找到它。然后去解决这个问题背后的一些原因。比如说我们现在很多团队都是这样的，一个项目完了，就去评审，评审完以后给出很多的意见，说我们什么地方不成功，然后我们会列出很多条例，列完就列完了，我们再也没有去改进它，这个是很多团队最可怕的问题，因为很多时候我们不是不总结，是总结了从来不改进。
所以这里我想用两段话来回答这个问题。那么第一段话，是Kent
Beck的话：“保持专注、适应、改进”，就是那句话，“保持专注、适应、改进”
！所以最后这个改进是要有的，不能光反思总结而不改进。第二句话是祖尔说的一句话：“软件开发是这样一个过程，你瞄准一个目标，瞄准、卧倒、射击、移动...”
，所以我们说在软件开发过程中，千万不要想大踏步前进，一步一步的前进，那么我们发现自己身上有一个问题，改正它，让它变成我们的一个习惯，再发现一个问题，然后再改进它，再变成我们的一个习惯。
所以在此我也给想使用敏捷的人一个建议，就是我们在使用一个实践的过程中，有些时候，不要一上来就把所有的实践都堆过来，这个时候更改非常非常难，找到我们最关注的部分，然后在这个部分的思想价值观达到了统一以后，去逐渐的去改变它，形成一个习惯，再加上一个习惯。什么是优秀的团队？优秀的团队只是有几个优秀的习惯而已，但是这些习惯的养成非常非常难。
还有一个好消息是这样的，在敏捷的实践里边很多的实践是相互套接的，就像刚才我们讨论了很多问题，它们都是离不开的，比如说沟通，反馈，交流，测试驱动开发，持续构建，它们都是连在一起的。那么迭代本身紧接着后面就是反思改进，反思改进完了下次迭代。迭代过程中我们需要测试驱动开发、持续集成，再后面围绕着一个迭代的过程，它们之间是相互连接的，只要你有一个好的实践，并且体会到了，你马上会有第二个，第三个，第四个实践。