4万字《腾讯云技术实践精选集 2021》发布,点击下载 了解详情
写点什么

“STEP” ——通往敏捷之旅的藏宝图

  • 2012 年 9 月 25 日
  • 本文字数:7236 字

    阅读完需:约 24 分钟

若干阻碍

现在来看,公司要在创新上、产品改进上获得成功是越来越困难了。通常需要花上几个月,甚至几年才能到熬到“收获”的时刻。

然后,只有灵活的、快速适应的组织才能够繁荣地发展,赢得市场份额。这些组织往往鼓励每个员工找到满足客户需求的方法,并能够在为他人工作时获得快乐。

那些对变化响应缓慢的组织,则只能眼睁睁看着自己的生意被慢慢地蚕食掉,有时候甚至走向消亡。这些组织往往无法有效地调动起员工的智慧和热情,只会孤军奋战。

在许多方面,我们的管理人员的思想、运作组织的方式与结构,还是会与快速适应的理念背道而驰,尽管他们的初衷是希望能够做到快速的适应,但结果往往却把事情搞复杂。

让我来列举些典型的阻碍:

  • 许多传统的组织都寄期望于最大程度地挖掘员工的使用率。在这样的组织中,他们要求员工同时做多个任务(10% 的时间做做这个,20% 的时间做做那个,等等),这样做的后果是,将时间都浪费在任务转换上了。而且,这种方法还忽略了一个事实,即多任务工作节省下来的时间远不及由此带来的可怕后果。这些后果包括由分心造成的,可能降低的质量、无法有效地控制时间成本、反而更可能造成延期等等。
  • 这种企图将利用率发挥到极致的幻想,将人们变得非常忙碌,而根本没有办法去学习如何思考问题,或开展新的工作方法。甚至是,这种忙碌会演变成当前障碍的根本原因,而人们又往往习惯性思考如何解决表象症状,却忽略了找寻根本原因的对策。
  • 许多组织的边界也会制造矛盾和摩擦,以至于人为延长了为客户创造价值的工作流程。康威定律(Conway’s Law)对系统演进有着举足轻重的影响。由于系统的结构通常反映的是创造它的组织的结构;因此如果这个组织随着时间变得越来越复杂,它的工作流程和系统也会变得越来越复杂。重组更是加剧了系统进化的复杂性,并更可能发生增加运营成本和延期的情况。
  • 企业浪费了巨大的精力和资本,强迫每个部门独立地尝试改进自己的绩效。而忽略了系统地缩短周期时间和改进端到端成果上,例如,每个部门都致力于提高自己的客户满意度。
  • 许多组织不能很好地实行跨功能团队间的学习,随意召集和解散特设团队,虽说用组织纪律来约束团队没错,但这类团队存在的时间会相当的短暂。

尽管我们大部分人都会有惰性,但一旦我们开始改变自己的思想,就能打破这种传统思维,开始一段更专业、更令人满足的个人之旅。

前进的方向

越来越多的公司,不论是哪个行业,都越来越倾向于一种全新的领导方式。这种方式基于对公司每名员工的高度尊重,并鼓励他们进行持续改进。许多组织只是为了不被遗忘而这么做,另一些则是拥有足够的智慧,主动寻求改变,主动回避可预见的重大困难。

你可以参考 Jim Womack 的《 Gemba Walks 》,书中讲述了组织如何做到可持续的适应能力的案例。我们还可以研究一下 Steve Denning 的《 Radical Management 》,该书讲述了如何激励人们寻求新的方法。这些方法包括了提升个人的思想、组织、行动,以及如何有效地延伸这些改进的新模式。

受这种全新方法的鼓舞,以及基于软件系统的本质,敏捷的软件开发概念是持续发挥组织中领导者的想象力,目的在于提高客户满意度和整体改进效率的方法。

阻碍通过敏捷方法获得巨大成功的困难在于这样一个事实:新的思想和工作方式必须在组织之间,特别是在组织的边界之间传播。为了克服这个困难,我们必须找到一种行之有效的方法,来鼓励人们改变现有的习惯和做事方式,并且克服自身对于改变的抵触心理。

克服抵触心理的有效方式是,让人们尽可能地在日常工作中找到快乐。快乐工作着的人,更能找到并推动满足客户要求、令客户喜悦的方法——这里面的科学依据可以参见 Barbara Fredrickson 的《 Positivity 》一文。

然而,仅仅单纯地希望我们的工作变得快乐还远远不够,要做到这点必须具备两个条件:能够营造团队学习的氛围;以及在团队中培养基本的稳定性。

团队的稳定性在于,工作流程的每个步骤都很合宜,并且被正确完成。流程的步骤合宜,指的是当有需要的时候,人们就能立即准备好执行这步。而正确完成,指的是每当这个步骤被调用时,只要有足够的输入,它就能得到期望的结果。一旦流程具备基本的稳定性,这个流程就能够被相对连贯地度量,人们也将对该绩效改进的实验充满自信。

相对而言,跨功能性的、自我组织的、合作时间更长的团队,有更好的机会去发展工作流程的稳定性,能够从以往的经验中快速成长,并持久地改进。然而,创造并维持高绩效的,自我学习的团队并非易事。组织必须提供给他们平稳的工作流程,并创造机会,使每个人都能得到专业的改进机会。

在之后的章节中( “S” 停止、 “T” 转型、 “E” 扩展、 “P” 完善——即缩写为“STEP”),我们将列出一系列的战略,针对如何创造、逐渐扩展并维持高绩效的社区。在组织、供应商和客户社区中推行敏捷的思想,这并不是一个 Sprint,而是一场探索、反馈并适应的生命之旅。

“S”——停止

通常来说,停止并不算是建议,更别说首先从停止开始了。有这样一个真理,所有的进步都是改变,但不是所有的改变都能进步。因此,当人们已经习惯于在某种工作方式下干活时,我们不得不找到一些方法,让人们能够勇敢地停下来,质疑自己的假设和固有习惯。如果我们不改变思考问题的角度和工作习惯,就无法预见进步,更别说持续进步了。

通常,我们倒并不鼓励从基层开始进行变革,情况恰恰相反。只要组织没有明确地开始在以下几个方面投入资金,他们适应客户快速反馈的机会就越少,也越不容易让客户满意。这些方面包括,创建更多学习的社区,减少在制品的数量。然而,当领导者停下来,实实在在地去找寻更好的工作方式,并持久地执行下去,开发更好的社区氛围,这样做的结果是显而易见的,成功也是水到渠成。

接下来,我想讲一个有关领导者习惯的故事。从前,在一家技术领先的公司,Gary 是一个分区的副总裁,他的分区负责建造由很多固件构成的、复杂的硬件设备。一天,Gary 下决心,要花时间学习敏捷思想,并开始在部门内部推行这种思想。不仅如此,他确保所在分区的所有部门的管理者都学习并接受这种思想。渐渐地,分区的每个管理者,都开始注意起他们专家团队的主要顾虑和阻碍,并帮着他们解决。这样一来,久而久之,就形成了一种席卷整个分区的改进计划,这个计划涉及的所有方面,最后带来了显著的收益。

比起旧时的从每条生产线开始独立编写固件的方法,他们最终开发出一种可配置的、统一的平台,从而减少了之前的重复工作,并降低了引入缺陷的可能性。因为有了这样一个维护程度极高的,统一的高质量平台,每个构件都能够快速地配置到适合它的生产线中。持续集成以及大范围的自动测试,也从另一个方面保证了平台持续、健康地工作。相应地,这也极大程度地缩短了新产品研发的周期,获得了更好的市场回报,同时也让客户非常满意。

每一个从中获益的人都有责任把敏捷思想带给更多的人,鼓舞更多的同事、管理者和高层。正如 Gary 一样的优秀领袖,把这些理念传达给每个人,达到促使客户满意及获得组织进步的目的。他们奉劝大家,从“停下来思考我们现在所做的、以及为何这么做”开始;去探索有什么更好的方式能够为客户带来满足和快乐,反过来也让为之工作的人也从工作中得到快乐。

“T”——转型

任何一个组织中,可用的精力总是有限的,其中一些通常花在创建新产品上,另一些花在维护已有的产品上,如果再有余下的,则可以花在改进组织中的工作流程上。

组织中的某些管理人员、某些经理、某些实施者,已经开始接受敏捷的思维方式,并开始了持续改进的旅途。他们能够形成这样一种共识,即在某一点上,将有限的改进能力发挥到极致的能力,变得至关重要。

举例来说,约束理论在如何构建针对核心约束的共识上,提供了非常好的建议。针对这种约束,敏捷的技术与工具在创建可行的对策上发挥着作用。一旦约束队列中最上面的那个约束被成功地解决,这个流程就能反复,久而久之就会推动整个系统的改进。产出会计则是另一个领导者们喜闻乐见的主题,相对传统的成本会计思维模式而言,它是非常尖锐的对立面。

令我吃惊的是,我发现一些高层管理人员,非常抵触“约束”,甚至仅仅是提到“约束”这个术语。这使得他们不愿意对约束理论进行深入的了解,从而忽视了由此带来的益处。在某些文化中,特别是倡导个人英雄主义的地方,人们往往习惯于抱怨,而忽视了流程的分析与改进。提出问题,以求协作解决,更不是一个“安全的”行为。

一个很好的提醒是,敏捷冠军(Agile champion)必须对共事的领导者的文化有所了解。在这种情况下,我们必须小心地调整,诠释约束理论的方法,使之能够被接受并受到欢迎。例如,我们应该强调可视化工作流的益处。让相关人员都感觉到由此带来的益处,发现最大的问题出现在哪里。然后,首先对付最显著的障碍,按照需求,检查和使之适应。我们可以考虑引入Stephen Denning 的《 Leader’s Guide to Radical Management 》,Jurgen Appelo 的《 Management 3.0 》以及 Eric Ries 的《 Lean Startup 》,作为领导者和管理层的更有效的、更激进的读物。使之更有利于满足客户需求,以及让实施者得到工作的快乐。

新的思维方式和新习惯无法一次性就有效地传遍整个组织。相对而言,从小的地方做起要有效得多。我们可以从建立一些跨功能的、有自我组织能力的、存在时间较长的团队开始。并且学会如何用敏捷的方式,在组织已有的文化中以及商业伙伴中有效地执行开来。你可以读一下 Diana Larsen 和 Ainsley Nies 共同撰写的著作《 Liftoff 》,找到关于如何通过敏捷团队和项目项目获得最大成功的指导。

当 Gary 的分区开始实行敏捷之旅时,他召集了管理团队,共同形成了关于如何减少产品开发流程周期时间的理解,认识到解决该问题的主要阻碍是什么。通过深入地观察情况,他们发现固件的开发流程是最主要的限制因素。管理者随即开始变革;他们采用了一种敏捷管理的迭代模式,帮助团队简化他们的工作,并把工作变得有趣。这个转型是逐渐开始的,每次只涉及一小部分人。

刚开始的时候,每个人都看着度量数据,准备激烈的辩论,以求更好地看清现实。渐渐地,这个过程变得越来越自然,不论是挑战其人的观点,还是有创造性的适应“坏消息”,都变得自然而然。请参见 Susan Scott 的《 Fierce Conversations 》,了解如何更有效地进行沟通与团队学习,并从中获得成功。

正如我们看待体育竞技一样,我们不会指望直接把运动员送去比赛,却不让他们一起合练一段时间;也不给他们找个好教练帮助他们进步。诚然,在软件工程领域,很少有组织,清醒地认识到这基本的常识,愿意正式地找个教练,辅导自己的团队,帮助他们加快进步的步伐。

Gary 和他的管理者们选择了发展自己的敏捷辅导技巧,并在他们的组织中,获得了巨大的、长期的进步。Lyssa Adkin 的《 Coaching Agile Teams 》一书,告诉了我们,辅导团队的价值,以及如何成为优秀的敏捷教练。

“E”——扩展

一旦我们建立了一些稳定的敏捷团队,并为他们提供好的辅导以帮助他们成功;这个时候,我们开始学习如何在团队之上的组织中实践改进后的习惯及文化。

组织中的敏捷冠军(Agile Champion)开始制定一系列辅导方案,并且把大家的兴趣聚焦到不同的课程,以及不同的工程方面上。在这种情况下,早期的敏捷团队,在积累了来之不易的知识之后,能够系统地把这些知识渐进地在组织中传播。我们希望这种传播是可以跨组织边界的。

事实上,需要努力克服的一个障碍是,许多人仍然把项目作为计划和活动的焦点,会时不时地问自己,敏捷方法究竟是否适合某个特定的项目。相反,我们得找到一种方法,鼓励人们从文化的角度去思考,接纳这种涉及所有团队的、持续改进的、跨组织的文化。敏捷方法不仅仅是对不同实践的激励,也是技术团队拿来提升工作流的利器。建立长期合作的、有效率的敏捷团队,为组织的发展与战略计划开启了新的篇章。记住,没有一种流程是永远完美的。不论他们现在关心的计划本质是什么,所有的团队都能在工作流程的改进中获益。

那么,建立并维持这种持续改进的企业文化,对组织是受益匪浅的。敏捷思想在各种改进实验的激励方面非常行之有效。这些改进实验,几乎考虑到团队能碰到的各种障碍。

随着越来越多的敏捷团队的形成,他们的敏捷之旅将变得简单,结果将必然是优异的;他们能够得到更好的敏捷辅导支持;他们可以从早期的敏捷团队中挖几个老兵过来,作为核心建立新的团队;或者,他们可以从其他敏捷团队中邀请一些导师来做辅导;在敏捷模式下的产品归属和管理方面,他们能够得到更多的支持;他们可以从其他的敏捷团队的经验教训中获益,并找到不同领域中的最佳对策。

在这样一个组织中,领导们能够依据更具预测性的工程能力制定计划。每个敏捷团队能够依据历史记录的数据,准确预测团队的敏捷开发速率。许多有用的统计分析变得可行,并可以用来指导未来的持续改进计划。这也使得“战略部署”更加可靠,对项目群和项目组合的计划也有显著提高。将“ Scaled Agile Framework ”作为企业级别的框架概括来思考,在项目组合、项目群及项目中应用敏捷的思维模式。

在这种工作模式下,领导者与其尝试去决定,在一个确定的范围内(固定的项目组合,项目群及项目中),在确定的时间内,在不明朗的预算下,需要多少人来完成这项工作。不如考虑在确定的预算内,他们需要多少个团队来实现特定的计划,以获得期望的发布能力和节奏。

然后,项目范围就变得合理,并能够满足客户的最大利益。将特性聚集成最小的产品增量,并且尽可能快速地发布他们。从更为相关的概念上,来考虑“ Beyond Budgeting ”和“ Throughput Accounting ”,来详细解释如何从财务管理的角度把事情做好。

这种战略计划和产品研发的方法,有着非常深远的益处。对用户而言,它能够极大程度地减少浪费在没有价值或价值不足的产品特性上的工作量。如果我们把精力集中在创造客户喜爱的特性上,那么就会创造出无与伦比的产品。我们越快发现错误、纠正错误(消除无用的特性,将产品变得简单、优雅),就能更好地服务客户。

在 Gary 的组织中,他下了大力气,在有效地实践敏捷思想方面投资。正因为他们改进了所有生产线上影响产品开发流程的固件平台,所以每个人都从中获益。除了使用更简单、更高质量的统一平台,所有团队开始更为连贯地实行问题解决的方法。共同营造找寻问题,探索对策的环境。在这种方式下,许多优化组织的对话,最终变成大家都能接受的决策。

“P”——完善

在敏捷思想中,本意是完美的“perfect”一词,更接近“完善”这个含义——指的是对某个产品或流程进行提炼或提升的动作。敏捷组织向来崇尚的理念是,没有一件事情是“完美的流程”,有职责心(并不一定是技术非常强或特别聪明的)的员工才能够带来成功。

相反,敏捷组织的人相信,人们天生愿意接受有挑战性的目标。人们愿意品尝满足客户所带来的快乐,愿意为有意义、有价值的成就而奋斗。受过高等教育、有智慧的员工能够自主地权衡并找寻获得更大成就的方法。他们渴望在所选择的领域,得到专业提升的机会。大家可参见 Dan Pink 的关于更好的激励技巧与根源的《 Drive 》一文。

持续地获得客户满意并维持它,本身就是持续改进的一次旅行。你有可能碰巧获得一次客户满意,仅仅是因为狗屎运。同样,这样一次性的客户满意,会迅速提升客户对于服务水平的期望值。用同样的改进方式或技巧,也许很难获得第二次成功。要保持这样一种客户满意度,就需要人们做出承诺,并找到客户需求的更深层次的理解。基于这样一种深层次的洞察,通过无止境的学习过程,团队才能持续地找到满足客户的新鲜方法。

敏捷团队崇尚的理念是,大家一起保证学习的过程;保证满足我们的客户;保证让我们的工作更为有趣、更令人满意。有效的敏捷团队与身后更为广泛的组织,通常会有目的地、系统地对他们工作的每个方面进行仔细的审查。甚至连团队如何应对阻碍,如何看待创新的机会、如何进行系统性的改进等方面也不轻易放过。

使梦想变成现实的基础,就在于人们对敏捷团队的领袖们最大程度的尊重。他们往往会亲自查看所发生的工作,耐心询问事情为什么是这样的。他们还会尽可能地让每个人都参与到科学的解决问题的流程当中,成为任何障碍物的主要解决者,让他们的团队生活得更好,更简单。

Gary 的组织并没有结束改进的旅行。他们深刻地感受到,在某些方面,他们仅仅只是开始。对于他们旅途的下一站,他们为之兴奋,努力工作以求找到持续改进;扩展团队、提升产品线的合适方法。

前方的路

任何一次敏捷之旅都充满着挑战——我所指的“敏捷”是通常意义上的,包括了精益、约束理论(ToC)、六西格玛(Six Sigma)、系统性思想、队列理论、精益生产(译注:TPS - Toyota Production System)等元素。我们会有不计其数的阻碍需要突破;众多的人性弱点需要克服;无数的对立方仍想着固守成规;还有难以想象的冲突和困难状况需要解决。

除了所列的这些危害,敏捷式的持续改进,着重在最大程度地获得客户满意度或喜悦感。并通过为人们寻求欢乐,承诺在未来的持续业务中成为主流文化,而达到帮助客户获得满意度或喜悦感的目的。你还在犹豫是否开始这次敏捷之旅吗?所要做的仅仅是“STEP”。

关于作者

Horia Slușanschi作为一名敏捷教练及战略家,领导着惠普的敏捷指导办公室以及软件工程行业。对于帮助团队及领导者找到方法满足我们的客户,并从中获得工作的快乐,有着由衷的热情。他拥有计算机科学专业的博士学位,并有着诸多背景,这包括敏捷思维模式、企业架构、精益的六西格玛、约束理论、丰富的古中国及古印度文字研究、以及诸子百家的思想。

他在更广泛的敏捷社区也非常活跃,是“ AgileWelly ”的共同组织者,新西兰权威敏捷咨询机构代表,以及“ PMI Agile Community of Practice ”学术管理团队的领袖之一。Horia 还是一位滑雪爱好者及狂热的摄影师。你可以通过 horia@hp.com @KiwiHoria 与他通信。

查看英文原文: STEP – A Map for an Agile Journey


感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2012 年 9 月 25 日 00:002532

评论

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

Linux内核分析学习路线总结(内核人员必看)

Linux服务器开发

操作系统 Linux内核 内核源码 内核开发 驱动开发

Github首次开放,一天遭狂转 50w 次!阿里内部不外传的 100 万字 Java 面试手册!

Java 程序员 架构 面试 计算机

一个算法“拿下”两个榜单!爱奇艺ICCV 2021论文提出人手三维重建新方法

爱奇艺技术产品团队

vr 论文 ICCV2021 高精度三维重建

FastApi-06-请求体-3

Python研究所

FastApi 8月日更

3000人群被字节内部技术图谱炸翻了,惊艳级实用

互联网架构师小马

Java 面试

【共识专栏】Quorum机制与PBFT

趣链科技

区块链 共识机制 PBFT 共识算法

维护数据隐私和增强竞争优势的秘密

九河云安全

拍乐云创始人赵加雨:沉浸式音视频加持数智化未来世界

拍乐云Pano

一周信创舆情观察(7.26~8.1)

统小信uos

开放搜索电商行业模版驱动业务增长实践

阿里云大数据AI技术

使用PyTorch构建神经网络模型进行手写识别

Shirakawa

神经网络 机器学习 深度学习 PyTorch 手写识别

现有市值管理机器人|交Y机器人系统源码搭建

Geek_23f0c3

做市机器人 去中心化市值管理机器人

贝壳找房基于StarRocks构建全新统一的极速OLAP平台实践

StarRocks

数据库 数据分析 OLAP StarRocks

Python RPC 不会?不妨看看这篇文章

星安果

Python RPC RPC架构

Jmeter分布式压测实战及踩坑处理(含参数化)

互联网架构师小马

从关门“振动”说起,在这部剧本杀综艺里,爱奇艺隐藏了多少技术“小心机”

爱奇艺技术产品团队

综艺节目 互动视频技术 爱奇艺

写作7堂课——【1.框架式写作】

LeifChen

框架 结构化思维 写作技巧 8月日更

5 分钟,快速入门 Python JWT 接口认证

星安果

Python JWT

字节跳动Android面试:2021Android大厂面试知识分享

欢喜学安卓

android 程序员 面试 移动开发

最全总结 | 聊聊 Python 数据处理全家桶(存储过程篇)

星安果

Python 数据库

中台的前世今生

涛哥

企业架构 中台架构 中台的由来

镜像是什么意思?分类有哪些?

行云管家

网络安全 镜像 堡垒机 云厂商

为什么拥抱能源的数字未来意味着在云上全力以赴

九河云安全

第一次凡尔赛,字节跳动3面+腾讯6面一次过,谈谈我的大厂面经

Java~~~

Java 面试 微服务 多线程 架构师

云计算以及云计算周边词概念简单介绍-行云管家

行云管家

云计算 服务器 云服务

资深大牛带你了解源码!最新Android面试题整理

欢喜学安卓

android 程序员 面试 移动开发

摘下手机赛场的夏季“金牌”,荣耀的“飞人之路”

脑极体

阿里顶级大佬整理出十六个专题的Java面试指南,金九银十不用愁!

Java 编程 架构 面试 架构师

强推!华为内部都在用的783页大数据处理系统:Hadoop源代码pdf

Java 编程 架构 面试 架构师

Ipfs未来价值怎么样?Ipfs值得投资吗?

区块链 分布式存储 IPFS fil IPFS未来价值

“STEP” ——通往敏捷之旅的藏宝图-InfoQ