如何使管理脱离我们的开发流程

我是软件开发团队的一名软件工程师。最近三年，我们为内部客户开发了新产品。现在该产品完成了，我们将为现有产品开发主要的新功能。对于特定功能，产品管理人员猜测开发需要150个小时。我们与项目经理一起制定了非常详细的计划，我们花了300个小时努力。昨天我们讨论了这个问题，他们认为我们已经严重高估了事情。

在我们的计划中，我们估算了编写单元测试的时间，其目的是丢弃它们以节省时间。尚未做出决定，如有需要，我将捍卫这一计划和单元测试。但是我在这里真正不喜欢的是管理正在干扰我们的开发过程。如何使它们脱离我们的开发流程？我可以使用哪些参数来保持单元测试到位（除了质量和长期节省时间之外）？

附带说明一下，我们公司有3个工程团队，我所在的团队按时交付了他们的软件（给予或获得10％的利润）。而其他团队总是迟交，这主要是由于对计划的低估。他们只计划编码，而不计划编码的管理，测试和处理。

首先，我要完全赞同你的立场。当您对业务的不同部分之间缺乏了解或沟通中断时，可能会感到沮丧。话虽如此，我认为您不应该尝试将它们排除在外。相反，您应该向他们显示有关为什么这是一个好主意的数字。您有什么事实证明值得进行的单元测试值得您付出努力？如果没有，那么您应该开始收集这些数字，或者进行一些研究以支持您的主张。

我本人必须处理类似的情况，我在类似的话题上回答了这个问题。我还在这里写了关于如何处理它的博客：

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

如果您不想进行链接追逐，我将重复相关问题的摘要：

总而言之，我将估算的工时与项目的实际工时进行了比较，然后将缺陷率与其他团队的缺陷率进行了比较。在我们的案例中，这些数字相比而言是有利的，没有更多的担忧了。

根据此经验得出的结论是：

...说服任何人相信您做某事的方法既实用又务实的最佳方法是做到这一点，并与其他方法进行比较。人们不在乎教条，也不在乎为什么您认为某事应该是最好的方法。只有向人们展示数字并衡量您的方法的有效性，您才能真正证明您的实践是有效的。

如果您的管理团队不同意将他们认为额外的150小时用于单元测试，那么您可以说服他们在产品的一小部分上进行投资（甚至同意自己花更多的时间来提供一些数据） ）。然后在产品的该一个区域中进行单元测试，然后收集有关该产品的该区域中的缺陷率以及与产品其他区域中的缺陷率相比查找和修复那些缺陷的成本的数据。希望您会收集一些数据来备份您的案子，这对您的下一个项目将不是问题。

无论使用哪种方法，遵循的第一条规则是

1. 开发人员应有权估计自己的工作。
2. 利益相关者应有权优先进行这项工作。

一旦双方都承担起自己的责任，估计和优先排序便是很好地协同工作的两种力量。因此，与其浪费时间争论，不如就此达成共识，并尊重双方将尽其所能进行工作。

您可能会指出，单元测试可以节省时间，因此，如果删除它们，估计会花费500个小时。

告诉他们技术债务和单元测试的价值

从一些关于技术债务的好主意看一下这篇文章。通过该帖子的后续操作，您可以获取以下pdf文件

我喜欢这篇关于单元测试价值的文章（可能还有更多的发现）

希望不是让他们脱离您的开发过程，而是让他们以正确的方式参与并作出正确的承诺。

恕我直言，您需要写下您的原始计划，并添加第1章和第2章（不在附录中），在其中解释技术债务和单元测试的价值。给他们替代方案：

• 较少的时间（不是整个150小时，这听起来很荒谬），平均每个变更（在开发阶段和维护期间）将花费：
  • 小4小时
  • 中16小时
  • 40小时
• 您估计的平均更改（开发阶段和维护期间）所需的时间：
  • 小2小时
  • 中8小时
  • 20小时

（时间仅是指示性的。您可以更好地进行正确的估算。）

不要忘记为预算内按时交货添加跟踪记录。

写下来，并与他们讨论。他们可能在功能上有一些有价值的要点，这些功能现在不需要，或者他们愿意承担一些技术责任以按时交付。只要确保这些是有意识的选择。

希望这会有所帮助，并祝你好运。

首先，不要将“编写单元测试”分解为一个单独的任务，以进行估计，计划和削减。您的估算应为“实施XYZ-18小时”功能级别。这18个小时应该包括您将过程中的功能进行“完成”所需的时间，包括“编写单元测试”。

这是“脱离开发过程”进行非技术开发的一种好方法。不要在您给他们的任务列表或项目进度表中包括您的开发过程！

其次，听起来您的团队已经在按时为他们提供优质的产品，而其他团队却没有。也许这个管理团队已经习惯于对那些团队进行微观管理。发挥自己的优势-提议每周或每两周向他们展示具有工作功能的更新，它们将使您对“开发过程”有所了解。

我曾经处于一个处于非常良好状态的代码库的情况。在很短的时间内就需要一个具有挑战性的新功能，而我设法在很短的时间内交付了该功能。那时，代码库处于更加糟糕的状态。因此功能已交付，但我的工作尚未完成：我必须将所有内容恢复为同样良好的状态。

我向经理解释了两个层次，就像这样：就像在家里做油漆工作。如果所有工具都在其中且状态良好，已清理所有刷子等，则可以非常快速地完成油漆工作。但是随后，您必须花时间将所有工具放回原处。如果您不这样做，那么您的下一个绘画工作将花费更长的时间。实际上，您将不记得您的工具在哪里，您的油漆刷也无法再打捞，并且这将花费您更多的时间和金钱，就好像您立即完成了清理工作一样。

编程工作中也是如此：通过清理，我使代码库进入一种状态，在下次需要它时，我可以非常快速地再次交付某些内容。如果没有，那么下次将花费更长的时间。

您无法将它们完全排除在您的流程之外，毕竟他们会支付您的工资并且他们将使用您的产品（如果不是直接使用，则可能是您公司中的某个人是最终用户）。

根据我的经验，经理们指责开发人员过高地估计时间是很常见的情况，如果不加以处理，可能会导致一场相当愚蠢的军备竞赛，在此情况下，您下一次估计会翻倍，因为您知道老板会将他们减半，他们知道他们将它们四等分，所以将它们等四倍等等。如果可能，您需要避免这种恶性循环。

假设没有截止日期的“落空”原因，那么我建议两件事。

1. 坚持您当前的高质量工作方法，为您提供150个小时内可以做的事情的详细计划。准确枚举在此时间范围内可以交付的内容。KeesDijk的答案在细粒度的规划上有一些很好的联系。
2. 以相同的详细计划样式进行工作，以涵盖所有功能并显示将花费300个小时（或得出的任何数字）。

然后开始工作，并定期报告进度，如果可能，应定期提供一些可交付成果。这应该使管理层对您的估计技能和交付能力充满信心。

要求他们提供估计的依据。讨论差异只是公平的。放弃单元测试是一种虚假的节约，您不用花时间编写单元测试，而以后会在调试器中使用（甚至更长）。本质上，您已经记录了计划对完成的工作进行测试的事实。他们告诉你不要测试在所有。在开发项目时，无论是使用单元测试还是临时测试进行测试，您仍然需要考虑这一时间。删除分配给单元测试的时间也将删除分配给临时测试的时间。

底线：坚持估计。您的往绩记录表明您知道自己在说什么，并且可以就估计的依据（假设，期望，过去的表现等）给出合理的答案。似乎您的高层管理人员没有他们需要创建合理估计的可见性。他们是否假设每天8小时都不会中断会议？他们是否在预算中预算用于系统测试？考虑到您的往绩，他们如何得出您一半的数字？

我估计这将需要300个小时，如果他们的预算为150，则可以选择是急于完成工作还是要延迟交付。项目完成后，如您所愿，就可以告诉他们您所要的内容。

沃利会做什么？

有多种方法可以解释管理层对您的要求，一种是他们不希望您按时交货。

看起来很荒谬？是的，但是他们又怎么能知道您没有高估呢？不要按时完成任务（必要时要放松一下），如果您滑倒并意外地准时交付东西，请确保看起来真的很累，以免给人以公园散步的印象。

你在泡菜 如果您坚持使用枪支并希望坚持进行单元测试，并希望获得300个小时的服务时间，那么您将成为敌人。

如果将时间减少到150小时并进行卡盘单元测试，则可以更快地交付功能更佳的产品，但这会带来麻烦，并增加维护成本。

不管怎样，你输了。

大概是这样。

你看，你不是在大学里经营科学实验室。您正在向公司的业务部门提供业务服务，该公司向公司生态系统中的客户提供服务。您的公司可能需要您的产品才能开始向其客户提供更快更好的服务，从而增加所需的收入。

您会看到，您需要的是投资回报率分析，并且您没有所有数据可以进行该分析。您只有一部分成本（您不知道每个人的工资单编号），并且您当然没有收入部分，尤其是没有收入预测。

无论您信不信，您的管理层都擅长做出ROI预测（这是他们在商学院中所教的内容），并且可能已经运行了多个ROI预测并提出了“如果我们现在就采取行动，我们将获得更多的收益，甚至支付三倍于IT部门抱怨的软件维护费用。”

因此，如果您想进行联合经营，请创建自己的公司。您会发现，这并不容易。

换句话说：按照提示进行操作。如果管理层知道自己在做什么，那么您会领先一步。如果没有，那么您就失业了，是否需要进行单元测试。

您问什么投资回报率？投资回报。不过这是一个坏名字。它必须是及时的投资回报率（ROTI），因为时机是投资中的一切。