“AI 技术+人才”如何成为企业增长新引擎?戳此了解>>> 了解详情
写点什么

The Agile Mind-Set 作者访谈

  • 2015-11-29
  • 本文字数:3377 字

    阅读完需:约 11 分钟

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

2015-11-29 17:041124
用户头像

发布了 92 篇内容, 共 22.6 次阅读, 收获喜欢 4 次。

关注

评论

发布
暂无评论
发现更多内容

啃碎并发(八):深入分析wait&notify原理 猿码架构

猿灯塔

给 Spring Boot 项目减减肥!18.18M 到 0.18M 是如何做到的?

给你买橘子

Java 程序员 Spring Cloud 编码 SpringBoot 2

区块链+高考,让世界再无冒名顶替

CECBC

【Java虚拟机】垃圾收集器与内存分配

烫烫烫个喵啊

Java Java虚拟机

图解:深度优先搜索与广度优先搜索

淡蓝色

Java 数据结构 算法

计算机操作系统基础(十七)---进程同步之Unix域套接字

书旅

php laravel 线程 操作系统 进程

终于有人把Elasticsearch架构原理讲明白了,感觉之前看的都是渣

爱嘤嘤嘤斯坦

Java elasticsearch 编程 架构

一个爱不释手的Apifox,让我扔掉 Postman的想法

给你买橘子

Java 编程 程序员 开发 Postman

游戏夜读 | 如何分析游戏体验?

game1night

微服务架构下分布式事务解决方案

Arthur

16种设计思想 - Design for failure

Man

Java 微服务 设计原则

啃碎并发(九):内存模型之基础概述

猿灯塔

Java 猿灯塔

猿灯塔:spring Boot Starter开发及源码刨析(三)

猿灯塔

Java 猿灯塔

使用 Dockerfile 创建镜像 | Docker 系列

AlwaysBeta

Docker 容器 镜像 Dockerfile

架构师必须知道的架构知识

Chank

架构 架构师 Architecture Architect

如何基于 BitMap 进行海量数据分析

GrowingIO技术专栏

互联网 数据分析 科技互联网 数据化

图说前端-内存管理(1/3)

梦见君笑

大前端 内存

《精益思想》读后感分享

zhongzhq

高效工作 精益 精益思想 精益生产方式

redis系列之——Redis为什么这么快?

诸葛小猿

Java redis 程序员

DOM 树的构建

法正

html 大前端 DOM

基于Kubernetes实现的大数据采集与存储实践总结

岿然独存5

Docker Kubernetes S3 EFK Fluentd

Docker基础修炼3--Docker容器及常用命令

黑马腾云

Docker Linux 容器 命令

实验室里的AI激情:腾讯优图的升级修炼之路

脑极体

Git 常用操作汇总-cheat sheet

多选参数

git GitHub gitlab gitee

刘华:上云还是不上云,这是一个问题

刘华Kenneth

架构 敏捷

如果你想写自己的Benchmark框架

程序那些事

JVM 性能调优 GC benchmark

无价值人生记录.0:浪费1000%时间去做一个用来节省1%时间的“轮子玩具”(上:因缘)

八苦-瞿昙

C# 程序员 随笔 随笔杂谈 aop

如何搭建一个HBase集群

Rayjun

HBase

SpringBoot入门:01 - 配置数据源

封不羁

Java spring springboot

创业使人成长系列 (2)- 散伙协议

石云升

创业 股权 合伙人 散伙协议

玩转Redis高可用 - 哨兵(Sentinel)模式

Man

高可用 redis高可用 中间件

The Agile Mind-Set作者访谈_Book Review_Ben Linders_InfoQ精选文章