本月初, 身为敏捷教练以及 Energized Work 创始人的 Simon Baker 根据其以往经验发表了一篇有关敏捷方法论的独特有趣的观点。该文题为《No bull》, 你可以从 Energized Works 的服务器上下载到pdf 格式的版本。Simon Baker 乐意为InfoQ 的读者们解答一些问题。
InfoQ: 您为什么选择在这个时候写这篇文章呢——要知道您之前有 12 年的敏捷经验？
Simon Baker: Shane Hastie 向我约稿，该稿会作为 InfoQ 的 Gordon Pask 获奖者系列文章的一部分。《No Bull》就是这样开始写起来的，它会作为敏捷宣言 10 周年纪念的一篇文章。最后，我打算多写点，基于我 12 年在极限编程（Extreme Programming）上的经验以及我目前的一些想法。
InfoQ: 您发表这篇文章有什么特别的意图吗？
Simon Baker: 我是打算分享我的一些经验，这也是值得去做的，我要谈谈目前对这些有关敏捷的东西的看法。
文章副标题提出了一个问题：经历了 12 年的时光，软件开发的世界是否有所改变呢？我并没有想刻意去回答这个问题。就像我曾对 Jerry Weinberg 说过，这是为大家愿意讨论的某个话题设定一个框架罢了。我们也应该扪心自问，如果没有敏捷方法，我们现在又会怎样呢？一定程度上，我希望《No Bull》能够让大家暂时停下脚步、回顾一下过往、思索一下现在——为那些美好的事物喝彩，反思那些不好的，并探究原因，想想至今走过的路以及未来的方向。
有些人说《No Bull》是老生常谈。我不知道大家现在都那么追求新意了。为什么一定需要新鲜事物来博取眼球呢？现在真的有什么是正儿八经创新的吗？有些人问我想从读者那儿得到怎样的行动反馈。事实上我的本意并不是要教大家应该做什么。
InfoQ: 您在 twitter 和博客上介绍了很多和这篇文章相关的事情。您还打算用其他什么方法来推广这篇文章吗？
Simon Baker: 我并没有打算向谁吆喝《No Bull》，而是很乐意听听大家的反馈。我想知道大家看了这篇文章之后想要些什么。如果激起某人的共鸣或者是反对意见，我想大家自然会讨论并且分享这篇文章。如果有人觉得这篇文章很有用，那自然会用到益处。总之，它涉及到很多方面。或许我可以将范围缩小, 写些更具体的文章，如果时间允许的话。
Twitter 用起来比较方便。还有不少人在用博客。在 LinkedIn 上也有一些相关讨论。大多数的评论通过电邮传达给我。这周我很高兴能够应邀去谈谈《No Bull》。我很乐意去交谈，哪怕只是在喝咖啡的时候闲暇时候做一些非正式的问答。Gus Power 是 Energized Work 的创始人，也是 6 月份电脑周报创办的 IT 领袖论坛，CW500 俱乐部的大会发言人。他会就软件开发的未来做一些讲话，我敢说他会用到一些《No Bull》的思路。
InfoQ: 您在文章中提到很多有关大型海外团队的开销问题。您之前有过在分散型团队工作的成功经验吗？您有什么好的策略是可以适合这种模式而不会造成浪费吗？
Simon Baker: 简而言之，答案是没有，如果你所谓的成功是指在预算内有计划的交付正确的产品，并拥有成本低廉且品质较高的软件的话。这涉及到交付周期以及延迟交付的成本问题。如果人员分散势必会延长客户诉求到产品交付的时间；交易和沟通成本都会提高。当然了，分散团队是可以有效地工作的——37signals 就是一个很好的案例。问题在于如何进行简单设置，安排有激情有能力的人员为团队工作，无论他们身处何处，而并非只是寻找一些教条化的拥有所需技能的替代资源。
组建海外离岸团队的决定往往是由成本驱动的。当项目变得庞大起来，人力成本的增加就会成为问题。事实上有很多项目并不需要做得那么大，而他们却把它过分复杂化了。我记得某公司的 CTO 说过他们的离岸开发团队有 400 人之多。而他们需要承担的风险是有可能其电子商务网站的后台比实际上的要简单得多，这么多开发人员真是多得有点可怕了。规模是个问题。我不认为大型项目配备大规模的离岸团队，再掺杂一些政治因素, 这就会是成功的配置。但是我真看过一些公司将这些作为 KPI，比如要求必须有 40% 的资本支出是海外离岸部分的。我不觉得这是个好的信号。“做最简单的事”不应该只适用于软件。一定会有更简单有效的方法将事情做好。
InfoQ: 文中您认为敏捷方法要以不同的方式得以应用。您觉得这对敏捷教练的工作来说有怎样的影响？是否公司外部人员在对业务和流程需求没有深入了解的情况下，也能帮助团队朝着更敏捷的方式工作？
Simon Baker: 我认为对于一位对敏捷和精益原则有深入了解的教练来说，方法不是问题。也可以这样说，有人会存在一些购买所谓“敏捷”商品的念头，业界也充斥很多敏捷教练，他们为了企业的需求而提出未经证实的建议。所以天晓得。你不能保证雇佣的这个教练能给你带来些什么。
转变往往将公司带到某个“地方”，他们在那儿开始做敏捷相关的事儿。对于公司而言所必需的是持续试验并将所积累的经验有效地应用在客户和利益相关人身上的这种能力。很多公司还没有意识到，他们所寻求的由更加敏捷而带来的种种益处，要求在人员操作准则和信念上有深刻的改变。如果环境不支持就不会有最终想要的结果。从公司外部招人，这对现有的观念、想法以及决策提出异议并挑战现状是一件很有价值的事。就像那句话说的“不识庐山真面目，只缘身在此山中。”那个外部人员会成为“系统”的一部分。但是敏捷教练并非万能。每个公司有其独特的内涵，改变需要得到管理层看得见的支持和切实有效的实际行动。无论大家平常怎么想的，就是不应该出现“事后解决 IT 问题”的情况。
帮助公司变革的技术可谓日新月异。我看到越来越多有关系统思维的东西，或许甚至是一些从约束理论中所重新发现的思维方式。我还注意到一些很成熟的看法将变革作为学习周期理论的一部分。现在的趋势是从教大家如何以不同方式工作，向与大家并肩工作并联合设计系统变更的方向转变。这说明了一种平衡需求和主张的方法，旨在帮助大家揭示驱动其思维、创造意识、勇于实践、以及最终促使更深入学习的一种信念和想法。这样的话会赢得大家的心，带来更多的新思路和变革所需的差异化行为。
InfoQ: 业务团队可以通过与系统运维团队目前所经历的类似的变革实现敏捷，所以在开发过程中他们不会成为瓶颈。您是否有过与敏捷业务团队合作的经历呢？您觉得这样的转变对公司如何设计其产品有什么影响吗？
Simon Baker: 业务计划、预算、以及设计理念等都是一些假设情况。迭代开发和持续交付会引起客户反馈并减少不确定性而且不需要额外的投资。只要变更的成本保持足够低廉，就可以与用户一起测试相关的一些想法和新点子，看看这些想法是否会奏效。这对我们来说是好事。不过对于那些业务人员来说我怀疑他们会觉得很可怕。
这 12 年来我一直试图让业务部门的人明白，项目开始时再详细的说明也不会减少将来的不确定性，一次性发布所有内容无异于赌博，孤注一掷地将所有预算一锤子挥下去。或许他们至始至终都是知道这点？或许这么做就可以隐藏更多说明需要花更久时间来交付的事实？作为业务部门的人员，一旦把需求给了 IT 部，或许我就没必要费脑筋去想到底客户需要什么；我随时可以进退。95% 的时候我都会汇报说：“一切正常，按目标进行。”因为这也正是项目经理告诉我的。这也强调可能存在一种紧迫，因为价值可能会和由关闭和业务决策上的交流而带来的透明性相冲突。
我们成立 Energized Work 就是想要提供一种端对端的交付能力，将其灌输给业务团队。通过连接日常的业务操作，大家会合作决定哪些产品或特征需要花钱去做，这会取决于逐渐被大家所意识到的可度量的收益。当一家公司内部有多个业务团队时，我们进行了进一步的延伸，引入了产品组合治理，关注与价值实现紧密联系的增长性投资，而不是根据计划好的里程碑以及预计的资金消耗率来跟踪进度。当业务部门双手牢牢控制了方向盘，所谓的竞争优势就基本不公平了。很不幸的是，我们一定程度上正目睹越来越多的业务部门愿意关起门来单独做决定。
InfoQ: 12 年的敏捷经验，您对现在发展的程度有感到惊讶吗？您觉得未来 12 年还会有很多变化吗?
Simon Baker: 我猜想自己本身热情的一面应该是没有耐心的，而且总是希望有更多的行动、更快的进展、以及更大的影响。而理智的一面，我知道这将会是一场持久战。Kent Beck 曾提醒我说我们所经历的变革会持续数十年。过去我们花了 50 年甚至更久才实现了量产，精益生产才广为接受。软件是一种新兴的技术。同时也是无所不在的。无论你怎么看待它，软件开发的潜力都是无穷无尽的。
毋庸置疑的是，下一个 12 年我们将经历的软件开发的过程会是缓慢的。问题的关键在于业务部门是否能与之更有效地融合？我希望高品质软件的价值在其拥有成本方面能够更好地得到理解，并且公司会在开发方面做更大的投入，希望他们明白只要有用户需求存在，持续收益总会实现而且所发生的支出也会随之越来越少。我期待着业务、技术、以及财务各部门能够想到一处，对客户和相关利益人重要的价值体现有深刻的理解。我期望看为了达到更加有效和有意义的结果，而做出的运维上端到端的重配。
我认为组织的变革，包括在工作地点以及工作文化、人员信念和行为方面的变革都能容纳进更加广阔而深入的社会政治变革。这将会是一个缓慢的过程。但是，我们总会时不时地听到一些新兴公司的涌现，比如 Semco 以及最近的 Valve。变革势不可挡。
关于被访者
Simon Baker 是 Energized Work 的创始人，2009 年度敏捷联盟Gordon Pask 奖项的获得者。他在全球范围内宣讲有关敏捷以及精益原则和技术在商务、软件开发、以及信息技术等方面的应用。Simon 有着20 年的软件行业经验，涉及的产业遍布媒体、零售、医疗、金融服务、及银行业等等，他不拘泥于传统思维，勇于突破现状。他深感工作不应该仅仅是看上去像工作的样子，他做了一个跟踪记录，记下了那些令人振奋的工作条件，它们能够帮助人们改变软件开发方式，为人们开发出更好的软件。你可以点击这里，阅读更多关于《No bull》一文的详细内容。
查看英文： Interview with Simon Baker, Author of No Bull
感谢侯伯薇对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。
评论