- Agility66
- 2026-01-21
- 来源：
第二册【Scrum 模式语言9】基于集合的设计（ Set-Based Design）
译者导读：
在敏捷开发实践中，“基于集合的设计”代表了一种重要的开发范式转变--从过早锁定单一方案转向并行探索多种可能。本译文深入解析了这一源自丰田的创新方法，它通过有意识地保持设计选项的开放性，为团队在复杂问题面前提供了更灵活的策略。这种方法与Scrum所强调的“持续改进”的思维高度契合，它教会我们“延迟决策”的智慧--不是回避选择，而是通过系统化的探索让最终决策更加稳健，让产品为客户带来更大的价值。
作为一名年轻的丰田工程师，你津津有味地解决问题。你仔细地辨别问题的成因，小心地进行“五个为什么（five-why）”的分析。然后你冥思苦想，想出了一个绝妙的解决方案。你丰富了方案的细节，兴冲冲地去和你的导师分享。他非但没有评价这个想法的优点并祝贺你，反而问:“你考虑过其他选项吗？此方案与其他备选方案相比如何？”当你确信自己有了最佳方案时，（实际上）已处于停滞不前的境地。(摘自《丰田之道:来自世界最伟大制造商的14条管理原则》[Lik04]，第263页。)
...一个¶7 Scrum团队已成为一个信任共同体(参见¶95信任的共同体，第466页)。团队正基于持续精细化的¶54 产品待办列表开展工作。靠近列表顶部的是已准备就绪(参见¶65 准备就绪的定义)进入¶75 产品集的一些¶55 产品待办事项 (PBIs)，靠近列表底部的则是远超当前关注的事项。在这两者之间，我们可以找到一些可能是¶85 定期产品增量的候选待办事项。其中可能是产品待办列表中其他PBI的替代选项。有时候，Scrum团队可能会为已经罗列在产品待办列表上的PBI准备替代事项。尽管其他PBI也已准备就绪(参见准备就绪的定义)，并且团队对要构建什么很有信心，但仍在探索“如何”构建这些PBI，并对每个PBI都准备了一些想法。
一个复杂的问题可能有许多的解决方案。通常（开发团队）不可能提前预测到哪一个是最好的。
在当下，若选定了某个选项并积极地开发会在后续增加额外的工作，（特别是）当新的信息出现并迫使团队重新考虑他们最初的决定时。在一个拥有大量子系统和众多（开发）团队的大系统中，这种返工会导致停工从而使得（项目）延迟，而此时Scrum团队（不得不）慎重考虑新的决策并评估其对系统其他部分的影响后果。
我们（Scrum团队）既重视拥抱变化，也重视消除浪费性返工。从后往前看，我们可以轻易明白在哪儿陷入了分析瘫痪，或者最初如何在错误的方向上一意孤行的。（真正的）挑战在于找到一条平衡的解决之道。
请参考下列图表，它来自UI和UX设计之父Jakob Nielsen一篇关于迭代用户界面设计经典文章(IEEE Computer 26 [Nie93]):
界面质量是一个设计迭代次数的函数:对于每一次额外的迭代，可用性的数值通常会随着每一次额外的迭代而上升，直到设计达到一个稳定水平点。IEEE计算机 26 [Nie93]
在这篇文章中，Nielsen为使用迭代来提高产品质量提供了一个强有力的案例，他说 ， “我们真的不知道是什么导致了创造性的洞见，这对于一个全新的、更好的界面设计是必要的”。因此，我们可以说（单是）迭代对于创新来说是不够的。客户对定期产品增量的反馈会改进产品，但不会从根本上重新定义产品。开发组织需要一个替代解决方案来指导他们将关键性的新业务特性从现有方案中区隔开来。
因此：并行开发多个选项，仅需解决未来的那些关键性约束。
为了实现这一目标，在每个开发阶段（我们）都要并行开发一组选定的设计备选方案（即备选方案集合）。负责该功产品特性的开发人员需持续地更新集合内每个备选方案的当前估算。当所有的备选方案都推进到（估算的）一半时，召开一次会议来交换意见，评估哪些方案应被淘汰，同时对已发现的新方案进行讨论。若有一个明显胜出的方案，则并行开发停止，（正式的）计划将录入这个胜出的方案。如果没有，团队（总是从¶11产品负责人那里获得输入）将为自己预留额外的工作增量，以获得额外的理解。随着时间的推移，选项不断减少的过程如下图所示：
有意的收敛和发散阶段 《海军工程师杂志》121 [SDB09]。
通过连续迭代团队成员对每个选项进行开发，他们也逐渐增加了开发成果的精准度(海军工程师杂志121 [SDB09])。最初的工作增量可能只是一个手绘草图，第二个可能是一个丢弃的原型，而最终的增量将是一个初始的真实实现。因此，每次产品负责人和¶14 开发团队成员在决定删除一些选项时，他们（事实上）也丰富了剩余选项的细节。
单一选项将通过改变多个参数（例如，算法选择，数据结构，界面布局）来探索不同的设计方案。在多个选项中开发团队应特别留意变量参数的个数。随着团队对如何运行基于集合的设计的理解不断加深，他们可以增加变量参数的个数。仔细考虑选项之间的重叠程度。独立的选项将覆盖更多的设计空间，但固定一个参数将增加结果的稳健性。如果做得好，团队可以通过减少实验数量来最大限度地缩短交付时间。这里的要点是，你可以（主动）设计自己的学习路径，而不是被动接受一个接一个的意外。
选项的数量会随着每次迭代而增加，而探索选项的组数（集合数）则会减少。
根据基于集合的设计实践的范围和程度，其结果既可以直接反馈到¶46 Sprint中，也可以在团队构建¶64 精细化的产品待办列表时，以（更深刻的）洞见来影响相应的决策。
由于有太多的解决方案可供选择，互赖性的团队无法锁定他们的系统设计。然而，这并不意味着开发工作必须等待（最终的）决定。在关键性约束内，团队可以开始设计子系统，同时记住它必须融入更大系统的整体解决方案空间。事实上，团队可能会将一些参数设定保留在开放状态直到生产阶段，而不会在设计阶段去固定。在某些情况下，甚至可以将备选方案作为选项（直接）提供给客户。
随着时间的推移，互赖性的组件逐渐汇集（“第二个丰田悖论：延迟决策如何使更好的汽车更快”，斯隆管理评论36 [WLCS95]，第43页）。
关键在于何时开始向最终的解决方案汇集。Ford和Sobek运用实物期权模型模拟了丰田的开发过程，并对一个为期900天的项目进行了100次模拟（“通过模拟第二个丰田悖论将实物期权应用于新产品开发”，发表于IEEE工程管理汇刊52 [FS05]）。
基于点的开发和基于集合的开发项目的预期质量(IEEE工程管理汇刊52 [FS05])。 
集合式开发相对于点式开发的灵活性期望值（IEEE Transactions on Engineering Management 52 [FS05]）。
这些研究表明，汇集的最佳时间接近整个项目跨度的中间。但作者警告说，如果在项目早期出现延迟，那么将汇集时间推迟一点可能是明智的。因此，产品负责人必须能够看到发散性工作的整体进展。
丰田更喜欢让同一团队开发所有的选项。这样，团队对问题空间更有感觉，以指导新选项的构建。他们可以通过同时而不是顺序地开发几个选项来加速这一进程。在构建选项时团队对选项的快速比较创造了开发者个人直觉所需的共享经验。同样值得指出的是，基于集合的设计帮助人们保持那些在产品中长期未使用的能力。它们会在企业留存，并对未来的产品贡献价值。
谷歌的“设计Sprint”是一种快速评估许多设计理念的方法。作者声称，它“为团队提供了一条无需构建和启动的学习捷径”。这个过程首先需要明确问题并识别焦点领域，最后与客户一起测试高保真的原型。整个过程需一周或更短的时间。5
最后，在这些关键时刻，当流程消除了某些团队全情开发的选项时，我们必须考虑人的因素：别人对你工作的评判可能会对你造成伤害，团队成员可能会将这种（评价性）决定视为对其个人的轻视。这种挫折感催生了某种“成人仪式”的必要性。《庆祝失败》（Celebrating Failure）一书的作者Robert Heath建议，领导者应该“用积极的评论来接纳失败。为每个人的努力喝彩，并提醒他们从经历中汲取智慧和力量。从这个角度来看，失败可以像胜利一样激励团队”（庆祝失败：冒险、犯错和大胆思考的力量[Hea09]）。
然而，如果这些即时评论未能融入一个更大的持续学习文化，它们将毫无意义。谷歌的“零责尸检”文化就是这样一个例子。它借鉴了医疗保健和航空电子领域的经验，在这些领域，失败可能是致命的。在这些工作场所，失败后的重点不涉及个人而是更大的系统，并揭示人们获取部分或错误信息的潜在原因，恰是这些信息导致了不良意外结果。Lunney和Lueder在《站点可靠性工程：谷歌如何运行生产系统[LL16]》中写道：“你无法修复人，但你可以修复系统和流程，以便在设计和维护复杂系统时更好地支持人们做出正确的选择。”团队必须完全拥有集体改进的想法，这样的模式才能成功。
¶12 产品负责人团队可以应用此方法来评估产品待办列表中应保留哪些备选待办事项(PBI)，或用于探索高风险/高不确定性的PBI，或整个定期产品增量的备选方案。这样的设计探索可能要跨越多个Sprint边界。
5. Jake Knapp（谷歌Ventures）等人，“设计Sprint”。http://www.gv.com/sprint/, n.d，无永久链接，2017年11月2日访问。
另外，开发团队也可以在Sprint内采用这种方法来评估跨多个实现替代方案的风险，并可以使用由此产生的深刻洞见来选择一个替代方案。当在Sprint中进行基于集合的设计时，开发团队应该为探索设定时间。因为这个过程产生了大量的紧急需求（这就是他们这样做的原因），所以很难评估团队在时间盒内能完成多少工作。因此，当使用这种方法时，团队必须接受这样一个事实，即探索可能不会产生潜在的、可交付的定期产品增量，但是花时间获得洞察是值得的。
无论基于集合的设计的（最终）结果是否进入市场，团队都会从这些功能特性在产品中的存在（或不存在）获得信心，从而提升¶38 产品自豪感。
译者：杨光
校对：汉斯
点击回顾第一册 Scrum模式语言合集
Tips：以上带符号黑体是模式语言。
