巴士因子
目录
巴士因子
公交车因素是对由于信息和能力未在团队成员之间共享而导致的风险的度量，源自短语以防他们被公交车撞到。 它也被称为公共汽车问题、xxx因素、卡车因素、啤酒卡车因素、公共汽车/卡车数量或货车因素。
这个概念类似于关键人物风险的更古老的想法，但考虑了失去关键技术专家的后果，而不是财务或管理高管（理论上可以以可保成本更换）。 人员必须既是关键又是不可替代的，才能为总线因素做出贡献； 失去可替代或非关键人员不会导致总线因素效应。
该术语首先应用于软件开发，团队成员可以通过编写性能良好的代码来创建关键组件，但其他团队成员也无法使用这些代码，例如未记录、从未共享、加密、混淆或未发布的工作 . 因此，作为该团队成员缺席的直接结果，关键组件实际上会丢失，从而使该成员成为关键。 如果这个组成部分是项目推进的关键，那么项目就会停滞不前。
定义
巴士因素是在项目停滞之前由于缺乏知识或称职的人员而不得不突然从项目中消失的最小团队成员数。
被公共汽车撞到这个表达描述了一个人要么死了，要么更普遍地从项目中突然消失了。 它用于以黑色幽默的方式描述假设的未来失踪事件。 团队成员不必真的被公交车撞到才能应用公交车因素——任何数量的事件都可能发生，在这些事件中，团队成员可能会突然和实质上无法从事项目工作。 这可能包括某人换一份新工作、休育儿假或改变生活方式或生活状态。
例如，假设一个 30 人的团队通过三个必要步骤生产面包：混合配料、揉面团和烘烤。 10个人会配料，30个人都会揉面，5个人会烤。 如果 5 个会烤面包的人都消失了，那么这个团队就不能生产面包，所以这个团队的总线因子是 5。
总线因素有一个罕见的替代定义，即：项目不可或缺的人数。 换句话说，它是单点故障的最少人数。 如果使用这个定义，那么高总线因子被认为是一件坏事（因为任何人的损失都会破坏项目），而零被认为是理想的总线因子。
历史
此类问题的一个早期实例是 Michael McLay 在 1994 年公开提问，如果 Guido van Rossum 被公共汽车撞了，Python 语言会发生什么情况。
Truck number 在 2004 年出版的 Organizational Patterns 书中已经是一个反复出现的概念，它本身是 1995 年 Pattern Languages of Program Design 系列xxx本书中发表作品的演变，这是xxx本 Pattern Languages of Programs 的出版记录 1994 年 8 月的会议上，它被引用到包括 Solo Virtuoso 在内的模式中。 到 1998 年，该术语在企业管理中变得司空见惯，并于同年用于心理健康领域。 它出现在 1999 年计算机和信息系统前沿协会的软件工程论文中，2003 年出现在工程学论文中，2005 年出现在 Debian 项目中。
2015 年和 2016 年进行的研究计算了 133 个热门 GitHub 项目的公共汽车/卡车系数。 结果表明，大多数系统的总线系数较小（65% 的总线系数 ≤ 2），并且只有不到 10% 的系统的值大于 10。
该术语主要用于企业管理，尤其是软件开发领域。
提高总线系数
在许多软件开发项目中，一个目标是共享信息以提高总线因子，可能会影响整个团队的规模。 良好的总线因素意味着许多人知道足以继续下去，即使在非常不利的情况下，该项目仍然可以成功。
已经提出了几种提高总线因子的方法：
- 降低复杂性，
- 记录所有流程并使该文档保持最新，
- 鼓励交叉培训。