你对产品怀有清晰的 ¶39 愿景，并已开始记录那些客户必将喜爱的创意，此刻正需将这些想法落地实现。你尚不知如何构建产品或验证这些想法的正确性，但你深知，随着了解的深入，新的创意会不断涌现。

许多伟大的愿景，仅凭个人力量难以实现。若要实现此等宏图，你需构建出复杂的产品，将其推向市场，并善用市场反馈。

有些产品，仅凭一己之力注定无法成就伟大；在缺乏反馈的环境里，太容易做出价值低廉的产品。经验表明，在人均效率上，团队表现优于个人：众人拾柴火焰高。

个人的经验、历史路径和内在倾向会使其聚焦于特定领域（比如，专注于从市场获取需求，而非产品实现）。但过度专业化（比如，只想做实现工作，却不愿处理文档或测试等开发任务）容易造成技能短板，因为不同交付任务所需的技术能力是动态变化的。角色的划分，应首要基于其核心活动的固有节奏差异而定。例如，某些角色按发布周期与市场互动，而另一些角色则需应对日常的生产问题。

业务与开发团队的工作节奏原本就存在差异，让两者独立工作，能增强自主性，并使其专注于各自所长。这样做的好处在于，业务团队得以腾出精力处理其他事务，而开发团队则可以专心打磨产品直至交付。然而，如果业务团队仅下达开发指令，便将产品交付的责任完全转移给独立的开发部门，弊端由此产生。这种交接往往伴随着一个截止日期，由于业务与开发团队是脱节的，相对于开发的实际能力而言，这个截止日期可能是武断的，最终导致开发团队只能疲于奔命地赶工。

关注产品的整体性，本质上是一种“心智模式”。对于像流水线工人那样，只负责生产某个小部件的成员而言，这种“心智模式”是极难培养的。与产品整体目标的疏离，会让工作显得缺乏意义，让人既无法对愿景产生主人翁意识，也难以认同产品存在的深层价值。

团队应成为学习和改进的场所，其结构也应支持持续学习。解决复杂问题本身就是一个深入学习的过程，你需要运用所学让解决方案逐渐成型。业务和开发团队可以分别收集并响应符合各自视角的反馈。但一个在业务看来很完美的方案，未必能创造¶93 最大价值；开发单方面的视角也同样存在局限。紧张的开发进度和复杂的产品构建需求，迫使我们将精力聚焦于解决手头的问题。我们疲于完成产品，反而抽不出精力去思考如何优化工作方式。无论是开发还是业务，都无暇顾及更高层次的流程改进问题，这非常令人担忧。因为Scrum源于日本的管理哲学，其核心智慧在于： “完善流程，产品自成。”

快速反馈能使学习变得及时高效。若能在开发过程中让具备不同专长和视角的人协同工作，学习成效会更为显著。专注于具体开发工作的人，往往无暇抽身思考如何优化与改进。

因此：

组建一个能力完整的团队，其成员应包括：能够实现并交付产品的产品组织模式语言，负责把握产品方向的 ¶11 产品负责人，以及致力于推动团队学习与改进的 ¶19 Scrum Master。

通常 ，产品负责人会组建Scrum团队来实现其愿景并创造价值。在多数情况下，产品负责人是在企业内部创建一个小型的、高度自治的Scrum团队。产品负责人将引领团队朝着愿景前进。团队可以小幅增员并随时间发展，但其规模应始终控制在 ¶9 小型团队的范畴内，即任何开发团队都不得超过约七名开发者。

开发人员构成开发团队，形成一种身份共识：团队为实现共同制定的 预测与承诺 而实行自我管理。产品负责人与开发团队并肩协作，共同选用 Scrum Master；此后，Scrum Master将主导流程运作，并持续支持团队的改进之旅。

Scrum团队并非只是一个将产品负责人囊括在内的空壳。它是一个能够在组织语境下运作，并为响应客户而作出独立决策的小型业务单元。当使用Scrum时，这种结构上的转变对产品开发具有深远影响。

Scrum团队为产品负责人的愿景提供了一个组织化的家园。每个Scrum团队都是 ¶16 自主团队，像小型企业一样运作。团队围绕共同的价值观凝聚在一起，并且意识到 ，甚至可能阐述其自身的 ¶31 行为规范。

一个小型的且频繁互动的Scrum团队能够创造反馈机会，使来自产品开发（作为¶85定期产品增量）的反馈融入¶54产品待办列表。由于开发团队与产品负责人投入大量时间共事——从而建立起牢固的工作关系——开发团队能够深入理解产品方向。产品负责人也将对产品实现获得更深刻的理解，这将促成二者作出其他可能提升投资回报率或其他价值的共同决策。

Scrum团队创建了一种结构，用以支持团队围绕产品方向和目标保持对齐。团队通过定期会面，处理周期性的评审与规划这类 ¶23 固定工作，并参与 ¶24 Sprint规划 等核心事件。团队有其目标，但若缺乏通过Scrum团队与产品方向建立的明确链接，此目标便可能碎片化。在Scrum团队中，不存在各自为政的职能子团体。同时，Scrum团队也奠定了产品开发的基调。产品所需的任何需求（如高安全性、快速交付或极致稳健），Scrum团队都能凭借其与市场的连接迅速确立。开发团队与产品负责人的紧密协作，营造出确保开发不偏离正轨的氛围。多个Scrum团队之间既可非正式对齐，也可通过 ¶37 元Scrum 进行更高层级的正式协调。

真正的团队几乎总是 ¶8 同地协作团队。团队规模应遵循小型团队 和  ¶15 稳定团队 原则 ，确保其是一个 ¶10 跨职能团队，并自行管理开发团队的成员构成。这为团队创造了机会，使其能变得自主且自组织，并与产品目标保持对齐。

从事同一产品开发的各团队应遵循相同的节奏（¶47 组织级Sprint节奏）。团队根据需要自由地进行协调，每日可通过 ¶34 Scrum of Scrums 进行正式协调，同时在每个 ¶46 Sprint 的 ¶35 Sprint评审会议 和 ¶36 Sprint回顾 中也会进行协调。卓越的团队遵循一种 ¶26 改善节奏，即在流程优化与产品交付之间循环切换其工作重心。

若遇紧急情况，团队可采取例外措施，中断既定工作节奏；相关规范请参阅 ¶32 紧急程序

对于外包或其他联合开发项目，应考虑使用 ¶13 开发伙伴关系 来配置Scrum团队角色，其中产品负责人必须紧扣核心业务驱动力。

尽管多人协作能够创造出超越个体工作成果总和的效能，但也不可避免地带来协调与沟通的额外开销，即"流程损耗"。采用 小型团队 的目的在于降低这一损耗。

Scrum团队的概念是由Jeff Sutherland基于丰田生产系统的工作单元（含工人与总工程师）演化而来，其关键创新是将总工程师角色拆分为专注业务的产品负责人与专注流程的Scrum Master。

——译者：Leo Yan

校对：Emma Ye