我刚开始在Scrum工作，似乎缺少了一些东西。我是Scrum的新手

该代码是经典ASP / ASP.NET组合的完整混乱。混乱包括我们修补大混乱或对其进行补充。我们都太忙了，无法开始重写，所以我想知道。

Scrum中哪一部分可以让开发人员有能力说足够就够了，并要求他们有时间开始大型重写？我们似乎无休止地循环使用“ Stories”修补旧代码。

因此，事情似乎由非技术人员执行，他们似乎不希望推动重写，因为他们不了解代码库的糟糕程度。

那么谁来负责进行这种大的重写更改呢？开发人员？Scrum Master？

目前的策略只是为了找到时间，去做自己不参与上级领导，因为他们大多归咎于当前的混乱我们是在.. <-关于非技术人员告诉技术人员在这里做什么插入咆哮->。

我不知道为什么这对人们这么难。他的商业案例就在这里：

We seem in an endless loop of just patching old code with 'Stories'.

开发人员时间就是金钱。很多钱。我离开一家公司，该公司计划在一年前修改其用户界面，希望采用scrum可以帮助他们停止旋转。发生了什么？相同OL'相同OL'。他们继续使用新功能，尽管由于基础代码库完全是过时的混乱，即使每次编写的代码都变得毫无意义，但“技术负担”却没有商业案例。自从我离开以来，他们的前端并没有发生任何变化，而我之所以被带去是为了彻底改造它。在那的两个月里，我实际上并没有碰过一点CSS或JavaScript。我只是搞砸了HTML和1990年代后期的一些古老Java模板系统。

我的答案？尽您所能，但是如果其他开发人员已经放弃并且为达到冲刺目标而工作很晚，而不是主张更实际的截止日期，并坚持认为技术债务实际上是一个阻碍性的问题，那就承担最坏的情况并开始寻找新工作现在。您的开发人员无法或不允许他们表达他们的担忧，或者业务太短了！

从长远来看，忽略这些问题总是要付出更多的代价。不多一点，但是更多。这不仅会牵扯到开发时间，而且会不可避免地减少您的人才水平，因为更了解并且拥有其他选择的开发人员将避免像瘟疫一样困扰您的公司。我目前的老板是开发商和公司所有者。我们不会重写某些东西，而只专注于其他优先级，但是当某些东西由于始终如一的时间消耗而确实需要重构时，它将得到适当的重构。结果很明显。由于多种因素，修改和添加新内容变得更加容易和快捷。如果采用适当的体系结构，曾经可能要花费数小时才能完成的工作可能需要花费几分钟。企业不喜欢听到它，但是为此值得搁置。

Scrum在开发人员没有太多影响力的环境中是失败的，IMO，因为对于业务类型来说，太容易想忽略维护和更新，而在需要时可以将其放在“成功计划”列表中的要点表示出来评估时间到了。他们将始终偏爱他们的生皮和晋升潜力，以期长期受益，即使它一贯地咬他们的屁股而忽略了这些问题。

Scrum还是一个以利润为动力的行业。公司为培训Scrum付出了很多钱。希望采用的人应该谨慎对待被推向谁，以及在给定的文化中它将变得多么现实。

无论如何，如果您实际上对开发一无所知，那么糟糕的代码库，含糊不清的管理以及没有尖刺的开发人员都是痛苦的秘诀，而在任何有用的方面，这种环境都几乎无法提高您的技能。在您真正发现您为解决该问题而付出的努力是否真正得到回报之前，请立即开始对GTFO采取行动。

如果您确实要做Scrum，我对此表示怀疑，那么产品负责人将负责决定重写。多数情况下，重写不是一个好主意，顺便说一句，因为它不会产生任何新功能，只会引入新的错误。

http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky
http://www.joelonsoftware.com/articles/fog0000000069.html

扩展“重写不是一个好主意”：

尝试逐步改进几乎总是更好。就像Jarrod Robertson在评论中写道的那样，找到需要改进的模块，成为该模块的专家，并为下一个冲刺编写一个故事，以改进该特定模块。向产品负责人解释为什么该模块需要工作。

我真的会变得直率...

• 您负责这项工作中的开发人员吗？
• 您是项目负责人吗？
• 开发人员在项目中持有多少“权益”？
• 您进行改写的业务理由是什么？
• 使它完全无用且不可恢复的代码库又是什么呢？

您已经说过您刚刚开始工作，但您似乎已经掌握了那里的情况。也许我误解了您提出问题的意图，但是我给您的印象是，您进入工作后会遇到许多问题，并且您已经得出了最简单的结论，在该结论中代码被破坏了，唯一的出路是重写，但是您是否真的考虑过雇主为此付出的代价？

使用任何现有的代码库-无论状态如何恶劣-所有者通常都会在代码所代表的产品上投入可观的投资。代码库既有直接成本也有间接成本，而作为软件开发人员，重写通常是您要做的最后一件事，因为这样会使您的代码资产贬值，从而使您之前的所有工作获得较低的回报。努力。

以Window的操作系统为例。创建了每个新版本后，就会有大量代码从上一版本继承而来。有时，整个库和API会被拖到几代OS中。为什么？因为开发人员知道这些元素可以正常工作，已经过测试，已经过修补和修复以防止安全和内存问题，并且因为进入该状态花费了很多钱。没有人愿意在赚钱的时候就抛弃工作代码，即使维护成本相对较高，从头开始的成本也始终会更高，在像微软这样的公司中，他们有数十亿美元在银行如果愿意，允许他们从头开始，但他们不愿意 t因为他们想最大化他们的投资回报。您的雇主与Microsoft没什么不同，除了有数十亿美元的现金可用于项目。

因此，代码是一团糟，听起来公司的各个部门之间存在沟通和边界问题。您或您的同事可以做什么？

一种选择是像团队一样继续前进，并希望将来有奇迹。可能不是一个好主意，可能只会增加您的挫败感和压力。

更好的选择是简单地完成工作，但在此过程中，它会寻找机会添加测试以支持那些看起来最脆弱的代码区域，然后对其进行重构，直到它们变得更稳定为止。您可以轻松地进行有说服力的论点以提高公司的投资，而不是简单地将其全部抛弃。

一个更好的选择是组织一个团队，并确保您有足够的资历来陪伴某个人，使他们成为一个很好的案例，使团队可以更有弹性地安排时间来改进代码库。我不在乎公司有多忙，或者时间表看起来多么僵硬，总是会有偶尔的“残酷”活动可以用来挤压一两个改进。但是，如果可以在完成其他任务的同时进行改进，那就更好了。如果是我，我很乐意与一位经理合作，并在软件开发人员阅读的一些规范书籍中向他们介绍概念。 清洁代码可能是您的团队最需要的那个。播下一些有关如何改进代码的种子，并提供一些您所要表达的示例。一个好的经理将看到为代码增加增量改进的价值，特别是如果您能够描述技术债务的概念。帮助您的团队负责人或经理为改进代码提出良好的业务案例，他们会更有动力对此采取行动。

仅仅说“代码不整洁”还不够。您需要鼓励您的同事一直练习干净的编码，并使用干净的编码技术来鼓励您在整理时进行一些整理。每当我从事新工作时，我都会打印出一张小海报，然后从办公室墙上挂下来。它说：“始终努力使代码比您发现的代码更漂亮”。在它旁边，我添加了另一个，上面写着“百合不需要镀金”。他们俩都提醒我，我应该始终尝试改善发现的问题，但要避免简单地将一个问题和另一个问题镀金。大规模重写通常是最糟糕的“镀金”操作，因为它们常常是出于错误的原因进行的。在某个时候肯定可以使用全新的产品版本，

这是官方Scrum指南中Scrum开发团队的正式定义。我重点介绍与您直接相关的部分：

开发团队由专业人士组成，他们负责在每个Sprint的末尾交付可能发布的“完成”产品增量。只有开发团队的成员才能创建增量。开发团队由组织架构和授权，以组织和管理自己的工作。由此产生的协同作用可以优化开发团队的整体效率和效力。开发团队具有以下特点：

• 他们是自组织的。没有人（甚至不是Scrum Master）告诉开发团队如何将产品待办事项转换为潜在可发布功能的增量。

• 开发团队是跨职能的，具有创建产品增量所需的全部技能。

• 除开发人员外，Scrum不认可开发团队成员的头衔，无论该人正在执行的工作如何；这条规定没有例外;

• 各个开发团队成员可能具有专业技能和重点领域，但是问责制属于整个开发团队；和，

• 开发团队不包含专门用于特定领域的子团队，例如测试或业务分析。

因此，开发团队应对自己的混乱情况负责，应自行解决，而不必问团队以外的任何人。

在以后的每个估算中都包括技术债务修复时间，并确保提供的软件质量是一流的。

如果确实需要完全重写，则必须在Scrum Restrospective中解决该问题。产品负责人最终可能会取消该项目并开始一个新的项目。产品负责人也是唯一可以取消冲刺的人。

正如您所描述的，我不得不说我认为与SCRUM没有任何关系，或者您的产品开发团队目前是一个问题。

这个是正常的

您所描述的是代码库的正常熵。在您的情况下，团队可能离理想还差得远，但是仍然每个代码库最终都变成了泥泞的大球。

在一个完全完美的 绿地情况下，所有你能做的就是开始从绝对熵和移动更远朝它慢。

我同意其他人的观点，代码库混乱是由于开发人员造成的。我确信它早于SCRUM的采用就已经很多年了。

这不是技术或开发人员的决定，而是业务决定。

您不知道为什么产品所有者不希望重写。您作为开发人员认为这是必需的，但是确实有任何商业案例吗？

如果存在真实的业务案例，则不仅挥舞着手；“代码是我想要开始的新旧烂摊子，因为那是我想要的”，然后考虑到该投资的回报，管理层将承担重新编写的费用。

您没有给出一个可靠的业务案例来进行重写，只是对您对其他人如何造成此混乱的意见感到之以鼻，并且您不想处理它。

证明-利润促使业务决策放弃可用的软件，而不是某些OCD需要干净的代码库

如果你能真正表现出的证明，不只是理论，但很难证明是花X美元在绿地重写将保证让 X * N以美元为业务Y的时间框架（其中N高，Y短），你可能会得到管理层一定的牵引力。您可以提出和证明的情况极不可能。

否则，您只需要处理它，这就是现实。与您坚定的断言相反，如果没有这种完美无瑕的重写，绝对没有前进的方向，我敢打赌，您抱怨的代码库从现在起5年后仍将继续工作并在某个地方运行，并在很长一段时间后为某人提供功能和价值你已经离开公司了。

人们通常要求“大笔重写”时，我通常会持怀疑态度。在某些情况下，绝对有一定道理，但在大多数情况下，遗留代码具有价值（因为它已经在生产中，并且被用于启发其创建的目的）。在许多情况下，执行大型重写与敏捷相反。将新版本的应用程序带到可以有效替换现有应用程序的时间。

我更喜欢的方法是马丁•福勒（Martin Fowler）所说的扼杀藤蔓。使用新方法实现新功能（包括对现有功能的更改），但将现有应用程序用作可以扩展新功能的网格。这为您提供了两全其美的优势，在进行大量重写时，您不必停止所有工作，但是您可以受益于编写利用更新框架的新代码的好处。这绝对比开始清理工作更困难，并且可能不那么性感，但是与为已存在的所有内容进行废弃相比，它为企业提供了更多的价值，因为它已经过时了。

我将在哪里以及我们的工作方式是：写一个新故事并将其交给产品负责人，然后由产品负责人决定如何确定优先级。一个例子是：“作为产品X的开发人员，我想在这一领域重新编写代码，以便将来的开发更加有效。”那么，接受标准就必须遵循以下原则：重写/重构x这样就更好了。

我不知道您的情况，但是如果我们要从头开始，那就是与产品负责人坐下来并说服他们为什么这样做，然后写一堆故事来重新创建现有案例的情况。功能。

我们尝试处理不良代码和/或遗留代码的其他工作是包括在分配用户故事时用于重做的任务。

决定进行大笔改写是一项商业决策。您可以通过将自己的观点卖给负责事物业务部分的人员来尝试影响业务决策。

然而; 从一次迭代到下一次迭代的代码质量变化是开发人员的决定。如果您允许代码质量下降，那么您正在增加技术负担，以便现在满足产品所有者的期望。您可以做的是开始对编写的代码负责，并确保它改善了代码库，而不是相反。现在，这意味着您将失去速度，因为您一直在减少技术债务，并且您的产品所有者一定会失望的。您可以尝试解释一下，您急于让代码质量下降，并且现在正在采取措施纠正此问题。

现在，我意识到这是一个可怕的步骤，可能会很想将其再延迟一次，因此您可以在重要的截止日期之前退出功能X。不幸的是，等待时间越长，难度就越大。

顺便说一下，这绝对不是Scrum的问题，我也不建议针对Scrum的解决方案。这与开发人员拥有代码所有权有关。

开发人员有责任就代码库的当前状态向世界发出警报。这可能发生在每日例会，回顾或非正式场合。这看起来似乎很明显，但是如果您不清楚表达混乱是什么，并因此浪费了多少时间，那么没人会注意到。Scrum Master通常负责将信息传递给PO和负责项目的人员，并说服他们需要做的事情，然后促进团队实施解决方案。

附带说明，IMO不一定是对此类问题的正确答案。但是，如果开发人员对当前的代码库感到厌倦，则朝着更整洁的体系结构迈出可衡量的小步通常是一个更好的主意，因为您可以看到进度，通过定期向PO展示成果来证明工作合理性，并继续实施新用户故事平行进行，而不是在无休止的资源垄断改头换面中迷路。

您问：

Scrum中哪一部分可以让开发人员有能力说足够就够了，并要求他们有时间开始大型重写？我们似乎无休止地循环使用“ Stories”来修补旧代码。因此，事情由非技术人员执行，他们似乎不希望推动重写，因为他们不了解代码库的糟糕程度。

作为既是经理又是开发人员的人，对您问题的最简单答案是，Scrum或任何其他方法论都不存在，或者在任何业务场景中，开发人员都有权说足够就够了，并且要求改写。这里的许多人提出了很好的，有效的论据，以解释为什么重写通常是个坏主意，并解释了如何以及应该如何以渐进的，敏捷的方式实现变更。我都同意。

但底线更简单。永远不要做出这个决定。您是员工，而您真正要做出的唯一决定是“我会继续为这些工作工作还是找一份担心我疯狂的技能的新工作？” 您的新工作也不允许您做出决定，但是至少您会感到自己在命运中掌控自己。

我感到您很痛苦，但不确定与Scrum有什么关系。是否重写代码的决定与开发过程无关。

等等...什么？

你在打补丁吗？您应该进行重构。坚持敏捷的价值观。使用TDD和适当的做法，情况最终会变得更好。