写点什么

可预见的敏捷交付

2017 年 1 月 18 日

要点:

  • 管理者想要的是可预见的敏捷交付,而不是新的价值组合
  • 组织扩张的“绞肉机”模型
  • 知识工作者的出现改变了管理者角色的作用
  • 人类推理是无法预测的,但团队的产出却可以
  • 软件开发阶段的知识和技能不可伸缩

如果管理者被告知他们的团队文化阻碍了敏捷目标的达成,他们的核心价值观和原则是错误的,他们的组织结构是造成这些问题的主要原因,那么他们该作何反应?从过去的经验来看,我可以很肯定地说他们心里其实很清楚真正的问题所在,他们已经尝试了很多方法,只是还不愿意使用敏捷思维和精益(LEAN)思维以及“天才情商”来武装自己和团队。他们的初衷并非自私也非贪婪,不过确实表现出了作为管理者的意图,他们的作用就是为那些资产所有者保护好他们的组织资产(Appelo,管理 3.0),特别是防止资产出现不可预见的问题。

“系统思维”放大镜

虽然敏捷专家和管理者对一些事情的看法不一样,不过他们都通过各自的放大镜看待这个世界。敏捷和精益专家偏重“系统思维”,他们认为有必要对组织进行重构,以便为客户带来更大的价值。他们的核心思维就是理解客户的需求,然后通过持续的改进(包括工具和人)来满足这些需求。任何阻碍向客户交付价值的事物都被当作“拦路虎”,而发现这些“拦路虎”是敏捷最擅长的事情。

假设你正在为一家咖啡连锁店提供 BI 服务,如果你能够为你的客户提供一个分析门店销售数据的流程,那么对咖啡店的管理者来说,通过分析流程掌握咖啡店的运营情况就是他们得到的价值。比如说,如果你的 BI 流程能够告诉他们每周每家店的咖啡销量、咖啡的使用量、门店员工的人数,那么他们就可以改进他们的经营活动,以便增加利润。他们或许可以提前预估需要多少劳动力,减少每个月的进货数量,计划推出下一个季节新品,等等。

如果使用“系统思维”来考虑客户领域的问题,那么很多事情都不言而喻。利益相关者的“计划会议”会拖慢团队的进度,每周三天,每天半个小时。数据库团队恢复一个快照会让测试延后五个小时。五步走的发布审批流程意味着发布者即使在工作启动之后仍然需要补发一个发布计划。以上这些情况都是我最近遇到的真实案例,如果你们愿意分享遭遇过的相似经历,或许我可以把它们一起陈列在“反系统思维犯罪”博物馆里。

当你遇到“拦路虎”,在听天由命之前你可以很容易地想出各种应对措施。这就是为什么新人总是能够为组织带来有用的新视角。改变现状可以帮助团队把精力聚焦在为能够为客户带来价值的事情上。这方面的高涨热情最起码可以保持一段时间,不过随着时间推移,日常工作和人际关系变得繁琐起来,毫无价值的事情会占用越来越多的时间,组织开始重组,变得越来越低效。解除这个魔咒的奥秘在于,再次启动改进流程,因为这是应对变化的重要手段。

“预见”放大镜

对咖啡连锁店(也就是我们例子里的客户)的高层来说,为他们带来价值的是那些能够帮助他们更好掌控咖啡店运营的信息——管理员工、预见结果、降低成本、改进经营、防止风险以及晋升。他们并不关心分析过程是怎么发生的,它可能只是一个电子数据表格、一个 Web 服务甚至是一个晦涩难懂的符号,只要它能够将门店的销售数据转换成有意义的输出就可以了。

作为连接输入和输出两个端点的分析流程,已经成为现今大型组织发展的基本要素。因为有了这些设计良好的分析流程,组织可以以组件的方式运作,变成一个复杂的机器,创造出难以置信的产品和服务。在《重新发明组织》一书中,Laloux 把这个层面的组织演化描述为达成目标或结果导向,并把可口可乐作为例子。以结果为导向的组织很擅长创造品牌,并让它发展壮大,再把它卖掉,然后开始创造下一个新品牌。有些人对此不以为然,创造品牌并把它们卖掉,这种做法无法吸引长期的投资,从长远来看,对组织并没有好处,不过如果只是从中短期来看,这确实是无可争议的成功。

绞肉机

我之所以把这个模型叫作“绞肉机”,大概是因为当我告诉那些IT 经理他们正在运行着一个绞肉机时,他们的反应令我印象深刻。作为管理者,他们自然能够理解这个模型。今年早些时候,在亚特兰大举行的敏捷联盟大会上,我在演讲中提到了这个模型,也得到一样的反应,说明这个模型具有普遍性。

不过对团队成员来说,他们需要更加警惕。在“绞肉机”里工作的团队要胜任他们的工作,否则他们会被其它团队取代。团队里的每个人要为自己和整个团队保持竞争力,不管是在技能、领域知识、沟通技巧和对流程的理解上,以免赞助商把橄榄枝伸向其它更好的团队。

“绞肉机”以结果为导向,而不是人际关系。团队的管理者和团队成员意识到自己还不如度量指标重要。有个高级经理告诉我,他即将失去他在欧洲的一个团队,就因为这个团队的成本比他的外包团队要高出四倍,而跟这个团队的产出毫无关系。很明显,这是高层向我们传达的信息:我们也喜欢敏捷,但在面临关键性决定的时候,我们更关心如何降低成本而不是怎么去改进质量。那些精明的经理清楚地知道这个信息的含义,好的技术人员离职去寻找更能体现自己价值的工作。如果有人原地不动,你一定会疑惑他们为什么还留在那里!

对于例子里提到的咖啡连锁店来说,BI 分析流程只不过是另一个绞肉机组件(很抱歉把咖啡店跟熟食店联系到一起)。BI 分析流程有可能需要升级或者被外包出去,咖啡连锁店的管理层有可能选择另一个服务提供商。主动权都掌握在他们手里,他们有足够的灵活性做出变更和改进。这就是大型组织想要的敏捷——绞肉机式的敏捷。

管理层真正想从敏捷中得到什么?为什么是这样?

今年早些时候,我有幸向一些高级经理提出了这个问题,他们给我的答案是“敏捷交付”。他们说敏捷交付就是要在较短的时间内做出交付(比如几周而不是几年)、具备变更优先级的灵活性以及在必要情况下改变目标方向的能力。

这听起来更像是一种合理的需求,而不仅仅停留在“我要采用敏捷”的阶段。绞肉机式的敏捷是满足这个需求潜在的方案,不过这并没有解释为什么他们需要这样的解决方案(我在InfoQ 上另一篇文章“用户故事是需求的替身”描述了用户故事在“什么”和“为什么”两方面达成一致的重要性)。

于是我针对“为什么”的问题展开调查,并且发现那些高级经理之所以需要敏捷,是因为他们可以借此制定更好的计划来保护组织并为组织创造价值。这些计划都是中短期的,这刚好是那些所有者租赁办公场所的时间,也是他们获得利益的时间。

从采用敏捷的那天起,我们所经历的一切使得我们不得不承认,组织并不希望我们改变组织的价值观和原则,尽管它为员工提供了更好的资源来开发更好的软件。组织需要的是可预见的敏捷交付。但问题是,软件开发是不可预见的。

你无法控制那些不可考量的东西

我最近一次跟客户一起工作是在丰田的英国工厂里,我们为他们的高层写了一个系统,借助这个系统,高层管理者可以知道他们的后勤部门是如何支配时间和资源的,我们因此可以看到他们员工的产出。信息先是被记录在A3 大小的纸上,然后被输入系统,最后通过分析可以知道他们的工程师是如何支配工作时间的。

这是一个有关管理者减少浪费和改进流程的例子。管理者这么做是为了保护“绞肉机”,防止在内部执行流程的员工对其进行破坏。他们并非不相信他们的员工(虽然从表面上看是这样的),而是因为员工的时间实在太昂贵了,所以这么做是值得的。如果24 个人每周工作35.7 小时,他们就可以为组织贡献856.8 个小时的工作量,这些工作可以是那些已经安排好的和不在安排之内的任务,比如培训、紧急任务、缺陷修复和日常改进。

这就是系统思维。明确的范畴,清晰的时间线,真实可信的数据。

“绞肉机”模型的运作遵循精益法则,它可以被应用在任何可自动化的场景里,包括那些需要人类参与的场景,因为有时候使用机器人成本太高了。

在过去的十年,我和很多团队一起合作,构建智能的账单系统、支持大量交易的有卡和无卡支付系统、银行的财务系统和航空公司的订票系统。尽管这些公司在它们所处的行业里都算得上是巨头,但我们从来没有见过这些系统为它们带来过利润,因为这是不可能的事情。所以说,组织的价值在于为内部员工带来更多的知识,并让那些为它们所提供服务买单的客户记住了它们。这些东西是没办法衡量和操控的,不过它们是可预见的。

对线性的误解

Lorenz 在 1972 提出的蝴蝶效应向我们阐述了一个细微的改动如何给一个复杂系统带来不可预测的影响。Lorenz 说,一只蝴蝶在巴西扇动一下翅膀,有可能在德克萨斯掀起一场龙卷风,因为气候是一个动态非线性的系统。蝴蝶效应和 Lorenz 的报告跟人们对这些系统可预见性的误读有关。蝴蝶效应被人们误读,包括我在内,直到我读了 Taleb 的《黑天鹅》这本书。Taleb 认为线性系统是可以预测的,因为输入和输出之间存在直接的联系,但我们无法预测非线性的系统,因为这类系统的规模无法衡量。对系统内部的东西我们知道得太少。人类的大脑就是这样工作的,我们先分析问题然后再解决问题,并把它们写成指令让机器来执行。

每个组织都有自己的特点,文化、行为、传统、流程、员工、工具、环境、发展的激情,这些元素与客户对特定产品的需求交织在一起,就像黑洞一样难以预测。这意味着一个组织的变更对另一个组织来说不一定会产生相同的结果。甚至可以这么说,同一个组织里的不同团队,尽管他们接受相同的培训,遵循相同的流程,具有相同的目标和指示,他们仍然会产出不一样的结果。所以,任何重度依赖人类推理的系统都将不可扩展,尽管随着时间推移它可能是可预见的。需求分析、用户界面设计和编码实现就是很好的例子,又比如设计下一代汽车混合动力引擎、音乐创作、玩填字游戏或为疾病寻找解药。在上述的每一个场景,随着时间推移,团队都会变得可预见,但他们的经验、技能和知识无法被用在其它团队上。他们必须自己去经历、去学习。

人类的团队不可复制,它们是非线性和不可以预见的。不过团队的输出却可以是线性的,可扩展,可预见。

这是因为我们每个人所处的环境不一样,我们的经历、喜好和情感过滤器决定了我们会使用何种方式来处理所接收到信息。每个人都有一只扇动翅膀的蝴蝶,它从我们的环境获取信息,形成不同的效应。

在最近的一个“一天学会敏捷”的课堂上,我看到有个人制作了一个非常复杂的电子表格来管理团队的时间。作为一个瀑布模型项目的管理者,他过去的经历成为他转向敏捷的一个阻碍。

在另一个组织里,敏捷教练使用电子表格工具来做项目计划。他们很认真负责地为每个团队成员计算假期、培训天数,并把它们从 sprint 可用时间里减掉。如果有人在其它项目上花费了 50% 的时间,他们的时间就会被减掉一半。他们还会为缺陷修复预先分配一些时间,以及随时待命的时间,甚至还包括花在管理上的时间。然后他们在计划会议上公布剩下的留给开发的时间。在他们对用户故事进行了完整评估之后,产品所有者接受了这些用户故事,这个 sprint 就开始启动了。两周后,他们交付了一些东西,完成 0% 到 50% 的目标。他们是不可预见的,尽管我对其中的原因心知肚明,但我仍然无法说服这些团队放弃使用他们的电子表格工具。他们被告知要使用这些工具,他们的经理告诉他们要这么做,他们不想冒任何风险去违背它。

当我跟他们的经理谈论这件事,我发现正是这些经理试图通过从 scrum 里挤出时间来达成他们自己的交付目标。至少他们解释了那些预留的时间是为了应付突发情况。

于是我告诉那些经理,他们的预测手段破坏了反馈机制,如果没有反馈,整个团队就不可预见。我想帮助他们让团队变得稳定且可预见,以便改变现状。我们建议所有团队把注意力聚焦在“可预见性”上,我和他们的敏捷教练一起工作,帮助他们把上一个 sprint 的产出应用到下一个 sprint 上。这对这些团队来说很困难,因为他们习惯于使用人天来计算工作量。他们在转向敏捷之前,甚至无法分清估算的人天和计划的人天之间的区别。有一个团队勇敢地尝试使用用户故事分数来做估算,不过当团队的成员搞清楚用户故事和人天之间的换算汇率,他们就可以使用人天乘以这个汇率,所以这种估算方式跟人天没有什么不同。

几个月之后,大部分团队能够做到根据上一个 sprint 的产出来作计划,而且每个 sprint 都可以达成 75% 以上的目标。有一个团队在发现他们漏算了一个银行公共假日后果断放弃了原先的计划方式,这说明他们原先的方式也是错误的。

管理者的作用

一旦你意识到所谓的转向敏捷目的是为了可预见性和敏捷性,而且管理者和团队成员极力想达成这个目标,那么这个时候管理者角色就成为取得进展的关键因素。在大多数组织结构里,作为两个利益阶层粘合剂的管理者,他们不断探索如何更好地协调两个利益阶层的关系,所以他们在达成目标方面有很强的执行力。

如果一个组织的大部分价值跟设计并构建了操作系统的技术人的集体思维有关,而且这些人的表现很大程度上取决于那些无法量化的因素,比如动机、理解和解决问题的能力,那么很显然,管理者角色的作用就要跟着发生变化。管理则不再需要为了保护组织资产而去限制员工,他们需要帮助员工解决挑战,尽量想办法让员工快乐地留在组织里工作。

那么对组织来说什么才是最有价值的?更重要的是,对于正在转向敏捷的中大型组织的管理者,我们需要重新思考他们的角色作用。我想这个看法可以写成另一篇文章,在这里我只想提一个问题:管理者所期望的过渡阶段是多长时间?微软用了超过十年的时间才转向敏捷(HBR 文档里有记载,同时也向 Stephen Denning 确认过),那么对于那些主要采用了大型机技术的银行、保险公司和制造商来说,他们转向敏捷需要多少时间?

每个团队都是独一无二的,每个团队都需要去改进自己的缺陷。他们只能按照自己的速度来进行,而且是循序渐进地进行。另一方面,我们应该认识到自动化在这个过程中起到多么重要的作用,因为自动化系统是线性的。由一个团队开发的自动化流程可以应用在其它团队上。

可预见的敏捷交付总结

人类的团队是独一无二的、非线性的、不可预见的,但在一定条件下,他们的输出结果可以变成线性的、可扩展的、可预见的。认识到这点是很重要的,因为它向我们指出了在管理上需要作出的响应和改进的途径。

绞肉机模型可以帮助管理者和他们的团队更好地理解知识工作领域的演化过程,并从计划驱动转向可预见的敏捷交付。系统思维和与之相关的方法论,包括敏捷,都是建立在一组对组织来说并不存在的价值上。团队成员和他们的管理者一般都支持这样的观点,但要克服文化和系统的障碍对他们来说有点困难。

管理者们需要在某些方面做出转变:鼓励提升可预见性,理解他们团队的需求,自己动手清除障碍或快速升级问题以便得到解决。

关于作者

Russ Lewis (@ConsultStorm)是一个敏捷教练,致力于帮助组织向可预见的敏捷交付转型。他是一个从技术专家转型到管理的先行者,他现在开始帮助团队成员和管理者更好地工作。他深入各个阶层,通过沟通取得进步。他主导了伦敦无接触票务支付系统的架构转型和伦敦国家铁路系统交通卡的普及,并为 Amadeus 公司的敏捷转型提供支持。他还在各种开发大会上发言,写过排名前100 的有关敏捷的博客

查看英文原文: Predictable Agile Delivery

2017 年 1 月 18 日 16:521091
用户头像

发布了 321 篇内容, 共 108.1 次阅读, 收获喜欢 101 次。

关注

评论

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

天地玄黄,宇宙洪荒

zhoo299

随笔杂谈

200 行代码就能骗人的首个聊天机器人

程序员生活志

编程 机器人

疫情按下快进键,电商抢占市场红利需可靠的助力

华为云开发者社区

高并发 电商 华为云 流量 云服务器

GrowingIO 数据采集 iOS SDK 测试实践

GrowingIO技术专栏

ios 数据采集 sdk

带着面试题学习红黑树操作原理,解析什么时候染色、怎么进行旋转、与2-3树有什么关联

小傅哥

Java 数据结构 小傅哥 红黑树 2-3树

常用SQL语句分享

Simon

MySQL sql

一个域名值百万, 现在不注册,未来价更高

华为云开发者社区

备案 商标 DNS 域名配置 SSL证书

MySQL常用函数介绍

Simon

MySQL mysql常用函数

带你认识MySQL sys schema

Simon

MySQL

时间戳,这样用就对了

Simon

MySQL timestamp

糖果不需要意义

zhoo299

随笔杂谈 电影

Docker入门与简单使用

Simon

Docker Linux

大数据平台架构设计探究

vivo互联网技术

大数据 架构设计 数据平台

高效程序员的45个习惯:敏捷开发修炼之道(4)

石云升

读书笔记 敏捷开发

不说再见

太以

疫情 毕业季 遗憾 大学

MySQL中几种常见的日志

Simon

MySQL 日志

MySQL下的DB Link

Simon

MySQL

MySQL容器化详细教程

Simon

MySQL Docker 容器化

Docker 架构及工作原理

哈喽沃德先生

Docker 容器 微服务 容器技术 容器化

学习源码的第八个月,我成了Spring的开源贡献者

程序员DMZ

spring 开源

Flink任务执行-3

小知识点

大数据 flink

ARTS打卡第一周(200511-200517)

老胡爱分享

ARTS 打卡计划 ARTS活动

三分钟看懂Python和Java的区别

程序员生活志

Java Python

拼多多员工小便池拉屎,网易智能马桶屏蔽信号,360、搜狐厕所被监控,互联网公司厕所那些事!

程序员生活志

互联网 职场

LeetCode152-乘积最大子数组-medium

书旅

LeetCode 动态规划

LeetCode题解:11. 盛最多水的容器,while循环双指针,JavaScript,详细注释

Lee Chen

LeetCode 前端进阶训练营

CDN百科11 | 担心纸质病例被洪水淹没?ECS+CDN+OSS如何助力医疗上云

巨侠说

CDN 存储 云服务器

云上攻击太多怎么办?不妨试试这些工具

华为云开发者社区

黑客 云服务 数据安全 华为云 企业上云

互联网公司建网站时最应该注意什么?

姜奋斗

互联网 网络安全 网站 网站搭建 互联网公司

Docker从入门到放弃---基础篇

书旅

Docker 容器 容器化

SecureBoost算法

soolaugust

学习 同态加密 secureboost

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

可预见的敏捷交付-InfoQ