主题 7.1 — 敏捷交付实践与团队健康

一句话概括： 一个交付团队每周实际如何工作——它的节奏、它的仪式、它的工作协议，最重要的是它的健康状况——不是软技能的装饰，而是决定安全、可用的数字照护能否被交付并持续维系的操作系统。

为什么这在卫生与照护中至关重要#

主题 7.0——团队结构、角色与责任划定了你团队周围的边界，并指明了谁做什么。本主题讲的是工作开始后、那些边界内部发生的事情：两周的节奏、人们真正参加的会议、约束行为的协议，以及在压力下维持团队运作的人力可持续性。结构是解剖学；工作方式是生理学。

在卫生与照护中，这比在大多数行业中更重要，因为构建和运行数字服务的团队常常支持着从不停止的临床运营。一个维护电子病历、电子处方系统或床位管理平台的团队，处于照护交付的关键路径上。当那个团队精疲力竭、噤若寒蝉，或淹没在计划外的工作中时，失败模式不是一个错过的市场营销截止日期——而是一次延迟的诊断、一个用药错误，或一起一个休息充分、心理安全的团队本会发现并标记出来的安全事件。

有强有力的证据表明，团队氛围会影响临床成果。对患者安全的研究一贯将员工敢于就风险发言的能力与预防伤害联系起来，从 Mid Staffordshire 事件以来对 NHS 失误的审查一再发现，那些担忧未被发声或未被听到的文化。你的交付团队如何运行其站会和回顾会，是同一个问题的一个小规模版本：人们能否毫无恐惧地说"这不安全"？你如何工作是一个临床安全和公众信任问题，而不仅仅是一个生产力问题。

核心概念#

敏捷软件开发（Agile software development）。 一系列方法的统称，在 2001 年的《敏捷宣言》中被系统化，相对于详尽的前期规划，更青睐可运行的软件、与用户的密切协作，以及对变化的响应。在卫生与照护中，敏捷不是跳过治理的许可证——而是一种更早、更频繁地揭示临床安全和信息治理问题的方式，而不是在最后才揭示。敏捷性是通向安全、有价值交付的手段，不是目的本身。

迭代与增量开发（Iterative and incremental development）。 以小的增量构建一项服务，每一个都是可用的，每一个都会产生塑造下一个增量的反馈。这是所有敏捷方法背后的核心机制：你通过交付薄片并观察真实使用来学习，而不是通过提前预测一切来学习。

Scrum。 最广泛采用的敏捷框架，将工作组织成称为冲刺（sprint）的固定长度迭代（通常为一到两周），每次迭代在开始时有计划会，结束时有评审会和回顾会，配有每日站会（Stand-up meeting）进行协调。Scrum 的价值在于它可预测的节奏和内置的检视与调整循环；它的风险是被当作仪式采用、却没有底层的透明度。

看板（Kanban）。 一种持续流动的方法，在一个看板上可视化工作，限制每个阶段的在制品数量（WIP），管理流动而不是有时限的批次。看板适合从事运营和支持工作、需求不可预测的团队——卫生与照护中很多实时服务工作——因为它不会把不规律的到达强行塞进人为的冲刺边界。WIP 限制是它的标志性纪律：一个同意一次最多处理，比如说，三个事项的团队，比一个什么都开始却什么都完不成的团队更快地完成事情。

就绪定义与完成定义。 两份约束质量的共享协议。就绪定义说明一项工作在团队开始之前必须满足的条件（清晰的用户需求、验收标准、已识别的任何临床安全或无障碍性考量）。完成定义说明"完成"意味着什么（已测试、无障碍、已文档化、已评估安全影响、已部署）。在卫生与照护中，完成定义是你把不可谈判的事项硬性写入的地方——DCB0129/DCB0160 临床风险活动、符合 WCAG 2.2 的无障碍性、信息治理签核——从而使它们不能在截止日期压力下被悄悄丢弃。

团队工作协议（或章程）。 一份简短的、由团队自己拥有的文档，说明团队选择如何工作：核心工作时间、会议规范、决策如何做出、分歧如何处理、值班如何共享。它把隐含的假设转变为明确的、可修订的协议，这在临床医生、工程师和研究人员带着截然不同的职业规范汇聚在一起的多学科团队中尤为宝贵。

心理安全（Psychological safety）。 Amy Edmondson 广泛研究的共享信念，即一个团队对于人际风险承担是安全的——你可以提出一个问题、承认一个错误，或提出一个担忧，而不会被惩罚或羞辱。在谷歌著名的亚里士多德计划（Project Aristotle）研究中，它是有效团队最强的单一相关因素，在医疗保健中，它与错误报告和学习直接相关。一个没有它的团队会隐藏问题，直到它们变成事件。

职业倦怠（Occupational burnout）。 世界卫生组织认可的一种综合征，由长期未受管理的工作场所压力导致，以精疲力竭、愤世嫉俗和效能降低为特征。可持续的节奏——敏捷原则中团队应该能够无限期地维持其节奏——是对策。对于支持安全攸关临床系统的团队，倦怠是一种安全风险，因为疲惫的人在支持全天候服务时会犯错误。

持续改进（Continual improvement）。 依据证据，对你的工作方式进行小的、定期改变的有纪律的习惯。团队层面的回顾会是它的一个实例；主题 10.2——质量改进与改进科学涵盖了更广泛的科学，包括 PDSA 循环，它同样适用于你的工作方式，也适用于临床路径。

最佳实践#

1. 选择与工作性质相匹配的节奏，而不是赶时髦。 在工作可规划、你能从可预测的心跳和利益相关者节奏中受益的地方，使用有时限的冲刺（Scrum）；在需求不可预测的地方，如实时服务支持和运营团队，使用带有 WIP 限制的持续流动（看板）。许多卫生与照护团队两者都做——一种"Scrumban"混合模式——在冲刺中运行发现和构建，同时在一个流动看板上处理实时事件。有意识地做出决定，并重新审视这个决定，而不是继承上一个供应商使用的任何模式。

2. 为其目的运行仪式，当它们不再服务于该目的时就终结它们。 站会的存在是为了揭示阻碍并协调这一天，而不是向经理报告状态；评审会或演示会的存在是为了从真实用户和利益相关者那里获得对可运行软件的反馈；回顾会的存在是为了改变团队下周的工作方式。如果一次会议不再实现其目的，就缩短它、重新构建它，或停止它。测试很简单：与会者会花钱来参加吗？

3. 让演示会成为临床医生和用户看到真实进展的时刻。 每两周一次的评审会，向将使用该服务的临床医生、患者和运营人员展示可运行的软件，能使反馈循环保持紧密，并建立采纳所依赖的信任。邀请将与这项服务共存的人，在现实（而不是精心挑选）的场景中进行演示，并把你所学到的东西捕捉为待办事项的变更。这是你抵御建造错误东西的最便宜的保险。

4. 撰写一份就绪定义和一份完成定义，把不可谈判的事项放进完成定义。 商定开始和结束工作的条件，把临床安全活动、无障碍性、信息治理签核和充分的测试编码进你的完成定义，使它们成为结构性的，而不是靠英雄主义。当截止日期紧逼时，一份明确的完成定义给团队提供了拒绝交付不安全工作的语言。参见主题 3.6——DevOps 与工程卓越，了解持续交付管道如何自动化完成定义的部分内容。

5. 限制在制品。 开始是容易且令人满足的；完成才是交付价值、降低风险的关键。商定 WIP 限制迫使团队在拉入更多工作之前群策群力完成工作，这缩短了前置时间，暴露了瓶颈——在卫生领域至关重要的是——减少了同时在途的半成品、部分测试的变更数量。一个带有明确限制的可见看板，常常是一个陷入困境的团队能做出的单一最高杠杆变革。

6. 共同撰写一份工作协议，并将其视为活文档。 让团队撰写自己的章程——会议规范、核心协作时间、决策制定、值班公平性、如何良好地分歧——并定期审查它。因为数字健康团队是多学科的，跨越有着不同默认设定的临床和技术文化，使规范明确化能防止侵蚀信任的悄然摩擦。从上而下强加的章程是表演；团队自己拥有的章程是一件真正的工具。

7. 有意识地保护可持续的节奏，关注倦怠的先导指标。 依据团队能够无限期维持的产能进行规划，而不是一个英雄式的高峰；防范把加班当作常态的永久性压力。监测先导信号——上升的计划外工作、萎缩的回顾会坦诚度、人们放弃休假、值班疲劳——并在它们变成离职或事件之前采取行动。对于支撑全天候临床服务的团队，公平地共享值班、兑现补休，并为韧性、而不仅仅是理想路径配备人手（参见主题 3.8——服务管理与实时运营）。

8. 有意识地建立心理安全。 领导者设定基调：将工作框定为一个学习问题，承认自己的错误，以好奇而不是指责回应坏消息，感谢人们提出担忧。运行无过错的事后事件审查。在一个临近临床的环境中，愿意说"我认为这次发布不安全"或"我不理解这个需求"的意愿，正是伤害得以被预防的机制——因此它必须被主动培养，而不是被假设存在。

9. 使用轻量级的团队健康检查，使不可见的东西变得可见。 定期运行一次结构化的自我评估——Spotify 推广的"小队健康检查"模型，团队在诸如交付价值、学习、乐趣、使命清晰度和支持等维度上给自己打绿色/琥珀色/红色——以随时间揭示趋势。价值不在于分数，而在于它们所开启的对话，以及它们让团队在一次滑坡变成一场危机之前发现它的方式。保持它的快速，在有帮助的地方保持匿名，并由团队拥有它。

10. 运行真正改变行为的回顾会。 一次只产生一堆牢骚、没有任何行动的回顾会，比没有回顾会更糟糕，因为它教会团队发声是没有意义的。用少量具体的、有归属的、有时限的实验结束每一次回顾会；用检查上一次的实验是否发生开始下一次。把改进你的工作方式当作一份自己的持续改进待办事项，与主题 10.2 的改进科学相连接。

11. 将远程、混合和异步协作设计为默认方式。 卫生与照护交付团队常常分布在各家信托机构、地区和供应商之间，因此要把良好的书面沟通、运行良好的视频仪式，以及异步决策记录当作核心能力，而不是退而求其次的选择。默认把决策记录在缺席同事能够找到的地方，最小化那些本可以是一份书面更新的会议，并对那些真正受益于同步进行的少数高带宽时刻（计划、回顾、事件响应）保持刻意。

与团队讨论的问题#

1. 我们的节奏和仪式集合是否真的帮助我们安全地交付，还是我们只是因为一直这样做才在表演敏捷仪式？ 许多团队继承了一套仪式安排——每日站会、两周冲刺、冲刺评审、回顾会——却从不问它是否适合眼前的工作，结果是消耗真实工时、却带来递减价值的会议。诚实的辩论关乎目的：每个仪式是为了什么，一个中立的观察者看着我们的仪式会得出它实现了那个目的的结论吗？一个应对不可预测临床事件的实时服务团队可能被僵化的冲刺服务得很差，被看板流动服务得更好，而一个发现团队则受益于冲刺的心跳和它所创造的利益相关者节奏。在一套熟悉常规带来的安心感、与只运行那些赢得自己位置的活动的纪律之间，存在真实的张力。考虑用一个月的时间给你的仪式计时，对每次会议问它产出了什么决策或协调。一个好的答案对终结或重塑仪式毫不留情，区分协调需求与状态报告习惯，并把节奏的选择与你工作的实际可预测性挂钩，而不是与框架图展示的内容挂钩。

2. 在这个团队里，说"我认为这不安全"或"我犯了个错误"真的安全吗——我们怎么知道？ 心理安全容易被宣称，却难以真正拥有，在一个支持临床系统的团队中，弄错它的代价是以患者伤害来衡量的，而不仅仅是错过的截止日期。不舒服的问题不是你是否相信你的团队是安全的，而是你有什么证据：上一次有人在站会上承认一个错误、挑战一位资深人士的设计，或凭直觉叫停一次发布是什么时候，之后他们发生了什么？看看你的事件审查——它们真的是无过错的，还是每个人都心照不宣地知道谁在被追责？领导者必须诚实面对一个取舍：感觉像果断领导力的行为（快速行动、展现确定性、对坏消息反应强烈）常常恰恰是那些教会人们保持沉默的行为。考虑你最安静的团队成员是否曾在一次会议中提出异议，以及为什么他们可能不会。一个有力的答案会抵制"这里当然人们能够发声"这种舒适的假设，指出具体的近期实例，或承认它们的缺失，并指明需要改变的具体领导行为，而不是把安全当作一个团队固定不变的特质来对待。

3. 我们的工作节奏是我们能够维持一年的吗——对于我们没有做到这一点的信号，我们在做什么？ 可持续节奏是敏捷的创始原则之一，也是在压力下最先被抛弃的事情之一，尤其是对于其系统支撑着无法宕机的服务的团队。这里的张力是，英雄主义在当下是可见且受奖励的——那个周末加班修复生产环境的人受到了感谢——而一个团队健康状况的缓慢侵蚀是不可见的，直到人们离职或犯错。问你的先导指标是什么：计划外工作挤占计划工作、未休的年假、值班打扰睡眠、回顾会变得沉默、语言中悄悄渗入愤世嫉俗。在一个安全攸关的背景下，一个疲惫的团队不仅仅是不快乐的；它更可能错过那个能防止伤害的缺陷或误读那个警报，因此这既是一场临床风险对话，也是一场福祉对话。考虑你的产能规划是假设理想路径，还是为事件、休假和学习预留预算。一个好的答案会把倦怠当作一种需要设计来防范的系统属性，而不是个人弱点，指明团队将要关注的具体信号，并承诺一个具体的变革——资源配置、值班公平性、WIP 限制——而不是一句"要更有韧性"的劝诫。

4. 当截止日期临近时，我们的完成定义究竟阻止我们放弃什么——我们是否曾经证明它站得住脚？ 每个团队都能背诵临床安全、无障碍性和信息治理很重要；真正的考验是什么能在与一个硬性交付日期和一个焦虑的利益相关者的接触中幸存下来。这里的张力是，一份完成定义只有在它让你付出代价时才有意义——当它迫使团队在承诺的那天不交付，因为一次 DCB0160 危害审查或一次 WCAG 2.2 无障碍性检查尚未完成。如果你的完成定义从未有一次让你叫停一次发布，它可能是装饰，而不是一项控制。寻找压力点：谁有权说"这还没完成"，他们会得到领导层的支持，还是被推翻？考虑这些不可谈判的事项是否是结构性的——编码在管道中、在验收标准中、在签核关卡中——还是依赖于某人在最糟糕的时刻记得它们。一个诚实的答案能指出一个完成定义在压力下被援引的具体场合，或坦率地承认它还没有被测试过，并把这当作一个需要弥合的缺口，而不是一种安慰。

5. 这个团队中不同的职业文化——临床、工程、研究、交付——是否真的共享一种工作方式，还是我们在悄悄地运行在互不兼容的默认设定上？ 多学科团队在卫生与照护中被强制要求是有充分理由的，但把一位临床医生、一位工程师、一位用户研究员和一位数据分析师聚集到一个团队中，意味着带来了四套关于证据、风险、节奏和"好"看起来是什么样子的职业直觉。这种摩擦常常是不可见的：一位工程师"先发布再迭代"的偏好，在一位受训要在行动前保持确定的临床医生看来可能是鲁莽的，而一位临床医生的谨慎，在一个习惯了可逆部署的人看来可能是阻碍。一份保持泛泛而谈（"要相互尊重，参加站会"）的工作协议从不揭示这些差异，而一份好的协议会说明这个团队如何做决策、如何处理学科之间的分歧，以及如何将临床谨慎与迭代交付相调和。考虑你的规范是真正共同撰写的，还是从声音最大的那个学科那里移植来的。一个有力的答案会把职业文化的多样性当作一种安全的来源，而不是一种不便，指出在它们之间进行转译的明确协议，并能描述一次近期的分歧，团队的规范帮助其得到了良好的解决，而不是被掩盖了过去。

6. 我们如何知道我们的回顾会和健康检查正在改变什么——当它们没有改变时，坦诚会发生什么？ 一个团队可能每两周运行一次完美的回顾会，以及一次季度小队健康检查，却仍然什么都没改善，因为重要的机制不是那次会议，而是后续跟进。这种腐蚀性的失败模式是微妙的：当行动被产生却从未完成时，人们会慢慢明白提出问题是没有意义的，因此坦诚会衰退，本应揭示风险的那个工具本身也会变得沉默——在那个未言明的问题是一个安全担忧的情况下，这尤其危险。诚实的问题是有证据支撑的：在最近几次回顾会行动或健康检查信号中，有多少导致了一个可见的变化，谁拥有它们？在产生一份长长的、令人满足的抱怨清单，与承诺少量有归属、有时限、团队真正会完成的实验之间，存在一个取舍。考虑你的下一次回顾会是否以检查上一次的行动是否发生开始，以及琥珀色到红色的健康检查趋势是否曾到达有权配置资源来修复它的人那里。一个好的答案会用已完成的变化、而不是已举行的会议来衡量改进习惯，把坦诚度下降本身当作一个早期预警，并将工作方式的改进与团队会应用于一条临床路径的同一种纪律联系起来。

实践中：一个卫生与照护案例#

一家社区 NHS 信托机构运行着一个支持其电子病历（EPR）和一款面向患者的预约应用程序的数字团队。这个团队是多学科的——产品经理、交付经理、工程师、一位用户研究员、一位临床安全官，以及一位数据分析师——按照主题 7.0 的结构设立。一年来，他们运行着教科书式的 Scrum：两周冲刺，完整的仪式集合。但他们也是每当 EPR 出问题时就会被呼叫的团队，临床事件不断打乱他们的冲刺承诺，让他们感觉永远落后，回顾会也越来越平淡。

交付经理提出了一个变革。他们拆分了工作：预约应用程序上的计划产品开发保留两周冲刺，每两周向使用它的门诊临床医生进行演示，而实时的 EPR 支持则转移到一个带有严格 WIP 限制和清晰流动阶段的看板上。他们重写了完成定义，要求任何触及 EPR 的变更，在"完成"之前必须有一次已完成的 DCB0160 危害审查和无障碍性检查——把安全编码进流程，而不是留给记忆。

他们还引入了一次季度小队健康检查。第一次检查揭示出，在"可持续节奏"和"支持"这两个维度上从琥珀色滑向红色，值班总是落在同样的两位工程师身上，休假也未被使用。团队用这份证据向他们的总监提出了一个具体的诉求：一份更广泛的值班轮值表，以及夜间呼叫后明确的恢复时间。六个月后，回顾会的行动明显在被完成，临床医生信任每两周的演示，最后两个潜在的安全问题在发布之前被工程师标记出来，因为他们感到说"等一下"是安全的。这里的一切都不是什么异想天开的东西——它是团队如何工作的有意识设计。

行业视角#

初创企业#

一家小型数字健康初创企业常常凭本能运行敏捷——所有人在一个房间里，非正式的站会，快速迭代——这对速度和学习而言是一项真正的优势。风险在于，"我们太小，用不上流程"悄悄意味着完成定义遗漏了临床安全和无障碍性，直到一位 NHS 买家的数字技术评估标准（DTAC）审查揭露了这个缺口。当团队还很小、由创始人领导时，心理安全通常很高，但一位对坏消息反应不好的富有魅力的创始人，可能会无形地摧毁它。早期回报最高的举措，是写下一份轻量级的完成定义，把安全和无障碍性不可谈判事项烤进去，并在融资轮的燃烧率文化使永久性压力常态化之前，保护可持续的节奏。

小型企业#

一家成熟的小型服务提供者——一家全科诊所、一家社区药房、一家养老院，或一家单点诊所——几乎根本没有一个"交付团队"：工作方式就是诊所经理、一位临床负责人，以及也许一位兼职 IT 承包商在看诊之余所能维持的东西。没有冲刺或回顾会可以改革，因此实际的做法是借用最便宜、杠杆最高的习惯——一个可见的、对在途数量有硬性限制的待处理数字化变更看板，以及一份关于一次变更上线前谁来签核的简短书面协议。完成定义仍然必须承载与一家大型信托机构相同的法定责任——临床安全、无障碍性、信息治理——但由于没有专职的临床安全官，这通常意味着一份轻量级的检查清单，以及知道该给哪个供应商或 ICB 联系人打电话寻求保证。因为同样一小撮人既承担服务交付又承担变更，可持续节奏是一个真实的风险：一次出错的升级会落到无法简单地呼叫一个值班轮值表的员工身上。现实的抱负不是完整的敏捷仪式，而是有意识的、书面的、默认安全的习惯，能在目前把一切都记在脑子里的那一个人离开之后依然存续。

大型机构#

一家大型 NHS 信托机构或健康科技公司拥有许多团队，面临着相反的问题：敏捷仪式激增，"敏捷"变成了涂在一种未曾改变的指挥控制文化上的一层油漆，团队表演着仪式，却没有让它们变得值得的自主权。在数十个团队中标准化一个单一框架（常常是规模化敏捷）有强加节奏的风险，这适合一些团队，却使另一些团队瘫痪，因此要允许团队在共享护栏内选择 Scrum、看板，或一种混合模式。在这种规模上，跨团队汇总的团队健康检查为领导层提供了一个关于组织氛围的真实信号——但前提是数据被用来帮助团队，而不是用来排名或惩罚它们。大型机构的决定性优势，是有能力投资于使可持续节奏变得可实现、而不是仅仅有抱负的平台、值班结构和受保护的改进时间。

政府#

一个诸如 NHS England 这样的国家机构，或一个地方当局，设定了其他人据以交付的标准——GOV.UK Service Manual 和 NHS Service Standard 都要求多学科团队以敏捷、迭代的方式工作——并对公众就工作方式如何转化为物有所值负责。许多交付是外包给供应商的，因此政府在工作方式上的杠杆是合同性的：坚持要求真正的敏捷交付，在定期的演示会上展示可运行的软件，而不是接受依据一份穿着敏捷语言外衣的瀑布计划所产出的文档。问责是正式的、可审计的，这可能会拉向扼杀团队流动的重度治理仪式，因此这里的纪律是在不扼杀团队自身节奏的情况下保证成果和安全。公众信任的维度在这里最为尖锐：一个明显健康、透明的交付团队，是一个公共机构赢得持有敏感数据、运行关键服务的信心的一部分。

常见失败模式#

• 僵尸仪式。 站会是给经理看的状态表演，评审会没有真实用户在场，回顾会从不改变任何事情。这些活动在自动驾驶中运行，消耗时间，教会团队参与是没有意义的。通过无情地将每个活动重新连接到其目的、或停止它来纠正。
• 敏捷作为无计划或无治理的掩护。 "我们很敏捷"被用来为跳过临床安全、无障碍性或信息治理工作辩护。敏捷性应该更早地揭示这些，而不是为它们找借口；把它们放进完成定义。
• 对框架的生搬硬套。 复制 Scrum 或 Spotify 模型的标签，却没有底层的自主性、透明度和信任。借用原则，适应你的情境，让团队在护栏内选择自己的节奏。
• 一切在途，没有完成。 没有 WIP 限制，因此团队开始许多事情，却完不成几件，前置时间膨胀，半测试的变更不断堆积。可视化工作并设定上限。
• 英雄主义作为运营模式。 持续的加班和值班由少数人承担，受到庆祝而不是被修正。它耗竭了你最好的人才，对安全攸关的系统而言，提高了临床风险。为可持续的节奏和公平的轮值而设计。
• 没有后续跟进的回顾会。 行动被产生却从未完成，因此坦诚度衰退。限制在少量有归属、有时限的实验上，下一次检查它们。
• 被假设、而不是被建立的心理安全。 领导者宣称团队是安全的，而他们自己的反应却教会人们保持沉默。用行为、而不是信念来衡量它。

成熟度模型#

检查清单#

• 团队已有意识地选择其节奏（冲刺、流动，或混合模式）以适应其工作性质，并重新审视这个选择。
• 每个仪式都有一个每个人都理解的既定目的，不再服务于该目的的活动被改变或停止。
• 定期的演示会向真实的临床医生、患者或运营用户展示可运行的软件。
• 存在一份书面的就绪定义和完成定义，临床安全、无障碍性和信息治理被编码进完成定义。
• 在制品被可视化并被明确限制。
• 团队已共同撰写一份工作协议/章程，并定期审查它。
• 一次轻量级的团队健康检查按固定节奏运行，由团队拥有，其趋势为行动提供信息。
• 回顾会以少量有归属、有时限的行动结束，下一次回顾会检查它们是否发生。
• 倦怠的先导指标受到监测，值班被公平共享，产能被为可持续节奏而规划。
• 远程/混合/异步协作被有意识地设计：决策被记录在缺席同事能够找到的地方。
• 领导者通过无过错审查和他们自己对坏消息的可见反应，积极建立心理安全。

关键资料来源#

• 《敏捷宣言》及其十二条原则（包括"可持续的开发……保持一个恒定的节奏无限期地"）——agilemanifesto.org
• 《Scrum 指南》——Ken Schwaber & Jeff Sutherland——scrumguides.org
• 看板——David J. Anderson——可视化流动和限制在制品
• NHS England —— NHS Service Standard 和 NHS Service Manual——多学科敏捷交付和演示会
• GOV.UK Service Manual（Government Digital Service）——敏捷交付、敏捷仪式和可持续的工作方式
• Amy C. Edmondson，《The Fearless Organization》——医疗保健中的心理安全和团队学习
• Google re:Work —— 亚里士多德计划关于什么使团队有效的发现
• Spotify"小队健康检查"模型——Henrik Kniberg & Kristian Lindwall
• World Health Organization —— ICD-11（QD85）中的倦怠分类

参考文献#

1. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
2. Iterative and incremental development — Wikipedia — https://en.wikipedia.org/wiki/Iterative_and_incremental_development
3. Scrum (project management) — Wikipedia — https://en.wikipedia.org/wiki/Scrum_(project_management)
4. Kanban (development) — Wikipedia — https://en.wikipedia.org/wiki/Kanban_(development)
5. Stand-up meeting — Wikipedia — https://en.wikipedia.org/wiki/Stand-up_meeting
6. Retrospective — Wikipedia — https://en.wikipedia.org/wiki/Retrospective
7. Psychological safety — Wikipedia — https://en.wikipedia.org/wiki/Psychological_safety
8. Occupational burnout — Wikipedia — https://en.wikipedia.org/wiki/Occupational_burnout
9. Continual improvement process — Wikipedia — https://en.wikipedia.org/wiki/Continual_improvement_process
10. Manifesto for Agile Software Development — Beck et al. — https://agilemanifesto.org
11. The Scrum Guide (2020) — Ken Schwaber & Jeff Sutherland — https://scrumguides.org
12. NHS Service Manual and Service Standard — NHS England — https://service-manual.nhs.uk
13. Service Manual (agile delivery) — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/agile-delivery
14. The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth — Amy C. Edmondson — https://fearlessorganization.com
15. re:Work — Guide: Understand team effectiveness (Project Aristotle) — Google — https://rework.withgoogle.com/guides/understanding-team-effectiveness/
16. Squad Health Check model — Henrik Kniberg & Kristian Lindwall, Spotify Engineering — https://engineering.atspotify.com/2014/09/squad-health-check-model
17. Burn-out an "occupational phenomenon": International Classification of Diseases (ICD-11) — World Health Organization — https://www.who.int/news/item/28-05-2019-burn-out-an-occupational-phenomenon-international-classification-of-diseases

另见主题 3.6——DevOps 与工程卓越、主题 3.8——服务管理与实时运营、主题 7.0——团队结构、角色与责任、主题 7.5——人员与组织发展，以及主题 10.2——质量改进与改进科学。