在 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
评论