软件交付低效的幕后推手
The drivers behind software delivery inefficiency
本想深入探讨软件交付低效的根源，却意外撞上了 dl.acm.org 的安全验证墙。Cloudflare 的防护机制误将正常访问判定为恶意机器人，导致页面直接返回 403 错误。浏览器扩展或网络防火墙的干扰，让获取 ACM 论文内容变得异常艰难。这不仅是一次简单的访问失败，更折射出当前技术生态中安全验证与用户体验之间的微妙博弈。当我们在讨论交付效率时，连获取基础研究资料都如此坎坷，这本身就是一个值得深思的讽刺。
你的浏览器扩展或网络设置阻止了 dl.acm.org 所需的安全验证流程。
HN 评论区
55- onion2k
我相当确定，导致软件交付变慢的首要因素就是同时做的事情太多。你的团队应该力求一次只专注一个项目。
在团队中接手另一个项目、工作流、想法或调查任务，几乎全是弊大于利：
- 更多的上下文切换，导致人们更容易烦躁；
- 任何工作的“巴士系数”降低，直到变成每人负责一件事，而一旦这个人不在，那件事就停摆；
- 投入工作的人手减少，意味着所有事情都只能按单人速度推进（对于可并行工作，两人本该快一倍）；
- 依赖项解决变慢，以至于连获取 PR 评审这样基础的事情都成了大麻烦；
- 看到问题的人变少，意味着能调用的经验更少，从而降低了因“以前见过类似情况”而带来的提速效果。
此外还有更多问题。对于每个项目，目标都应是实现最大程度的并行化。
- regularfry
对我们来说，评审延迟显然是一个问题，所以我们通过让交接过程同步化来消除它（至少对大多数工单而言）。当任务进入评审列时，直接和评审者开个电话会议。消除评审延迟带来的收益，远远超过了评审者上下文切换的成本。尤其是当补丁足够小，能在电话会议中直接通读时，如果有任何需要立即处理的问题，双方可以即时来回沟通，无需任何等待。
- BobbyTables2
根据我的经验，事情往往在经理看到“功能 X 需要 4 人月的工作量”后开始走下坡路，于是他们指派 4 个人来做，其中 2-3 人是初级员工，剩下的人还要兼顾其他任务。他们以为这样就能实现在一个月内完成功能的目标。
结果往往是缺乏统一的愿景，大家各自开发不同的部分，最后某个倒霉蛋不得不在两三个月后痛苦地把这些碎片拼凑在一起。QA 发现了一些边缘情况，导致最后一刻的修复，进而推迟发布。
最终，更多难以发现的 bug 逃过了 QA，引发客户投诉升级。
通常要过上一两年，再投入一两个月的开发精力，这个功能才会被彻底清理。
客户看到的只是一个持续两三年都出问题的功能，最终只能放弃。
如此多的浪费。
问题不在于有没有一个“首席沉思架构师”。在共享代码库上开发，其并行化程度远不如人们期望的那样高。
你必须彻底理解自己在做什么，并掌握所有相关考量。指望整个团队对每个功能都具备这种能力是不现实的。而且，也没人会花时间去编写一份详细的内部 API 规范，让这种并行化成为可能……
- akkartik
“别再怪 QA 了……”
现在都什么年代了？！还有人在怪 QA 吗？如果有，请看看日历，然后进入 21 世纪吧！
- jackb4040
> “当耦合度升高时，大量时间被浪费在繁重的协调、对齐和共享策略上。同一枚硬币的另一面是，当一个组件出错时，所有人都会损失大量时间。”
这算是胡扯，还是英语太差？在这里发布内容难道没有同行评审的门槛吗？因为这看起来就像是一篇低努力的、四页长的、罗列他人数据的综述，没有任何原创的实证证据。换句话说，这东西本来应该是一篇博客。