是卡车因素还是公共汽车因素?[关闭]

维基百科说巴士号是 more commonly known as truck number “但是在美国,“被巴士撞”实际上是一个成语,而“被卡车撞”并不是(尽管这两个短语都很容易理解),维基百科的文章说,关于高/低是好的:

“ 公共汽车的车次多了就好了 (与 最佳情况等于 项目开发人员)。这意味着 所有开发人员都了解代码库 差不多。低的总线号 (尤其是一个)代表一个高 风险。”

我要添加什么 @cartoonfox said : 混杂的 结对编程是一种很好的方法,可以在团队中传播关键知识,从而使卡车数量尽可能高。 如果你不交换配对 经常 而对于许多不同的团队成员来说,知识的分发速度并不快。

您需要高卡车/公共汽车系数:

卡车系数(定义):“数字 你的团队中必须 在项目开始前用卡车撞车 陷入严重困境”

(来自: http://www.agileadvice.com/archives/2005/05/truck_factor.html )

也就是说,您不希望代码中只有一个人知道它是如何工作的,或者只有一个人可以扩展/维护的部分。知识应该通过wiki信息和结对编程在整个团队中传播。

这个 载重车号码 (或卡车因素)是指具有关键知识的人的数量,你不能取代,即如果这一数量的人同时在一辆卡车下行驶,你将无法继续发展。

我相信某些化工公司禁止关键员工一起旅行,正是因为这个原因…

此处讨论: http://c2.com/cgi/wiki?TruckNumber

下面是一个关于比尔·阿特金森是Mac卡车生产商中的关键人物的故事。 -在Mac早期工作的主要人员之一。显然发生了车祸,人们担心他无法完成Mac图形软件的工作:

http://folklore.org/StoryView.py?project=Macintosh&story=I_Still_Remember_Regions.txt

高卡车数更好 -也就是说,很难同时消灭那些挑剔的人……

卡车数量少更糟 -也就是说,有一个更大的风险,一些关键的人可能生病,或离开或死亡,使项目处于不可恢复的崩溃状态。

结对编程是在团队中传播关键知识的一种好方法。 使卡车数量尽可能高。

无论你称之为:

• 总线号
• 卡车编号
• 总线因子
• 卡车系数
• 等

此外,无论您是否用一个更高的数字来描述它是更好的,还是用一个更低的数字来描述它是更好的,原则都是相同的:

• 如果你描述的是项目成员的数量,他们可能会被一辆巴士撞到,并让项目存活下来,那么一个高的公交号码是很好的;
• 如果您描述的是在一次公共汽车事故中幸存下来并让项目存活下来的项目成员的数量,那么一个较低的总线数量是很好的。

我曾经看过一次,但我不记得是谁先来的(见@paolo的答案)。不管谁先来,我已经经历了足够的困惑,我确保所有各方都使用相同版本的数字,无论是高还是低。;)