《洞悉敏捷》一书客观全面地介绍了全球正在使用的各种敏捷方法的价值、原则、架构、过程和适用场景。除敏捷知识讲解外，书中还记录了13位享有盛名并且受人尊敬的敏捷大咖的访谈内容。受访者包括，Bob 大叔、Mike Cohn、Scott Ambler、Lyssa Adkins、Alistair Cockburn……本期为您带来Lyssa Adkins、Alistair Cockburn的访谈实录。
点此获取业界大咖谈敏捷（上篇）
唤醒者Daniel滕振宇，京东资深敏捷与创新顾问、《Scrum精髓》译者姜信宝，InfoQ中国总编辑崔康，《敏捷无敌》作者、《敏捷开发一千零一夜》主编王立杰，软件工匠和敏捷教练姚若舟，精益看板国际认证讲师、前微软过程改进经理王明兰，资深软件工程师Gary Zhang联袂力荐。
Lyssa Adkins 访谈
Lyssa
Lyssa Adkins 的Coaching Agile Teams 一书把敏捷教练的实践提升到了一个新的高度。自2004 年起，Lyssa开始教授Scrum及敏捷教练课程。她指导过很多敏捷团队并作为master coach 对实习教练进行考核。在进入敏捷领域前，她在领导项目团队及项目经理团队方面已经拥有15 年以上的经验。她相信敏捷不仅仅是一种可行的项目管理方法。为了最大程度地展现敏捷的能力，她致力于深化敏捷中的角色——尤其是在敏捷教练及敏捷经理方面。她拥有多个认证，包括Scrum认证教练（CSC）、Scrum认证讲师（CST）、项目管理专业人员认证（PMP）、六西格玛绿带（SSGB）及组织与关系系统认证教练（ORSCC）。她还是一位受训的共创式教练和领袖。
Q
对一名Scrum master 来讲，什么是最重要的技能？
Lyssa：首先，作为Scrum master 最重要的目标是帮助团队提升工作效率，创造出引以为豪的产品并满足广大用户的需求。但令人惊讶的是，技术或产品知识并不是一名成功的Scrum master 的关键特征。事实上，太多的专业知识甚至是不利的，它可能会导致这名Scrum master 会一直“冲在前线”。在敏捷方法中，团队成员才是应该“冲在前线”的，这也是非常正确的。他们具备领域和产品的专业知识，并且他们还知道实现产品的最佳方案是什么。这就让Scrum master 可以腾出精力去思考一些流程层面的问题，比如团队对敏捷流程的掌握情况如何？他们可以有效地沟通吗？他们可以将冲突转化为积极的因素吗？团队开发出的产品是创新并且有价值的吗？这是一个完全独特的角色，相比任何专业知识，这个角色更需要具备一组工作技能。这个层面的工作，要求Scrum master 具备的关键技能是引导、培训、辅导及专业的教练技术。这些技能可以让他们应对各种团队动态问题，无论是整个团队层面还是对那些已经厌倦了变化的个体成员。这些技能还能帮他们有效地处理敏捷之路上的各种阻力。当然，对敏捷原则及敏捷价值观的深入理解也是至关重要的。哈，这才是Scrum master 的专业领域，他需要将这些知识传播给团队。注意，这只是众多领域中的一个哦。
Q
Scrum master 如何不断地成长？
Lyssa：虽然Scrum 是由于软件开发才被引入到组织中的，但它并不仅仅停留于此。它会逐步深入到组织中。首先，它要求业务人员肩负起产品领航员的角色，然后它甚至会挑战组织的既有流程、架构及领导力文化。这可是对Scrum master 的巨大挑战。为了迎接组织层面的挑战，Scrum master 会从服务于一个团队，发展为服务于整个企业。在这条敏捷之路上，他们需要具备很多的技术和模型以应对各个层面的人员。他们需要努力进行自我发展以提升个人的领导力。当他们需要和执行官一起工作时，这个特质会非常重要。在入门阶段，Scrum master 服务于一个团队，他是贴身的Scrum 向导及团队发展教练。他们的主要目标是帮助团队用好Scrum。他们还帮助团队扫清道路上的障碍。当Scrum master 具备了Scrum 的经验并开始指导团队的动态时，他们就开始成长为一名敏捷教练了。
Q
在刚刚开始实践敏捷的企业中，什么样的内部人员最适合担任Scrum master 的角色？
Lyssa：最适合转型为Scrum master 的人，是那些乐于帮助别人同时着迷于提升团队动态的人。一个人之前的角色和专业知识并不能决定其在Scrum master这个角色上的成败。学习Scrum很简单，但要帮助其他人掌握Scrum就很难了。为了完成这个使命，这个人需要在团队开发卓越产品的同时帮助他们进行自我提升。
Alistair Cockburn访谈
Alistair
Alistair Cockburn 博士，Humans and Technology 公司的合伙咨询师，以帮助企业成功开发软件为己任。包括制定企业战略、有机整合敏捷方法和现有方法、指导和培训员工、设计新的过程、改善设计质量、管理项目、协助进行技术设计。Cockburn 博士从1974 年开始设计硬件和软件系统，主导了包含硬件、软件、研究及系统应用程序的多个项目。他是一名国际公认的敏捷开发和面向对象开发的专家，作为协作引导师广受赞誉，同时还是一位知名的培训师和演讲家。
Q
在实施敏捷转型的过程中一般会有哪些令你惊奇的事情？有经历过针对水晶方法族的意外的回应吗？
Alistair：让我感到惊讶的事可能与你想象的不同。大家通常认为我（我们）应该惊讶于人们在采用敏捷方法时做得有多不靠谱，或他们如何误解我所表达的信息等问题。但这些问题其实并不出乎预料，而且我也不认为这会让其他的敏捷创始人感到惊讶。我的观点是你要么被曲解要么被忽略，期待人们完全理解你并照着你的意思办是不现实的。话虽如此，有一件事确实让我们这些编写宣言的人感到吃惊，那就是业界接纳敏捷的速度是如此之快—简直就是几个月的时间。我们在2001年2 月编写了敏捷宣言，当年夏天就成立了相关的委员会，第二年（2002年）就有了专门的会议。2003 年年末已经有两家大公司明确在合同中规定要使用敏捷的方法。这种被采纳的速度是非常快的，虽然PMI 和IEEE等了接近十年时间才接纳它。另外一件对我个人有触动的事情是，业界已将改进反思会和其他适应性的方法作为核心的敏捷方法了。2001 年的会议时，在我看来举办月度反思这一改进会议的想法对于绝大多数团队来说还是遥不可及的。2001 年工作坊上呈现出的众多方法在形式上是基本固定的，不像水晶方法那样具有可塑性——这些方法确实是“敏捷的”，但不是特别具有“适应性”（举个相反的例子，RUP 是“适应性”的但不是特别“敏捷”）。令我吃惊的是，五年以后，绝大多数实践者已经在其方法中将持续改进和敏捷进行了整合，持续改进已经成为其核心理念和实践了。这对我来说真是个惊喜，因为早在1991 年，适应性的方法就已经融入了我的血液。
Q
你期待人们从水晶方法族中领悟到的最重要的理念是什么？
Alistair：逐步实现你的目标；关注团队的沟通质量；每个月都尝试一些新东西，以探索改进之道。这看起来像是三件事情，但每一项都是水晶不可或缺的。
Q
对于入门级敏捷实践者，你有什么建议吗？
Alistair：为真正的用户提供尽量早、尽量频繁的交付；关注于团队的沟通质量；每月尝试新东西来探索改进之道。
Q
当我们展望软件开发的未来时，你对敏捷方法的愿景是什么？
Alistair：我不确定它是一个愿景还是一个渴望。20 世纪90 年代，我们承受着北约（NATO）1968 年和1969 年软件工程会议以及由此引发的所有争论的重负，这一切带给我们的是瀑布式开发和重型的、不人性化的、预测式的方法。伴随着敏捷宣言，我们挣脱了这些负担。我和其他人的研究做了大量工作去阐明对于设计工作来说该如何提升团队的工作效率。所以我们现在已经知道为什么要敏捷，以及有哪些东西是需要调整的。在实施敏捷时经常出现的问题是：缺乏思考、草率行事，以及自欺欺人地认为敏捷已经解决了所有问题。我反对这种做法。我希望大家可以保留自己的思考，不断磨砺自己的思维，最终达到青出于蓝而胜于蓝的境界（我最近将这些观点记录了下来，称为“正规的学习”，详见我的网站）。如果能做到这一点，我们就能两全其美了。未来会这样发展吗？我从不推测这类事情。还是让我们拭目以待吧。
Q
你认为是否会出现敏捷方法一统天下的局面，或者说，你认为像瀑布这样的传统方法会一直在软件开发中扮演重要的角色吗？
Alistair：瀑布的策略是计划式、阶段式的，它只在最后进行一次集成和交付。确实有项目（这类软件很少）只能在最后进行一次集成和交付，为了应对这类情况，对这类知识的需求还是会持续存在的。不过瀑布方式继续存在的更主要原因是，大部分情况很多人其实就是简单地不愿意接受改变——这个问题可能还会困扰我们数十年。
