1.4 工作方式

概述与动机

“工作方式”描述的是你的团队在日常工作中实际如何协调、规划、沟通和交付。工作是如何被拆分的？谁在什么时候与谁交流？进度是如何被追踪的，决策和知识又是如何流动的？

大多数组织都会采用一种有名有姓的方法论，Scrum、看板（Kanban）、某种扩展框架，并假定这些仪式与其背后的价值是同一回事。事实并非如此。那些改变了软件交付方式的方法论，最初是对重量级的、依赖交接的流程的一种反抗。它们的目标是快速反馈、小批量和被赋能的团队。如果只采纳仪式（）站会、冲刺、故事点（）却不采纳其背后的原则，你得到的就是流程的成本，却没有它的收益：货物崇拜式敏捷。

对大型团队而言，这正是良好意图成败的分水岭。一千名工程师不可能都待在同一个房间、参加同一场会议，或共享同样的默会知识（tacit context）。规模越大，就越需要依赖书面沟通、异步协作和轻量级协调，而不是会议和走廊闲聊。规模改变了物理法则。对八个同处一地的人运作良好的实践，放到八十个分散各地的人身上可能就会崩溃。而那些承诺解决这一问题的扩展框架，往往又重新引入了敏捷本应消除的交接和中心化。

企业和政府机构会全力感受到这些压力。它们跨越多个时区，把正式员工与承包商和供应商混合在一起，还常常背负着强制性的阶段关卡和报告要求。在这里，一种以文档为先、异步、以成果为导向的工作方式，不是锦上添花，而是唯一能够扩展的方式。下面的建议更倾向于把原则适配到具体场景，而不是整体照搬某个框架，也更倾向于书面的、异步的、透明的实践，从而让庞大的、分散的、混合的团队真正实现协作。

关键原则

采纳原则，而非仪式；在照搬一种实践之前，先理解它为什么存在。
小批量和快速反馈胜过大计划和长周期。
在合适的地方，优先选择流动（限制在制品数量）而非僵化的时间盒。
估算是为了促成对话和规划，而不是制造虚假的精确。
默认使用异步的书面沟通；把同步时间留给真正需要它的事情。
让工作和决策可见并留档，使任何人都能在不开会的情况下跟上进度。
以交付的成果为优化目标，而不是所执行的活动或所利用的产能。

建议

依据场景调整敏捷、Scrum、看板和精益

要把这些方法当作一套工具箱，而不是一种信仰。Scrum 的时间盒式冲刺适合那些能从固定节奏的规划和评审中受益的、有探索性工作的团队。看板的持续流动和明确的在制品限制，适合那些工作不可预测、由中断驱动的团队，例如平台和运维团队。精益（Lean）对消除浪费和缩短前置时间的关注，是两者共同的基础。要有意识地做出选择。在有帮助的地方进行混合；许多团队运行的是”Scrumban“。保留那些能创造价值的实践，放弃那些已经沦为空洞仪式的活动。对任何实践的检验都很简单：它是否缩短了反馈、减小了批量，或提高了清晰度？如果没有，就应当质疑它。

谨慎扩展，而非货物崇拜

扩展框架（）SAFe（规模化敏捷框架）、LeSS（大规模 Scrum）、被广泛传播的”Spotify 模式”（）承诺协调众多团队。要以怀疑的眼光看待它们。SAFe 带来了结构性，常常因其全面性和培训生态系统而被大型企业和政府机构选用，但它也可能重新引入繁重的规划、层级结构和交接，从而削弱敏捷性。LeSS 更贴近精益原则，但要求真正的组织变革。所谓的 Spotify”模式”，只是一家公司不断演变的文化在某一时刻的快照，从来都不是一个模板，即便 Spotify 自己也并没有按照人们想象的那样运作。更应优先通过上一章所述的团队拓扑来减少协调的需求，从而实现扩展，而不是把一个协调框架强行嫁接到一个支离破碎的结构上。

诚实而轻量地进行估算

故事点和速度能帮助你的团队规划自己近期的工作，并就相对复杂度进行讨论。它们不是生产力指标，不是跨团队的通用货币，也不是承诺。绝不要把速度变成一个目标：它会因为点数膨胀而被操纵。对于更长期的预测，应优先计数吞吐量并使用历史周期时间数据，这往往比累加估算更准确。许多成熟的团队通过把工作切分成大小相近的小块、并简单计数它们的数量，来削减估算方面的开销。无论用什么方法，都要记住估算是不确定性下的预测，而不是承诺。要把它们表达为区间。

默认使用异步的、以文档为先的沟通

在庞大的、分散的组织中，同步会议无法扩展，还会把身处其他时区的人排除在外。要把书面写作作为默认方式：设计文档、决策记录、书面状态更新，以及承载足够上下文、无需一次实时对话就能据此行动的详尽工单。把那些无法避免的会议记录并总结下来。一种以文档为先的文化，能让身处另一个时区的人充分参与贡献，能让新加入者和承包商通过阅读来完成入职，还能留下一份持久的记录。把同步时间留给真正的协作、建立关系，以及快速厘清歧义。要保护大块的专注时间，不被会议切得支离破碎。

在跨时区、承包商和供应商的场景下良好运作

在规模化的场景下，分散的、混合的团队是常态。要为”跟随太阳“（follow-the-sun）模式而设计，在这种模式下，交接是书面且完整的，而不是口头的。设定几个重叠的核心工作时段，用于你所需要的同步联系，并公平地分担不便会议时间所带来的痛苦，而不是总是让同一个地区承担。对于承包商和供应商，要额外投入书面上下文、清晰的接口和共享的工具，因为他们不具备你的正式员工所积累的默会知识。要把供应商纳入同样可见的看板和文档中，而不是通过一个独立的、不透明的渠道来管理他们。在可能的地方，要围绕成果而不是工时来构建合同结构。

权衡：优点与缺点

方法	优点	缺点
敏捷（利益相关者互动）	高度协作，价值实现最快	需要信任和灵活性
Scrum（时间盒式冲刺）	有规律的节奏，可预测的韵律，内置反思机制	仪式开销；不适合由中断驱动的工作
看板（持续流动，限制在制品数量）	灵活，能暴露瓶颈，适合运维场景	节奏感较弱；需要纪律来限制在制品数量
SAFe / 重量级扩展框架	结构性强，配套培训，为大型组织和政府机构所熟悉	重新引入层级结构和交接；可能扼杀敏捷性
LeSS / 轻量级扩展	更贴近精益原则	要求深度的组织变革
异步 / 以文档为先	能跨时区扩展；持久留存；包容性强	对模糊话题的处理较慢；需要书写纪律

总体的权衡在于协调与自主之间，以及结构与适应性之间。更多的框架和更多的同步协调换来的是可预测性和一致性，代价是速度、开销和团队自主权的削弱。更少的框架换来的是速度和主人翁意识，代价是众多团队之间可能出现的不一致。对大多数大型组织而言，最佳答案是一种最小化的共享节奏，加上强有力的书面实践。这从源头上减少了协调负担，而不是用更重的流程去管理它。

与团队讨论的问题

如果管理层想要一个扩展框架所承诺的那种可预测性，你们要如何在不重新引入敏捷本应消除的交接的情况下，给予他们这种可预测性？ 大型企业和政府项目往往强制要求 SAFe 式的大房间规划和阶段关卡报告，因为监督机构需要能看到的预测和协调。相抗衡的考量是真实存在的：管理层需要跨众多团队的可预测性和一致性，而重量级框架正是以速度、开销以及那些拖慢交付的交接本身为代价来换取这一点的。请把证据带到讨论中来，例如一周工作时间中有多少消失在规划活动和跨团队依赖协调之中，以及这些活动究竟是消除了依赖，还是仅仅把它们暴露了出来。更有力的做法，是通过团队拓扑来减少协调需求，从而实现扩展，然后从实时看板和书面接口而不是从规划马拉松中满足报告需求。要判断哪些协调是真实的，哪些只是仪式，并用吞吐量和周期时间数据、而不是某个框架的开销，来给管理层提供他们所需要的预测。
你们究竟会采取什么行动，来阻止速度被变成一项跨团队的生产力指标？ 故事点能帮助单个团队规划自己近期的工作，而一旦它们被跨团队比较，或被设定为目标，就立刻变得毫无价值，因为点数膨胀是理性的应对方式。在大型组织中，把速度汇总成一份供高管比较的仪表盘的冲动十分强烈，它会在不知不觉中腐蚀团队所依赖的估算。请带来漂移的证据：点数是否随时间膨胀，团队是否在估算中掺水，是否有人正依据速度被排名？对于任何离开本团队范围的预测，应优先计数吞吐量并使用历史周期时间数据，并把估算表达为不确定性下的区间，而不是承诺。讨论的结果应当形成一项明确的约定：速度绝不离开本团队，跨团队预测应改用流动指标。
你们对”写下来”的具体标准是什么，又有哪些决策确实仍然需要一次同步对话？ 以文档为先的默认方式是能够跨时区、承包商和供应商实现扩展的关键，而这需要付出真正的书写纪律，并非人人都已具备。要把标准具体化：一张工单是否承载了足够的上下文，使人无需一次实时通话就能据此行动？决策是否落入一份持久的记录？那些无法避免的会议是否被记录并总结？对于混合了正式员工和缺乏默会知识的承包商的企业和政府项目而言，书面上下文正是让一支混合的、分散的团队能够充分参与贡献的关键。其中的权衡是，模糊或有争议的话题往往通过同步方式解决得更快，因此要明确把这些话题指认出来，把稀缺的同步时间留给它们。要决定由谁来承担养成书写习惯的成本以及不便会议时间的成本，并公平地分担这一成本，而不是总是让同一个地区承担。
如果我们仅仅依据每一项活动是否缩短了反馈、缩小了批量，或提高了清晰度来评判，我们当前的哪些仪式能够存活下来？ 仪式会悄悄地累积：这里一个站会，那里一个梳理会，加上一次评审、一次回顾和一次规划活动，直到一个大团队每周花在周期性会议上的时间，超过了这些会议本应服务的实际工作。相抗衡的考量是真实存在的，因为一项对某个人而言感觉纯属开销的仪式，可能正是一个分散团队建立共享上下文或暴露阻塞点的唯一场合。请把证据带到讨论中来：每人每周花在周期性会议上的总时长、每场仪式的出席率和参与度，以及每一场仪式实际产生了什么、原本无法通过一份书面更新得到的决策或信号。对于每个团队都被要求遵循同一套强加节奏的企业或政府项目而言，累积的成本是巨大的，因此要就每一场仪式必须通过的明确检验标准达成一致，用以保住它在日程表上的位置，并愿意砍掉或合并那些仅仅因为习惯而延续下来的仪式。
当工作停滞时，我们是否知道它实际卡在哪里，我们是在管理流动，还是仅仅在管理人员配置？ 在大多数知识型工作中，一项任务生命周期中的大部分时间都花在排队、交接和评审上等待，而不是被主动处理，然而团队面对缓慢的交付时，本能的反应却是增加人手或推动更高的利用率，这只会拉长队列，而不是缩短它。这里的张力在于，限制在制品数量会给人一种把产能闲置的感觉，而看起来闲着的人会让管理者和监督机构感到不安。请带来能揭示真相的证据：周期时间的分布、主动处理时间与总前置时间的比率、各项工作在看板上被阻塞的位置，以及当你真正执行在制品限制（对同时在制的项目数量设置的上限）时，吞吐量会如何变化。对于一个以人员利用率作为考核指标的大型或政府组织而言，这会把目标从”让每个人都忙碌”重新定义为”让已完成的工作持续流动”，而这种转变往往是撬动交付速度最大的一根杠杆。
我们的工作方式将如何容纳那些不是坐在我们核心时区的正式员工的人（）承包商、供应商，以及与总部相差许多小时的地区？ 在规模化场景下，混合的、分散的团队是常态，而那些为同处一地的核心团队量身定制的实践，会在不知不觉中把其他所有人排除在外：通过私人渠道被管理的供应商、缺乏默会上下文的承包商、工作日与决策会议从不重叠的地区。这些考量彼此拉扯，因为更严谨的书面接口和完整的书面交接需要付出真正的纪律，也会拖慢同处一地的团队所享受的那种快速非正式协调。请带来诸如以下证据：谁经常缺席决策会议、时差较大的地区多久会因等待一次交接而被阻塞一次，以及供应商是在与员工相同的可见看板上工作，还是处于一条独立的、不透明的轨道上。对于在强制性报告要求下、跨越多个时区混合了正式员工、承包商和供应商的企业和政府项目而言，应当把书面的、透明的、跟随太阳式的实践当作基准，让整个团队都能参与贡献，并公平分担不便时段所带来的负担，而不是总是把它强加给同一个地区。

行业视角

初创企业。 在只有少数几个人、几乎没有现金跑道的情况下，要跳过仪式目录，以尽可能轻量的流动方式运作：一块共享看板、一份简短的书面每日更新，以及记录在文档中的决策，这样就不会有人因为等待队友醒来而被阻塞。要从第一天起就把书写作为默认方式，因为在五个人的规模下养成异步习惯，远比在五十个人的规模下再去补建要便宜得多。不要采用未来多年都用不上的扩展框架；你的优势在于几乎没有什么需要协调，所以要保护好这一点。

小型企业。 由于团队中没有敏捷教练或交付经理，预算也很紧张，应当优先选择现成的实践，而不是带有你无法证明其合理性的培训和认证成本的外购框架。要挑选一种适合你工作的方法论（）针对由中断驱动的服务型工作使用看板，针对项目型工作使用轻量的 Scrum 节奏（）并抵制在一块简单看板和清晰工单就能胜任时购买重量级工具的冲动。要把稀缺的协调精力花在把事情写下来上面，这样一个小团队就不会被某一个人的记忆所挟持。

企业。 在跨越众多团队的场景下，问题在于协调成本和一致性：一种最小化的共享节奏、一个共同的”写下来”意味着什么的定义，以及能够汇总、又不会把速度变成跨团队目标的流动指标。应通过团队拓扑来减少协调需求，从而实现扩展，而不是嫁接一个重新引入交接的框架，并把工作方式当作一种依据证据不断调优的东西来治理，而不是一次性的推行。要把接口和报告标准化，使监督需求能从实时看板中得到满足，而不是从规划马拉松中得到满足。

政府。 采购规则、强制性的阶段关卡以及公众问责，塑造着每一个选择，而由正式员工、承包商和供应商混合组成的团队，在强制性进度报告的要求下跨越多个时区。应当偏好一种以文档为先、透明的工作方式，让每一项工作都在一块员工和供应商同样可见的看板上承载完整的书面上下文，这样状态报告就能直接来自记录，而不是来自单独的会议。要围绕成果和共享可见性来构建供应商合同，而不是不透明的按小时计费，并把这份书面的、可审计的记录当作一项合规资产，而不是一项开销。

示例

初创企业。 一家由八人组成、分散各地的初创公司，跳过了完整的 Scrum 仪式目录，运行在一块共享的看板加上 Slack 中一份简短的书面每日更新之上。由于两位创始人身处不同时区，他们从第一天起就把书写作为默认方式：每一项决策都落入一份文档，这样就不会有人因为等待另一位醒来而被阻塞。当他们后来在第三个时区招聘时，入职几乎只需要阅读，异步习惯无需改变就能扩展。他们从未采用过的那种实践（）同步状态会议（）正是他们从未错过的东西。

企业。 一家跨国银行在数百个团队中推行了一套扩展框架，配套季度性的大房间规划。表面上的一致性提高了，但交付却变慢了。团队把大量时间花在规划活动上，协调该框架暴露出来、却并未消除的跨团队依赖。这家银行进行了纠偏。它只保留了真正需要的轻量级跨团队协调，重组了团队，使其端到端地拥有自己的价值流，并把大部分协调转移到书面接口和异步更新上。交付前置时间缩短了，令人筋疲力尽的规划马拉松也缩减成了聚焦而偶尔的同步会议。

政府。 一个交付公民服务的政府机构，其正式员工位于一个地区，承包商团队位于另外两个地区，跨越多个时区，并处于强制性进度报告的要求之下。它采用了一种以文档为先、基于看板的工作方式。每一项工作都在一块员工和供应商同样可见的共享看板上承载完整的书面上下文。各地区之间的交接是书面且完整的。所要求的状态报告直接来自看板，而不是来自单独的会议。这让一支分散的、混合的团队得以持续协作，顺带满足了监督报告的要求，并减少了这个机构对难以排期的跨时区会议的依赖。

商业论证：动机、投资回报率与总拥有成本

其经济论证建立在流动效率之上。在大多数知识型工作中，一个工作单元被主动处理的时间，只占其总前置时间中很小的一部分。其余的时间都花在等待上：排队、开会、交接、时区差异。那些缩小批量、限制在制品数量、用书面异步流动取代同步瓶颈的工作方式，直接针对的正是这种等待。其回报是更短的前置时间和更高的吞吐量，且无需增加人手，此外还有更少的缺陷，因为反馈能在上下文还新鲜时更早到达。

要权衡采纳的成本与维持现状的成本。以文档为先、异步和精益流动，其成本主要是习惯上的改变，以及在书写和工具方面的一些前期投入。它们不需要昂贵的许可证。相比之下，重量级的扩展框架则带有真实的成本：培训、认证、专职角色，以及大型规划活动持续不断的开销。只有真正的协调需求才能证明这些成本是合理的。什么都不做的成本，会体现为被会议塞满的日程表、被排除在外的远程贡献者、消耗时间却不改善结果的货物崇拜式仪式，以及缓慢的交付。要向管理层说明理由，可以衡量交付前置时间、部署频率，以及一周工作时间中有多少比例流失在低价值会议上。在庞大的团队中，流动方面的微小改善累积起来，会带来巨大的产能收益。

反模式与陷阱

货物崇拜式敏捷：执行仪式却没有其背后的原则。
把速度当作目标：诱发点数膨胀，摧毁该指标的实用性。
框架崇拜：不考虑是否适配，强行套用 SAFe 或”Spotify 模式”模板。
把估算当作承诺：把不确定性下的预测当作有约束力的承诺来对待。
会议驱动型文化：默认使用同步通话，把其他时区的人排除在外。
未留档的决策：知识被困在人们的脑海中和过去的对话里。
供应商黑箱：通过不透明的侧渠道管理承包商，而不是共享可见性。
利用率崇拜：以最大化每个人的忙碌程度为目标，而不是以已完成工作的流动为目标。

成熟度模型

第 1 级，启动。 流程是临时性的或货物崇拜式的；团队执行着借来的仪式，却不理解其背后的原则，或者干脆没有共享方法、完全靠临场发挥。沟通是会议驱动的、未留档的，决策存在于人们的脑海中，估算被当作承诺来对待。分散的贡献者、承包商和有时差的地区靠口头协调，只要正确的人还在睡觉，就会被搁置。
第 2 级，发展。 各个团队分别采用一种有名有姓的方法论，例如 Scrum 或看板，并以一定的一致性加以遵循，但实践因团队而异，仪式也常常流于形式。一些团队会撰写设计文档和决策记录，而另一些团队仍然依赖开会。估算和协调都在发生，但缺乏对”写下来”意味着什么的共享标准，因此上下文仍在流失，跨团队交接依然繁重。
第 3 级，标准化。 实践被有意识地选择以适配具体工作，并被记录为一项全组织范围的预期：一种最小化的共享节奏、一个针对工单和决策记录中书面上下文的明确标准、以异步的、文档为先的沟通作为默认方式，以及把估算用于对话而不是用于控制。该标准被一致地执行，因此任何团队中的承包商或新加入者都能通过阅读完成入职，供应商也能在与员工相同的可见看板上工作。
第 4 级，管理。 工作方式是依据基线来度量的，而不是被想当然地假设。团队追踪交付前置时间、周期时间的分布、部署频率、吞吐量，以及一周工作时间中流失在低价值会议上的比例，并留意速度是否正因点数膨胀而被操纵。在制品限制依据证据来执行，管理的是流动而不是利用率，数据而非意见决定了哪些仪式能保住自己的位置，以及队列正在哪里变长。向管理层和监督机构的报告直接来自这些实时指标。
第 5 级，编排。 组织依据流动指标和回顾性证据持续调优自己的工作方式，协调需求通过团队拓扑从源头上被最小化，而不是靠更重的流程去管理。工作方式、交付指标和组织设计相互集成，并随着团队构成、市场和监管形势的变化而适应；由员工、承包商和供应商跨越多个时区组成的分散混合团队顺畅协作，而那些不再值得其成本的实践会被悄无声息地退役。

讨论提纲

如果我们仅仅依据每一场仪式所创造的价值来评判，我们会保留其中哪些？
我们是通过增加一个框架来实现扩展，还是通过减少协调需求来实现扩展？
我们的速度是一种规划辅助工具，还是一个我们正在暗中操纵的目标？
有哪些决策和状态只存在于会议和人们的记忆中，本应被写下来？
我们的同步会议的成本由哪个时区来承担，这公平吗？
我们的承包商和供应商是否与我们的员工处于同样可见的流动之中？

关键要点

要采纳方法论背后的原则，而不只是它们的仪式。
选择敏捷、看板，或两者的混合，以适配具体工作；优先选择小批量和快速反馈。
以怀疑的态度看待扩展框架；通过减少协调来实现扩展，而不是增加流程。
把估算用于对话和预测，绝不用作生产力目标或承诺。
默认使用异步的、以文档为先的沟通，使庞大的、分散的、混合的团队能够协作。
以成果和流动为优化目标，而不是活动或利用率。

参考文献与延伸阅读

David J. Anderson, “Kanban: Successful Evolutionary Change for Your Technology Business”
Donald Reinertsen, “The Principles of Product Development Flow”
Mary and Tom Poppendieck, “Lean Software Development: An Agile Toolkit”
Craig Larman and Bas Vodde, “Large-Scale Scrum (LeSS)”
Nicole Forsgren, Jez Humble, Gene Kim, “Accelerate” (delivery metrics)
The Agile Manifesto and its twelve principles
Henrik Kniberg, “Scaling Agile @ Spotify” (with the caution that it is a snapshot, not a model)
GitLab’s public Handbook on asynchronous, remote-first working