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 King 的列表 的 12 条提示,来自 Perl Shop

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

讨论

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

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

  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 / Kanban / 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 部门认为自己非常重要的日子,没有他们,业务就无法生存。那时,项目会运行数月而没有交付任何单一功能,而开发人员团队则会就宏大的框架进行智力辩论,这些框架将在一个假设的未来节省数周的努力。这就是为什么有产品负责人的原因。如果开发人员需要时间思考、等待回复、重新思考一些更大的设计,这都没问题。但这不能成为他们为所欲为的借口。这需要与客户或产品负责人以及开发团队讨论。如果相关,产品负责人应在 sprint 评审时或在听到问题时与其他利益相关者讨论。这就是所有营销经理和所有其他人如何将他们的意见输入到产品中的方式。在评审时或通过 PO。开源社区和初创公司可以调整产品的用途。当团队有特定的问题要解决时,需要有人提醒团队,有一个任务要完成。如何构建产品取决于整个产品团队,但构建什么产品取决于产品负责人。每天开始时或前一天结束时的每日计划会议在每个领域都是一个好的做法。建筑工人几十年来一直在进行工具箱会议。如果团队是分散的,那么最好采用追随太阳式交接班,但在每个时区,沟通和计划接下来的一天是行不通的。不要与某些团队所做的汇报和指责的公开处刑相混淆

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

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

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

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

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

> “那时,项目会运行数月而没有交付任何单一功能,而开发人员团队则会就宏大的框架进行智力辩论,这些框架将在一个假设的未来节省数周的努力”

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

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

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

一位“木匠”建造了令人惊叹的家具,按时交付,并取得了扎实的成果,但这并不意味着他们适合建造房屋,甚至夏季露台。

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

我认为您需要雇用一个相信您的使命并愿意与您一起完成使命的团队,而不是为了钱而来的某人,这样您就不必雇用经理和 scrum master 来扮演领导者(在他们不完全理解的事情上)并鞭策团队更加努力地工作。

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

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

回复 作者 Jorge Carvalho (未验证)

这正在变成一篇独立的博文(认真地:http://zxq9.com/archives/1110),所以这里是简要说明,因为我还需要一段时间才能完成修订

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

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

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

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

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

> “Scrum/敏捷是在为客户编写代码的背景下开发的,客户是问题领域的专家,但不了解软件,而开发团队是不了解问题领域的专家,但却是软件专家。”

如果它停留在那个领域,那么我就不会有问题。让它留在服务行业(我不想去的地方,也不鼓励任何人将其用作构建软件的方法)

相反,它被作为一种方法出售给各地的“产品团队”,其中关于“客户”的说法根本不成立,因此反对它所遵循的实践。

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

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

是的,有大量的库、中间件、实用程序等,它们反过来为那些面向用户的软件项目提供动力,因此您对开源世界的假设或接触非常有限。我敢打赌,您使用的许多软件和硬件实际上是由开源驱动的(而不是像您声称的那样处于低级别)

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

很棒的陈述,完全同意。我们现在可以同意 Scrum 可能只适用于代理和咨询服务世界吗?尽管我相信开放开发方法实际上可以极大地造福那个世界,但至少在这一点上达成一致,或许可以将我们从辩论的泥潭中拉出来,专注于软件开发的实际情况,并在所谓的“敏捷崇拜”之外创造更多价值?

回复 作者 Craig Everett (未验证)

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

敏捷和 scrum 就是垃圾。我亲眼目睹了当新所有者将敏捷教条强加给我们时,它摧毁了我自己公司以前的团队环境。

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

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

在我看来,您是在陈述您对完成定义的Requirements。

大家好,感谢大家的回应、问题,甚至不同意见!:)

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

话虽如此,这里有一个重要的点需要澄清,我非常惊讶 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(或其他敏捷工具)不能协同工作。代码质量对于公司/项目可能很重要,在这种情况下,相关任务可以获得优先级并进入 sprint。您还可以创建一个工作流程,任务可以按开发、文档、测试(以任何顺序)进行。

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

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

微软的 Windows 10 开发团队刚刚完全转型为敏捷。它是一个完美地适用于您对跨越“微服务、移动平台以及多屏和无屏设备”的事物描述的产品。

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

> “微软正在拥抱开源”

拥抱开源与采用“开放开发方法论”(不是命名中缺少“源”)无关 :)

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

至于 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 转向看板有一个简单且更实际的原因:Scrum 中的定期会议太多了!

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

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

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

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

然后还有一些文章(例如这篇文章)显然对其中一个(或两个)存在根本性的误解,然后利用他们自己知识中的这些错误来做出负面主张。

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

敏捷 [由宣言定义] 是一组 4 个价值陈述和 12 个原则。如果*任何人*认为他们有一个不适用这些原则的场景,我将欢迎讨论,因为在我支持动态概念开发公司运营 31 年以来,我还没有发现这种情况适用于*任何*客户。

我感谢这篇文章,并理解您所说的,经理们认为 Scrum 是开发世界方法论的终极目标,结果却只有糟糕的代码。我参与过的最成功的方法论是团队可以根据项目自由使用多种方法。Scrum 对于缺陷纠正等短期目标非常有效。1-2 周的 sprint 是有道理的。但对于长期项目,我发现瀑布式是确保您生产的产品既有质量又有数量的更好方法。您可以将事物按开发阶段和发布分段,为每个版本应用不同的目标。我认为在虚拟全球环境中,在项目基础上采用可适应的方法论更有意义。

感谢您的分享

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