Scrum 已死:剖析全新的开放式开发方法

目前还没有读者喜欢这篇文章。
Iceburg with a cycle symbol

Opensource.com

“江湖郎中”这个词让人联想到那些戴着圆顶礼帽、留着浓密胡须、身穿定制细条纹西装的老头,他们兜售装满“包治百病”液体的瓶子。虽然几个世纪前很流行,但江湖郎中这个职业现在已经消失在历史的长河中。如今,江湖郎中的描述已经扩展到人类医疗保健之外。例如,在科技界,江湖郎中式的解决方案可以用来描述防病毒软件或某种流行的软件开发流程。

在当今引入业务开发团队的、最被“过度推销为灵丹妙药”的方法论中,Scrum 就是其中之一,它是几种 敏捷 软件开发方法之一,并被引入作为简化流程的一种方式。Scrum 已经成为一种根深蒂固的方法,它有自己的圣经,即 敏捷软件开发宣言,以及每日的虔诚仪式(又称 Scrum 会议)。

虽然 Scrum 在 90 年代早期开发时可能更有意义,但多年来情况发生了很大变化。初创公司和企业的工作人员分布在许多国家和时区,这使得员工更难共享办公室。随着我们的劳动力世界不断发展,我们的软件开发方法也应该随之发展。

当今的开放技术

初创公司和企业正在以开放技术的理念为基础创立,甚至更多成熟的企业实体,包括微软,也都在 拥抱一切开放事物Matt Asay描述当前的事态 方面做得很好。

十年前,一家新的开源公司或项目还是新闻。现在已经不是了。开源在移动领域占据主导地位,Android 在智能手机和平板电脑领域都取代了看似不可战胜的 iOS。开源也在云领域占据主导地位,除了 Azure 之外,每个重要的云平台都是使用开源构建的。甚至 Azure 也将开源技术视为其平台上的头等公民。开源在大数据领域也占据主导地位,Hadoop 和 NoSQL 技术是管理世界数据爆炸的主要力量。

2015 年的开源无处不在。每个从现代技术中受益的人,可能也在以某种方式从开源解决方案中受益。当您考虑到国际开发者群体为世界上最流行的开源项目做出贡献时,您不禁要问,他们如何在没有管理者、会议和代码冲刺的情况下取得成功?当我开始研究开源项目是如何取得成功的时,我意识到它们共享一套原则,这些原则可以被认为是开放式开发方法的信条

开放式开发方法的信条

代码质量

作为开放式开发方法的一部分,代码质量至关重要。每次编写代码时,您都应该问自己关键问题:

  1. 这段代码是否易读?
  2. 这段代码是否可测试?
  3. 这段代码是否模块化?
  4. 这段代码是否经济高效?

提出的每个问题不仅对您有益,而且对您的团队也有益。当您以一种身处半个地球之外的另一位开发人员可以坐下来立即开始工作,而无需提出任何问题的方式编写代码时,您就是在帮助提高团队的效率。同样,当您确保您的代码是可测试的时,您会大大减少团队可能遇到的障碍数量。通过模块化,您向您的团队展示的代码既易于维护,又有可能为另一个项目回收利用。最后,经济高效的代码可以为每个人——从您的团队和未来的贡献者,到客户和最终用户——节省时间和金钱。

文档

开发人员不一定喜欢记录他们的代码——这不是秘密。此外,当他们受到像 Scrum 这样的系统的急诊室流程的影响时,即使他们想记录他们的代码,他们也可能没有时间,因为业务部门确定的优先级通常会优先考虑。您将编写的最重要的文档是您的高质量代码,但这还不够。考虑那些不了解代码的人,以及那些既没有时间也没有意愿阅读所有代码的人。当您的团队专注于适当地记录您的项目时,您正在为您的代码做与流行的电视节目 制造的原理 为其观众所做的事情相同的事情,即解释您项目的复杂性,并以更易于理解的方式将其带给更广泛的受众。

测试

在一个地理位置分散的团队中,您可能无法实时获得帮助,采用测试优先的代码方法可以让您更独立地工作,并减少障碍。可测试的代码有很多好处值得考虑。让我们来看看 Tim King12 条技巧 列表,该列表来自 Perl Shop

  1. 单元测试证明您的代码确实有效。
  2. 您获得了一个低级别的回归测试套件。
  3. 您可以在不破坏代码的情况下改进设计。
  4. 与不进行单元测试相比,进行单元测试更有趣。
  5. 它们展示了具体的进展。
  6. 单元测试是示例代码的一种形式。
  7. 它迫使您在编码之前进行计划。
  8. 它降低了错误的成本。
  9. 它甚至比代码审查更好。
  10. 它几乎消除了编码员的瓶颈。
  11. 单元测试使设计更好。
  12. 它比不进行测试编写代码更快。

讨论

在讨论您的项目和方向时,每个人都应该有发言权。永远不要忽视营销协调员、客户经理和非编码设计师。一切都可以公开讨论,当每个人都可以在无需通过指挥链的情况下相互访问时,一些最巧妙的想法和解决方案就可以被发现。

虽然资深开发人员可能会因为他们的专业知识而在讨论中占据主导地位,但永远不要忽视拥有不同、新鲜想法的新开发人员。TODO 组织开源行为准则 概述了一个项目社区的一般期望,我们在参与团队讨论时也可以考虑这些期望:

  1. 友善和耐心。
  2. 热情欢迎。
  3. 体谅他人。
  4. 尊重他人。
  5. 谨慎选择措辞。
  6. 努力理解我们为何意见不合。

透明度

赢得用户信任、促进社区参与以及提高项目的安全性和稳定性传统上被认为是项目成功路线图上的独立目标。但是,当您的团队拥抱开放式开发方法的透明度时,所有这三个目标都可以同时实现。

从发布项目的源代码到公开问题跟踪器,再到提供对内部流程和沟通的深入了解,项目的热情对于任何接触到它的人来说都是显而易见的。当用户和开发人员可以访问这些资源时,您的团队不仅会找到许多愿意贡献的人,还会获得社区更大的尊重和接受。透明度是一种强大的营销和工作工具。

异步性

随着初创公司、企业和开源项目将工作负载分配给世界各地的开发人员,维持像 Scrum 这样的软件开发流程所期望的某种同步水平变得困难。对于某些团队来说,维持每日 Scrum 会议是不现实的,当您有五位开发人员分布在五个不同的国家时,您可以排除结对编程的可能性。当今的软件世界在异步性中蓬勃发展,遵循开放式开发方法的团队也可以如此。

如果有人有问题,他或她可能会发送电子邮件或在开发者论坛上发帖,并期望他们的消息不会立即得到回复。那么,提出问题的开发人员会停止他们的工作吗?不一定。由于需要自力更生和适应性强,开发人员可以修改他们的期望,专注于代码质量,加强他们的文档,并提高他们的技能。

民主

除了在项目社区内进行公开讨论和分享想法外,社区成员还应参与决策过程。当决策由闭门董事会会议、高管或经理(我称之为单点故障)做出时,通常带有狭隘和有限的观点。当每个人都参与决策过程时,包括最终用户或客户,否则无法识别的潜在问题更有可能在成为问题之前得到解决。

共同构建开放式开发方法

与其只允许我自己或少数人开发这种方法,我更相信这个过程应该像任何其他开源项目一样开放和包容。

可能有一些我遗漏的优先事项,或者需要理顺的点,所以请 在 GitHub 上加入我,我将在那里继续讨论,并致力于创建一套精美的指南,使所有规模的开发团队都能取得成功。

标签
User profile image.
Ahmad 是开源的倡导者,也是开发者工具的热情爱好者。目前在 Mashape 领导才华横溢的工程团队,构建世界一流的 API 工具和市场。在业余时间,Ahmad 在 Technology & Leadership 上写博客,指导早期创业公司,并构建数千名开发者使用的开源项目。

49 条评论

亲爱的读者,您好!

很高兴回答任何问题或讨论任何反馈,请在此处留言或通过 Github 项目贡献您的想法!

这很有趣,但我看不出您描述的任何内容与 Scrum 不兼容。

回复 ,作者:ahmadnassri

你好,Ahmad。感谢您撰写这篇文章。我的公司以相对严格的方式实践敏捷(真是讽刺,不是吗?),但我发现自己在日常运营和团队互动中更倾向于您的开源方法论。作为一名传统的敏捷产品负责人,我的开发团队分布在三个大洲的 15 个时区,坚持传统的敏捷方法论极具挑战性。

您对如何弥合传统敏捷和开源方法论之间的差距,以努力兼取两者之长有任何见解吗?

嗨,Joseph,

感谢您的评论!国际团队确实给传统的项目管理方法带来了挑战!我过去经历过这种情况,今天仍然在经历,我的团队分布在 7 个城市、6 个时区、8 个国籍,说 8 种不同的语言 :)

这就是我寻求替代方案的原因,这让我走向了开源世界和开放式开发方法论。

关于我在下面留下的较长评论:https://open-source.net.cn/business/15/11/open-development-method#comment-8…

我不认为敏捷宣言与开放式开发方法论相悖,事实上,我认为它在原则上是——大部分——兼容的,但它从根本上是不同的,因为它是一个“宣言”,而不是一个“方法论”。两者都需要一个“流程”来实现日常活动。

虽然敏捷有 Scrum/看板/XP 等…,但开放式开发方法论没有。尚未有。

这是故意的,因为我不希望规定我们使用的流程是神圣的,或者作为专家应该遵循的答案,我希望这是一个开放的倡议,由社区决定什么是合理的,什么是不合理的,甚至可能有不止一个流程!

我邀请您帮助塑造每个人的未来,造福大家 :)

回复 ,作者:JosephFromOhio (未验证)

大家好,我是江湖郎中。

我不确定这篇文章是如何出现在我的新闻订阅中的,可能我遗漏了很多背景信息,但是,我想插一句。

您提出了一些相当大的论断。我很欣赏您没有足够的时间来完善您的论点。所以我也想大致谈谈。

我同意现在有很多糟糕的 Scrum 实施。就像有很多项目不尊重“开放式开发方法的信条”一样。

但这与重点无关。您将一种侧重于客户价值的方法论与一种侧重于代码质量的方法论进行比较。再说一次,我对开源世界没有足够的了解(实际上这是我第一次来到这个网站),但我的内心弗洛伊德告诉我,在您的众多项目中,您可能见过很多敏捷教练。听起来大部分都是糟糕的。这可能让您对敏捷感到不满。

Scrum 不是任何事情的万能药,在某些环境中肯定不适用。但我希望您重新考虑您对 Scrum 的看法。也许您有一些朋友同事曾在“良好”的 Scrum 团队中工作过?

我不得不赞同作者关于江湖郎中的评论。我现在工作过的两个地方,都有来自外部的人进来鼓吹 Scrum 的所有好处。他们从不停止思考这是否真的适合环境(不是开源)。管理层吸了江湖郎中的毒药。一个冲刺又一个冲刺,故事没有完全完成。用户无法进行测试。故事太大,无法在一个冲刺中完成。冲刺中的故事不够。外部干扰太多。等等等等。管理层仍然沉迷于江湖郎中,看不到它不起作用。

是的,我相信 Scrum 在合适的环境中确实有效,但我还没有见过它。
通常,当按照最初设计(迭代)完成时,瀑布模型是更好的选择。

回复 ,作者:RicoTrevisan

我完全同意。

回复 ,作者:Steve Jones (未验证)

嗨,Rico,

希望这篇文章出现在您的新闻订阅中,以帮助我们走到一起,改进每个人的流程和软件 :)

确实,这篇文章非常关注“代码质量”和“代码”本身,这是我的错误,我确实倾向于使用开发术语,但我指的是整个产品。

我说的关于“代码”的一切也适用于“设计”+“用户体验”+“商业价值”。

以我在质量下列出的关键问题为例,更广泛的产品所有方面仍然适用:

这段代码/设计/体验/业务是否易读?
这段代码/设计/体验/业务是否可测试?
这段代码/设计/体验/业务是否模块化?
这段代码/设计/体验/业务是否经济高效?

这篇文章可能需要更长的时间才能包含产品所有方面的列表,请放心,我将在未来的文章中明确说明这一点。

至于敏捷教练,是的,我们有过很多,遍布不同的团队和公司。有些很好,有些很棒,实际上很少有糟糕的。我想说,我合作过的敏捷教练通常是对我们团队工作流程和生产力的巨大投资。实际上,他们是我合作过的最有活力的人之一。

也就是说,虽然教练很棒,并且提供了巨大的价值,但他们仍然在鼓吹一种过时的流程,这种流程是为过去的软件开发设计的。我们的世界已经发展,我们的技术也是如此,团队分布在多个时区、语言和文化中。软件不再是单一的定义,而是多种定义,而从事产品的团队必须接触到不断扩展的技术领域,这些技术领域无法轻易地分组到具有重叠交付计划和需求的小型 Scrum 团队中。

不存在“万能药”这种东西,我完全同意,我也没有暗示开放式开发方法论是万能药。我建议的是,我们通过有争议的进化周期来进化我们的流程和方法论,以适应我们的时代和需求,而不是坚持 20 多年前的方法论。

毕竟,敏捷不是提倡迭代、增量和进化的开发风格吗?为什么不将其应用于 Scrum 本身呢?

回复 ,作者:RicoTrevisan

我在 IT 行业工作了很多年,见过和听过很多关于敏捷/Scrum 等事物是终极解决方案的疯狂说法,但我的经验是,这些说法总是与现实不符。
如果您询问客户,他们总是会选择最便宜的(没有保险)选项,但是当一切出错时,他们又想要所有的文档和五星级支持,因此让他们选择是一个巨大的风险。

另一个问题是,您通过信任他人来赋能他人,而不是像操场上的恶霸一样站成一个圈来欺负他们。

回复 ,作者:RicoTrevisan

“另一个问题是,您通过信任他人来赋能他人,而不是像操场上的恶霸一样站成一个圈来欺负他们。”

没错,企业主(糟糕的企业主)似乎只想在流水线上工作,开始清晰,结束清晰,沿途步骤清晰。一切都可预测。这本身不一定是坏事,但软件的现实是它是一项创造性的职业,您对其施加的限制越多,您获得的质量就越低。

“如果您询问客户,他们总是会选择最便宜的(没有保险)选项,但是当一切出错时,他们又想要所有的文档和五星级支持,因此让他们选择是一个巨大的风险。”

是的,Scrum 通常最终会这样,为了成本和时间而交付次等质量的产品...

我不明白为什么我们的行业将客户视为愚蠢的,当然,他们中的一些人只关心进度和成本,但这些都是糟糕的客户,他们伤害自己胜过伤害您交付高质量工作的能力,如果您无法教育他们并向他们展示更好的方法,那就解雇他们!!

回复 ,作者:Andrew64 (未验证)

很抱歉回复您这么晚,尽管您是第一个评论者 :)

希望这篇文章出现在您的新闻订阅中,将您带到这里,为讨论增加价值和思考,并帮助我们改进我们的工作流程和流程 :)

我不应该将其标记为“代码质量”,而应该简单地标记为“质量”。

这适用于设计、代码、用户体验和商业价值。您希望在所有这些方面提供质量。

测试也是如此。测试您的设计,测试您的代码,测试您的用户体验,最重要的是测试您的商业模式!

Scrum 和敏捷最大的失败之处在于“关注客户价值”的虚假承诺,而实际上几乎没有帮助实现该价值。

客户通常不是专家(这没关系),但被视为专家,因此在大多数情况下都受到温和的对待。他们没有充分了解幕后真正的工作,而是得到了脚注,这些脚注通过两个层级委派:Scrum Master(通常是项目经理)和产品负责人(通常是产品经理)。

客户永远不会真正看到或理解用户体验的复杂性、设计选择或开发挑战。为了时间和成本,您最终会创建不断增长且永远无法真正解决的技术债务,因为您想专注于“客户价值”,这意味着在最短的时间内交付他们要求的功能,无论成本如何。

同样重要的是要记住,敏捷和 Scrum 的目标是服务行业,而不是产品构建者。从它们的起源和历史到它们所依赖的措辞,例如“客户”,它从根本上对产品构建采取了不同的视角,并在软件创建者(开发人员、设计师等)与软件的实际用户(通常是客户的客户)之间引入了深刻的隔阂。

> “您可能见过很多敏捷教练。听起来大部分都是糟糕的。这可能让您对敏捷感到不满。”

实际上恰恰相反,与敏捷和教练有很多愉快和有益的经历。尽管如此,它仍然未能达到上述原因。

似乎这是对任何敏捷教练或长期饮用 Scrum 酷爱饮料的人的默认反应:“您只是没有做对。”

老实说,这不是进行讨论和提供价值的方式。让我们详细讨论一下缺少什么、什么是好的、什么是坏的,并进行全面的改进。

毕竟,敏捷/Scrum 的核心是通过迭代过程持续改进。我没有看到 Scrum 或敏捷本身得到改进或重新审视,而是像最初发布宣言的原始网站一样保持静态,这是过去时代的遗物,完全体现在它发布的过时网站上。

n

回复 ,作者:RicoTrevisan

一个有趣的驳斥,希望也能得到作者的回应,以进一步丰富讨论。

回复 ,作者:RicoTrevisan

我也看不出在软件开发中拥有最佳实践如何与在您的团队中运行 Scrum 相矛盾。

如果您阅读 Scrum 宣言,它完全是关于在您编写软件时拥有短的反馈周期。您如何编写以及您选择哪些实践取决于您自己!

除非您的副标题将 Scrum 列为“已死”,否则这将使开放式开发方法论自相矛盾。如果我目前在所有项目中都成功地采用了混合 Scrum 方法,我就不会将 Scrum 列为已死。需要明确的是,我没有严格遵守,也不期望任何方法论都如此规范,以至于我无法灵活运用软件管理的艺术。毕竟这是软件。严格——任何东西几乎都肯定预示着某些东西会达不到要求。

所以我认为许多对 Scrum 的不满都是由于为了流程而流程,或者操作员经验不足(或者正如有些人所说,当不适合动态时应用)。

回复 ,作者:ahmadnassri

您将 Scrum 与敏捷混淆了。

敏捷是一种方法论,它带有宣言 + 原则。

Scrum 是一个流程,侧重于角色、任务和交付工作的步骤。

这样,开放式开发方法论是一种方法论,我们将与社区的帮助一起发展它、修改它和改进它,然后围绕它创建流程。

回复 ,作者:Mikey (未验证)

您将 Scrum 与敏捷混淆了。

敏捷是一种方法论,它带有宣言 + 原则。

Scrum 是一个流程,侧重于角色、任务和交付工作的步骤。

回复 ,作者:Milad (未验证)

我几乎同意每一个积极的陈述,并且不同意大多数关于 Scrum 的负面评论。代码质量、测试、一些文档、透明度、扁平化结构、所有团队成员的平等发言时间,所有这些都是构建优秀产品的基本要素,即使您可能将它们视为对 Scrum 的回应,但这些都是 3 年前我在 Scrum Master 课程中涵盖的内容。在所有这些事情中,我没有看到任何新颖性,也没有看到任何与 Scrum 的对立。结束我们达成一致的事项清单,事实是,世界上有很多糟糕的事情正在发生,它们是对 Scrum 的拙劣模仿,试图将 Scrum 的某些要素强行塞入,通常只是早上的站立会议塞入完全的瀑布 PMO 中,甚至把这一件事也做错了,仍然声称自己在做 Scrum。现在,说到我不同意您的观点的事情,除了您对 Scrum 的所有其他批评之外,但这现在应该很明显了。我对您关于异步性的段落的理解,让我想起了 IT 部门认为自己非常重要的日子,企业没有他们就无法生存。那些日子里,项目会运行几个月而没有交付任何一个功能,而开发人员小组则会就宏大的框架进行智力辩论,这些框架可以在假设的未来节省几周的工作量。这就是为什么有产品负责人的原因。如果开发人员需要时间思考、等待回复、重新思考一些更大的设计,这都没问题。但这不能成为他们想做什么就做什么的借口。这要与客户或产品负责人以及开发团队讨论。产品负责人,如果相关,应该在冲刺评审时,或在任何时候听到问题时与其他利益相关者讨论。这就是所有营销经理和所有其他人如何将他们的意见输入到产品中的方式。在评审时或通过 PO。开源社区和初创公司可以调整产品的用途。当团队有一个特定的问题要解决时,需要有人提醒团队有一个任务要完成。如何构建产品取决于整个产品团队,但构建什么产品取决于产品负责人。每天开始时或前一天结束时举行的每日计划会议在每个领域都是一个好的实践。建筑工人几十年来一直在进行工具箱谈话。如果团队分散了,最好进行追随太阳式交接,但在每个时区,沟通和计划未来的一天都行不通。不要与一些团队进行的报告和指责公开处决混淆。

哦,我的天哪,从哪里开始呢...

> “让我想起了 IT 部门认为自己非常重要的日子,企业没有他们就无法生存。”

是的,IT 非常重要,以至于现代企业没有它就无法生存。句号。

此外,开发 != IT,您使用的是过时的术语,IT 现在正在完全自动化并迁移到云端。开发是构建软件的艺术(包括用户体验设计和产品设计),这些都很重要,现代企业没有它们就无法生存。

即使是奶牛养殖户也依赖软件和技术。这种“流水线”心态的旧世界思维模式,即企业主期望人们在一条直线上运作,开始清晰,结束清晰,中间步骤可见且可衡量,在技术世界中根本行不通,这是一项创造性技能,而不是机器人式的、可重复的流程。

> “那些日子里,项目会运行几个月而没有交付任何一个功能,而开发人员小组则会就宏大的框架进行智力辩论,这些框架可以在假设的未来节省几周的工作量。”

当您去修理厂修理汽车时,您真的希望他/她安装最便宜和最快安装的零件吗?毕竟您的生命取决于这辆车的安全性。关于最佳实践和最佳解决方案的辩论实际上是在辩论拯救您的生命。

但先别管这个,似乎您的公司(或者可能是那些有您描述的“IT 问题”的公司)宁愿雇用廉价的、未经培训的劳动力,并将大问题抛给他们,只是像流水线一样工作?这应该可以解决问题吧?

如果您的团队不熟练或未经培训,或者可能不适合解决您的问题,那么再多的方法论、流程或超级明星敏捷教练和 Scrum Master 也无法从该团队中交付质量。

一位建造精美家具的“木匠”按时交付并取得可靠的成果,并不意味着他们适合建造房屋,甚至露台。

> “需要有人提醒团队有一个任务要完成。”

我相信您需要聘请一个相信您的使命并愿意与您一起完成使命的团队,而不是那些为了钱而来的人,这样您就不必聘请经理和 Scrum Master 来扮演领导者(对他们并不完全理解的事情)并鞭策团队更加努力地工作。

> “但构建什么产品取决于产品负责人。”

基于什么技能或指标?产品负责人,一位非技术人员,如何能够为系统架构选择最佳选项?或者一位非设计师,如何能够选择最佳的用户体验设计?也许他们有能力衡量商业价值,具有商业背景,或者他们实际上是技术人员并且能够理解细节,但现实是没有人能够涵盖所有方面。因此需要讨论、透明度和民主。

回复 ,作者:Jorge Carvalho (未验证)

这正在变成它自己的博文(真的:http://zxq9.com/archives/1110),所以这里是 Cliff 的笔记,因为我暂时无法完成修订:

Scrum/敏捷是在为一位客户编写代码的背景下开发的,这位客户是问题领域的专家,但对软件一窍不通,而开发团队不是问题领域的专家,但却是软件专家。

大多数 foss 项目都是基础设施、实用程序和中间件,最终用户通常是技术人员(而且通常开发人员本身就是最初的用户)。Scrum 永远不适合这里。

软件开发跨越几个不同的世界,而且它们之间没有真正融合在一起的。嵌入式、Web、移动应用程序、应用程序后端服务、运行时、客户端应用程序代码、单次发布游戏、滚动发布/内容游戏等。这些都不共享同一组需求,因此显然没有一种万能的方法论能够奏效。

我们必须根据我们正在从事的项目的性质和背景来选择方法论并发展我们自己的团队规模的开发工作流程——就像我们(真的应该)根据开发工具旨在完成的工作的性质来选择我们的开发工具一样。

将任何事物奉为宗教都是愚蠢的,无论是开发方法、TDD,甚至是特定的许可策略(尽管老实说,到目前为止我还没有遇到发布闭源软件真正带来任何好处的情况——但肯定有一些情况是 GPL 并不合适的)。

> “Scrum/敏捷开发是在为一位精通问题领域但对软件一窍不通的客户,以及一个不精通问题领域但精通软件的开发团队编写代码的背景下开发的。”

如果它一直停留在那个领域,我就不会有问题。 把它留在服务行业(一个我不愿意待,也不鼓励任何人用来构建软件的地方)

但现在它被当作一种适用于任何地方“产品团队”的方法来推销,而关于“客户”的说法根本不成立,因此才会有对它所遵循的实践的反对。

> “大多数开源项目是基础设施、实用程序和中间件,最终用户通常是技术人员(而且通常开发人员自己就是最初的用户)。 Scrum 永远不适合这里。”

虽然从统计学上讲你可能是正确的,但实际上,最大的项目实际上是面向消费者的项目。 你听说过安卓吗? Linux(Ubuntu、Redhat 等)? Open Office? 我可以举出更多更多的例子,适用于所有行业的软件,我们每天都在使用。

是的,有大量的库、中间件、实用程序等等……它们反过来为那些面向用户的软件项目提供动力,所以你对开源世界的假设或接触非常有限。 我敢打赌,你使用的许多软件和硬件实际上都是由开源驱动的(而且不仅仅是你声称的底层)

> “我们必须根据我们正在从事的项目的性质和背景来选择方法论并发展我们自己的团队规模的开发工作流程——就像我们(真的应该)根据开发工具旨在完成的工作的性质来选择我们的开发工具一样。”

很棒的声明,完全同意。 我们现在可以同意 Scrum 只适合代理和外包服务行业吗? 虽然我认为开放式开发方法实际上可以极大地惠及那个世界,但至少在这一点上达成一致,或许可以让我们摆脱辩论的泥潭,专注于软件开发的实际情况,并在所谓的“敏捷崇拜”之外创造更多价值?

回复 ,作者是 Craig Everett(未验证)

哦,开始了,第一个回复来自信仰的捍卫者,他们鼓吹通常的借口,“你做得不对。”

敏捷和 Scrum 就是垃圾。 我亲眼目睹了它如何摧毁了我自己公司以前的团队环境,当时新老板把敏捷教条强加给我们。

敏捷开发只是强行应用于软件开发的商业理论。 而且像大多数 MBA 理论一样,它不起作用。

感谢您的这篇文章。 虽然我不同意“Scrum 已死”的说法,但我欢迎每一种质疑 Scrum 作为每个人最佳选择的观点。 Scrum 一旦被提出作为一种特定的敏捷方法,就变成了许多人的宗教。 他们没有问自己“它对我们有用吗?”,而是问“这是正确的 Scrum 实施吗?”。 他们在敏捷和实施 Scrum 之间划等号,让任何不遵循他们宗教的人都“不敏捷”(读作:“不好”)。 您的观察非常有趣。 实际上,异步开发团队、空间和时间距离——这些是我们越来越频繁地在软件开发中面临的真正挑战——甚至不一定是在开源领域。 我还要补充一点专业化——这使得“任何团队成员都从迭代中承担任何任务”的范例完全无效,并对故事点和团队速度的整个概念提出了疑问。 我同意您的看法,或许现在是时候开始为当今世界考虑更好的开发方法了。 顺便说一句——您可能有兴趣访问这个网站:http://growsmethod.com/。

感谢您,Marek,

的确,我们需要分享我们的想法,互相帮助,改进我们构建软件的方式。

我在这里写了一个更长的总体回复:https://open-source.net.cn/business/15/11/open-development-method#comment-8…,而且实际上,在微服务、物联网、移动和多屏设备的世界中,专业化问题甚至更加突出!

我确实一直在阅读关于 GROWS 的内容,因为我一直在关注 Andy Hunt(敏捷宣言的 17 位创始人/作者之一)以及他启动 GROWS 的故事和理由 (http://blog.toolshed.com/2015/05/the-failure-of-agile.html)

我计划联系 Andy,以获得更多关于其发展方向以及(如果有)哪些经验可以分享的反馈!

回复 ,作者是 Marek Kucharski(未验证)

在我看来,你似乎在陈述你对完成定义的必要条件。

各位,感谢大家的回应、问题,甚至是不赞同! :)

很高兴看到一个对工作质量充满热情并希望改进它的社区。 这一点很重要,要记住,因为没有完美的系统。 如果你不同意,那么你已经将自己局限于改进你偏好的系统的任何可能性。

话虽如此,这里有一个重要的点需要澄清,我很惊讶 Scrum/敏捷专家和顾问还没有指出这一点

敏捷和 Scrum 是相关的但又不同的。 敏捷描述了一套指导原则,用于通过迭代开发构建软件。 敏捷原则最好在敏捷宣言中描述,通常被称为敏捷方法论。

Scrum 是一套特定的规则,专门用于项目管理,恰好遵循敏捷宣言。

敏捷是一种方法论,Scrum 是一种流程。

我碰巧同意敏捷方法论宣言 (http://www.agilemanifesto.org/),我甚至同意宣言背后许多(但不是全部)*原则*(另一个需要记住的区别)

另一方面,Scrum 虽然根植于敏捷方法论,但似乎更侧重于流程、任务、术语和团队成员角色,因此——在我看来——失去了合法性。

超越敏捷/Scrum,更重要的是,自敏捷方法论和 Scrum 诞生以来,软件开发的世界已经发生了多次变化,不仅技术本身比以往任何时候都更加多样化和互联,人们的工作方式也发生了变化,包括何时、何地以及如何工作。

Scrum 时代的场景,其中产品的定义意味着在单个环境中运行的单个工作软件,这种场景不再准确,也不可接受。

我们生活在一个产品需要跨越微服务、移动平台以及多屏和无屏设备的世界中。 软件开发人员、产品设计师和架构师的技能和工具不再适合这个多维世界,因此团队变得更大、更多样化,并将职责分摊到 Scrum 显得不足的地步。

我的信息很简单,让我们跳出框框思考,从开源世界吸取教训,开源世界在没有流程、规则和项目管理方法的约束下蓬勃发展,看看有哪些可以应用于我们的日常流程(Scrum 或其他),并进行改进和调整,以便我们可以交付更好的产品。

我之所以声明“方法论”而不是规定的“流程”,是为了让社区能够讨论、批判和改进所提供的原则和宗旨,以便下一个逻辑步骤演变为讨论应用什么流程,或者如何改进/改变我们现有的流程并创建下一个版本。

Scrum 社区拒绝讨论 Scrum 2.0 似乎相当自相矛盾,毕竟敏捷宣言完全是关于持续交付、反馈和改进的。 为什么不将同样的原则应用于 Scrum 本身呢?

快速说明一下,这个评论串非常精彩,我希望继续进行这个讨论,因为我想向大家学习更多关于什么有效,什么无效。

为了进行更长时间的讨论,我邀请您与围绕开放式开发方法在 Github(长篇和公开)和 Gitter(公开和实时)上的更大社区进行讨论:https://opendevelopmentmethod.org/#resources

回复 ,作者是 ahmadnassri

您的文章和评论是基于错误的假设。 而敏捷顾问没有指出您的发现,因为它们部分是不真实的! 例如,
Scrum 不是项目管理流程。
Scrum 没有定义“在单个环境中运行的单个工作软件”
Scrum 不仅仅是一个流程,Scrum 中的流程只是最明显的部分
Scrum 2.0 是一直在迭代和增量地发生的事情。 Scrum 指南正在相当频繁地更新。

看来您应该更深入地了解 Scrum,然后再尝试批评那些根本不真实的事情!

回复 ,作者是 ahmadnassri

我很清楚(甚至深入参与了 Scrum 2.0 的辩论!)

在某些东西上粉刷一层新油漆(更换术语,添加更多规则)绝不是解决基础中严重缺陷的方法。

正如我对其他评论的回复,它归结为敏捷和 Scrum 的基础是关注“付费客户,他们不了解所涉及的用户体验和技术决策”,但在现代世界中,这既不是对成功商业客户的描述,也不适用于机构和外包服务行业之外的产品开发,在这些行业中,工作外包给与业务无关的团队,而业务对工作几乎没有兴趣,除了交付日期和预算。

回复 ,作者是 P(未验证)

抛开关于 Scrum 的争论不谈,它是一种流程,而敏捷最初是作为项目管理方法论开始的。 后来它被采纳为软件方法。

回复 ,作者是 P(未验证)

我觉得这篇文章的标题有点误导。 它一开始谈论的是“Scrum 已死”,我们应该“拥抱新的……模型”(是的,“开放”是故意遗漏的)。 在阅读了“拥抱新的……”部分的几段后,我意识到这篇文章实际上是关于当今的企业如何拥抱开源的。 它与 Scrum 已死几乎没有任何关系,如果有的话。 这是怎么回事!?

继续阅读也许? 对开源的引用很多,因为新方法的学习主要来自那个世界,尽管不提倡切换到开源,那是另一个单独的讨论 ;)

回复 ,作者是 John Calcote(未验证)

我发现评论比原始文章更有用和更有趣。 完全公开,我既不是敏捷的狂热粉丝,也不是敏捷的批评者,我的团队也尝试过许多不同的开发模型。 到目前为止,最好的评论来自那位指出开源开发和敏捷开发应该用于不同问题的家伙。 敏捷(对我而言)似乎最适合客户拥有所有领域知识而开发人员相对较少的情况,而开源开发似乎是由具有极端领域知识的开发人员驱动的。 使用两种不同的方法是有道理的

继续保持圣战言论,虽然它很有趣,但对材料进行解析和过滤可以提供一些有用的信息。

如果你觉得这个评论串很有趣……你应该看看 Slashdot 上关于这篇文章的展开情况……(提示:拿些爆米花)

回复 ,作者是 Bobcat(未验证)

Ahmad,我看到了您对质量、文档、测试、讨论、透明度、同步性和民主的强调与 Scrum 的价值观之间几乎没有矛盾。(我想您无论如何都知道这一点,因为您写道“我不觉得敏捷宣言与开放式开发方法相矛盾……”)但请记住,敏捷宣言不是 Scrum,尽管 Scrum 与其一致。 我意识到“同步性”与敏捷对协同工作的偏好相冲突,但大多数敏捷实践者并不禁止分布式团队:他们只是有理由认为某些项目以这种方式工作得更好——毫无疑问,部分原因与敏捷起步时协作工具的弱点有关。

在细节方面,重要的是要记住 Scrum 不仅仅是一种软件工程方法——它是一个用于开发和维持复杂产品的框架(强调“复杂”和“产品”)。 这是一个重大且根本的区别。 Scrum 对期望的测试、故事评分等相当沉默。 它没有指定这些东西,Scrum 也没有禁止它,但 Scrum 的重点在其他地方。

我不确定“蛇油”标签是否合适。 将任何东西标记为“蛇油”的问题在于,根本问题可能更多地在于容易上当受骗的人,他们被给予了任何正在“销售”的东西的扭曲版本。

> “敏捷宣言不是 Scrum,尽管 Scrum 与其一致”

绝对是这样,我在评论中的许多回复中都指出了这一点。

> “您对质量、文档、测试、讨论、透明度、同步性和民主的强调与 Scrum 的价值观之间几乎没有矛盾。”

我认为与敏捷原则(不是宣言)+ Scrum 最大的矛盾是,客户本质上不了解工作的细节(无论是代码、设计还是用户体验),因此领域知识仅在于 Scrum 团队。

但现实情况是,情况绝非如此! 当然,可能有一些客户不在乎,只是向团队投入资金和时间表,他们只想在最后看到“完成”的复选框。

那些是不好的客户,团队应该解雇他们。

我认为在所有评论者中,您对 Scrum 提出了最平衡的反馈,很乐意继续讨论,并看看我们可以分享哪些经验和成功,并整体改进开发方法和流程! 您是否有机会在 github 项目上做一些笔记? https://github.com/OpenDevelopmentMethod/discussion/

回复 ,作者是 jgn

我仍然不明白为什么开放式方法论和 Scrum(或其他敏捷工具)不能协同工作。 代码质量对于公司/项目可能很重要,在这种情况下,相关任务可以获得优先级并进入迭代。 您还可以创建一个工作流程,任务可以按开发、文档、测试的顺序进行(无论什么顺序)。

很棒的文章。 感谢您的分享。

回复您的评论“我们生活在一个产品需要跨越微服务、移动平台以及多屏和无屏设备的世界中。 软件开发人员、产品设计师和架构师的技能和工具不再适合这个多维世界,因此团队变得更大、更多样化,并将职责分摊到 Scrum 显得不足的地步。”

微软的 Windows 10 开发团队刚刚完全过渡到敏捷。 它是一个产品,最能应用于您对跨越“微服务、移动平台以及多屏和无屏设备”的事物的描述。

是的,微软正在拥抱开源,但 Win10 的反响非常积极,尤其是他们的内部人员计划和迭代构建/发布计划——所有这些都是由敏捷宣言驱动的。 我认为这是敏捷力量的有力证据。

> “微软正在拥抱开源”

拥抱开源与采用“开放式开发方法”(名称中不包含“源”)无关 :)

教训和宗旨是从开源世界学习和采用的,但这并不意味着将您的软件和团队转移到开源,这与本次讨论无关,更多的是取决于您正在构建的产品的背景的选择。

至于 Windows 10 + 敏捷。

我不能确定评论,我不完全了解微软团队的内部运作,或者他们在多大程度上成功实施了敏捷流程(Scrum、XP、其他……)

回复 ,作者是 bcaspar(未验证)

Scrum 中没有任何东西禁止您在原始文章中说您想要的大部分内容。 唯一的例外是异步部分。 您当然可以在 Scrum 框架内拥有高质量的代码、单元测试、自动化以及您想要的所有其他“代码质量”(和其他质量问题)。 Scrum 指南的哪一部分另有说明?

Scrum 旨在作为一个入门框架,让人们以正确的方式思考,并提供一小套实践,这些实践似乎可以帮助大多数组织走上正确的道路。 它绝不是旅程的终点。 如果您想进行货物崇拜式的 Scrum,我想它可能会看起来很糟糕,但我希望我们已经过了组织只是不思考和反思结果就简单地做 A、B 和 C,并从中创造有意义的改变的阶段。

我认为将糟糕的 Scrum 实施等同于所有 Scrum 实施是一种巨大的夸大其词。 有许多 Scrum 实施确实做到了您列表中的每一件事,除了每日 Scrum 的异步性,他们不这样做是因为他们也相信敏捷宣言原则,即“向开发团队内部和外部传递信息的最有效和最高效的方法是面对面的交谈。” 我不确定您怎么能完全赞成“敏捷”,然后在同一口气中说异步通信是可以接受的。 异步通信可能在某种程度上是一种障碍,但 Scrum 团队不会仅仅接受它,而是会探索替代方案。

Scrum 说要透明、检查和适应。 这是它的核心,实际上这 3 个词通常被称为 Scrum 的“支柱”。 如果有什么东西不起作用,那就修复它。 这就是为什么我看不出您列出的任何需求/需求都无法在 Scrum 框架内解决的原因。

嘿,Bob,

感谢您的反馈,其他人也提出了与您类似的观点,我已在评论中对此做出了回应。

回复 ,作者是 Bob Hartman(未验证)

我完全同意您的评论。 我见过 Scrum 运作良好——即使在大型/规模化环境中——唯一会构成挑战的是异步方面。

看到所有关于 Scrum 的负面评论令人失望,因为听起来这些评论的作者只是参与过蛇油式的实施,并且从未体验过它真正起作用。 我曾经对 Scrum 感到沮丧,直到我来到一家真正“理解它”的商店。 然后一切都迎刃而解。 看到它在行动中真是太棒了。

回复 ,作者是 Bob Hartman(未验证)

我同意所有宗旨。 这些宗旨可以很容易地融入 Scrum 方法论。 我看到人们从 Scrum 转向 Kanban 是出于一个简单而更实际的原因:Scrum 中的定期会议太多了!

感谢 Ahmad 您的文章并引发了这些有益的讨论。 我同意您想要推广的终点,以及开放式开发的所有积极好处和良好原则。

但这篇文章提出了一些其他的旁枝末节的想法,在我看来需要重新考虑。 我写了这篇博客来讨论这些要点。

http://amr-noaman.blogspot.com.eg/2015/11/is-scrum-and-probably-agile-dead.html

很多人使用敏捷和/或 Scrum 这些术语,却不清楚它们中的任何一个真正是什么。 其中一些人是“蛇油推销员”,但也有同样庞大的商业人士群体声称他们正在采用这些方法,但仅仅是在口头上说说而已。

然后还有一些文章(例如这篇文章)显然对其中一个(或两者)存在根本的误解,然后在其自身的知识错误中使用这些错误来做出负面声明。

Scrum 可能不是您组织最有效的框架。 如果不是,那么恭喜您,因为这意味着您的组织属于 Scrum 尚未被证明能带来好处的 <20% [即 Scrum 对超过 80% 的开发团队来说是对当前框架的改进]。

敏捷 [如敏捷宣言所定义] 是一组 4 个价值陈述和 12 个原则。 如果有*任何人*认为他们有一个场景,这些原则不适用,我将欢迎讨论,因为我还没有发现我支持 Dynamic Concepts Development Corp. 31 年来的任何客户是这种情况。

我欣赏这篇文章,并理解您的出发点,即管理者认为 Scrum 是开发世界方法论的终极目标,结果却只有粗制滥造的代码。 我参与过的最成功的方法论是团队可以自由地根据项目使用多种方法。 Scrum 对于缺陷纠正等短期目标非常有效。 1-2 周的迭代是有道理的。 但对于长期项目,我发现瀑布模型是确保您生产的产品既有质量又有数量的更好方法。 您可以将事物划分为开发阶段和发布阶段,并为每个版本应用不同的目标。 我认为在项目基础上采用方法论的方法更有意义,尤其是在虚拟全球环境中。

感谢您的分享

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
© . All rights reserved.