优先改进哪个点：捏软柿子还是啃硬骨头？
极客时间编辑部
讲述：初明明大小：4.41M时长：04:50
你好，欢迎收听极客视点。
实践敏捷、精益或 DevOps 的团队，都在进行“持续改进”。但在持续改进中，会面临两个痛点：
找不到起始点：不知道该优先改进哪个点，感觉没有方向；
啃不下硬骨头：优先选的点改进成本太高，让人望而却步。
如果发现改进起始点这块“骨头”太硬，你是不是想换一个“软一点的柿子”，作为改进的第一步？
如果能发现“要害点”，作为优先改进的点，且有方法来“啃硬骨头”，那么就能让持续改进切中要害，成效更大。
最近，ThoughtWorks 软件开发咨询师伍斌分享了他的方法，供你参考。
找到起始点，啃下硬骨头
解决方案是，可以用“优先改进象限”来识别改进的起始点，用“敏捷阶梯模型”来啃下硬骨头。
优先改进象限有两个坐标轴，横轴越往右，表示质量越差；纵轴越往上，表示价值越大。改进的起始点，应该是价值最大，质量最差的那个待改进点。
敏捷阶梯模型表示团队在互信的基础上，以消除“价值最大、质量最差”这个最大瓶颈为愿景，“尽早、频繁、小批”地进行 PDCA（Plan/Do/Check/Adjust）迭代。
“优先改进象限”是受技术债墙的启发。偿还技术债也是在做持续改进，所以道理是相通的，但技术债墙很容易被团队误用。
在这个技术债墙四象限中，右下角“投入少、见效多（止痛多）”的技术债优先偿还，而左上角“投入多、见效少（止痛少）”的技术债就不值得偿还。
人人都愿意做“投入少，见效多”的事情。这就是技术债墙四象限容易被误用的地方：团队往往只关注“投入少、见效多”的技术债，而对“投入多、见效多”的则视而不见。
如何偿还“投入多、见效多”的债？
比较好的做法，是将右上角“投入多、见效多”的大技术债，拆分成“投入少，见效多”的小技术债，并移至右下角的象限，参考“敏捷阶梯模型”，尽早、频繁、小批地偿还。
除了技术债墙的启发，吉姆·海史密斯（Jim Highsmith）的敏捷三角也是“优先改进象限”诞生的启发点。
敏捷团队工作的主要目标，应该是价值和质量，而不仅仅是“范围、时间、成本”，那么当进行持续改进时，首先要改进的点，也自然是价值最大，且质量最差的。因为只有这样，才能更有效地达成追求“价值和质量”的目标。
除技术债墙之外，另一个常用的识别优先改进点的思路，是使用约束理论。即先绘制价值流图，标上各道工序的增值时间、等待时间和返工时间，并据此识别系统中最大的瓶颈。之后优先将这个最大的瓶颈“扩容”。等“扩容”后，再识别下一个最大的瓶颈，循环往复。
但在软件开发相关的持续改进中，尤其是当要治理一个大泥球系统时，经常会面临深陷“泥潭”的局面，哪里都有问题，难以找到最大的瓶颈。另外，如果团队使用大批量交付的瀑布式开发方式，那么就难以搜集和度量增值时间、等待时间和返工时间这些识别瓶颈的数据，让瓶颈识别难上加难。
此时如果使用“优先改进象限”，那么识别出来的”价值最大、质量最差“的改进点，在大概率上是系统的最大瓶颈。这是因为，”价值最大“，意味着改进点位于价值流的主干上；”质量最差“，意味着返工最多，可以视作价值流动最大的瓶颈。所以，使用”优先改进象限“，可以快速地找到系统的返工的巨大瓶颈，有“投资少、见效快”的好处。
“优先改进象限”该如何落地？
可以召集团队所有成员，召开“优先改进工作坊”，一起绘制“优先改进象限”。
团队成员全员参与“优先改进工作坊”，一方面能提高优先改进点的识别准确率，另一方面能增强团队成员改进的主动性，有助于改进的落地。
工作坊主持人可以参照下面的方法，来主持“优先改进工作坊”：
召集团队所有成员；
每人把痛点写在便利贴上，每个便利贴只写一个痛点，贴到白板上，合并相同的点，然后分类；
先按价值大小，上下排序（可以众人排队，每人一次只能移动一个改进点的上下顺序，轮流进行，直到不再有改进点的移动）；
再按质量优劣，左右排序（可以众人排队，每人一次只能移动一个改进点的左右顺序，轮流进行，直到不再有改进点的移动）；
右上角的痛点，就是优先改进点；
大家讨论，如何用敏捷阶梯模型，尽早、频繁、小批地改进刚刚识别出的“优先改进点”；
定期举办优先改进工作坊，重复上述过程。
以上就是今天的内容，希望对你有所帮助。
原文链接：
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
Ethan.Yuan点赞
收起评论