QQ截图20200520162309

四步说服产品负责人优先安排重构工作

作者: Mike Cohn

译者:李洁(Jerry Li)

原文链接:
https://www.mountaingoatsoftware.com/blog/4-steps-to-persuade-a-product-owner-to-prioritize-refactoring

 

团队通常很难说服其产品负责人给他们时间做重构,特别是重构工作量较大的时侯。在本文中,我想分享一个四步框架——团队可以用于证明重构的合理性,并说服其产品负责人允许进行重构。

什么是重构?

首先,让我们明确重构的含义。重构是指:在不改变代码外在行为的前提下,优化代码的结构。这就意味着,团队不会将重构用于修复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个小时。

投资回收期的计算方法是:将重构所需的小时数除以每迭代节省的小时数,如下所示。

QQ截图20200520163109

由于团队为重构规划了40个小时,并且每迭代将会节省10个小时,所以投资回收期是4个迭代。

四个迭代的投资回收期,应该能获得大多数产品负责人的青睐。这意味着在四个迭代后,就能收回用于重构的时间;并且与重构前相比,团队后续每个迭代都将会有额外的时间可用。

投资回收期需要多短?

团队和产品负责人应该寻找投资回收期最短的重构机会,但不存在严格的“所有重构都必须在n个迭代中得到回报”的指导标准。

投资回收期多长才合理?这会受项目的诸多因素影响,包括其他特性的紧迫性和产品的预计寿命等。难以证明:产品集任何重构工作的有效期都会少于六个月。

以产品负责人的术语来提交论据

通过使用这四个步骤来评估重构,团队能为重构展示其经济情况。他们对投资(执行重构所需的时间)除以每迭代节省时间的粗略估计,使产品负责人能大致了解多久能收回投资。

当以这些术语向产品负责人提出重构的论据时,产品负责人可以根据重构的经济效益做出合理的决策。这对团队、产品负责人以及产品的用户和客户都有利。

您有何经验?

您的产品负责人会接受重构请求吗?或者,如果您是一名产品负责人,什么能帮助说服您批准在重构上投入时间?请在下面的评论区分享您的观点。