Scrum角色vs角色和责任

不过我完全明白你的意思了

你能在这里给我们解释一下吗?“宪章”的实际目的是什么?

听起来好像它构成了一个组织映射，当组织改变是Scrum成功的必要条件，也是Scrum获得好处的必要条件。

Scrum团队中的每个人要么是产品负责人，要么是Scrum管理员，要么是开发团队的成员。

Scrum不认可额外的角色，开发团队和Scrum团队都是自组织的。

在这种情况下，不同的开发团队成员如何能够自我组织，充分利用每个人的才能，而不被由于组织或文化而增加的附加层所阻碍?
例如，尽管工作头衔不同，开发团队能否找到自己的工作规划方式，或者是否期望初级开发人员对高级开发人员尊重，这意味着建设性的异议和适当的自组织受到阻碍?如果团队中有一个架构师，开发团队是否接受架构的共同责任，并且他们是否愿意做出一个集体的决定，即使这个决定与架构师的专业意见相抵触?

这些角色中哪些可能存在于Scrum团队之外?我建议你看一下建议阅读专业敏捷领导力认证．这涵盖了经理和其他领导职位的角色。专家可能会扮演仆人式领导者的角色，从而使其他人能够自我组织以获得更好的结果。例如，我曾经在QA工程师身上看到过这种情况，他们从Scrum团队中退出，作为顾问和教练，帮助Scrum团队承担全面的质量责任。他们还提供了额外的支持，例如确保自动化测试框架保持运行，并提供总体质量趋势的透明度，同时使团队能够自己解决问题。

这些功能对Scrum有效吗?如果是这样，有什么机会可以帮助这些人摆脱他们现有的责任，以一种帮助他们在Scrum团队内部或与Scrum团队合作做出贡献的方式?

你能在这里给我们解释一下吗?“宪章”的实际目的是什么?

我更多的是指这样的练习，即确定某些团队成员正在做什么，其他团队成员希望这些人做什么，以确定角色之间的交叉，以及是否有些角色做得比他们应该做的多。

包机研讨会明天就要开始了，我没有团队包机的经验(我之前的雇主没有使用过这个)。我被告知章程列出了团队愿景并定义了工作方式，并且第一次研讨会的产出将被纳入章程，以定义开发人员、高级开发人员和首席开发人员应该做的角色。

值得指出的是，这些团队都是新成立的，刚成立不久，采用Scrum还处于起步阶段(不确定这是否相关)。

Scrum不认可额外的角色，开发团队和Scrum团队都是自组织的。

所以我实际上在会议开始时提到了这一点，正如我所说的，我对这个练习感到困惑，并认为团队应该自组织，只承认这些角色，而运行研讨会的人告诉我，这个练习是关于团队如何自组织的练习，而敏捷是非常灵活的。

如果团队中有一个架构师，开发团队是否接受架构的共同责任，并且他们是否愿意做出一个集体的决定，即使这个决定与架构师的专业意见相抵触?

我认为这是召开会议的另一个原因，因为看起来他们实际上是在定义架构师角色的职责，例如，该角色的职责之一是“解决方案保证”和“提出并设计新的解决方案”，这至少对我来说表明，如果一个解决方案被提出或保证是错误的，整个团队都不会感到有责任。

再说一次，这只是我对这个问题的理解，我想这也是为什么我认为我可以接触其他有Scrum经验的人，可能还有团队章程，看看他们是如何一起工作的(如果有的话)。

这个讨论让我想起了The Liberators博客中的第5步:如何组建一个优秀的Scrum团队(要做的10件实际的事情)

更常见的技能划分(可能与职位名称有关)是在一个团队中拥有前端、后端、运维和全栈开发人员。同样地，也有一些人有自己的偏好或特殊的优势，但愿意在其他需要的领域工作。原则上，没有理由不以同样的方式处理业务分析或架构;但它必须为团队工作。

如果组织期望一个人去做这件事，然后团队被告知在这个领域进行自组织，那么事情就会变得混乱。组织是如何将强制性的个人责任和责任放在一边，并将其交给团队的?

一个健康的包含架构师的开发团队可能会在决策过程中严重依赖该成员的建议。它可能会尝试适当的交叉技能，以便其他人也获得足够的这种罕见的技能，以在架构师缺席的情况下发挥作用，提供足够的替代观点，以进行健康的辩论，并在一天中促进他们自己更好的开发决策。架构师也会认识到团队的需求，并寻求在其他人身上发挥出最好的一面，而不是成为解决每个架构相关问题的英雄。

甚至在我分享的链接(由一位专业Scrum培训师所写)上，图片(用荷兰语写的，但对于说英语的人来说部分可以理解)显示的角色是“开发/团队领导”。有一个团队领导不是Scrum。Scrum并没有明确禁止它，但我认为它几乎总是阻碍自组织。
偶尔在挑战现状和允许团队在现有外部约束下工作之间找到平衡可能是最好的选择。

在任何情况下，透明是非常重要的，因为来自Scrum之外的额外层已经被应用到上面，以及它们可能会抑制团队的效率。

这是一篇很棒的文章，所以我猜这个团队被认为处于形成\风暴阶段，正在创建章程，以便他们可以就操作时的规范达成一致，以及对每个成员的期望，然后进入“规范”阶段。

我计划下周为我的团队举办同样的角色研讨会(由其他人促成)，我仍然不确定章程方面，我想知道我们是否可以使用一个简单的团队清单，在章程上列出诸如角色应该做什么的事情。

我希望我们能够正确地进行Scrum，我计划在团队中不存在任何等级制度(我是首席工程师，但不想拥有更多的权力)，我希望我们能够有效地自我组织。

当我想到自我组织时，我只是想象我们会作为一个团队合作来分解门票，人们会拿起他们自己能够完成的门票，而不是分发出去，这将有机地发生，而不必事先制定。

举个例子，一个故事被分解了，它的一部分涉及到架构工作，架构师自然会接手这个工作，一个创建新的API端点的子任务，由开发人员接手，一个react前端的更改，由开发人员接手，等等。事后看来，认为这是自然而然发生的想法可能太天真了。

我曾计划在团队中不存在任何等级制度(我是首席工程师，但不想拥有更多的权力)，我希望我们能够有效地自我组织。

我喜欢你处理这个问题的方式，从你在这个论坛上的帖子来看，你给人的印象是真诚的。这样的真诚可能有助于建立团队成功所需的信任。

你知道“隐形枪效应”吗?这是一种现象，你在组织中的位置造成了权力的不平衡，而你使用这种权力的能力(“开枪”)意味着其他人可能会看到你拿着枪，即使你从来没有打算开枪。事实上，你甚至可能都没有意识到你带着一把枪，你完全看不见它;但当你进入一个房间，它是每个人看到的第一件事。
看到的:https://www.agilealliance.org/wp-content/uploads/2016/01/AgileAntipatte..。

通常，一个Scrum团队包括5到11个人，他们分担与项目/产品交付相关的各种任务和责任。它是一群自我激励的个人，他们相互协作，以成功交付产品。Scrum团队成员之间需要高度的沟通，以确保他们专注于同一个目标，同时在整个过程中保持相互尊重。此外，它们还共享一套共同的规范和规则。

Scrum团队的三大支柱如下:

• 透明度

团队中的每个人都有一个关于共同目标以及每个人的角色和责任的简单而透明的信息流。

• 检查

所有团队成员都有权及时检查朝着共同目标的进展情况。

• 适应

敏捷的Scrum团队会尽快适应变化，以优化产品价值。

根据2020年Scrum指南，推荐的团队规模通常是10人或更少。从你的组织或过去的经验来看，你是否提到Scrum团队的规模是5到11人?你可能想要限定它，以免让任何学习Scrum的人感到困惑。

并不是说经验支柱不能应用于团队的意义上，但这不是来自Scrum指南，可能会误导学习框架的人。在支柱和事件、工件和承诺之间有一个关键的联系……

Scrum将四个正式事件结合在一个包含事件(Sprint)中进行检查和调整。这些活动之所以有效，是因为它们实现了Scrum的透明、检查和适应的经验支柱。

Scrum的工件代表工作或价值。它们旨在最大限度地提高关键信息的透明度。因此，每个考察它们的人都有相同的适应基础。

对于Scrum团队及其内部的问责制来说，跨职能和自我管理与Scrum价值观一样重要。

这一切都与下面的陈述相吻合，Scrum团队体现了为生活带来支柱的价值观……

当这些价值观体现在Scrum团队和与他们一起工作的人身上时，透明、检查和适应这些经验主义的Scrum支柱就会建立信任。