写点什么

《It's All Upside Down》作者访谈录

  • 2017-07-17
  • 本文字数:5645 字

    阅读完需:约 19 分钟

关键点:

  • 敏捷团队仍然需要流程
  • 如果您希望团队绩效得到真正的改善,那么在前面就把流程和衡量方式规定得很细不是一个好方法
  • 让流程注重原则和目标,而不是步骤
  • 在职培训的投资回报大大高于正式的课室培训
  • 利用 Essence 来激发讨论,找出根本原因和有效的解决方案

在《 It’s All Upside Down 》这本书中,Paul McMahon 提供了来自受助于颠倒原则的软件开发团队案例和应用它们的指导技巧。他解释了您如何能用 Essence 来改善流程,获得更好的组织绩效。

InfoQ 的读者们可以下载阅读《It’s All Upside Down》的样章。

InfoQ 采访了 Paul McMahon 并讨论了很多问题,包括:当组织采用了敏捷方式时,为什么还需要流程?为改善流程所做的工作,哪些有用,哪些没有用?怎样处理不完整或模糊的需求?团队能从指导中获得什么好处?技术领导者如何提高其指导技能?为何选用 Esssence 来解释软件开发案例?对那些想要利用 Essence 来改善其绩效的组织有什么建议?

InfoQ:您写本书的原因是什么?

Paul McMahon:本书的副标题:“我所学到的关于软件开发的知识,为什么其看起来与老师教的都相反”,跟我写本书的动力有很大的关系。仅仅在过去的几年间,作为一个指导者,我已经在如何帮助软件开发团队上做了大幅的改动,看起来像是我在跟我的客户推荐与很多成熟的长期软件工程原则完全相反的东西。这是促使我写本书的主要动力。我希望跟大家分享我们最近在实践中所发现的对成功的软件开发团队真正有效的东西。本书第一部分中的 8 个案例都发生于 2015 年和 2016 年。

InfoQ:本书适合哪些人阅读?

McMahon:在本书中,我强调了 26 个颠倒原则,以及颠倒原则的澄清思想。我也强调了 18 个指导技巧。如果您想知道一本强调指导技巧的书是否适合您,那么答案是肯定的。我认为组织中的每个人应该把自己看作是个指导者。本书特别适合那些在组织中能够影响软件开发决策或被其影响的人阅读。

InfoQ:敏捷软件开发宣言建议大家关注人而非流程。当组织采用敏捷开发时,还需要流程吗?

McMahon:是的。团队总是需要合适的指导来确保团队理解自身的使命,以及如何处置团队面对的常见情形。不幸的是,如今有太多人把流程(或实践)等同于过重的书面指导。只要您接受我对流程的定义:流程是对团队适当的指导,那么总是需要流程的。我们面临的挑战是如何决定合适的水平和合适的媒介物来提供指导。我最近发现的见解之一是如何通过对原则的关注来捕获适合敏捷组织的流程。原则更多地关注于目标,而流程(或实践)更多的是关注于实现目标的步骤。我现在把原则看作“迷你实践(mini-practices)”(或迷你流程)。这个方法有助于团队关注正确的行为以获得更好的绩效。

InfoQ:您是否能举几个例子,来讲讲您从不要为改善过程而工作中学到的东西?

McMahon:这问题问得好。事实上,“对于改善流程不起作用的事物”可以作为本书的副标题,因为这真是整本书都在讲的东西,书里还讲到了很多 有作用的东西。因此,我在这里就举几个例子。不起作用的东西的其中之一是,在您的团队已经在实际项目中证明了某个“流程”之前,试图通过书面定义流程细节来“改善”流程。这没用,因为我们已经知道,不管您之前在定义流程上花多少精力,一旦团队开始在实际的项目中使用流程,就会学习重要的新东西。另一样没有用的东西是花钱买教训的想法,您必须先定义措施来确保您有所改进。您真的需要措施来确保您不糊弄您自己,这个说法是对的,但是当实际项目的改进正在实施时,才会发现一些最好的措施。本书的“案例一”中可以找到这样的一个例子。第三样没有用的东西是认为要获得重复的结果,重复性的流程是必要的。有时候,获得重复的结果的最好方式是允许团队改变他们的流程来解决其面临的具体挑战。这是“案例二”中的要点。

InfoQ:您学到的哪些东西是有用的?

McMahon:我学到的最重要的东西是认识到这一点:当敏捷行动已经强调了很多健全的做法,即大多数项目有具体的限制或者法规的要求,需要对“纯敏捷”的做法进行一定程度上的剪裁。因此,最有效的就是要认识到这一点,以及指导团队和团队领导者如何去寻找适合其文化和环境的 “混合证明最佳实践(hybrid proven best practices)”的最佳水平。太多的组织认为“剪裁”只是跟项目的开始相关(如果有的话),而实际上,剪裁是在整个项目进行的过程中必须不断考虑的事。与此同时,无节制的剪裁会滋生混乱。因此,我发现的另一样有用的东西是提供一套最小化的“必做事项”的指南,同时,这套指南永远都不能被“剪裁”掉。

InfoQ:当团队在处理不完整或模糊的需求时,您对他们应该做什么有什么建议?

McMahon:这个问题也问得好!我喜欢帮助团队做的事情之一是:与其讲理论,不如分享那些有用的案例。我最喜欢分享的案例之一是跟不完整或模糊的需求有关的。多年前,我参与了一次客户研讨会,该客户为美国海军开发模拟训练软件。在我们讨论不完整的需求时,一个参与者插话进来:“让我来跟你说说我与我客户之间的问题吧”。他接着说,当他正准备让其客户澄清模糊的需求时,其客户回答到:“我们需要飞得又高又快的模拟导弹”。随后,他问其客户:“多高?多快?”其客户回答到:“我不知道,尽管去做,然后我们会让你知道你做的东西是否足够好。”

最有趣的是,其他研讨会参与者关于这实际上是否是个问题的讨论没有达成一致意见。一个参与人员回应到:“我一直用这种方式跟我的客户打交道,他们看起来很喜欢我们!”而另一个人说:“这是个大问题,因为我的客户总是在抱怨我们无法控制成本和进度。”

这个案例的要点是,要决定一个场景是否是个问题,您就必须理解您的客户和项目情况。您必须先多问一些问题,比如:“您的客户有多少资金?”及“您的客户是否了解用迭代这种方式来找出需求的成本?”

如果您的客户不合作,而您的预算和进度是不可变的,那么这会是个巨大的问题,您也许需要马上采取行动。但是,从另一方面来说,如果您的客户了解以迭代方式找出需求的成本,并希望您帮助其找出需求,也有足够的钱来支付费用,那么您也许只需要做您的客户要求您做的事,并让客户支付相关的费用。

InfoQ:团队能从指导中获得什么好处?

McMahon:仅仅在过去的几年间,我才意识到指导是多么的有价值。我习惯于把大量的精力投入到为我的客户组织正式的研讨会,包括数百张我在研讨会上要用的幻灯片,这些研讨会通常持续三天或更多天。我的确针对具体的客户需求,对这些研讨会进行了剪裁,都受到了好评。因此,我最近几年都是这么做的。

但是,在 2015 年,我开始意识到某些重要的东西,它们是我正式课室培训中所缺乏的,而有了它们,我能够提供更有效的在职员工培训。当研讨会的参与人员坐在课室里时,对他们来说,很难把他们正在学的东西转化成如何让这些新知识对其实际项目任务产生影响。因此,更多时候,当他们离开课室,面对工作上的情形时,那些我曾经在课室里教过他们的东西,他们并没有应用到实际中去。这是因为他们只是回到了旧时的习惯上,而这对我们大多数人来说都是很自然的。指导者的优势在于,作为一个指导者,您能够更接近学生面临着的真正挑战,由此能够识别出在所要求的时间点采取新行为的机会。当我们和我们的客户之间的交互被限制在一个正式的课室培训中时,我们会错失这个机会。

有些人认为,指导,特别是一对一的指导比起课室培训要昂贵得多,但这不一定。

很多组织仍然通过送其员工参加长达几天的正式研讨会来进行培训。但是,用精简的课室培训来代替那些冗长的研讨会,辅以按需指导,会更高效和有效。这样能节省正式培训的费用,也允许指导者和更多客户并行工作,他们可以根据情形所需,通过电子邮件、简短的通话、专门的网络研讨会提供指导。

这种方式被证明对指导者和客户双方来说都是更高效和有效的。强调指导而不是正式的课室培训的优势在于,对于客户来说,不必将其看作是纯粹的“开销”成本,因为指导者和学生在一起面对的是一个真正的项目挑战。

InfoQ:技术领导者如何提高他们的指导技能?

McMahon:首先,我想指出的是,当我还是个年轻的软件开发员,头两次我的经理试图让我做技术领导者时,我讨厌那份新工作,并尽快辞了工,做回软件开发员。事后看来,我意识到我这样做是因为在技术领导者的职责和如何履行这些职责方面,我没有受到任何培训或指导。我想就这个话题指出的第一点是,组织应该向从业者明确说明谁对技术领导方面负责以及如何获取技术领导技能。

如今,我认为成为技术领导者,包括放弃软件开发,不应该是开发人员必须要做的一个选择。最好的技术领导者应该也是个开发人员,以便了解最新的实践、工具和开发人员面临的问题。因此,在如今的世界上,技术领导地位应该来自那些您的团队所需要的已有知识的地方以及所需要的时候。

鉴于这一思路,提高技术领导者的指导技能更多地跟团队沟通和了解团队成员的职责有关,而不是任何技术问题。那是先聆听,了解您的团队面临的问题,然后和那些有经验、能够提供帮助的人们接触。这意味着需要告诉每一个团队成员,他们的职责包括跟其他成员分享必要的知识,以及在其他成员需要帮助的时候帮助他们。

InfoQ:什么是 Essence?

McMahon:Essence 是基于软件工程方法和理论(Software Engineering Method and Theory,简称 SEMAT)的倡议,是 2009 年底由 Ivar Jacobson 和两位顾问 Bertrand Meyer 及 Richard Soley 最先发起的。来自全世界包括工业界、学术界和研究界在内的很多人以志愿者的身份工作,形成了 Essence Object Management Group(OMG)标准。虽然 Essence 成为唯一的 OMG 标准始自 2014 年,但可以追溯到 2005 年,当年 Ivar Jacobson International(IJI)重新设计了 Rational Unified Process(RUP)并将其改为 ESSUP(Essential Unified Process)。SEMAT 的主要动机之一已经在 SEMAT 网站上写明了的:“全世界有数以百万计的软件工程师们存在于无数的程序、项目和团队中;让世界运转起来的上百万行的软件程序见证了他们的聪明才智”。然而,作为一个社区,我们仍然觉得难以分享我们最好的实践、真正让我们的团队强大起来、把软件工程和其他工程学科无缝整合到我们的业务中、持续地殚精毕力、避免不必要的灾难性故障。整个业界在‘没有方法’和最新的‘真正方法’之间不断切换的习惯(这种令人悲伤的痛苦甚至影响到了敏捷社区)不是前行的道路。

在关注这个趋势方面,SEMAT 社区不是唯一的一个。多年来一直在软件质量、风险和最佳实践方面收集数据的 Capers Jones 告诉我,软件工程已经在人类历史上创造了比其他任何工程学科多得多的软件方法。

InfoQ:您为什么选择用 Essence 来解释在您书中提到的那些软件开发案例?

McMahon:在我书中的那些案例中,您会了解到很多问题,这些是我问过我的客户的问题,还有我给他们的指导技巧,以帮助他们克服常见的困难,获得更好的绩效。很多我问过的问题和我提供的技巧都来自于经验。但是,我认为 Essence 提供了一个简单的方法,在不能马上找到指导者时,从业者能以他们容易获得的形式分享这些问题和技巧。

有时候,我把 Essence 称作“思维框架(thinking framework)”,但是,事实上,Essence 比“思维框架”要丰富得多。Essence 提供了与所有软件开发工作相关的“共同点”要素集合。这点和我前面的回答有关,我提到过必须要有一套最小化的“必做事项”指南,并且其是绝对不能被“裁剪”掉的。

Essence 包括一套清单,这个清单能激发我向客户提问。您能够从本书第一部分中的那些案例中提到的问题中学到更多的内容。Essence 也为包括顾问、指导者、实践或方法的作者和从业人员在内的任何人提供了一种方法,以一种通用的语言表达他们的实践和技巧,突出其方式的独特之处。这种在 Essence 语言中表达实践的方法被称作“本质化(essentialization)”。这是在本书中,我选择 Essence 来解释软件开发案例的根本原因。

InfoQ:对于希望用 Essence 来改善绩效的组织,您有什么建议?

McMahon:我觉得开始使用 Essence 的最佳地方就是利用框架作为一种辅助手段来激发讨论,从而找到关键问题的根本原因和解决方案,因为那些关键问题阻碍组织获得更好的绩效。本书中有个很好的例子,是我们利用 Essence 研究 NORO 案例。NORO 是一家小公司,它脱胎于一个大型 CMMI 第三级机构,该机构为美国国防部开发复杂的软件系统。NORO 希望更灵活,因此,他们放弃了其先前上级机构繁重的流程,但是很快地,他们意识到自己走得太远了,需要增加一定程度的纪律性流程。

NORO 的目标是增加足够的纪律来解决其导致客户不满意的关键痛点,但是,不要加入那些有碍高效和有效运营的官僚主义。我们通过利用 Essence 进行根本原因分析,得以快速地识别出两个关键问题领域,其中包括:

• 关键利益相关者没有充分参与
• 不良的测试导致的缺陷遗漏

后来,我们给 NORO 软件团队一些精简的培训,重点是关键目标,以及帮助团队解决这两个问题的一些简单实践。

在短短的八周时间里,NORO 团队能够达到 100% 可测的绩效改善,该结果是通过先前低满意度客户再次证实的。利用 Essence 来辅助根本原因分析不仅仅是 Essence 能有助于组织的唯一领域,但是,正如我们在 NORO 案例研究中所展示的,它是一个非常好的起点,展示了 Essence 帮助团队快速改善绩效的能力。

本书作者简介

Paul E. McMahon PEM Systems 的首席顾问,过去二十年来,他一直在用实际的方法指导大大小小的团队以提高敏捷性和流程的成熟度。McMahon 刚刚出版了其第五本书《It’s All Upside Down: What I’ve Learned About Software Development and Why Its Seems Opposite to Everything I was Taught》,在书中,您能找到更多关于软件开发团队成功颠覆的真实案例。McMahon 不是在进行指导,就是在跑马拉松。他已经完成了 12 场波士顿马拉松。您可以通过 pemcmahon@acm.org 联系 McMahon。

阅读英文原文 Q&A on the Book It’s All Upside Down


感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2017-07-17 17:232596
用户头像

发布了 199 篇内容, 共 84.7 次阅读, 收获喜欢 295 次。

关注

评论

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

Apache APISIX 社区周报 | 2021 9.13-9.30

API7.ai 技术团队

开源社区 api 网关 社区周报 Apache APISIX

基于HarmonyOS分布式技术,这群学生赋予冰箱更智能的体验

科技汇

iOS签名校验那些事儿

百度Geek说

后端

爱奇艺埋点投递治理实践

爱奇艺技术产品团队

数据治理 埋点 pingback

【Flutter 专题】28 易忽略的【小而巧】的技术点汇总 (五)

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 10月月更

java springboot自习室选座预约小程序源码

清风

计算机毕业设计

关于征集第六届世界智能大会平行论坛活动方案的通知

InfoQ 天津

开源许可协议介绍

webrtc developer

阿里大牛珍藏版:高并发系统设计(全彩版手册)带你从基础走向实战

Java 架构 面试 后端 高并发

无处不在的Kubernetes ,难用的问题解决了吗?

望宸

容器 云原生 PaaS KubeVela kubenetes

Apache APISIX 社区成员助力 openEuler 发布第一个社区创新版

API7.ai 技术团队

开源 openresty openEuler api 网关 Apache APISIX

技术干货 | jsAPI 方式下的导航栏的动态化修改

蚂蚁集团移动开发平台 mPaaS

容器 大前端 移动开发 mPaaS 动态化

产业互联网下半场,SaaS平台的机遇与挑战

雯雯写代码

SaaS

腾讯云,五轮面试,六个小时,灵魂拷问,含泪拿下 60W offer

收到请回复

Java 面试 大厂Offer

从Ftrace开始内核探索之旅

金蝶天燕云

Linux内核 Ftrace

这篇 python 文章,是过去你错过的 python 细节知识点,滚雪球第4季第15篇

梦想橡皮擦

10月月更

怎样才能画出清晰明了的时序图

华为云开发者联盟

接口 模型 UML 系统 时序图

云小课丨SA基线检查:给云服务来一次全面“体检”

华为云开发者联盟

态势感知 华为云 基线检查 SA 上云合规

Python代码阅读(第38篇):根据谓词函数和属性字符串构造判断函数

Felix

Python 编程 Code Programing 阅读代码

☕【Java技术指南】「技术盲区」看看线程以及线程池的异常处理机制都有哪些?

洛神灬殇

Java 线上程序问题 线程异常 10月月更

Vue进阶(幺叁捌):vue 路由传参的几种基本方式

No Silver Bullet

Vue 路由 10月月更

新书榜第一的《图解产品》,帮助内卷中的产品经理实现跨越式发展!

博文视点Broadview

秀到飞起!Alibaba全新出品JDK源码学习指南(终极版)限时开源

收到请回复

Java jdk 面试

一周信创舆情观察(9.27~10.10)

统小信uos

这几种Java异常处理方法,你会吗?

华为云开发者联盟

Java 数组 异常 程序

Apache APISIX 社区新里程碑——全球贡献者突破 300 位!

API7.ai 技术团队

开源社区 API网关 Apache APISIX

官方线索|2021科大讯飞全球开发者大会

搬砖人

AI 大会 1024我在现场

10 月 30 日 北京 LiveVideoStack 阿里云视频云专场限量赠票 100 张

阿里云视频云

阿里云 音视频 高清视频 视频编解码 视频云

华为云企业级Redis:助力VMALL打造先进特征平台

华为云开发者联盟

华为云 云数据库 GaussDB(for Redis) 华为商城 VMALL

第六届世界智能大会主题征集活动入选主题公布

InfoQ 天津

【万字长文】吃透负载均衡

Java 负载均衡 架构 面试 后端

《It's All Upside Down》作者访谈录_Book Review_Ben Linders_InfoQ精选文章