在第一部分中，我们研究了令人震惊的症状以及在“机械”混乱中“对待”产品所有者的可能方法。 我们将继续进行角色分析，接下来是团队。
但是，他们知道团队必须具有自组织性和跨职能性的口号，这似乎是Scrum最简单的部分：我们聘请具备必要能力的人员，然后告诉他们：“您是团队”，然后飞起来！ 但实际上，一切都有些复杂。
自组织
症状 ：团队内部存在明确的等级（指令提交），或者团队内部更糟。 即 实际上，产品开发人员可能会执行与团队活动没有直接关系的任务。 或者，在团队内部，人们不是自由选择一项工作以实现冲刺目标，而是从“领导者”那里接受任务。
不好的是 ：
任何边界-CEP限制
当一个人被工作描述，提交的等级等挤压时，这会阻止他被揭露。 Scrum团队的力量在于为人们提供机会。 有一项任务，要勇于承担并对其执行负责。 一个人必须自己决定他将如何实现冲刺目标。 如果他们告诉他该怎么做，那么这不是自组织，也不是混乱。
如何对待 ：对于团队中的人员，所有工作描述和层次结构都被取消，结构趋于平坦。 团队中的
所有人都是
产品的
开发人员 （
Scrum指南不允许其他角色 ）。 只有情势领导，人们才能决定工作的舒适程度以提高效率。 当然，公司中有游戏的一般规则，团队不会以任何方式违反规则（
尽管这可能会影响公司级别的变更 ），但它负责所有内部事务。 如果在解除对开发人员的限制方面存在严重障碍，那么值得将问题升级到那些决定实施Scrum和敏捷转换的人。 您可以尝试运行平坦的结构，例如针对多个冲刺的实验，然后进行广泛的回顾，所有感兴趣的各方都在其中讨论实验结果。
症状 ：除团队合作外，人员还必须在公司中执行其他职能职责。 例如：50％的时间执行团队的任务，50％的时间执行部门的任务（开发，测试等）。
糟透了 ：scrum中的价值之一就是专注。 团队专注于冲刺目标并朝着它前进。 如果除了在团队中工作之外，一个人还必须做其他事情，那么重点就会丢失。 结果，结果将更糟。 在这种情况下很难保持团队合作精神。
如何对待 ：我们需要确保团队中的成员只在该团队中工作。 为此，有必要从外部了解团队开发人员的工作性质，并找到在不中断工作的情况下进行工作的方法。 当然，这项工作对公司来说是必要的，因此，根据工作的具体情况，您可以：
- 要么将工作放入团队的积压工作中，然后将根据单个工作流程完成。
- 或将其转移给团队以外的其他员工。 例如：并非所有公司都在Scrum上工作，而您需要在特定时间做一些常规工作，那么这样的工作就不再适合于Scrum员工。
- 或可以创建一个特殊的团队并选择一种产品来收集所有此类工作。
- 或者，如果由于缺乏专家，这是一个人由几个团队完成的一项独特功能。 然后值得将这个人从所有团队中剔除出来，并为他建立另一个不会破坏Scrum其余部分的流程（ 例如，优先任务队列 ），直到找到这些Scrum团队的专家为止。
交叉功能
症状 ：团队中的人只做某一项工作，有明确的专业知识。 更糟的是，它仍然被官方职责，法规和其他官僚机构所涵盖。 团队一名成员的缺席（休假，病假等）会降低团队的功能。 嗨， 巴士系数 。
不好的是 ：如果一个团队依赖于其成员之一的能力，那就是一个不稳定的团队。 与她建立联系非常困难，因为 您需要了解其当前功能，并记住与此容错级别相关的风险。 开发人员的专业化程度狭窄，极大地增加了团队的组织工作：在计划时，您需要考虑很多事情，谁将做什么； 并非每个任务都需要预定比例的团队能力，因此很难实现平衡的冲刺。 在这种方案中，必然会出现“瓶颈”，从而降低了团队的整体速度。
做什么 ：有必要促进和支持T型技能。 为了保持团队的灵活性，重要的是特定功能或知识不能集中在一个人身上。 有必要刺激和鼓励持续发展。 确保团队不断改进，寻找改进流程的方法很重要。 作为T形开发方案：举办内部研讨会，团队成员彼此分享知识； 每个团队成员在每次冲刺中都采用非核心任务执行规则； 配对完成任务等 您可以通过“关闭”成员一段时间来人为地刺激团队：假期，研讨会，培训，商务旅行等。
症状 ：在价值链中，团队只负责其中的一小部分（影响），结果，团队无法自行发行增量。
糟糕的是 ：如果团队对增量交付（ 产品发布 ）的影响很小，那么scrum也会失去其本质：发布发生延迟，反馈发生延迟。 通常，没有节奏，因此没有速度。 没有速度-没有灵活性。 这样的团队并没有感觉到它的所有权，它只是大型汽车中的功能螺钉。 团队的功能应该足以关闭大部分价值链，否则团队将不会仅仅传递价值，而只会将一种“工件”加工成另一种“工件”并进一步转移。
我们通过网络上的示例对此进行了说明。 在简化的地方，创建新功能包括以下步骤：
对于这些工作，需要各种能力。 未能成功划分团队的一个例子：将
团队A与UI / UX，设计师和前端开发分开，他们以SPA的形式准备自己的增量； 但是它们取决于后端何时准备API以使新功能正常工作； 等待质量检查人员全面检查所有内容并编写测试； 然后他们仍然希望DevOps能够将其全部投入战斗。 这样的
团队A很难负责价值的释放和交付，只是削减了“空白”-SPA。
如何看待 ：我们确定团队缺乏哪些能力来实现增长。 我们通过培训现有团队成员或向团队中添加新球员来赋予团队这些能力。 因为 寻找/教人不是最容易和最快的任务，然后您可以与相邻的团队/部门建立联系，向他们解释Scrum的价值，并就特殊规则/互动规则与他们达成一致，在这种特殊规则/交互规则下，他们不会破坏对您团队的混乱。 值得强调的是扩展团队功能的过程：在进行第一次回顾并确定缺失的能力之后，您可以打印它们并将其放置在团队面前。 当团队应对能力不足的问题（
学习到的；团队的新成员；与另一支团队建立有效的沟通等 ）时，我们将解决方案置于先前缺乏的能力之上。 随着时间的流逝，团队应努力扩展其功能以完全覆盖价值链。
团队和产品
症状 ：有一个团队，但没有产品。 没有订单，没有积压。 人们只是在执行来自不同方向的任务。
比坏 ：这不是混乱。 如果没有将产品分配给团队，则该团队不太可能“消耗”工作。 当有一个全球目标（ 产品开发的愿景/战略/路线图 ）时，您想要实现它。 您可以进行工作，获取反馈，进行反思并采取下一步措施。 没有主人翁意识，您将冒着被套牢的风险：您实际上并不需要反馈，团队只是将TK处理为功能的工具。
如何看待 ：团队应该拥有自己的积压产品和PO，这可以点燃产品团队并将其随身携带-这就是本质。 需要了解为什么需要scrum？ 了解团队来自哪里？ 知道在此流中是否有“产品”？ 从“客户”团队中选择一个，并使其成为产品的所有者 ，从而使其拥有唯一的积压回答权。 可能有必要将团队划分为与一个PO（ 可以是“先导” Scrum团队 ）和第二个团队一起工作的Scrum团队，同时与其余“客户”一起工作。 为新的Scrum团队中的流程和结果提供最大的透明度，您可以为进一步在组织中分布Scrum和敏捷奠定基础。
症状 ：团队对产品组件没有任何影响：它没有决定“如何做”，团队只是说“做什么？”。 将传统知识作为输入，团队被视为职能部门。
比坏 ：如果公司真正宣扬敏捷和敏捷的价值，那么这是一个非常危险的选择。 通常，这意味着所有员工都是出色的专业人员，可以解决任何不怕做出决定并承担责任的问题。 但是，如果不允许他们做出产品决定，那么团队的所有创作自由通常会从产品传播到技术。 由于不允许团队决定如何使用户的生活更轻松，因此世界变得更好，产品更有用。 然后团队开始开发代码库，尝试新技术/工具/框架等。 PO与团队之间存在利益冲突，团队开始以新堆栈的形式出售“重构”，“优化”，“银色子弹”等。 这主要受用户和产品的影响。 在从指令管理模型过渡到敏捷的过程中，存在陷入将团队理解为职能部门的危险（ 团队之前尚未做出决定 ）。 我们要么扼杀了团队的主动性，要么是团队对技术比产品更感兴趣，这让我们充满了困惑。
如何对待 ：您需要确定团队不信任或犹豫不决的原因：为什么团队不寻求解决方案，而只需要执行详细的技术任务？ 找到原因后，就可以逐步消除它。 例如：
- 团队缺乏能力或经验。 ：有人正在研究解决方案并编写TK，您可以将这个人添加到团队中，或者让他与团队一起完成某些任务，从而将他的部分技能和经验转让给团队。 因此，团队将逐渐学习并习惯于解决产品问题。
- 管理层担心团队会犯错。 ：这是向敏捷过渡的基石恐惧，但是如果不克服它，您将无法获得Scrum团队的全部实力。 团队注定会犯错，因为每个人都犯错了。 但是错误是经验和技巧的来源。 当一个团队犯了一个错误，因为它是这样决定的，而不是因为一个不正确的外部传统知识，它会更有用。 Scrum是有节奏的：迅速做出决定以检验假设。 收到反馈 意识到他们走错了路； 做出决定。 错误的成本得到了大大降低（ 花费了sprint，而不是一个季度/年/您的发布期 ），这使您可以避免对错误的担心。
症状 ：团队成员无法免费访问团队工件。 例如，并非所有人都看到冲刺或普遍积压，或者更新其状态存在困难。
不好的地方 ：Scrum是基于透明度的，工件可以帮助提高透明度。 如果团队成员在使用这些工件时遇到困难，那么团队成员本身在团队工作中就不会透明，对于其他感兴趣的人，情况将更加糟糕：不清楚谁在做什么以及为什么做。 目前尚不清楚团队在实现目标的过程中所处的位置。
如何处理 ：有必要确定团队中Scrum工件的格式并将其制作（ 您可以专门进行这次回顾 ），然后将其放置，以使团队可以轻松地与他们合作。 如果您可以为团队创建一个单独的空间，这很好，那么团队可以同时（肩并肩）工作。 这将减少通信开销。 在公共空间中，可以轻松地可视化所有内容（ 活动挂图，贴纸，标记是敏捷开发人员最喜欢的工具 ），主要是要方便，而不会对团队造成压力。 工件应有所帮助，而不应干扰团队的工作，不使其官僚化。 言语互动有利于团队合作。 如果团队的本地工作安排有困难（ 例如，分布式或远程 ），则需要最大程度地发挥团队合作和团结的作用。 例如，视频状态的通道，可直接查看团队每个成员的交互式Scrum面板等。
结论
在下一部分中，我们将继续考虑Scrum的角色，最后接触Scrum管理员。 简要提醒您如何处理症状：
- 选择适合您情况的症状。
- 在这些中，选择最敏锐的。
- 意识到这种痛苦。
- 您提出了一个团队解决方案（ 您可以将本文中的案例作为起点 ）。
- 执行您的决定。
- 转到步骤1。
感谢您的阅读，我想在评论中看到您所知道的“症状”。
感谢Sai Kin的插图。
关于Scrum向导的下一部分