The Agile Mind-Set作者访谈

在 The Agile Mind-set书中，Gil Broza探讨了敏捷价值、信念和原则，并解释了他们如何使用这些，推动敏捷实施。本书提供了思路、案例、和轶事，组织可以参考它们，转向敏捷。

你可以下载一份 the Agile Mind-set样本，对本书有个大概印象。

InfoQ采访了 Gil Broza，主要关于改变思维定式、应用敏捷实践、你可以从稳定团队中获得的好处、为什么改进会止步不前，和如何处理这种情况、以及组织如何检查敏捷是否是适合他们的方法。

InfoQ：什么使您决定写一本关于 the agile mind-set的书？

Gil Broza：十多年来，我一直目睹着组织挣扎在转向敏捷的过程中。这三种情形看起来无处不在：

• “我们正确地做了所有的事情，但是……”——结果不太令人满意，并且他们不知道为什么。
• · “这种变革比我们想象的要大得多……”——他们引入敏捷实践，但是他们不能“坚持”（stick）或者不能交付承诺的结果。
• “这是敏捷”……“不，这不是！”……“当然是！”——人们充满了困惑，人们不知道如何在这种新的框架下取得成功。

我还了解到，当人们在网上或者文献中搜索答案时，他们被告知“他们应该运行敏捷思维定式”——但是没有搜到可用的解释。敏捷宣言也不能帮助他们，应为它太简洁了。我写这本书就是为了弄明敏捷真相。尤其是，我希望脱离特定的实践和框架，解释敏捷思维。

InfoQ：您能分享一下您对敏捷思维定式的看法吗？

Gil：跟任何工作有关的思维定义一样，敏捷思维定式有三个要素：

• 价值：你认为现状中最重要的是东西
• 信念：在那种情况下，你深信不疑的东西
• 原则：指导你的选择、决定和行动的标准内容。

如果你拥有了敏捷思维定式，有四件事对你而言是极重要的：以人为本、适应、及早和频繁地交付价值、和客户协作。你持有一定的信念，比如说工人，其作为人类，一定会犯很多的错误，但是你可以通过以自组织团队的形式协作，降低这种风险。你遵循一定的原则，比如协作、简单、效力优于效率、和推迟决定到最后责任时刻。如果我不得不将敏捷思维定式浓缩成一句话，我会说：通过反馈和适应取悦客户。

InfoQ：人们有没有可能改变他们的思维定式？团队呢？组织有没有可能？

Gil：我们身边充满了人们改变思维定式的证据。它不是那么的容易或快速，并常常需要支持和耐心，但是它是有可能的。团队和组织也是一样的，因为它们是由人组织。但是，作为群体，他们文化和习惯的影响力是非常强大的。

InfoQ：您是否亲眼目睹过团队在没有合适的思维定式情况下，使用敏捷实践？

Gil：至始至终我就见过两种这种模式。第一种模式中，团队遵循指示；他们把敏捷等同于一组实践，并且认为通过以某种方式应用这些实践，他们将会敏捷。例如，他们在每日例会上报到，并回答三个问题；他们捕捉他们的用户故事，并以具体的方式评估它们；或者他们编写自动化测试。他们在没有思维定式意识或者理解的情况下，完成这一切。在第二种模式中，团队引进与敏捷相关的实践，但是他们的方法很明显是不敏捷的。例如，他们使用每日Scrum例会作为状态会议，或者产品待办事项作为产品计划。这两种模式只会产出令人混淆的过程和平庸的结果。

InfoQ：在书中你解释说，在采用某种敏捷范式之前，人们应该首先探索目标和价值。您能解释一下吗？

Gil：并非所有的工作情境都应该给敏捷让步。当你有工作要做时，首先了解它的目标：会带来什么不同？这种不同为什么值得？然后，与假设相比，你应该使用敏捷或者 Scrum或者精益完成工作，并完成这些目标，识别你的价值。为了完成这些目标，什么对你而言是重要的？你支持什么？例如，你可能想要明确的规范和承诺，但是响应改变、频繁交付、与客户协作可能更加重要；没有这些，可能会使项目失败。在这种情况下，敏捷就是一个有效的选择。在另一个案例中，与适应和及早交付价值相比，及早承诺和在第一时间获得解决方案 更加重要，所以计划驱动的范式，比如瀑布式就会更加有吸引力。

InfoQ：你可以从稳定团队中获得的好处是什么？

Gil：一些可交付的成果不能或者不应该由一个人完成。只要我们继续雇佣团队交付成果，随着他们学会有效地协同工作，我们就可以期望降低他们的综合生产效率。这是我们进行的投资，但是如果团队最终胜过个人，那么这种投资就是值得的——有积极的协同作用。如此，稳定的团队能够最大限度地回报我们在其身上进行的投资。

当成员共同解决问题时，基于思维和经验的差异，积极的协同作用就会很明显。同样，当成员帮助陷入困境的同事，或者在掉入兔子洞之前抓住他们时，积极的协同作用也是很明显的。稳定的团队比无关联的个体保留更多的适用性知识，所以他们重新学习时会浪费更少的时间。最后，与新团队相比，管理稳定团队花费的组织精力更少，这意味着成员和领导可以为额外有价值的成果投入更多的关注。

InfoQ：书中提到“传统开发为编写代码优化，而敏捷为阅读和改变优化”。您能否解释一下这是什么意思？

Gil：在传统开发中，人们花时间收集需求，并有授权实体对其进行签字保证。这时，开发人员为满足规范编写代码，假设该规范是正确的：这一路上他们就不应该期待任何显著的变化。因为相关成本，也会有一些人积极地推迟变化。由于程序员合理地期望实现整个规范，他们就可以（应该）优化他们的编写过程。

敏捷实践者非常重视调整，他们预测变化并欢迎变化。这在使用敏捷方法进行计划时尤其明显。但是前提是在敏捷工程内：改变代码的行为——可能相当频繁——必须是经济的。通过阅读代码开始改变代码，所以他们会加倍关注编写代码，传达其意图、逻辑和流程。他们的编写习惯导致可塑性的代码，并当需要时为调整代码使用安全、经济的技术。而且由于团队共同分享交付职责，这些陈述均使用整个团队。

InfoQ：为什么改进会止步不前？有没有如何处理的建议？

Gil：改进工作止步不前或者失败的一个原因是它们的抽象属性。将注意力和压力从当前转移到未知的未来，并希望做得更好，需要大量的脑力劳动。敏捷通过希望团队能够频繁自省和调整，解决这个挑战，但是它没有设置进一步的期望。因此，团队可以很好地控制改进或变化的范围，让其更实用和适用。

改进停滞不前、不温不火、或者无计划性的最大原因是，改进者是人。改变会受到伤害，直到改变趋于稳定，发生的错误可能会让人感觉到失败。一些改进意味着不足；发现或者指出不足可能是一个有风险的提议。在商业环境中，团队成员可能会担心高级管理人员和利益相关者等群体的推论。并且要人们移除这种顾虑，将持续改进作为一个随时可行动的原则，需要尊重、支持、和安全文化、以及领导力的支撑。同样，你需要关注的不仅仅是提高输出度量（比如速度），还需要关注发展一个可靠团队，这样团队自己将会关注输出的提高。

InfoQ：对于组织如何检验敏捷是否是适合他们的方法？

Gil：在回答前面的问题时，我解释过在特定情况下，如果你的价值与敏捷是一致的，那么敏捷对你而言就有吸引力。这意味着敏捷或者其它思维定式的选择是根据情况不同而不同的。看看这四种价值，认真想一想，“这些是我们的价值吗？我们的行为方式是否反映出了这些价值？我们希望这样子吗？”考虑大多数组织赖以为生的价值也是非常重要的：降低成本和计划、及早承诺、第一时间做正确、用标准化的流程。

当你思考这四个敏捷价值，你会注意到它们是不一样的。第一个价值——个人高于流程——很大程度上是文化问题。你的文化是否与它是一致的？或者你是否仅仅拥抱适应、交付价值、和客户协作，但是仍然把人看成可计算的“资源”，基于技术技能和可用性组建团队？如果你希望用敏捷方式实现大量工作，你必须调整你的价值使其与敏捷相适应。这么想：你的一些工作是敏捷的，但是其它会从瀑布式中受益。你可以在以人为本的环境下成功运行瀑布式项目，但是你不能在流程优先的环境下很好地运行敏捷项目。

关于作者

Gil Broza帮助软件组织建立并领导忙碌的、可靠的、高效的敏捷开发团队。他在创造有效的、人性化的、负责的工作环境下指导团队和负责人，所以他们能够真正取悦客户，并产生积极的影响。他是一名“全才”，能够服务不同的组织级别，指导人们的技术和领导行为。Gil最近一本书，The Agile Mind-set，帮助从业者真正实现工作的敏捷。他早期一本书，The Human Side of Agile，对领导敏捷团队而言是一本明确的实用指南。他是 the Agile series of conferences的定期撰稿人，和三次 track chair，并且是 projectmanagement.com的敏捷作家。

查看英文原文：Q&A on The Agile Mind-Set