Scrum团队

一个由生产者和支持者组成的团队，他们紧密合作，在守护者的护航下，追求一个共同的愿景并确保实现。

…你们有一个面向客户的产品愿景。你们已经开始记录客户感兴趣的想法，并着手将这些想法变为现实。你们不知道如何实现整个产品，也不知道这些想法是否正确，但你们知道随着学习的深入，一定会有新的想法出现。

✥ ✥ ✥

许多伟大的愿景是单打独斗难以实现的，要实现这样的愿景，你需要构建复杂的产品，将其推向市场并得到反馈。

有些产品仅靠单个个体的努力无法实现卓越，因为在没有反馈的真空环境中，很容易开发出低价值的产品。经验表明，团队比个人更出色：众人拾柴火焰高。

历史、经验和个人兴趣会使人更倾向于关注特定的领域（例如，从市场而不是从产品开发中挖掘需求），但过于专业化（例如，只想从事产品开发而不涉及其他开发任务，如文档编写或测试）可能导致专业知识匮乏，因为需求在每次交付过程中都有所不同。角色划分首先应基于这些角色主要活动的长期规律变化。例如，一组角色可能按照产品发布节奏处理市场事务，而另一组角色可能负责处理日常产品开发问题。

商业和开发的工作节奏由于正当原因而不同,让它们分开工作可以提高自主性,并让每个组织专注于最擅长的事情。好处是,这可以让商业自由地处理其他事情,同时开发团队准备产品交付。坏处是,如果商业下达开发产品的命令并将产品交付的责任转移到独立的开发组织,那么产品移交会出现问题。移交可能包括最后期限,但是由于商业和开发组织互相脱钩,最后期限可能与开发实际能交付的情况不符。开发组织唯一能做的就是加快生产节奏。

业务和开发的工作节奏不同是正常的，把它们区分开可以增加自主性，并让每个人专注于其擅长的领域。好的一面是，这使得业务在开发准备产品交付时有足够的自由去处理其他事务。糟糕的一面是，如果业务发出开发产品的指令并将产品交付的责任转移给一个独立的开发组织，就会出现交接问题。这个交接可能包含一个最后期限，但由于业务和开发组织相互脱钩，最后期限可能与开发实际交付情况不符。开发组织唯一能做的就是提高他们的生产率。

对产品整体关注是一个心态问题。作为开发产品某个小部件的流水线工人，要形成这种心态是很难的。脱离对产品整体视角的关注，会使工作显得毫无意义，并使人们失去对“愿景”的主人翁意识，或失去对产品意义的认同感。

一个团队应该是一个学习和改进的中心,团队结构应支持学习。解决一个复杂的问题意味着您在产品开发过程中会学习很多,并利用这些学习让解决方案逐渐呈现。商业和开发可以分别提出和采取与自己的世界观相关的反馈。从商业的角度来看,一个运行良好的解决方案可能无法产生最大价值。开发的角度也是如此。开发的疯狂节奏和构建产品的智力需求共同使我们的注意力只集中在当前的问题上。我们忙着开发产品,根本顾不上做得更好。开发和商业都忽略了过程这个更高层次的问题,这从Scrum的日本思想的角度来看非常令人担忧,他们建议我们“建立正确的过程,你就会开发出正确的产品”。

团队应该是学习和改进的中心，而团队的结构应该支持学习。复杂问题的解决意味着在开发过程中你会学到很多东西，并利用这些习得让解决方案逐渐显现。业务和开发都可以根据自己的视角搜集并运用过程中的这些反馈。从业务的视角来看，一个运行良好的解决方案可能并不会产生最大的价值。同样，从开发的视角来看也是如此。在疯狂的开发节奏和构建产品投入的大量精力的共同作用下，我们只关注眼前的问题。我们忙于开发产品，根本顾不上做得更好。无论是开发还是业务都没有关注更高层次的过程问题，这从scrum日本渊源的角度来看（译者注：1986年的《哈佛商业评论》文章"The New New Product Development Game"中竹内弘高（Hirotaka Takeuchi）和野中郁次郎（Ikujiro Nonaka）在产品开发的背景下引入了术语 scrum），是非常令人担忧的，它告诫我们“构建正确的过程，你就会构建正确的产品”。

快速反馈使学习及时且高效。 当具有不同专业知识和观点的人在开发过程中一起工作时，学习将更加有效。专注于产品开发活动的人们通常没有太多时间去思考如何改进。

因此：

组建一个拥有所有必要能力的团队：可以开发和交付产品的开发团队、指导产品方向的产品负责人和引导学习的ScrumMaster。

开发团队具备实现产品和将产品交付给最终用户所需的所有技能和知识。产品负责人是Scrum团队中的业务代表(将团队与客户联系在一起)。ScrumMaster具备辅导Scrum团队、帮助其不断优化开发过程、解决障碍的所有技能和知识。

多数情况下，产品负责人在其所在的大型企业实体内部创建小型的、自治的Scrum团队来实现他或她的愿景并产生价值。产品负责人将引领团队向着愿景前进。团队可以少量地增加开发人员并随着时间的推移而变大，但任何开发团队中，小团队开发人员的数量永远不要超过7人。

开发人员在开发团队中有自己的定位，可以自我管理以实现预测和承诺。产品负责人和开发人员共同招聘或任命ScrumMaster。ScrumMaster对流程负责并支持团队持续改进。

Scrum团队不仅仅是将产品负责人包含在团队中。 Scrum团队是一家小型企业，可以在组织的环境中工作，并做出独立的决策来响应客户。 使用Scrum时，这种结构上的变化对产品的开发具有重大影响。

✥ ✥ ✥

Scrum团队为产品负责人的愿景提供了组织结构的基础。 每个Scrum团队都像一个小型企业一样运作，它是一个自治团队。 每个团队都围绕着共同的价值观而团结在一起，并且表达出一致的“行为准则”。

一个小型的交互式Scrum团队能够在产品开发（以定期产品增量的形式进行交付）过程中获得产品待办事项的反馈。开发团队花了大量时间与产品负责人建立起了牢固的工作关系，所以开发团队能够很好地理解产品方向。 产品负责人也会对产品的实现有更深入的了解，这会让开发团队和产品负责人做出共同的决定。可能会增加产品的ROI或其他价值。

Scrum团队创建了一个支持团队围绕产品方向和目标达成一致的结构。团队定期沟通以处理日常工作，例如定期评审和规划，以及其他关键活动，例如[Sprint计划](Sprint Planning.pdf)。团队有自己的目标，如果没有与产品方向的明确链接，团队的目标可能会变得支离破碎。每个功能小组都有各自独立的目的：Scrum团队中没有这样的小组。产品开发的氛围也可以通过Scrum团队来建立。无论产品需要高度安全、快速交付还是极具弹性，Scrum团队都可以通过与产品市场的联系迅速确定。 开发团队与产品负责人之间的紧密联系营造了一个有利于向着正确方向发展的氛围。多个Scrum团队会根据需要进行非正式合作，并通过MetaScrum进行更正式的协调。

真正的团队几乎总是同署办公团队。 根据"小团队"模式来调整团队规模，以确保它始终是一个跨职能团队，随时间的推移，根据"稳定团队"模式管理开发团队的成员。 这为团队创造了成为自治、自组织以及与产品保持对齐的机会。

开发团队在同一个产品开发过程中，工作于同一节奏（组织级Sprint脉搏）。 他们可以根据需要自由地相互协调，每一天都有机会在Scrum of Scrums中进行正式的协调，也可以在每个Sprint中的Sprint评审或者Sprint回顾进行一次正式协调。 伟大的团队在流程改进和产品化之间以特定的节奏（改善脉搏）不断交替。

紧急（涌现）情况下，团队可以采取特别行动打破节奏。 请参阅紧急程序。

对于外包或其他联合开发项目，请考虑使用发展伙伴关系模式为Scrum团队配备人员，尤其需要注意的是，产品负责人要时刻保持对业务驱动因素的关注。

虽然多个人一起工作所产生的收益超过了他们独立完成工作的总和，但小组的设置会导致协调和沟通的浪费，其代价称为“过程损失”。 可以通过小团队模式来弥补这一过程损失。

Scrum团队的概念是杰夫·萨瑟兰从丰田生产系统工作单元的组织形式演变而来的，它通常由工人和总工程师组成。 杰夫将总工程师的角色一分为二，产品负责人聚焦在业务上，ScrumMaster聚焦在流程上。

Picture credits: Dirk Hansen, https://www.flickr.com/photos/dirkhansen/3235465927/ (license: CC BY 2.0).

原文链接：http://scrumbook.org/product-organization-pattern-language/scrum-team.html