写点什么

Tobias Mayer 访谈:人的 Scrum 和 AgileLib

2014 年 6 月 16 日

Tobias Mayer 编著的《人的 Scrum》是他在 2005 到 2012 年间基于原始素材所写的一系列短文。

这些短文叙述了敏捷的理念和实践,包括如自组织、协同工作、技艺、技术债、估算、回顾、文化和 Scrum 应用等主题。

InfoQ 对 Tobias 进行了采访,主题为关于人、团队和自组织对于 Scrum 的重要性和 AgileLib.net (一项共享敏捷资源的新行动)。

InfoQ:你的书叫作**“人的Scrum”。为什么要强调”**,什么使它们如此重要?

Tobias我不是指所有的人。它和之前所说的工作人员的 Scrum 是一回事。这个标题来自于早先的一篇博客,这篇博客针对的是越来越多的组织倾向以自顶向下的方式在团队上推动 Scrum。如果那些正在开展的工作能够拥抱 Scrum,并使其以一种有意义的、周到的、健康的方式去适应环境,就能取得最好的 Scrum 效果(也可以说只有这样它才能发挥作用)。向一组工作人员推行任何流程的时候都将遇到这两种反应:抵制或是服从。这两种态度与我们在 Scrum 中寻求的协作精神背道而驰。

那么是什么使工作人员如此重要呢?我想读者们自己会找到答案的:)

InfoQ**:您认为什么是Scrum,什么又不是Scrum?**

Tobias: Scrum 是一组已得到经验证明的工作实践,它以一些核心的人文价值和文化为基础,也就是大家所熟知的创建开放、信任、创造性的环境。Scrum 不是一种流程。它勉强算是一个框架。它通常本身是已经实现了的,而这经常带来些烦恼。大家只是在做这些事,却不知道为什么要这么做。

学习 Scrum 是一个纠正坏习惯的过程,比如那些从 MBA 课程上沾染回来的坏习惯以及从以往的经历中养成的坏习惯,但是,早在上学期间就养成的坏习惯或许更具破坏性(并且更加顽固),那时把合作称为作弊,把创造性思维当成胡思乱想。

Scrum 并不是一件事物,就像事物的残缺一般。它就是其中的空隙。当我们看一棵树的时候,我们看的是叶子。但我们很少注意过叶子之间的空隙,那些毫无意义的空气,那些渗露出来的光让叶子有了轮廓,让它有了纵深和色彩。Scrum 强调一种反思的心态。它可以被看成是繁忙工作日中的空隙,命令与服从之间的空隙。我们先停一停,在此我们能客观判断事实,慢慢克服我们已经养成的习惯。Scrum(做得好的话)让人们以一种持续不变的、甚至从容不迫的步调行动,完成更有意义的工作。

InfoQ**:在书中你提到了Scrum团队的重要性。什么使团队协作如此重要,你能详细说明一下吗?**

Tobias: 在 Leonard E. Read 的幽默短文中有这么一段话。“我,铅笔”,这支铅笔说“……这个世界上没有一个人能够只从外表就判断出来我是如何制造的。”在“当想法有性别”的 Ted 演讲中 Matt Ridley 引用了这篇短文。它的重点是,某些东西就像一支铅笔那么简单(或者对于 Matt Ridley 来说,是一只鼠标),但实际上异常复杂,要创造它需要很多的思想和很多的技能。如果一个人能拥有制造这些东西所需的所有技能,倘若这件事还算不上骇人听闻的话,那说它极为罕见却是一点也不为过的。同理,软件产品也是这样的。

从本质上说这个问题有两种解决方案。一是工作分解,二是团队协作。我们最初的策略是借鉴工业革命的成功因素,让管理人员分解工作并把它们分配给工人。对于制作铅笔来说这可能是一个成功的策略,但以往的经验证明在知识性工作行业中这么做会带来惨痛的失败。铅笔是大规模生产的。而软件不是。它总是新的。知识工作者需要与其他人讨论,他们需要协作,他们需要快速做出实现上的决策,不必通过一个行政管理系统。出于这种需求,团队作为一种解决方案非常自然地浮现出来。接受其他人的详细指令孤立地工作已经是十九世纪的事了。这是我们需要抛弃的另一个习惯。

InfoQ**:如果在Scrum里人和团队都重要,那么哪一个更加重要呢?怎么平衡它们呢?**

Tobias团队是由人构成的。高效的团队是由热情、负责的人构成的。如果一个人在某个方面不开心了,那他就很难保持热情、负责的状态。所以在团队尚未完全成形之前,需要我们大家先考虑自己,保证自己开心愉快的状态。我的团队可能会变,但是我始终都是我,所以我最好还是找个方法乐在其中!

InfoQ:我看到许多组织想把他们的团队变成自组织时遇到了一些困难,你有没有看到过同样的情况?要解决这个问题需要做些什么呢?

Tobias你刚才所说的“成为自组织”是错误的。不管我们想还是不想,人文系统本身就是自组织的。我们需要做什么呢,作为管理者或者领导(或者工作人员)要去创造一个能以最为高效的方式蓬勃发展的环境。开发人员和客户需要去实验目标和边界,确定哪种方法可行,并做出相应的调整。如果我们把自组织想成一些新生(通常是令人担心的)事物,必须以某种方式去控制它,那么永远都不解决不了这个问题。这在逻辑上是不成立的。

InfoQ:自组织环境看起来是什么样的呢?你能举一些例子吗?

Tobias我觉得计划会看起来有点像露天会议。在一个产品开发环境中,产品经理或客户会把需求和不确定的事按优先级填到一块板子上。开发人员和设计人员将围在这块板子的周围,提问、倾听、提出深刻的见解,然后他们报名说对于哪些工作 i)感兴趣 ii)拥有所需的技能,鼓励有一技之长的其他人也加入进来,从而针对那个用户故事形成小型的、跨职能的团队。也许随着时间的推移,当大家知道喜欢和谁在一起共事的时候,将形成更加稳定的团队。由于这更多地取决于所处的环境,所以在此很难具体去讲。根本的原则是:让做事的人决定如何完成工作。充分理解这条原则,剩下的就是确立之间的关系、契约或协议,并不断地找办法去改进了。我们需要摆脱专家、经理和领导等等这些人指导大家“如何”完成工作。

InfoQ**:有些人把敏捷看成是个方法,这个方法让大家在一起工作向客户交付产品。对于他们来说角色、仪式和工件是敏捷里最主要的事。其他人则关注技能、工程或技术实践,以及个人的修炼。通常,Scrum与第一种 ****“流程的观点有些联系,而XP看起来更符合第二种专业的”**观点。对于敏捷你有什么观点,Scrum是如何支撑这一观点的呢?

Tobias:说到底“敏捷”就是一份两页的宣言,它针对的是如何高效地构建软件。我不确定除此之外还有什么含义。我们在采用新的工作方法的时候,敏捷、scrum、看板、精益这些术语仅仅是更便于我们的理解罢了。重新定义所有这些术语可是个大工程。Bob Marshall 呼吁适当的转变,其他人则讨论拥抱混沌理论。从本质上看,它就是一种从控制到释放的模式上的转变,从(公司的)监禁到自由,从敬畏到信任。全世界的经营之道正在发生着变化。敏捷只是其中的一小部分,即使它是其中很重要的一个。

InfoQ**:你的几个随笔讨论了你对Scrum的理解,它是什么,又不是什么。人们如何充分地理解Scrum?**

Tobias要充分地理解 Scrum,那就必须要理解它不是什么。我认为像这种理解能让我们更多地了解它的缺点,而不仅仅局限于它所带来的好处。这个世界充满了 Scrum 专家,那些疲惫、守旧的项目经理们仅仅把这个词挂在脸上当面具罢了。为了擅长 Scrum,你应该理解目标、关注点、发布和校准的原则,然后抛弃角色和流程,特别是要抛弃所有的跟踪工具。

InfoQ:跟踪工具有什么问题么?

Tobias其实,它本身没什么问题。如果你希望跟踪你的工作,有套工具当然会很有帮助。我妻子和我使用一个小的粘签看板去跟踪我们的家庭事务和个人项目。它的确很有用。问题在于,大多数跟踪工具的设计初衷是让管理人员去跟踪其他人的工作。这种层面上的跟踪阻碍了质量和生产力。我注意到很多团队使用了许多电子跟踪工具。这些工具很少是开发人员按他们自己的意图选择的,这通常会变成无用的管理成本。它带来了不必要的麻烦。

InfoQ**:许多组织采用Scrum是从一种项目文化开始的。他们习惯了使用任务分配、预算和项目小组的项目管理,要找方法使项目适用于敏捷。你对他们有什么建议么?**

Tobias你不能把一枚圆的钉子敲进一个方孔里。不管是敏捷、Scrum 还是精益,它们都是非常自然的工作方法。如果你们难以完成转变,那么很可能就是因为你们现在的工作体制本身就极其违反自然规律的,很可能其中含有巨大的浪费,只不过你可能对此已经熟视无睹了。所以你要带着置疑的态度去做每一件事,抓住每个时机问问为什么。不要草率地执行敏捷。卸下旧包袱后重新开始。

AgileLib.net 已经在 2014 年 1 月正式发布了:这是一个与敏捷相关的资源库,它是由敏捷实践者为敏捷实践者创建的。它包括引用的书籍、博客、文章、白皮书、视频、幻灯片、免费工具、用户组、社区论坛和其他的资源,这次变革的动因是为深入地理解敏捷带来帮助,并且为敏捷从业者和敏捷教练的个人职业发展带来帮助。

InfoQ**:大家可以在现在已有的一些网站和论坛上共享敏捷文章和链接。那为什么还启动AgileLib呢,你期望它补充些什么呢?**

Tobias大家经常在 LinkedIn、Twitter 等网站上共享文章和链接。这很好,但是有两个问题。它们很快就会消失,你很难把它们找回来,而且它们通常只是些个人的推荐。很多咨询公司提供图书列表,但没有告诉你是否应该在另一本书的基础上来读这一本书。你需要到亚马逊、GoodReads 或其他地方去了解这一点。而 AgileLib 收集了很多敏捷开发者的推荐,并把信息保存到一个单独的、可搜索的数据库。在“关于”的页面上它是这样声明的:优秀的敏捷需要持续不断地学习和探索。很多已有的资源是对这段旅程的有力支撑——但同等数量的资源也会把你带上弯路。你如何找出来什么是真正有用的呢?答案是去问问另一个敏捷开发者。哦,我想可能还不止:或者是十个、二十个敏捷开发者。

InfoQ**:在AgileLib网站上的活动日志展现了贡献者们做的每件事,比如增加一个新的链接、推荐的内容或者追随者。为什么公开这些信息?这对贡献者有哪些影响?**

TobiasAgileLib 旨在营造公开的社区,在此共享信息。你也可以选择是否公开个人的追随和收藏,但是如果你正在推荐这些东西,那么保密还有什么意义呢?我们的目的就是共享我们的知识,以及我们热情。

InfoQ**:贡献者们在AgileLib上推荐了很多的链接,你能从中选一些很赞的共享给InfoQ的读者们吗?**

Tobias:我从我的书签列表中推荐几个吧。前三个我不确定之前是不是已经在库里了,很高兴我还记得第四个是库里的。我了解和信任的人都很赞同这几个。我也一直都在阅读它们,所以真说起来也不算是他们的推荐:

在库中最受欢迎的是由 Esther Derby 和 Diana Larson 共同推荐的 Agile Retrospectives

InfoQ**:你有没有对AgileLib做过未来的打算?**

Tobias无非是发展这个库和会员人数。并找些其他的人来帮助我。我也希望从用户那里得到更多的反馈意见,从中发现怎么做能让他们在这个网站上获得更好的体验。

InfoQ:在这次采访中,我们讨论了两个非常独立的课题。**“人的Scrum”“AgileLib”**之间有没有联系?

Tobias我之所以被 Scrum 吸引,其关键原因(那是 2003 年的事了)多少和 10 倍生产率的承诺或过程是有些关系的。社区承诺的是崇尚平等的工作方式,我被这种工作方式深深地吸引了。我的经验告诉我,开发人员需要一种更加协作的方式走向成功。他们需要成为平等的社区、合作的公民,而不是由管理者引导的团队。在企业的世界观里这种领导和跟随者模式(大部分仍然是这种模式)是典型的社会结构。Scrum 让我们有机会换一个方式去思考社会化,这是另一条路。

在 Scrum 的大千世界中我找到一小组热情洋溢的探索者,关于人和工作方式他们分享了类似的想法,并提出了新的观点去挑战我的假设。我找到了一个优秀的社区。在我自己的技能不断成熟的这十几年间,社区创立或发展也一直在推动着我的前进。AgileLib 是迄今为止又一个精神展现。我希望它成为一个共享的场所,去探索和学习;一个时常前往的地方,磨砺你的敏捷思维,增强你的工具箱;一个使你的社区会员不断升值的场所,无论他们身处哪个领域。

关于本书作者

Tobias Mayer在软件开发、出版、戏剧艺术和社区服务工作有深厚的背景。在过去的九年时间他曾经是一名变革推动者、教练和引导者,为希望转变工作方式为更加敏捷、信任和团队至上的团队和组织提供指导和咨询服务。

查看英文原文: Interview with Tobias Mayer about the People’s Scrum and AgileLib

2014 年 6 月 16 日 23:34704

评论

发布
暂无评论
  • 书评:The Scrum Field Guide

    Mitch Lacey撰写了《The Scrum Field Guide:Practical Advice for Your First Year》一书,在书中他针对如何实施敏捷开发和极限编程的实践阐述一些自己的观点。InfoQ的Shane Hastie评阅了该书并针对实施的相关方法与作者进行了沟通。出版商为InfoQ的读者们制作了示例章节以供参考。

  • 变化中的敏捷认证

    Scrum和敏捷认证现在是人们的焦点。“认证的故事”正在逐步成为2010年辩论的焦点。这个故事包括很多方面,Scrum联盟、Scrum.org和广大社区都有其行动,社区方面的行动来自知名博客写手以及“敏捷技能项目”。认证的基本价值成为讨论的中心。

  • 特别放送(三)| 学习 DevOps 不得不了解的经典资料

    为了让你在专栏之余可以更加有效地持续学习,我特意整理了一份我认为DevOps从业人员需要了解和关注的资料。

    2019 年 11 月 28 日

  • ScrumMaster 项目面谈诀窍

    ScrumMaster或者迭代经理在敏捷团队里面是一个关键角色,而且,对于ScrumMaster,选择与哪个组织合作或者与哪个团队共事是非常重要的——在考虑是否接受一个新项目时,很重要的是创造一个取得成功的环境。本文提供了一些面谈时的建议,可供ScrumMaster考虑是否接受项目或团队时参考。

  • 使用 Water-Scrum-Fall 交付软件

    Water-Scrum-fall通常被描述成一种混合的敏捷工作方法。根据 Andy Hiles所说,Water-Scrum-fall是一种封闭的、阶段性的软件交付方法,其中 Scrum是最主要的开发管理方法。它可以作为通向敏捷、成为活生生的敏捷组织的跳板。

  • 第 89 讲 | 刘俊强:做好一对一沟通的关键要素(下)

    本文将跟大家分享更多实践,包括如何在一对一会议中倾听对方需求并分享你的需求,如何评估会议结果并跟进完成情况等内容。

    2018 年 9 月 18 日

  • 白天开会,加班写代码的节奏怎么破?

    开会是有价值的,开会是有成本,会议是不是高效,就看它创造的价值是不是高于其成本。

    2019 年 3 月 26 日

  • Scrum Master 的成功定义是什么?

    有经验的Scrum Master们解释了他们如何定义和衡量Scrum Master的成功,并分享了有关如何获得成功的经验。从处理干系人,到如何改进教练技能以及如何帮助团队达到可持续发展的步伐。多年的经验教训将有助于你改善Scrum Master的表现。

  • 预习篇 · 小鲸鱼大事记(二):崭露头角

    解决了应用打包的技术难题,同开发者与生俱来的的亲密关系,再加上PaaS概念已经深入人心的完美契机,是Docker项目一举走红的重要原因。

    2018 年 8 月 29 日

  • Kanban in Action 新书问答

    Kanban in Action 是Marcus Hammarberg 和 Joakim Sundén的最新著作,介绍了如何用看板结合实际实施管理。其中提到如何使用看板将工作可视化、跟踪进度,限制在制品,以及使用哪些度量指标进行改进。书中同时介绍了一些游戏和练习,可供学习看板原则。

  • 敏捷是怎样改变测试管理的

    敏捷方法中内建了许多传统的测试管理活动,随着人们对敏捷团队特性,例如自组织、角色的模糊化以及技能的多样性的期望,测试管理的性质也随之改变了。我们必须回答的问题是,在高效的敏捷组织中,测试经理这一角色是否还有存在的必要?这一角色一直以来所从事的这些活动又是如何被剥夺的呢?

  • 和专家沟通出现冲突时,我该怎么办?

    如果说沟通有一个心法,我觉得就是坦诚。坦诚沟通不一定能解决所有的问题,但这是通往解决所有问题的唯一路径。

    2019 年 6 月 28 日

  • Kanban Change Leadership 作者访谈

    在 Klaus Leopold和 Sigi Kaltenecker合著的 Kanban Change Leadership书中,他们研究了如何在组织内部署 Kanban以完成变革,和建立持续改进的文化。本篇采访主要关于循序渐进地实施变革、解决问题、使用限制在制品、Kanban中服务的优先级和级别,使用 Kanban约束理论,和使用 Kanban获得成果。

  • Scrum 认证迎来一个新的转折点?

    Scrum认证是一个永不消亡的争论。首先,它曾被认为是没什么价值的认证:“交学费,然后在课堂上坐几天,然后就学到了”。一个新的形式设计也没有能让反对认证的敏捷专家提起热情来。有了这么多教训,还有什么新的玩意能推出来吗?

  • Bob 大叔关于 Scrum 和敏捷的 7 条缺陷

    在回应Scrum/Agile的固有缺陷这一问题时,Bob大叔(本着马丁路德的精神)写了7条:缺乏技术实践、30天的冲刺周期太长、Scrum教练有时变成了项目经理,Scrum暗中包含了反管理等等。

  • 使用人物角色疏通中层管理

    在敏捷转型中,中层管理者这类“人物角色”(persona)可能会非常有用。如果能设身处地地了解中层管理者,那么我们就易于从他们那里有所收获。人物角色有助于我们了解哪些事情可问,而哪些事情不应该问,从而增加从中层管理者那里获得所需资源的机会。

  • 荷兰国家档案馆的 Kanban

    Bianca Griffioen在 Lean Kanban Benelux 2015会议上发表了演讲,关于荷兰国家档案馆(Dutch National archive)的基础设施和服务部门如何使用 Kanban可视化、优化和管理工作。InfoQ就他们为什么决定采用 Kanban,他们如何引入 Kanban和如何使用 Kanban,团队和利益相关者对 Kanban的看法和他们从中学到的经验教训,这些问题对他进行了采访。

  • 文化建设:哪些价值观能够提升团队凝聚力?

    想要促成组织文化的形成,首先就要公开问题、暴露问题,形成一个坚定践行文化的核心团队,当然我们要强调知行合一,用实打实……

    2020 年 10 月 5 日

  • 去除隔间,增进沟通

    敏捷的“自组织团队”模式需要团队成员们具备新的技能——包括他们曾寄希望于项目经理具备的人际交往技能。此时,管理不再是多余的东西,它对帮助团队学习新的沟通和协作方式起到了非常重要的作用。本文为如何传授新的技巧给出了一些策略,并提供了一些相关资源。

  • Scrum 看板:是进展,还是矛盾?

    与看板有关的研习班、课程和会议越来越多,有实用精神的敏捷专家们开始研究这种来自精益的方法能为团队带来什么。人们提出的吸引人的好处包括:揭示瓶颈、让团队体验更多的“流畅”状态而变得更为快乐。但是有些思想者们警告说:看板那种不紧不慢的方式,就像是让超人绵软无力的“氪星石”,不能满足Scrum对于去除障碍的迫切需要。

发现更多内容

说说规则引擎

张老蔫

28 天写作

京东方“8K+5G”技术助力牛年春晚 开启超高清视频直播时代

爱极客侠

1353道,阿里+腾讯+字节+滴滴+美团java面试题及答案(2021版)

Java架构师迁哥

测试技术

牛鬼蛇神VS魑魅魍魉

Instana:如何评价可观察性方案?

行人23

第十三周 数据应用二 作业 「架构师训练营 3 期」

feiyun123

抓包带你详解TCP的11种状态

运维研习社

三次握手 四次挥手 TCP/IP 抓包

学习 Java 语言,你必须知道的 Java 简史

白色蜗牛

Java spring 程序员

Kafka.03 - Message 介绍

insight

kafka 2月春节不断更

做出赋能其他人的产品是技术牛人最好的证明

刘华Kenneth

敏捷 平台

iOS BAT面试对答题

ios 面试题

阿里+腾讯+字节+滴滴+美团java面试题及答案(2021版)1353道题全部开源

Java架构追梦

Java 架构师 面试题总结 金三银四 大厂面试真题

BOE(京东方)全面发力8K 成为央视8K超高清技术合作伙伴

爱极客侠

13w字!阿里新产面试速成笔记全网开源,内容涵盖程序员必备23个技术栈!

程序员小毕

Java spring 程序员 面试 分布式

实例详解Linux下ulimit每个参数

运维研习社

Linux ulimit linux系统资源管理 open file

Nginx加密套件配置不当,造成SSL无法建立连接

运维研习社

nginx zabbix SSL证书 证书监控

面试官一上来就问我Chrome底层原理和HTTP协议(万字长文)

魔王哪吒

前端 后端 chorme 28天写作 2月春节不断更

二、MongoDB基础知识

Kylin

读书笔记 日更挑战 分布式数据库mongodb 二月春节不断更

关于Linux系统中Message中的Session日志详解

运维研习社

Centos 7

你好,2021~

数据社

程序员 2021年展望

区块链农产品溯源系统开发,区块链公共服务平台建设方案

WX13823153201

区块链农产品溯源系统开发

一文搞懂Linux下Ulimit资源限制

运维研习社

Linux linux命令 ulimit

IO 模型知多少 | 理论篇

圣杰

io

牛启新春|优质文章人气大挑战

InfoQ写作平台官方

活动专区

【STM32】CubeMX+HAL 输出PWM

AXYZdong

硬件 stm32 2月春节不断更

2021年目标,我打算这样去实现

谙忆

为行动而读书-《麦肯锡精英高效阅读法》读书笔记

代码技艺

读书笔记

翻译:《实用的Python编程》02_02_Containers

codists

Python 人工智能 容器 后端 数据结构与算法

创业公司人力资源体系建设的几点思考

一笑

人力资源 28 天写作

Nginx如何监控各server的流量

运维研习社

nginx Prometheus zabbix upstream

为什么做这样一个产品之容量评估篇

数列科技杨德华

28 天写作

微服务架构下如何保证事务的一致性

微服务架构下如何保证事务的一致性

Tobias Mayer访谈:人的Scrum和AgileLib-InfoQ