作者： Mike Cohn
译者：李洁（Jerry Li）
团队通常很难说服其产品负责人给他们时间做重构，特别是重构工作量较大的时侯。在本文中，我想分享一个四步框架——团队可以用于证明重构的合理性，并说服其产品负责人允许进行重构。
什么是重构？
首先，让我们明确重构的含义。重构是指：在不改变代码外在行为的前提下，优化代码的结构。这就意味着，团队不会将重构用于修复bug，因为修复bug需要改变代码的外在行为。
然而，团队却可以通过重构来防止产生更多的bug。实际上，防止将来出现问题是实施重构的最常见原因之一。
例如，团队遇到了产品某部分代码bug过多的问题。团队想要对该代码做个“清理”（重构），以便将来再访问该代码时，程序不会如此脆弱。
然后，您就能明白：在优化代码结构而非行为时，为何产品负责人会难以理解和优先安排重构工作。“如果没坏，就不要动”的心态，正在占主导。
评估不重构的成本
当产品负责人不愿意对重构开绿灯时，我发现开发团队最好用产品负责人的语言来表达其观点。也就是说，给出重构在经济上的正当理由。
为此，我建议采用以下四个步骤：
1.估计现状（不重构）会造成的影响
2.估计实施重构所需的工作量
3.估计重构后能节省多少时间
4.估计投资回收期
遵循这些步骤，能使团队将他们的重构项以经济视角提交给产品负责人。例如，他们提出一个重构项时可以这样说——“我们认为这个重构将会花费1/3个迭代，但只需五个迭代就可以回收投资”。当以这种方式来描述重构时，产品负责人对是否投资重构就能更容易地作出决策。
步骤1：估计现状（不重构）会造成的影响
第一步是估计代码保持现状会造成的影响——也就是——不重构的成本。
要做到这一点，需要针对您想重构的代码，收集在此代码上进行缺陷分析、修改和验证所花费的时间。当拿不到实际数据时，可以进行有根据的猜测。
如果确实需要猜测，我建议您进行保守猜测，避免为了重构而夸大事实。这样团队能更加确信：他们是真地在推荐一个明智的选择，而非仅仅出于喜好。
否则，当他们因过度承诺技术工作（例如重构）的好处而出名，团队未来再兜售类似技术工作的好处时会变得很艰难。
一个案例
让我们来看一个混合应用实际数据和团队凭经验猜测数据的案例——我发现这种情况是最常见的。
在本案例中，我们的团队深挖了产品待办列表或缺陷跟踪软件，以确定系统中某特定功能域到底报告了多少个bug。他们决定查看前六个双周迭代的数据（约三个月）。我发现在使用更多数据和花更多时间进行分析之间，三个月是一个很好的折衷方案。
通过查看前六个迭代中执行的工作，团队确定这段时间共修复了12个bug。其中8个被归类为“高”严重级别，4个为“中”严重级别。此外还有3个严重级别为“低”的缺陷没有被修复。
这就是所有的数据。如果团队在过程中记录了修复这些bug的实际工作量，那么就使用它。然而，很多团队并不会记录这些数据，那就可能需要对缺陷修复花费的时间进行猜测。这是OK的。正如你将看到的，数据并不需要太完美。
我们不妨假设：我们的团队估计修复每个“高”严重级别的bug需要花12个小时，其中包括了bug分析、编码、测试以及任何其它用于讨论或记录解决方案的时间。
接下来，团队猜测：每个“中”严重等级的bug花了一半时间，也就是 6个小时/个。
综合起来，我们的团队在过去三个月里共花了120（ 8*12 + 4*6 = 120）个小时来修复bug。
那怎么处理未修复的bug？
别忘了，还有三个“低”严重级别的bug被报告而又没有修复。处理这些bug，需要打个电话来判断。
如果产品负责人确实真心希望修复这些bug而又没能够做到，那么就要把修复它们的估计值也包括在内。反之，如果团队对“低”严重级别的定义是：这些缺陷微不足道和无需修复，那么就可以将其排除在计算之外。
为何我建议采用小时而非故事点？
我建议在计算中使用小时，因为大多数团队都不会以故事点来度量缺陷。但是，如果您的团队确实是使用故事点来估计缺陷的，那么不妨在计算中使用故事点。不过在本文中，我会继续使用小时。除了单位差异外，分析上不会有任何不同之处。
步骤2：估计重构的工作量
说服产品负责人优先安排重构的第二步准备工作是：估计实施重构所需的工作量。
要做到这一点，团队成员应该像估计任何其他产品待办项一样估计重构项。这就意味着，要以故事点或小时来进行估计。
然后，团队需要把此估计值的单位转化为与步骤1一致，即估计不重构会造成的影响时采用的单位。
我们不妨假设：我们的团队有一个对某不良代码进行重构的产品待办项。我建议他们开一个类似于小型迭代计划的会议，讨论重构预计会有哪些工作。
例如，他们可能会认为只需要进行编码和测试。但为更好地理解工作，他们将其拆分为3个编码任务和2个测试任务。每项任务都进行了快速而粗略的估计——再次重申“数据无需完美”。在我们的例子中，假设：总共为40个小时。
步骤3：估计重构后将会节省多少时间
在我们四个步骤的第三步中，团队要估计重构完成后将会节省多少时间。这通常仍然会是实际数据和有根据猜测的结合。
为了搞清楚如何做到这一点，让我们再次回到我们的案例。在第一步中，我们的团队查找了数据，确定在前六个迭代中他们修复了12个缺陷（8个“高”严重级别、4个“中”严重级别）。他们估计共花了120个小时来修正这些缺陷。
这意味着团队平均每个迭代花了20小时（120÷6=20）来解决他们想重构代码中的缺陷。
在大多数情况下，认为重构能消除所有旧代码的缺陷和所有对旧代码的再次访问需求，是不现实的。因此，我们让团队假设：他们提出的重构项，能使系统中该领域的缺陷投入时间减少一半。
换句话说，重构将能使每迭代处理系统中该部分缺陷需花费的时间，从20个小时/迭代减少到10个小时/迭代。
或许团队能改进得更多，但我建议在估计改进成果时仍然持保守态度。
步骤4：估计投资回收期
是时候看看是否值得实施重构了。要做到这一点，需将执行重构所需投入的工作量（在步骤2中确定）除以节省下来的时间（在步骤3中确定）。
在本案例中，我们的团队估计重构需要花40个小时。并且他们估计每迭代可以节省10个小时。
投资回收期的计算方法是：将重构所需的小时数除以每迭代节省的小时数，如下所示。
由于团队为重构规划了40个小时，并且每迭代将会节省10个小时，所以投资回收期是4个迭代。
四个迭代的投资回收期，应该能获得大多数产品负责人的青睐。这意味着在四个迭代后，就能收回用于重构的时间；并且与重构前相比，团队后续每个迭代都将会有额外的时间可用。
投资回收期需要多短？
团队和产品负责人应该寻找投资回收期最短的重构机会，但不存在严格的“所有重构都必须在n个迭代中得到回报”的指导标准。
投资回收期多长才合理？这会受项目的诸多因素影响，包括其他特性的紧迫性和产品的预计寿命等。难以证明：产品集任何重构工作的有效期都会少于六个月。
以产品负责人的术语来提交论据
通过使用这四个步骤来评估重构，团队能为重构展示其经济情况。他们对投资（执行重构所需的时间）除以每迭代节省时间的粗略估计，使产品负责人能大致了解多久能收回投资。
当以这些术语向产品负责人提出重构的论据时，产品负责人可以根据重构的经济效益做出合理的决策。这对团队、产品负责人以及产品的用户和客户都有利。
您有何经验？
您的产品负责人会接受重构请求吗？或者，如果您是一名产品负责人，什么能帮助说服您批准在重构上投入时间？请在下面的评论区分享您的观点。
