【问题标题】:Scrum enabled development process - role of Team Leader or Solution Architect [closed]Scrum 支持的开发过程 - 团队领导或解决方案架构师的角色 [关闭]
【发布时间】:2019-11-19 05:35:31
【问题描述】:

我只是好奇,因为对于支持 Scrum 的开发过程,团队领导 (TL) 角色与 Scrum Master (SM) 角色合并,并且团队应该是自我激励、自我组织和自我驱动的. 如果团队内部没有团队负责人(和架构师!) - 谁来决定未来的实施方式?比如说,要使用哪些库、客户端数据处理等。 基于 Scrum 概念,此类决策应由团队协作或由单个团队成员做出。他们很可能没有足够的资格/经验,并且该决定可能会在未来几年花费数百万美元(甚至是一两年的时间)。

请问这是如何在 scrum 概念中解决的?

谢谢

【问题讨论】:

  • 当我们使用 CMMI 实践进行项目时,我们使用决策分析和解决 (DAR) 来做出关键决策。我们仍然将 DATE 放在 DAR 中,因为多年来我们的优先级可以改变。所以当我们看3年后的一个项目的时候,我们就做出了判断的决定。我们应该考虑这些事情,比如时间,以及影响做出决定的其他因素。
  • 恕我直言,我将从最低架构开始。我认为架构本身是一个不断发展的过程,随着系统的发展而发展。考虑最近的微服务模式,公司从单体应用开始,并考虑从单体应用中剥离多个服务。但在开发单体应用时,他们会保持选择余地。

标签: scrum teamleader


【解决方案1】:

Scrum 只是交付过程。技术决策应由相关负责人进行。这些决定可能会在讨论和团队会议之后做出。如果需要,团队成员也可以参加这些会议。 scrum master 的作用是确保交付进入 sprint 的积压项目。它与技术决策无关。 (Scrum master 负责消除障碍,使团队朝着 sprint 目标前进)团队在计划会议期间接手一项任务时,可以为架构决策或设计/重新设计过程分配时间。

例如,TL​​ 可能有一个 4 小时的 scrum board 任务来完成设计。如果此任务涉及与架构师的会议,并且架构师不在现场,则 Scrum Master 应采取必要的措施来安排会议并确保删除此障碍。也许他可以安排他们之间的通话。

认为技术领导者应该是 Scrum Master 也是错误的。这是两个不同的角色,可能是也可能不是同一个人。

【讨论】:

    【解决方案2】:

    在 Scrum 中定义了三个角色:

    • Scrum 大师
    • 产品负责人
    • 开发团队

    Scrum Master 帮助团队遵循 Scrum 并消除障碍。产品负责人负责处理积压的工作并确定优先事项。

    开发团队负责其他所有工作。开发团队中没有明确的角色,但我们有能力

    例如,开发团队有能力进行开发。它还具有进行测试的能力。

    没有什么可以阻止开发团队拥有能力来做架构。例如,它可能有一个具有架构背景的团队成员,或者可能有几个团队成员具有架构经验。

    至于团队领导角色,没有必要这样做,因为 Scrum 中的每个人都可以充当领导者。例如,如果团队中的某个人在数据库工作方面非常有经验,那么当团队处理数据库工作项时,他们可能显示出领导能力

    谁在制定面向未来的实施方式?

    团队做到了。

    经验丰富的 Scrum 团队会定期聚在一起讨论“大局”。他们会考虑实现的未来、架构方式等。

    使用哪些库、客户端数据处理等

    谁有决定使用哪些库的经验?他们可能是建议使用哪些库的方法的好人。然后团队可以讨论它并就方法达成一致。客户端数据处理也是如此。

    这是合作。每个人都有发言权,每个人都是潜在的领导者。

    他们可能没有足够的资格/经验,并且该决定可能会在未来几年花费数百万美元

    如果团队担心他们没有足够的经验来做出重要的决定,那么他们应该将其作为一个问题提出。一些可能的解决方案包括:

    • 为团队成员获得额外培训
    • 让有更多经验的人加入团队
    • 使用实践社区获取建议

    【讨论】:

      【解决方案3】:

      敏捷宣言在提到自组织团队的原则中直接解决了您的问题:“最好的架构、需求和设计 从自组织团队中脱颖而出。”相对于其他著名的敏捷方法,Scrum 可能在信任“有动力的个人”(根据另一个原则)使用科学家所谓的“群体思维”来做到这一点方面做得最好。我的教练实践基于我对与团队合作相关的科学研究的回顾。这些研究反复表明,随着时间的推移,具有不同背景的跨职能小组在决策质量方面将胜过单个专家。Scrum 通过让人们一起计划每个人的工作和通过 Scrums 和 Demos 让他们对团队负责。

      这并不意味着您不能在团队中拥有像架构师这样的技术专家或为团队提供意见。我同意莱尼的观点,最好不要让技术专家成为 SM,因为这会在一个角色中巩固太多的社会力量,并为真正的自组织设置更多的心理障碍。 (从社会心理学的角度来看,拥有一个全职的 SM 会阻止真正的自组织,所以我让成员轮换角色。)但是这些专家可以通过协调跨团队自下而上的标准开发来充当顾问,为用户故事提供输入,坐在各个团队的策划仪式和演示等。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多