在软件开发中解释Scrum角色的原理简单明了
scrum是一种敏捷软件开发方法，现在被许多公司和企业作为数字转型计划的一部分采用。
关于scrum
scrum方法的作用是为敏捷软件开发提供一个框架，使团队能够协作高效地交付高质量的软件产品。
它是一个团队共同开发复杂产品的框架。与在长时间的规划、设计、开发和测试阶段之后发布产品不同，scrum旨在从一开始就以小增量的方式交付可用的产品。
scrum的主要原则是团队之间透明的沟通、定期的质量验证和适应变化的能力。如果以正确的方式采用和使用，团队可以及时高效地交付高质量的软件产品。
scrum的主要优势
- 您可以提高生产力。作为一个scrum团队，团队将复杂问题拆分成小部分。然后这些小部分在冲刺中作为冲刺增量交付。团队成员可以在冲刺中专注于特定任务（冲刺定义了增量开发的时间周期，例如两周）。
- scrum鼓励整个团队之间进行定期沟通。这样可以确保每个人对范围和期望都很清楚。这减少了可能发生的很多误解。特别是如果您希望从一个冲刺到另一个冲刺的速度较高，整个团队必须从日常工作中朝着同一个目标努力。
- scrum设计为灵活，所以团队可以适应变化的需求和优先级。这使得团队可以快速响应项目范围或客户需求的变化。您可以在冲刺之间只更改内容，而不必等到整个开发生命周期结束。
- scrum强调测试和质量保证的重要性，最好是以自动化的方式。最终目标是提高最终产品的质量。这减少了缺陷的风险，并确保产品符合客户的要求。
- scrum设计为以客户为中心，这意味着客户从开始到结束都参与开发过程，通常以产品负责人的角色或与产品负责人有直接联系的方式参与（稍后详细介绍）。这确保最终产品符合客户的需求和正确的优先级。
接下来，我们将讨论scrum方法的作用。
scrum方法的作用
scrum方法的目标是为敏捷软件开发提供一个框架，使团队能够协作。您组建一个每天、定期聚会并在每个冲刺中重复的团队。通常，以下聚会是scrum团队基本设置的一部分：
- 每日站立会议 – 所有团队成员在此时间和地点会面并讨论上一天完成的工作、下一天的工作以及当前的障碍（如果有）。
- 故事细化 – 在这里讨论和最终确定新内容（用于下一个迭代周期）。
- 迭代规划 – 在这个仪式上，团队估计已编制好的内容（在故事中定义），然后根据优先级和工作量估计从中选择特定的子集进行承诺。
- 迭代回顾 – 在这里，团队与利益相关者会面，并向他们展示团队在上一个迭代周期中所取得的成果。
- 迭代反思 – 这是一个专门为团队讨论的对话，旨在讨论如何改进或团队认为必须在未来改变的事项。
scrum方法的重要性在于它能够帮助团队更有效地工作。 scrum方法的核心原则基于《敏捷宣言》，具体如下。
经验性过程控制
scrum基于通过持续检查和调整的经验性过程来实现进展的理念。这意味着团队应定期检查他们的工作并调整他们的过程以提高他们的表现。
自组织团队
scrum团队是自组织的，这意味着他们负责管理他们的工作并做出关于实现目标的决策。这有助于促进团队内的协作和责任。
时间盒子的迭代
你可以将scrum项目分为称为迭代周期的时间盒子，通常持续一到四个星期。这确保团队朝着一个特定的目标努力并定期取得进展。
优先级产品待办事项
产品待办事项是一个按优先顺序排列的功能和需求列表，团队将在项目中进行工作。产品负责人负责维护产品待办事项，并确保它反映了客户的需求和优先级。
持续改进
scrum强调持续改进的重要性。无论是在开发的产品还是开发产品的过程方面。这意味着团队应定期反思他们的工作，并寻找提高表现的方法。
挑战
虽然scrum方法在软件开发中非常有效，但在实施时团队也可能面临一些挑战。
对变革的抵制
scrum需要进行重大的思维和文化转变，这对一些团队成员来说可能很困难。有些团队成员可能对改变持抵触态度，这会使scrum的有效实施变得具有挑战性。换句话说，你需要“理解它”。在你没有理解之前，你不算在内。
经验不足
你需要一定水平的经验和专业知识来有效实施。如果团队成员不熟悉scrum或敏捷方法论，那么这将成为一项需要克服的挑战。
缺乏承诺
scrum需要所有团队成员的高度承诺，包括产品负责人、scrum主管和开发团队。如果团队成员对这个过程没有完全承诺，那么要实现预期结果就会很困难。
沟通不畅
scrum在团队成员之间的沟通和协作上非常依赖。如果团队成员不经常有效地进行沟通，那么这对他们来说可能是一项挑战。
过于强调流程
尽管scrum提供了敏捷软件开发的框架，但重要的是要记住它只是一个框架。如果团队成员过于专注于按照流程进行，他们可能会忽视交付高质量软件产品的最终目标。
scrum团队的角色
每个scrum团队为了有效运作，应该包括一些具体的角色。如果这些角色没有全身心地投入团队或者数量不正确，那么这样的scrum团队的成功建立可能会面临危险。
#1. 开发团队
这是团队的执行部分，从产品交付的角度来看，可能是团队中最重要的部分。一个典型的scrum开发团队由4-10人的开发/测试/架构/分析专家组成。如果人数不足，那么是否仍然可以称之为团队是值得怀疑的。如果人数过多，所有的仪式和团队讨论的管理将变得过于复杂，而且并不值得维护。
开发团队接受来自待办事项的故事，估计它们，并在sprint内部实施它们。团队负责故事的开发和测试，一旦完成，还负责部署到生产环境中。
#2. scrum主管
scrum主管充当开发团队的协调者。他安排定期会议，确保开发团队在内容上清楚，并组织sprint期间的活动，以实现sprint计划和目标。
这并不是一个真正的内容角色。事实上，scrum master不需要从故事内容中技术上理解任何东西（尽管这肯定有帮助）。然而，scrum master为开发团队服务并保护其不受外部环境的影响。所谓保护，我是指允许团队基于敏捷原则工作。作为团队的发言人，不要允许任何非计划的请求改变当前同意的冲刺计划。
#3. 产品负责人
产品负责人（po）作为开发团队与业务用户（利益相关者）之间的连接者。po与所有相关方讨论内容，并将达成一致的内容带给scrum团队。
然后，po为团队创建具有明确描述和期望的故事。po需要确保开发团队理解这个内容，以便团队可以估算每个故事。因此，po在团队内部拥有故事细化讨论的所有权。
除了内容和整个待办事项管理外，po还负责为待办事项设置优先级。然而，po不负责具体的故事选择进入冲刺。只有开发团队可以通过承诺决定下一个冲刺的范围，团队将选择哪些故事。po只能通过正确地设置和传达优先级来影响这个选择。
scrum团队内角色的互动
即使有了所有的人和角色，沟通仍然是成功的关键。最重要的是正确的沟通，因为有很多使其出错的方式。这实际上是为什么许多scrum团队不成功的最大原因。他们只是没有做好。
例如，产品负责人经常要求开发团队提出新的内容故事。但开发团队的目的并不是创建待办事项。当然，他们可以帮助定义故事，使其详细，并将其分割为可以在冲刺中执行的部分。但是产品负责人负责待办事项。po理想情况下不应要求开发团队与业务利益相关者联系。
另外，scrum master和产品负责人都不应该定义下一个冲刺的范围。虽然scrum master和产品负责人的角色通常是scrum团队内的一种天然领导角色，但实际上，他们并不能决定开发团队是否应该将什么纳入冲刺。只有开发团队才能执行此操作，因此决策权在于开发团队。这意味着po要提供关于业务角度上每个故事的重要程度的信息；po甚至可以按照重要性对故事的待办事项进行排序。通过这种方式，开发团队可以知道首先选择哪些故事。
产品负责人应该努力与团队定期讨论po要求团队交付的新内容。po在此要彻底讨论他/她创建或带到待办事项的每个故事。开发团队的每个人都必须理解故事，并且对他们来说很清楚验收标准是什么。
scrum master不仅是团队的策划者；在某种程度上，sm还保护团队免受产品负责人、领导或其他外部利益相关者的影响。sm保持内部scrum流程运行，并主持团队的大部分仪式。在每日状态电话中，sm确保每个人只说当天的重要更新，以免会议超过预定时间。实际上，这适用于所有电话。
sm还为团队组织定期的回顾电话，在这些电话中，他/她帮助团队回顾前一个迭代中完成的工作，并确定团队可以改进的领域。
最后的话
建立一个成功的scrum团队通常是一条漫长的道路。即使团队的具体成员已经具有一些先前的经验，您也需要在团队内建立经验。每个scrum团队都是独特的，找到如何在共同话题上一起工作和协作的方法总是需要时间。
最重要的是，在形成团队后要保持团队的稳定。只有这样，团队才能随着每个下一个迭代的进行不断改进。最终目标是转变为一个自组织的团队，在大多数情况下，甚至不再需要scrum master的存在。如果无法保持团队的完整性，您将仍处于学习阶段。
接下来，查看适用于初创公司到中型企业的最佳scrum工具。
