一个团队可以有150人吗？ FAST 敏捷说是

FAST 敏捷是我一段时间以来了解到的最有趣的组织实践。今天我分享什么是FAST敏捷，并探讨它是否值得尝试。长话；博士？相当引人注目，但仍处于实验阶段。

什么是快速敏捷？

1. FAST Agile是一种敏捷软件变体。 FAST 专注于大型团队内的自组织。这些大型团队称为集体。他们可以是几个人，最多可以有 150 人 [1]。

该集体每周举行两次会议。在会议上：

• 团队成员展示并讲述他们所取得的进展。
• 产品负责人重申愿景并设定方向。他们提供了顶级项目的背景信息。随着工作完成或优先事项发生变化，他们会引入新的优先事项。通常，他们以视觉方式在墙上或虚拟等效物上显示优先级。
• 集体内的人员自行组织并自行选择组建较小的团队，以交付最优先的工作。

FAST 敏捷最有趣的部分是这些自组织团队，所以让我们更详细地描述它们。

每次会议，人们都自愿领导团队，也有人自愿参与这些团队。当有人自愿管理一个团队时，他们会上前说：“我将从事[顶级项目之一]”。然后人们加入已创建的团队并在该领域工作。团队规模最小为两人，因此需要人们“用脚投票”来组建团队。

组建的团队做不是必须围绕产品设定的优先事项。例如，可以围绕改进部署管道或改进对某些不稳定服务的监控来组建团队。

除了每周一小时的会议之外，人们大部分时间都花在自己选择、自行组织的团队中。理论上，你可以每周更换两次团队。但在实践中，人们最终会弄清楚他们喜欢和谁一起工作，团队往往会在第一个月左右就安定下来。

它们保持足够的流动性，以便人员可以随着业务需求的变化而流动，或者不同领域需要具有专业知识的人员。调动团队是一种预期的、省力的改变。因此，这意味着在集体会议期间，人们会重新创建他们的团队，但组成往往不会像您想象的那样发生变化。

还有很多其他细节，例如如何处理错误和待命值班。稍后我将介绍其中一些主题。但 FAST 敏捷的基本核心是这些自我选择的团队，在更大的集体中开展项目。集体会议是结构化的，重点是提供业务需求的背景信息，并根据这些优先事项沟通进展情况。

差异总结

FAST 与当今大多数敏捷软件组织的运行方式有很大不同。以下是我所看到的差异：

正如您所看到的，FAST 是一种与大多数公司目前采用的方法截然不同的方法。

那么有什么权衡呢？

在我看来，以下是 FAST 敏捷的权衡：

• FAST 可以提供更好的组织可扩展性
• FAST 可以逐步进行试验
• FAST 应该会减少重组
• FAST 可以更轻松地响应不断变化的优先事项
• FAST 可以更好地提高内在动机和保留率

但…

• 许多环境与 FAST 不兼容
• 您可能必须进行自我管理
• FAST 需要大量工作
• FAST 材料充满了行话

我们将依次讨论其中的每一个。

FAST 可以提供更好的组织可扩展性

当您扩展组织时，您通常通过“水平”扩展来实现。您一次可以将组织发展为一个团队。每个团队都拥有产品的一部分，并且通常有一个平台组织可以使产品团队更加高效。

随着人数的增加，组织的复杂性呈爆炸式增长。如果你有十个人从事工程工作，他们都可以互相交流。一百个工程人员不可能都互相交谈。而且代码库不适合任何人的头脑。因此，您可以将这种复杂性划分为多个团队，每个团队都有一个可以关注的领域。

FAST 很有趣，因为它是“垂直”扩展组织的尝试。 FAST 没有增加更多的团队，而是尝试建立更大的团队，称为集体。集体仍然拥有代码，但集体内的自组织团队则不拥有代码。而且你仍然需要分段沟通。但团队更加充满活力并且不断发展。它不是通过重组来重塑团队，而是您运营方式中持续的、预期的一部分。

团队规模是许多工程负责人熟悉的话题。团队应该有多大？让我们深入研究一下这个主题，因为它可以帮助我们理解 FAST 声称如何更好地扩展。

团队应该有多大？

当您与工程副总裁相处时，偶尔会出现工程团队规模的话题。您会听到针对小团队的争论，以及针对大团队的争论。双方各有各的优点。

小团队的优势

• 团队内的协调和沟通开销更少。
• 结果可以快速移动。
• 工作流程更少，因此更容易集中精力并产生结果。
• 更容易管理。

大团队的优势

• 组织更加扁平化。一个拥有 150 名工程师的工程组织将有 3-4 名主管和 10 人的团队。它将有 6-8 名董事和 1-2 名副总裁，以及 5 人团队。组织中的混乱从何而来？可能是领导层，所以大的团队可以减少混乱。
• 更有弹性。有人可以休假，团队可以继续正常工作。

因此，小型团队在团队中固然很好，但不太理想，因为团队人数太多，增加了组织的复杂性。较大的团队更适合整体组织复杂性，但每个团队内的绩效不太理想。

许多领导者采取的方法是组建大型团队，专注于较少的工作流。这降低了内部团队的复杂性，也降低了组织的复杂性。

您可以将 FAST 视为一种尝试通过极其庞大的团队实现更大的组织简化性的方法。它还试图获得小型自组装团队的好处。

扩展组织是一项具有挑战性的工作

我的大部分咨询业务都是帮助组织应对规模问题。组织在扩展过程中会遇到几个阶段的挑战。

第一个障碍通常是 15-25 名工程师。这是你的变形虫变得太大并且需要分裂的时候。您会看到以下类型的问题：

• 沟通渠道变得无效。
• 工程开始出现交付和/或质量问题。
• 经理或领导者感到不知所措。添加更多的人只会使情况变得更糟，而不是更好。

第二个障碍是大约 60 名工程师。此时，您开始看到更多的协调问题：

• 跨团队项目很少能成功。
• 产品工作淹没了平台团队，反之亦然。
• 无法完成大型计划。

我见过才华横溢的人一次又一次地失败，无法驾驭组织复杂性的这些阶跃变化。我的预感是，这些步骤顺序的复杂性增加与您添加额外的管理层相对应。

发展工程组织是一项真正的技能。它需要对组织和人员的工作方式有深入的了解。您将了解以下内容：

• 让人群一起工作的协调模型。
• 流程一致的团队与功能设计的团队。
• 如何进行重组，即随着业务优先级的变化而调整人员和代码。
• 如何将产品划分为与产品投资重叠的技术职责领域。
• 围绕团队建立沟通渠道。
• 设置随叫随到和可靠性计划以有效支持您的产品。
• 建立平台组织和开发人员体验计划来应对复杂性。
• ETC。

即使您拥有具备此专业知识的人员，您的管理团队也需要付出大量努力来处理扩展问题。因此，如果 FAST 能够更好地扩展，您将释放管理团队的大量潜力，专注于其他事情。而且，由于您的分步顺序更改发生的频率要低得多，因此您可能会使您的组织更易于管理。

围绕 FAST 敏捷的思想实验

因此，想象一下您可以扩大团队规模。如果您的团队不是由五人或十人组成，而是由二十人组成的高效团队会怎样？还是六十人的团队？

从表面上看，这是一个荒谬的提议。这么大的团队效率不高。即使是 12 人的团队也有些困难。我有时会看到那些有二十或三十人向他们汇报的人的简历。我的第一反应是认为他们在一家糟糕的公司工作。拥有如此多的直接下属是一种“组织气味”。

FAST 敏捷的核心前提是，如果您在这个更大的集体中添加自组织和自选团队，您可以更水平地扩展您的团队。每个团队（FAST 将其称为集体）可以更大。然后，人们日常工作的团队就会在这些集体中自我组装。

如果更大的集体有效，它们将显着降低组织的复杂性。典型的软件初创公司可能需要几年的时间才能划分出职责范围。代码库不需要严格划分为每个团队拥有的区域。这将节省大量的管理时间，让经理可以专注于产品和团队。

因此，这是我们需要测试的核心问题：自组装和自组织是否提供了一种与小型设计团队一样有效的运作方式？

如果确实如此，那么它将提供一种扩展组织的方法，这种方法在扩展组织方面可能会更好一个数量级。为什么这么多？让我们比较一个由 6 人规模的团队成长的组织与由 60 人规模的“团队/集体”规模扩展的组织。

这个论证中有很多假设，你也许能够找出其中的一些漏洞。但即使您这样做，FAST 本质上也允许更大的组织单位拥有产品和代码库的某个区域。

FAST 是新事物，因此目前还没有大量证据表明 FAST 团队的运作是否与传统敏捷团队一样有效。但我怀疑这个问题的答案是肯定的。我有几个理由相信这一点。首先，吉姆·肖尔（Jim Shore）的初步经验非常积极，他是我信任的人。

我看好 FAST 的第二个原因是我有过与一大群人进行自组织的一些经验。我对它的效果感到惊讶。

当然，在小公司中，你会看到很多自组织。但随着公司的发展，你会标准化事物并消除除团队内部之外的自组织。然而，我参与过的最有趣的实验之一是在 New Relic 举办的大规模自组织活动。我们重新设计了所有团队，并要求五十个软件团队中的每个人选择他们想要加入的团队。我们对每个团队所需的技能进行了限制，并定义了每个人都需要拥有的技能。它最终比任何人预想的都要成功，甚至比我们组织者预想的还要成功。

因此，尽管对此还没有定论，但我的预感是，这种做法在适当的环境下具有很大的潜力。

FAST 可以逐步进行试验

FAST 材料中没有提到这一点，但令我惊讶的是 FAST 的一个有趣之处是您可以逐步对其进行试验。

您可以在一个团队中实施 FAST Agile 作为实验，然后使用 blob 方法，随着时间的推移吞并其他团队。如果进展顺利的话，继续吞并更多的队伍。如果没有，则中止实验。

FAST 应该会减少重组

变革发生在组织中。优先事项发生转变，人员离开，产品领域出现意想不到的增长。以前的技术决策会影响你，你必须做额外的工作。新的机会出现，需要投资。

所有这些都会对您的组织结构产生影响。您有一组团队，每个团队都有自己的所有权领域。随着这种变化的发生，您将随着时间的推移重构您的组织，以尽最大努力发挥最佳作用。这些重构就是“重组”，在成长型组织中，它们可能经常发生！

使用 FAST 重组应该会大大减少。重组的单位太大了，您不必经常这样做。

这样做的一个潜在缺点是您的团队没有明确的职责范围。因此，您的责任可能会分散，并且代码共享区域可能维护得很差。 （我们稍后会讨论这个）

FAST 可以更轻松地响应不断变化的优先事项

当传统结构的团队中的优先事项发生变化时，您需要组建团队来完成这项工作。如果该团队结构不支持新的优先事项，您就必须重构您的组织。

对于 FAST，优先级的变化更加流畅和连续。只要职责属于集体，团队就可以围绕工作组织起来，一切又恢复正常。

集体会议结构也使得优先事项的变化不那么引人注目。您基本上每周都会有两次内置的全体人员会议。在集体会议上，您可以不断交流背景情况并教育您的团队有关客户和市场的信息。这应该有助于让您的团队更好地保持一致。

当我将这种方法与季度 OKR 之类的方法进行对比时，它似乎更加流畅，并且可以更好地协调人员。它确实需要产品领导者的不懈努力来不断共享背景和优先事项。但我曾加入过的一些最好的团队都有一位以这种方式行事的产品负责人，所以我怀疑这段时间花得值。

FAST 可以更好地提高内在动机和保留率

许多团队可能会觉得他们的流程被设计成控制人员的工具。感觉就像在装配线上工作。

FAST 将自组织作为其设计的基本组成部分。它是如此基础，没有自组织就无法发挥作用。它需要一个完全不同的管理工具包，并且它基本上（尽管不是完全）与自上而下的分层方法不兼容。

丹尼尔·平克（Daniel Pink）著名地概述了内在动机的三个方面：

• 自主性——渴望自我指导，这会增加参与度而不是服从性。
• 掌握——获得更好技能的冲动。
• 目的——渴望做一些有意义且重要的事情。只关注利润而不重视目标的企业最终会得到糟糕的客户服务和不满意的员工。

借助 FAST，您可以自我指导您的工作，帮助您感受到自主权。您可以选择专注于提高您的技能的工作，从而获得一种掌控感。我们会不断提醒您您的工作与对业务重要的事情如何联系起来，帮助您感受到使命感。因此，尽管不能保证，但我认为实施 FAST 的组织有可能获得高保留率。

自组织还提供了一些方便的信号，可以让社区中的人们更好地合作。 “混蛋经理”类型的人会收到这样的信号：他们的行为不受欢迎。如何？他们上前带领团队，说出自己想做的工作。如果没有人加入他们的团队，工作就不会发生，团队也不会形成（团队中至少有两到三个人，否则就不会形成）。

自组织还允许人们处理工作中可能不会引起其他公司关注的痛苦方面。例如，如果测试套件很糟糕，有人可以挺身而出，领导团队解决该问题。从事不属于明确业务优先事项的工作是完全合理的。但这是公开的，其他人必须加入才能实现。这可以帮助避免感觉就像在功能工厂中一样。

最后，您可以选择每天一起工作的人。当我过去看到自组织团队时，这是一个意想不到的好处：人们选择与他们想一起工作的人一起工作。而且这些队伍比我预想的要强大得多。

这一切需要平衡的是人们在使用 FAST 时会遇到的任何新的痛苦。一项挑战可能来自非正式的权力动态或潜在的政治。

许多环境与 FAST 不兼容

由于 FAST 太新，实施起来风险更大。 FAST 并非在所有情况下都有意义。还有更多的未知数。最好将其视为一种实验方法。

哪些环境最有利于尝试 FAST？哪些地方应该避免使用 FAST？

贵公司拥有的此列表中的品质越多，就越适合 FAST：

• 对管理创新和实验感兴趣。
• 高信任、低恐惧的环境。或者至少希望避免领导力中的命令和控制。
• 该过程的良好指导者或促进者。能够召开有效的集体会议、制定流程、评估并积极管理流程的人。了解组织动态以及群体中的人们如何协同工作的人。 （你可以为此雇用我）。
• 优先事项的变化率为中等到高。如果优先级没有改变，FAST 就没那么有用了。
• 一个协作、自我指导、高绩效、持续学习的团队。
• 一个能够确定优先事项的领导团队。
• 您有一位产品负责人，可以在每次集体会议上讨论优先事项和业务背景。他们可以有效地沟通。

这些特征越不真实，你在 FAST 中面临的阻力就越大。我认为你不需要处于完美的环境中。在某些方面，我认为想要成为这些东西比实际成为这些东西更重要。因此，也许最重要的成功因素是领导层愿意为其腾出空间。

您可能必须进行自我管理

自组织系统可以有效地工作。但它们不是免费的。他们更像是管理一个社区。

您需要创建约束和手段来激励正确的行为。你需要仔细观察并设法确保事情不会偏离轨道。

任何组织都可能有不良行为者，或者与该社区利益不一致的人。我记得有一次与一位工程师交谈，他告诉我（我没有骗你）他们认为自己没有义务为雇主创造价值。一些工程师可能希望专注于发展他们的技能或使他们成为更有价值的员工的事情，而不是对雇用他们的公司有利的事情。

通过 FAST，您将注册管理一个社区。

在传统情况下，层次结构会明确谁对此负责。在 FAST 中，我怀疑尝试避免冲突并“让成员自己解决”是很容易的。这可能会导致非正式的权力网络在某种无结构的暴政中占据主导地位。如果你确实使用 FAST，这是我会警惕的。

另一个极端是不让团队自己解决问题，而让管理层完全处理。这也可能是有害的。

因此，FAST 需要良好的引导、仔细的观察以及偶尔的干预。

FAST 需要大量工作

您可能不想尝试 FAST 的最大原因是 FAST 有很多隐藏的工作。它需要您的组织进行大量变革，采用不熟悉的运营方式。

您可以将 FAST 比作使用新的计算机编程语言。这种新语言似乎很有前途，因为它具有许多新的人体工程学功能，看起来比您以前见过的任何语言都要好。但是，您没有用这种新语言编写的框架和库。所以你必须自己构建很多东西。

所以 FAST 最大的缺点是它不是一个成熟的实践。您需要做很多事情来处理 FAST 操作方式与传统实践之间的不兼容性。这里有些例子：

绩效管理如何运作？

在传统团队中，有一位经理负责监督工作并指导个人。你有绩效评估，如果某人不适合，经理可以进行干预。尽管绩效评估存在问题，但大多数人都了解它们的工作方式，并且它们在组织中服务于一个目的。

在 FAST 团队中，并没有真正明显的方法来进行绩效评估。此人的经理是否知道他们在做什么或如何工作？你甚至无法评估“团队”，因为它们是短暂的。

因此，绩效管理的整个概念需要重新发明。无论如何，这可能是一个好主意，但这需要思考和发明。

工程经理在 FAST 中的角色是什么？

构建工程经理角色的方法有很多。我通常建议让工程经理负责项目管理，因为这可以让他们与团队并肩工作，而不会将他们置于权力差异导致问题的区域。定义工程经理角色的有效方法有很多，但我倾向于采用这种方法。

在 FAST 中，工程经理的角色不太明确。您没有长期存在的团队，因此工程经理很难与他们的直接报告并肩工作。

您可以让工程经理领导自组装团队。或者你可以让他们成为纯粹的职能经理。或者你可以让他们担任球员兼教练。

所有这些都需要权衡，并且有一些相当大的缺点。 FAST 似乎减少了对工程管理的需求。您仍然需要招聘人员、进行绩效管理和监督流程。但也许不像传统组织那样？

我见过许多组织因为不重视管理作为一门学科而遭受损失。但我猜想 FAST 组织需要的管理较少。

我真的很想知道这是否会发生，并且想听听尝试 FAST 的组织的意见。你在管理方面做什么？

如果没有所有权领域，您将如何确保代码质量？

代码所有权为保持高代码质量提供了自然的激励。这符合您的自身利益，因为未来的您必须按照当前的代码工作。

在共享代码所有权的情况下，您必须付出更大的努力来确保代码质量。我的建议是结对或围攻作为必要的练习。

您还需要更严格的代码模式标准。您需要代码检查。您将需要某种架构决策。您不希望前端代码处理状态的方式有二十种模式。这些是大多数软件组织中都会遇到的问题，但在使用 FAST 的组织中它们会更加紧迫。

许多组织投资不足的一件事是围绕有效的软件设计模式进行培训和沟通。并进行对话，以确保每个人都就使用哪种方法以及何时使用达成一致。这些在 FAST 组织中可能更为重要。

共享代码所有权是一种有先例的做法。如果您继续 FAST，那么花时间深入研究如何取得成功是值得的。

多个集体和跨越集体边界会发生什么？

跨越集体边界的工作在 FAST 中本质上是未定义的。 FAST 也没有明确说明需要高度协调的大型计划。因此，您必须针对这些情况发明解决方案。

任何规模足够大、拥有多个使用 FAST 的 Collective 的组织都会遇到跨 Collective 项目。解决这些问题的模式将与您在较小范围内解决问题的方式相似或类似。但据我所知，这在很大程度上是未知领域。因此，当这些问题出现时，您需要使用一些协调模型来解决它们。这将是一项发明行为。

FAST如何处理on-call？

FAST 指南中没有具体提及 On-call。所以你需要发明一个方案来处理它。

在传统团队中，on-call 的标准建议是让每个团队负责自己的运营。并让团队中的每个人都随时待命。这意味着您应该拥有至少四人的团队，这样负担才不会太重。我们的想法是，让团队随时待命提供工作产品可以激励他们提高可靠性。这有助于他们确保有一个体面的待命时间表。

使用 FAST，您可以创建具有层级的待命轮换（按照此操作手册进行操作，如果不能解决问题则升级）。并且您需要明确地保留谁能够支持什么的地图。这不会映射到您的团队。

这并不是很难做到，但它比传统的随叫随到的做法不太常见，并且需要管理层的关注。

修复错误和支持升级怎么样？

FAST 有一个可选角色，称为“功能管理员”。他们是特定功能的专家，并且是利益相关者围绕该功能的联系人。他们不需要持续致力于该功能，但需要持续了解它。

与待命一样，您需要将功能映射到具有这些功能专业知识的人员。这对于错误和支持升级都很重要。您也可以将其与 on-call 结合起来。您需要某种方法将问题分类给合适的人。

当专业知识仅限于一两个人时，您还需要确保拥有一种填补知识空白的机制。

您必须决定的一件事是修复错误的策略。您是否希望它们始终得到修复，从而减慢其他功能的工作速度？这些错误是由引入它们的人修复的，还是您想要其他方案？您将如何确定谁负责对错误进行分类？可能是某种轮换？

支持升级也需要一些努力。联系人是某个区域的功能管理员。但如果功能管理员正在度假怎么办？您可能需要不止一个人了解每个领域。如果支持问题最终需要解决怎么办？你只是做工作，还是将其纳入中心优先事项？

这些都不是很难解决的问题，而是管理工作。你所做的一切都会在专注力和响应能力之间进行权衡。

可靠性事件和事件回顾怎么样？

FAST 没有定义如何处理事件。您的随叫随到模式将在很大程度上决定事件的处理方式，并且可能会涉及任何知道如何解决问题的人来解决问题。

FAST 没有描述如何处理事件回顾。我建议执行如下操作：安排在下一次集体会议之前进行事件回顾。回顾的目的之一是确定一些可以完成的工作，以减少导致事件发生的可能性或严重性。另一个方法是从事件中了解一切。

在事件发生后立即召开的集体会议上，我将分享我们所学到的知识，并自动将下一个周期的优先事项定为完成回顾中确定的一些工作。

在 New Relic，我们没有使用 FAST，但我们有类似的政策。我们称之为“不要重复事件”(DRI)。这是我们为可靠性所做的最好的事情之一。规则是 DRI 工作自然比其他优先事项更重要。因此，事件总是会导致范围缩小，或者最后期限被推迟。

设计师如何在 FAST 中工作？

许多设计师面临的挑战是专注于与工程团队合作，或者先于工程团队完成工作。或者让他们双向操作。您会听到对这两种工作方式的强烈争论。

FAST 没有指定它应该如何工作，因此您需要自己决定。设计师是否会报名参加团队工作？或者他们是一个服务组织，在事情上提前工作，并在人们需要他们的东西时充当顾问？你需要做出决定。我可能会让设计师注册并成为团队的一部分，但这又是您在采用 FAST 时需要做出的决策类型的一个示例。

产品经理在FAST如何工作？

FAST 中的产品角色主要是确定优先级并传达优先级。关于除此之外的工作，FAST 手册中没有真正描述很多内容。

FAST 手册中的假设似乎是产品经理进行启发和沟通，然后工程师研究功能。

在可以的范围内，我会让工程师与客户交谈，让他们获得他们正在工作的产品领域的专业知识。理想情况下，他们会做这项工作，向客户演示，并从他们那里获得反馈。让产品经理推动这一点，并提高工程师有效地做到这一点的能力，可能是他们工作中很有价值的一部分。

这个模型有很大的灵活性。您可以进行典型的产品到工程的交接，或者您可以让他们与客户一起发现并解决问题。

正如您所看到的，FAST 存在很多差距。你需要解决剩下的问题。

FAST 材料充满了行话

您可能会发现 FAST 网站和手册令人困惑。您必须了解大量行话和烦人的术语才能获得快速敏捷的黄金。举个例子，下面是 FAST Agile 的可怕定义，它试图定义FAST 指南 2.12 版本中的实践：

“什么是流体缩放技术？流体扩展技术结合了开放空间技术和开放分配，创建了一种轻量级、易于理解和易于掌握的方法来组织人员围绕工作进行扩展。 FAST 是流体缩放技术的缩写。敏捷的流体扩展技术是快速敏捷。”

所以。坏的。而且这个很有代表性。你会看到很多关于集体、价值周期、开放技术、青色转换、Y 理论等的参考资料。这些都没有任何解释，而且即使解释了也没有什么帮助。他们面向的是敏捷理论家的小众受众，并关注归因而不是有用性。

结论

那么我们会怎样呢？ FAST 敏捷值得尝试吗？

我相信答案是肯定的，但要谨慎，并且要在正确的背景下进行。您可以在各个团队中使用它。如果您有领导支持，请在较大的组织中逐步进行试验。

如果您尝试过，请与我分享。如果您需要帮助在您的组织中推广它，请与我联系。我会直接帮助您，或者为您联系其他可以提供帮助的人。

谢谢

这篇文章的早期版本……非常糟糕。我要感谢Seth Falcon和Davy Stevenson的批评。他们都指出了这篇文章的一些主要问题，这些问题让我重新思考我的方法。他们提出了一些精彩的观点，我将这些观点纳入了他们自己的帖子部分。最终，我重写了大部分帖子，我对结果感到非常满意。谢谢你！ Seth 有一份关于工程领导力的时事通讯值得一读，而 Davy（像我一样）则提供创业建议和指导。

Jim Shore向我介绍了快速敏捷。他就自己的经验进行了一些精彩的演讲。我们见过几次面并讨论了 FAST 的含义和实施。 Jim 是《敏捷开发的艺术》一书的作者。

该图片由Kanenori在Pixabay上发布

脚注

1. 我相信 150 个人对于一个集体来说可能有点笨重。我怀疑 60 人是更好的最大人数。