Categories
程式開發

优先改进哪个点:捏软柿子还是啃硬骨头?


如果能发现“要害点”,作为优先改进的点,且有方法来“啃硬骨头”,那么就能让持续改进切中要害,成效更大。

实践敏捷、精益或DevOps的团队,都在进行“持续改进”。但在持续改进中,会面临两个痛点:

  1. 找不到起始点: 不知道该优先改进哪个点,感觉没有方向;
  2. 啃不下硬骨头: 优先选的点改进成本太高,让人望而却步。

如果发现改进起始点这块“骨头”太硬,你是不是想换一个“软一点的柿子”,作为改进的第一步?

如果按这个思路进行改进,那么成本高的改进点是不是就一直没有机会被改进?这就解释了为什么很多团队只做低成本的代码层面的重构,但很少进行软件系统架构和基础设施这些成本高的改进。

如果能发现“要害点”,作为优先改进的点,且有方法来“啃硬骨头”,那么就能让持续改进切中要害,成效更大。

要想达到这个目的,首先要解决“找不到起始点,啃不下硬骨头”这两个问题。

找到起始点,啃下硬骨头

先说解决方案,可以用“优先改进象限”来识别改进的起始点,用“敏捷阶梯模型”来啃下硬骨头。

优先改进象限,有两个坐标轴,横轴越往右,表示质量越差;纵轴越往上,表示价值越大。改进的起始点,应该是价值最大,质量最差的那个待改进点。

优先改进哪个点:捏软柿子还是啃硬骨头? 1

敏捷阶梯模型,表示团队在互信的基础上,以消除“价值最大、质量最差”这个最大瓶颈为愿景,“尽早、频繁、小批”地进行PDCA(Plan/Do/Check/Adjust)迭代,一个迭代进步一点地进行改进。

优先改进哪个点:捏软柿子还是啃硬骨头? 2

我创造“优先改进象限”,是受了技术债墙的启发。偿还技术债也是在做持续改进,所以道理是相通的,但技术债墙很容易被团队误用。

优先改进哪个点:捏软柿子还是啃硬骨头? 3

在这个技术债墙四象限中,右下角“投入少、见效多(止痛多)”的技术债优先偿还,而左上角“投入多、见效少(止痛少)“的技术债就不值得偿还。

人人都愿意做“投入少,见效多”的事情。但就如同绘制该图的博客作者所说,在他们回顾技术债时,发现“投入少、见效多(止痛多)”的技术债很少。作者的解释是他们在日常工作中,已经顺手把这类技术债给偿还了,所以这是个好现象。

但好现象后面隐藏着危机:对于右上角“投入多、见效多(止痛多)”的技术债,该如何处理?那篇博客没有提及。

这就是技术债墙四象限容易被误用的地方:团队往往只关注“投入少、见效多”的技术债,而对“投入多、见效多”的则视而不见。

如何偿还“投入多、见效多”的债?

比较好的做法,是将右上角“投入多、见效多”的大技术债,拆分成“投入少,见效多”的小技术债,并移至右下角的象限,参考“敏捷阶梯模型“,尽早、频繁、小批地偿还。

比如,一个团队在维护一个有10余年历史的遗留系统。该系统80%的业务逻辑都写在了难以维护的PL/SQL里面,不仅很难阅读、重构和编写单元测试,其中还有大量的重复代码。将PL/SQL中的业务逻辑,改造成易于阅读、重构和编写单元测试,就应该属于偿还“投入多,见效多”的技术债。

由于该遗留系统80%的业务逻辑,都写在PL/SQL里面了。要想在短期内治理全部PL/SQL的业务逻辑难以维护的问题,是不可能的。但可以使用“优先改进象限”,先识别出价值最大的几个业务逻辑,再从中识别出质量最差(多次出现生产事故)的一个业务逻辑,做为改进的第一步。然后就可以集中优势资源,集中治理这一个业务逻辑的维护性差的问题。比如可以考虑使用PL/SQL转Java的工具,将业务逻辑转移Java中,并编写单元测试并重构。如果能解决这个PL/SQL的业务逻辑难以维护的问题,那么就能让这个曾经多次出现生产事故的“脏乱差”,变成易于维护且高价值的“首善之区”。这样还能增强团队士气,促使大家识别下一个“价值最大、质量最差”的改进点,从而形成正反馈循环。

除了技术债墙的启发,Jim Highsmith的敏捷三角,也启发了我创造出“优先改进象限”。

优先改进哪个点:捏软柿子还是啃硬骨头? 4

既然敏捷三角告诉我们,敏捷团队工作的主要目标,应该是价值和质量,而不仅仅是“范围、时间、成本”,那么当进行持续改进时,首先要改进的点,也自然是价值最大,且质量最差的。因为只有这样,才能更有效地达成追求”价值和质量“的目标。

除技术债墙之外,另一个常用的识别优先改进点的思路,是使用约束理论。即先绘制价值流图,标上各道工序的增值时间、等待时间和返工时间,并据此识别系统中最大的瓶颈。之后优先将这个最大的瓶颈“扩容”。等“扩容”后,再识别下一个最大的瓶颈,循环往复。但在软件开发相关的持续改进中,尤其是当要治理一个大泥球系统时,经常会面临深陷“泥潭”的局面,哪里都有问题,难以找到最大的瓶颈。另外,如果团队使用大批量交付的瀑布式开发方式,那么就难以搜集和度量增值时间、等待时间和返工时间这些识别瓶颈的数据,让瓶颈识别难上加难。

此时如果使用”优先改进象限“,那么识别出来的”价值最大、质量最差“的改进点,在大概率上是系统的最大瓶颈。这是因为,”价值最大“,意味着改进点位于价值流的主干上;”质量最差“,意味着返工最多(价值往回流,浪费很惊人),可以视作价值流动最大的瓶颈。所以,使用”优先改进象限“,可以快速地找到系统的返工的巨大瓶颈,有”投资少、见效快“的好处。

“优先改进象限”该如何落地?

可以召集团队所有成员,召开“优先改进工作坊“,一起绘制“优先改进象限”。

团队成员全员参与“优先改进工作坊“,一方面能提高优先改进点的识别准确率,另一方面能增强团队成员改进的主动性,有助于改进的落地。

工作坊主持人可以参照下面的方法,来主持“优先改进工作坊”:

  1. 召集团队所有成员;
  2. 每人把痛点写在便利贴上,每个便利贴只写一个痛点,贴到白板上,合并相同的点,然后分类;
  3. 先按价值大小,上下排序(可以众人排队,每人一次只能移动一个改进点的上下顺序,轮流进行,直到不再有改进点的移动);
  4. 再按质量优劣,左右排序(可以众人排队,每人一次只能移动一个改进点的左右顺序,轮流进行,直到不再有改进点的移动);
  5. 右上角的痛点,就是优先改进点;
  6. 大家讨论,如何用敏捷阶梯模型,尽早、频繁、小批地改进刚刚识别出的“优先改进点”;
  7. 定期举办优先改进工作坊,重复上述过程。

总结

团队在进行持续改进时,往往有两个痛点:找不到起始点,啃不下硬骨头。约束理论在团队进行瀑布式大批量交付的情况下,难以识别最大的瓶颈,这样就难以找到最佳的优先改进点。技术债墙虽然能识别“投入少、见效多”的优先改进点,但很容易被误用,因为大家往往只”捏软柿子“,不”啃硬骨头“。

团队在进行持续改进时,往往有两个痛点:找不到起始点,啃不下硬骨头。约束理论在团队进行瀑布式大批量交付的情况下,难以识别最大的瓶颈,这样就难以找到最佳的优先改进点。技术债墙虽然能识别“投入少、见效多”的优先改进点,但很容易被误用,因为大家往往只“捏软柿子”,不“啃硬骨头”。此时,团队可以在“优先改进工作坊”中,一起绘制“优先改进象限”,识别“价值最大、质量最差”的改进点作为起始点,然后参考敏捷阶梯模型,“尽早、频繁、小批”地“啃下这块硬骨头”,并循环往复,形成正反馈循环,最终让每个迭代的持续改进,都切中要害,并收获更大成效。

作者简介:

伍斌_Ben,ThoughtWorks软件开发咨询师。潜心进行软件开发技术的操练与悟道。因经常办技术操练道场,人称“道长”。著有《驯服烂代码》。自1993年大学毕业以来,先后做过程序员、测试工程师、项目经理和软件开发咨询师。2013年4月创办全栈开发者的编程操练社区“bjdp.org北京设计模式学习组”。微信公众号bjdp_org。

本文转载自ThoughtWorks洞见

原文链接

https://insights.thoughtworks.cn/continuous-improvement-priority/