SCRUM 和遗留/高度耦合的代码 [关闭]答案

【问题标题】：SCRUM and legacy/highly coupled code [closed]SCRUM 和遗留/高度耦合的代码 [关闭]
【发布时间】：2015-03-31 19:09:20
【问题描述】：

我的公司坚持将 SCRUM 作为一种开发流程来维护和扩展我们的代码库。

我们的代码库没有文档记录，采用多种技术编写且高度耦合（无处不在的全局变量、过程 javascript php 代码以及后端大约 800 个 Oracle PL-SQL 存储过程、没有对象、隐藏的假设等）。当然没有单元测试。

此外，开发团队是新人，对现有代码几乎没有经验，而且绝对不是跨职能的，因为他们每个人都具有特定的技术知识（例如 javascript 但没有 PL-SQL）。

几个月前，当我们第一次尝试引入 SCRUM 时，我们惨遭失败

没有人愿意给出估计，因为他们不了解代码
编写单元测试是不可能的，因为添加单元测试需要更改，因为代码库需要几个月的重构
设置合适的测试环境本身也是一项巨大的工作（收集测试数据等）
没有人想尝试更改属于“外来”技术的代码（例如，SQL 人员接触 php 部分）。

另一方面，用户故事确实以可用的形式出现，我们有一个相当好的流程来写下并向开发团队解释需求。

鉴于上述情况，我认为 SCRUM 可能不是最好的前进方式。但是，我想看看是否有人计划提出如何在这样的环境中使用 SCRUM。

【问题讨论】：

如何使用 SCRUM 特别是遗留代码库的问题？该问题与您选择的项目管理理念有何关系？
我的理解是 SCRUM 要求在 sprint 结束时有经过测试的用户故事实现。鉴于目前的代码库不支持单元测试（这就是我称之为遗留代码的原因），问题是我们是否可以采用 SCRUM。我们要么花太多时间重构要进行单元测试的代码，要么交付未经单元测试的用户故事。
还有其他类型的测试可以在不容易进行单元测试的系统上完成。有很多可用的集成测试框架。 Michael Feathers 的“有效处理遗留代码”可能也是一本好书。
谢谢。我读过这本书，但我发现其中的大多数技术都不能应用于编写糟糕、高度耦合的 PL/SQL 代码。其中很多是针对 OO 代码的，而关于摆脱全局变量的说法很少。然而，问题不在于如何重构遗留代码以对其进行单元测试，而是在请求对遗留代码进行更改时是否可以应用 SCRUM，而这些遗留代码不太符合“实施一点，测试一点，重复”的理念
您列出了采用 Scrum 的一些障碍，但它们似乎都与您的代码库有关，与流程无关。

标签： scrum legacy coupling

【解决方案1】：

Scrum 是一种产品开发框架/方法。你的代码是好是坏并不重要。或者即使有关于这件事的代码。您可以使用 scrum 方法来写一本书（this book 实际上是使用 scrum 制作的）。

您上次失败的原因是 scrum 没有正确实施。通常在介绍 scrum 时，它并没有 100% 实施到书中。

Scrum 是一个框架，因此人们无法真正按照自己喜欢的方式挑选和更改它。就好像您在下棋，但更改了一些规则以使游戏对自己更容易。它不是那样工作的。

从技术上讲，估算、单元测试和用户故事不是 Scrum 的一部分。然而，它们通常与 scrum 一起使用，因为它们是有用的工具。 scrum的核心描述here和总结here和here。

为了成功实施，贵公司需要至少派一名人员参加认证 ScrumMaster® 课程或聘请 Scrum 教练。

如果实施得当，scrum 可能会提高您的产品质量。 Scrum 是现代产品开发（尤其是软件开发）框架。不能保证 scrum 会解决您的问题，但majority of organisations 使用 scrum 进行软件开发是有原因的。

【讨论】：

【解决方案2】：

认证表明你遵循了课程，而不是你擅长你所做的事情~~有趣:)~~
您的 Scrum 解决方案：
步骤 1. 建立多功能团队，每个团队的专业尽可能多样化。引入“结对编程”，让人们互相学习...
第 2 步。将您的“代码库”视为一个新的大型项目！您的 Scrum 团队开始以模块的形式处理它：一次一个切片。
第 3 步。组织每个模块以包含“代码库”中的一个应用程序并处理它：初始评估、冲刺计划、产品待办事项等 - Scrum！
您的 XP 解决方案：
第 1 步。带上 XP 教练来培训您的员工！几天的强化训练可以让你从它开始（与正确的教练一起）。您将拥有跨职能团队、结对编程、持续迭代等。
第 2 步。将您的“代码库”视为一个新的大型项目！您的 XP 团队开始以模块的形式处理它：一次一个切片。（敏捷，我爱你！）
第 3 步。在前三个月让教练随时待命……您将需要他！
享受吧！

【讨论】：

非常感谢您的回答。但是，我认为您重新执行了我最初的想法。具体来说，我认为 SCRUM 无法应用，因为：无法执行第 1 步（团队不是我所说的多功能团队），无法执行第 3 步（高度耦合的代码不允许组织包含我们的一个应用程序的模块）代码库）。我错过了什么吗？
在不知道你的工作环境和项目的最私密细节的情况下，我真的不能说 Scrum 或 XP 或 RUP 或 DSDM 或任何其他敏捷或瀑布方法是否能在你的情况。我要说的是，我的答案中给出的步骤是 AGILE 环境中的逻辑步骤！如果您（作为公司或技术团队）不想要或不能采用它们，这就是您手中的东西。
敏捷让您无论是作为公司还是作为个人都变得灵活——如果您的公司和团队的最大利益是学习更多的语言，而不是作为敏捷从业者，那么您就去追求它。结对编程存在的主要原因之一是技能交流（除了沟通和双重关注 - 一个人负责代码，另一个人负责正在进行的工作的整体形象......）。
很可能，考虑到您必须处理其他人编写的代码这一事实，您会发现最好的方法是分解代码：您可能会处理“模块” ，在某些情况下集成新的东西，在其他情况下重新设计等。在我看来，这听起来像是迭代开发。您的编码员必须学习新技能才能提高效率...如果您愿意，我们可以在您有时间的时候讨论一下。
感谢您的回答。由于我看到这很快就会进入扩展讨论而不是明确的答案，我认为应该关闭这个问题（并且可能会转移到其他地方的论坛）。