软件项目管理的敌人是干的吗？

Question

最基本和被广泛接受的软件开发原则之一是枯燥的(不要重复自己)。很明显，大多数软件项目都需要某种管理。

现在，哪些任务是易于管理的(估计、计划、控制)？对，重复的任务，正是按照干法应该避免的任务。

因此，从项目管理的角度来看，通过复制一些现有代码100次并根据需要对每个副本进行一些小的调整来解决一个任务是很棒的。在任何时候，你都知道你做了多少工作，还剩下多少。所有的经理都会喜欢你。

如果您应用了枯燥的原则，并试图找到一个或多或少消除重复代码的抽象，那么情况就不一样了。通常有很多可能性，你必须做决定，做研究，有创造性。你可能会在更短的时间内想出一个更好的解决方案，但也可能会失败。大多数情况下，你不能真正说出还有多少工作要做。你是项目经理最可怕的噩梦。

我当然是夸大其词，但显然有一个进退两难的局面。我的问题是:什么是决定开发人员是否过度干的标准？我们怎样才能找到一个好的妥协？或者，是否有办法彻底克服这一困境，而不仅仅是通过找到一种妥协？

注意:这个问题是基于与我上一个问题软件开发中的日常工作量及其对评估的影响相同的想法，但我认为它使我的观点更加清晰，很抱歉重复了自己:)。

Answer 1

您似乎认为项目管理的主要目标是产生准确的估计值。事实并非如此。项目管理的主要目标与开发人员相同:为产品所有者提供价值。

从理论上讲，使用大量缓慢的手工过程而不是自动化的产品可能更容易估计(尽管我对此表示怀疑)，但它并没有为客户提供物有所值的服务，因此它只是糟糕的项目管理。没有进退两难的局面。

众所周知，软件项目的评估是困难的，已经编写了大量的书籍，并开发了各种过程来管理它。

如果首相的唯一目标是提供准确的估计，那就很容易了。只要把估计值降到10倍，如果开发人员提前完成游戏，就让他们玩游戏吧。这实际上比你的建议要好，使用复制粘贴忙碌的工作来填补时间，因为玩游戏不会降低产品的可维护性。

但在现实中，产品所有者希望得到有用的评估，并尽可能快速和廉价地交付高质量的产品。这些是PM必须导航的实际约束。

无论如何，我不同意您的假设，即重复的手工工作比自动化的工作更可预测。所有的经验表明，重复的手工工作更容易出错。如果在复制粘贴的代码中发现了错误怎么办？突然，修复错误的成本与重复的数量相乘，这使得不确定性爆炸。

Answer 2

你是对的-复制粘贴工作伟大，当你的任务是生产一个程序复制模板或副本将不必维护或发展在未来。当这两个软件组件有一个完全不同的生命周期时，通过将公共代码重构成一个公共库来将它们耦合到一起，而这个库本身正处于大规模开发中，这确实会对这项工作产生不可预测的影响。另一方面，当在一个程序或程序系统中复制代码部分时，所有这些部分通常都具有相同的生命周期。我将在下面说明这对干燥和项目管理意味着什么。

说真的，有很多这样的程序:例如，电脑游戏产业产生了大量的程序，必须在短时间内最多维护几个月或一年，当这段时间结束后，复制-粘贴旧代码从以前的游戏中的维护周期是超过了，进入一个新游戏的代码库是非常好的，可能会加快速度。

不幸的是，在过去的几年里，我不得不处理的大多数程序的生命周期都与此大不相同。我收到的98%的要求或bug修复请求是对现有程序的更改请求。当您需要更改现有软件中的某些内容时，“项目管理”或计划在您的测试和调试工作非常低时效果最好--如果您在一个地方更改了某个地方，情况就不会如此，但是由于复制粘贴的业务逻辑，您很容易忘记您还需要更改代码库中的其他十几个地方。即使你设法找到了所有这些地方，改变它们的时间(并测试变化)可能要高得多，就好像你只有一个地方可以改变一样。因此，即使是您也可以对更改做出准确的估计，如果成本比所需的高出十几倍，则很容易与项目的预算发生冲突。

TLDR -当你开发一个程序时，当你没有必要或没有责任去修复和维护原版或副本时，请随时复制。但是，如果你、你的团队或你的公司正在或可能变得负责任，只要你能做到，就用干爽的。

示例

作为一个补充，让我解释什么是“错误修复和维护”，以及这如何导致规划的不可预测性，特别是在一个产品内部，通过一个现实世界的例子。我确实在现实中看到过这类事情的发生，可能不是100个实例，但当您只有一个重复的实例时，问题甚至会开始。

任务:为一个应用程序创建100个不同的报告，每个报表看起来非常相似，报告之间有一些需求差异，一些不同的逻辑，但总的来说，差异不大。

获得此任务的开发人员创建第一个任务(假设需要3天)，在完成QA和客户检查后进行一些更改或小错误修复后，它似乎运行良好。然后，他开始通过复制粘贴和修改整个过程来创建下一份报告，然后是下一份，对于每一份新的报告，他平均需要1天。很容易预测，乍一看.

现在，在100份报告“准备好”之后，该程序将进入实际生产，一些问题在QA过程中被忽略了。可能有性能问题，也许报告经常崩溃，也许其他事情不像预期的那样工作。现在，当干法原理被应用时，90%的这些问题可以通过在一个地方改变代码库来解决。但是由于复制粘贴的方法，问题必须解决100次而不是一次。而且，由于已经从一个报表应用到另一个报表，开发人员无法将第一个报表的补丁快速复制到另一个99。他必须查看所有100份报告，阅读它们，将更改翻译成修改后的报告，对其进行测试，或者单独调试每一份报告。对于PM来说，这开始变得非常困难--他当然可以花时间修复一个“常规的”bug (比如说，3个小时)，并将其乘以100，但实际上，这很可能是一个错误的估计，一些修复可能比其他的更容易，其他的可能更难。而且，即使这个估计是正确的，调试的成本是他们所需要的100倍，你的公司将花费很多钱。

下次当客户要求更改所有这些报表中的公司徽标颜色，使页面大小可配置，或通过其他以类似方式影响所有报表的新要求时，也会发生同样的情况。因此，如果发生这种情况，您可以对成本进行估算，并向客户支付100倍于代码干涸时必须支付的价格。然而，尝试这几次，然后客户将取消该项目，因为他可能不愿意支付您昂贵的演变成本。也许在那个时候，有人会问为什么会发生这种情况，并用手指指着那个决定复制粘贴程序的人。

我的观点是:当你为他人生产软件时，你至少在很短的一段时间内就有责任让它工作，修复错误，使程序适应不断变化的需求等等。即使是在绿色领域的项目中，这些部分也会比最初计划的开发工作量更大。特别是当你所有的复制粘贴代码都在一个产品中的时候，所有部分的责任时间都是一样的，这与你从一个不再处于主动维护状态的死项目中复制粘贴一些旧代码的情况完全不同。

Answer 3

因此，从项目管理的角度来看，通过复制一些现有代码100次并根据需要对每个副本进行一些小的调整来解决一个任务是很棒的。在任何时候，你都知道你做了多少工作，还剩下多少。所有的经理都会喜欢你。

基本断言是不正确的。

让软件有别于其他职业的是，你每天都在做一些新的东西。毕竟，没有一个客户会付钱给你去建造别人已经做过的东西。项目经理可能喜欢可预见性，但他们的老板喜欢价值。如果你只是复制粘贴代码，稍有变化，你就没有为公司提供太多的价值。

最终，公司会意识到，只要雇佣一名优秀的程序员，他们就能在一小部分时间内完成同样的工作。如果他们不这样做，他们的竞争对手就会。