【问题标题】:Does Scrum alone = agile? [closed]单独的 Scrum 是否 = 敏捷? [关闭]
【发布时间】:2008-10-03 22:47:53
【问题描述】:

我听说很多公司都表现得像敏捷一样,但他们所做的唯一敏捷的事情就是 Scrum 流程。这足以被认为是敏捷的吗?单独使用 Scrum 似乎是一个糟糕的经理更频繁地召开更多会议的完美借口。我应该厌倦这样的公司吗?

【问题讨论】:

    标签: project-management agile scrum


    【解决方案1】:

    敏捷是一个大而模糊的概念。很多东西都是敏捷的。

    Scrum 是一组用于冲刺和发布的特定技术。它是敏捷的,因为它符合敏捷宣言。

    还有许多其他特定的敏捷技术(例如所有 xDD。)

    如有疑问,请将公司的实际做法与Agile Manifesto 进行比较。

    【讨论】:

    • 您不能忘记,即使公司中的团队使用 SCRUM,它也不会神奇地将公司转变为敏捷公司。有很多官僚的大公司不能作为一个整体敏捷,但他们可能会使用 SCRUM 作为一些小项目的项目方法以使其敏捷,而他们(也许)对大型项目使用更传统的瀑布方法。
    • @Mantisen:好点。敏捷项目与任何其他项目无关。但是,请注意:“敏捷公司”的想法毫无意义。公司——作为一个整体——在任何意义上都不能是敏捷的。即使公司只创造软件,它也不可能是一个整体的敏捷。敏捷不适用于法律、人力资源、财务、销售、营销、运营等。它仅适用于项目。正如您所注意到的,它一次应用一个项目;每个都是独一无二的。
    【解决方案2】:

    “我听说很多公司表现得好像他们很敏捷,但他们做的唯一敏捷的事情是 Scrum 流程。这是否足以被视为敏捷”

    简短的回答 - 是的。无论如何,我认为:-)

    当然——他们必须真正 Scrum——而不是仅仅把名字贴在墙上。 Scrum 不仅仅是每天的站立会议……如果这就是他们所做的一切,那么他们就做得不对。

    正确完成 Scrum 迫使公司识别组织运行方式的瓶颈。通过设置定期的时间盒冲刺、获得体面的反馈循环以及在产品所有者和团队之间适当地划分责任,您实际上可以获得有关如何改进流程的有用基线信息。

    组织必须听取反馈并采取行动。

    这当然不是实现敏捷的唯一方法。它甚至可能不是将敏捷引入组织的最佳方式。我自己更喜欢 XP ——并且发现额外的实践为启动这些流程改进提供了一个有用的框架。

    也就是说 - 对于许多组织而言 - 最大的问题是职责分工不当以及完全缺乏理智和快速的反馈循环。 Scrum 解决了这个问题。

    会议只是其中很小的一部分:-)

    【讨论】:

      【解决方案3】:

      Scrum 所提倡的透明度会让糟糕的经理脱颖而出。真正采用 Scrum 的公司绝对值得一看。

      【讨论】:

        【解决方案4】:

        单独使用 SCRUM 不一定是召开更多会议的借口。能够跟踪每天完成的工作并决定如何修改(通过削减或重新平衡工作)冲刺的其余部分本身就非常有用,而且对我来说听起来很敏捷。 :-)

        当然,如果您没有敏捷流程的其他组件,您将很难衡量工作的成功与否,因此您可能认为自己在 sprint 中步入正轨,但实际上却一无所获接近您应该按时交付优质产品的时间点。

        更新:你不应该仅仅在这个前提下解雇这样的公司。但是,在面试期间,您应该利用这个机会了解他们为什么只使用 SCRUM。如果没有人来支持 TDD 或 CI 之类的事情,那么如果您愿意成为技术负责人,那么它可能很适合您。如果是因为他们将这些流程视为“开销”、“愚蠢”或“不必要”,那么你应该警惕这家公司。

        【讨论】:

          【解决方案5】:

          首先,Scrum 是一种项目管理方法。是的,如果你在做 Scrum,你可能会开始更多地考虑敏捷,并为你的客户提供价值。但这并不一定会让你变得敏捷。对于初学者来说,Scrum 不会谈论你如何进行软件开发。这就是 XP 之类的东西的用武之地 - 其他方法和想法会迫使您审查和改变您的工作实践,以提高效率和效果。

          因此,与其问“你是否从事 Scrum / XP / 什么”,我会询问这些公司他们的整体流程并采取整体观点。公司是否专注于提供最大的商业价值并以持续改进的精神为动力?如果是这样,那么他们可能比那些说它做 Scrum 的人敏捷得多。

          【讨论】:

            【解决方案6】:

            不可能仅仅因为有人说他们在做 Scrum 就判断一个团队是否敏捷。

            Scrum 实现有好有坏,但敏捷的关键在于:

            • 项目和团队灵活思考的能力
            • 团队的自组织程度如何(他们是否有控制狂“架构师”或经理?或者是否有相当多的共识决策?)

            在没有真正敏捷的情况下,很容易满足团队在进行 Scrum 时需要做的最低要求。这些最低要求只是为了带来某种态度和工作方式。

            项目中的决策可能极其僵化和自上而下受控,但仍符合 Scrum 的最低要求。 遗憾的是,当我寻找合同约定时,我发现仅 scrum-in-name 的实现数量远远超过实际实现。

            就个人而言,我会选择在 scrum 中实现极限编程。 (事实上​​,Jeff Sutherland 说他从来没有见过没有进行 XP 实践的顶级生产力 Scrum 团队。)但是,我非常有信心人们也可以非常糟糕地实施 XP... ;-) 它真的失败了对团队的态度。

            【讨论】:

              【解决方案7】:

              敏捷!= scrum。

              敏捷是为改变做好准备。

              敏捷多次被呈现为一个保护伞,一组不同的技术、方法,用于在支持变革的环境中工作。 Scrum 用于项目管理,开发技术有 xp,更好的需求流程可以使用 BDD,用于测试 TDD。

              从 scrum 开始是敏捷之路的第一步。也考虑其他技术。这需要时间,但有真正的好处。没有什么比共识和良好的团队精神更好的了。作为第一个实现它。

              【讨论】:

                【解决方案8】:

                我注意到,仅使用 Scrum 会议是一个非常明显的迹象,表明公司没有正确实施敏捷概念。

                想想 Scrum 会议有多么简单,只需启动 Outlook 并让每个人每天开 15 分钟的会议。但是,将所有内容分解为快速迭代并确保最终用户快速测试新功能需要更多的工作。

                我猜,大多数经理在 Scrum 部分之后就停止阅读,他们就失去了兴趣。但是,他们的日常会议请求永远存在。

                【讨论】:

                • 是的,就像呆伯特的尖头老板一样。
                【解决方案9】:

                敏捷宣言实际上是一种与更好的工作方式相关的哲学。 Scrum 是一种敏捷方法,所以是的,使用 Scrum 的公司通常被认为是敏捷的。

                然而,在尝试实施 Scrum 时完全有可能忘记敏捷哲学。很容易陷入对完美 Scrum 流程的追求而忽视个人及其互动。

                您应该对那些忽视个人和互动的公司感到厌倦,而应该盲目地偏爱严格的流程和工具。 但是,无论他们声明的方法如何,这都是正确的。

                【讨论】:

                  【解决方案10】:

                  Scrum 就等于敏捷,这完全是一种误解。敏捷是一种保护伞,其中有几种方法,如 scrum master、看板、精益、XP。现在你说伞的一部分如何才能实现伞的整体概念。因此,Scrum 是敏捷的一部分。

                  【讨论】:

                    【解决方案11】:

                    Scrum 为您提供了一个框架来修复/改进您的开发过程。它应该被视为“jelled team”和更有生产力的团队的起点。您很可能很快就会超越标准的 Scrum 实践,但作为起点,它具有一些吸引人的特性:

                    1. 很容易理解
                    2. 几乎可以应用于任何项目和团队
                    3. 有很多人赚钱并帮助公司采用 Scrum

                    还有really not so important to know whether Scrum = agile。最好专注于提高生产力,不要为这些问题烦恼。

                    【讨论】:

                      【解决方案12】:

                      是的,我同意这里的一些观点。敏捷是遵循宣言并确保您正确排列优先事项。 SCRUM 只是另一种写下特定部分的变体。如果有的话,它是一种管理“工具”。

                      话虽如此,请记住,工具是次要的,你的人是你的首要任务。不要过度关注管理风格,而不是关注人和产品。

                      【讨论】:

                        【解决方案13】:

                        仅实践 Scrum 的组织很可能会在软件管理和项目可见性方面看到收益。然而,他们很可能不会通过不结合 XP 原则(如单元测试、持续集成、结对编程等)来实现更高的工程质量和吞吐量潜力,从而使他们的 Sprint 产品的末端不是“潜在可交付”的。

                        【讨论】:

                          【解决方案14】:

                          人们成为主观观点的牺牲品。我认为敏捷和 Scrum 是什么,另一个人的想法可能会有所不同。幸运的是,我们在敏捷 manifestoprinciplesScrum values 中有一套指导方针,但通常公司最终会变得专注于遵循流程,而不是理解它及其目标。

                          敏捷宣言

                          我们正在通过这样做来发现更好的软件开发方法,并且 帮助别人做到这一点。通过这项工作,我们开始重视:

                          • 个人和互动超过流程和工具
                          • 工作软件优于综合文档
                          • 客户合作超过合同谈判
                          • 响应变化优于遵循计划

                          也就是说,虽然右边的项目有价值,但我们重视 左边的项目更多。

                          Scrum 价值观

                          您可以通过询问使用 Scrum 的公司的价值观以及他们如何遵守这些价值观来了解他们的很多信息。这可以让您了解是否只是执行 Scrum 流程而没有真正考虑与之相关的价值。

                          在 Scrum 中执行的所有工作都需要一组价值观作为基础 用于团队的流程和交互。通过拥抱这五个 价值观,团队使它们对其健康和 成功。 - 更多信息请访问: https://www.scrumalliance.org/why-scrum/core-scrum-values-roles#sthash.qsmCTxdU.dpuf

                          • 专注
                          • 勇气
                          • 开放性
                          • 承诺
                          • 尊重

                          目标

                          目标是在每次迭代结束时发布优质软件

                          有了正确的影响力,公司内部的价值观可以改变。不幸的是,人们是不可预测的,因此当引入其他变化时,公司可能会重新陷入不良习惯。这就是使软件更具挑战性和令人兴奋的原因。它正在寻找在技术和产品之间建立平衡的方法。

                          危险信号

                          • 如果公司更关注过程而不是目标。
                          • 如果您必须跳过各种圈套和程序来签署最小的更改。
                          • 公司不必让流程 100% 正确,但如果他们没有不断适应和改进以实现目标,而不是仅仅遵循流程,那么他们最终可能会得到一个"Half-Arsed" 敏捷实现:

                          我们听说了通过付费开发软件的新方法 顾问和阅读 Gartner 报告。通过这个我们一直 告诉价值:

                          • 个人和互动超过流程和工具,我们有强制性流程和工具来控制这些个人(我们 更喜欢“资源”一词)互动
                          • 工作软件优于综合文档,只要该软件有综合文档
                          • 客户协作在严格合同的范围内进行合同谈判,当然,并受到严格的约束 变更控制
                          • 响应更改而不是遵循计划,前提是制定了详细的计划来响应更改并准确地遵循该计划

                          也就是说,虽然左边的项目在理论上听起来不错,但我们是 企业公司,我们不可能放过这些物品 在右边。

                          合规性

                          一些公司可能制定了繁重的合规程序,阻碍了敏捷。这可能包括无法逃避的治理和其他法规。这可能会影响敏捷方法,使其感觉更加笨重和沉重,但这并不意味着这些流程不能被简化以变得更加适应。

                          【讨论】:

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