巴士因子
一个项目失去多少名关键成员后，就会陷入严重困境？
显示原始英文内容
Bus Factor
The minimum number of team members whose loss would put the project in serious trouble.
Takeaways
- A bus factor of 1 means one person holds critical knowledge; if they disappear, the project is essentially 'doomed' or stalled. A higher bus factor (e.g., 5) means the project could lose any one of five specific people before stopping work.
- It's basically a measure of knowledge distribution and risk. A high bus factor is good (knowledge is shared among many), while a low is bad (single points of failure in expertise).
- Teams should work to increase their bus factor by sharing knowledge, documenting critical systems, having code reviews, and rotating responsibilities.
Overview
The Bus Factor highlights the human single point of failure in projects. In many software teams, one or two people might understand the legacy system, a crucial algorithm, or have all the deployment knowledge. If those people leave, others cannot easily pick up the work.
The concept encourages actively avoiding such dependency. Improving bus factor overlaps with knowledge management practices: pair programming, code reviews, documentation, mentorship, and rotating responsibilities.
Examples
If a startup's only database expert is Alice, the bus factor for database knowledge is 1. If Alice quits, nobody else knows the backups, schema intricacies, or tuning.
The Left-pad incident reflects a bus factor of 1 for the broader ecosystem: a single maintainer pulled a tiny NPM package, and thousands of builds broke.
Origins
The concept was popularized in the 1990s in discussions of project risk. The term is somewhat morbid, so some call it "lottery factor" (flipping the scenario to a positive reason someone leaves).
It's not attributed to a single person but emerged as slang in software teams. An early reference appears in patterns literature (1994 PLoP conference), discussing "truck number" in organizational patterns. The idea likely existed informally even earlier.
核心含义
巴士因子衡量的是关键知识和责任集中在少数人身上的程度。数字越低，项目对个人离职、休假或调岗越脆弱。
提高巴士因子不只是写文档，还包括结对工作、轮值、代码评审、自动化和让更多人真正拥有决策权。
实践例子
只有一名开发者知道生产部署流程。即使代码在仓库里，团队失去这个人后仍无法发布。通过轮流值班、演练恢复和补齐操作手册，可以把知识变成团队能力。
来源与边界
它是软件团队常用的风险指标，不应被用来指责个人“没有分享知识”。知识集中往往是流程、激励和时间安排共同造成的组织问题。