Чыньнік аўтобуса

**Чы́ньнік аўто́буса** (ад )&nbsp;— мера засяроджваньня інфармацыі сярод асобных чальцоў праекту; чыньнік паказвае колькасьць удзельнікаў праекту, па „трапленьні якіх пад аўтобус“ (звальненьні, захворваньні, народзінах у іх дзіцяці, няшчасным выпадку, іншых форс-мажорных абставінах) праект ня можа быць завершаны астатнімі ўдзельнікамі. Зьява таксама вядомая пад назвамі **праблема аўтобуса** альбо **нумар аўтобуса[[Грузавы аўтамабіль|цяжкавіка]]**.

Асноўным пытаньнем для вызначэньня ключавой колькасьці зьяўляецца:

Тэрмін быў упершыню ўжыты да распрацоўкі праґрамнага забесьпячэньня, дзе чалец каманды можа ствараць важныя кампанэнты шляхам распрацоўкі коду, які працуе добра, але які таксама недаступны для іншых чальцоў каманды, напрыклад, праца, якая была не задакумэнтаваная, ніколі не распаўсюджвалася, была зашыфраваная, заблытаная альбо не апублікаваная .

Такім чынам, ключавы кампанэнт будзе фактычна страчаны як прамое наступства адсутнасьці гэтага чальца каманды, што робіць удзельніка ключавым. Калі б гэты кампанэнт быў ключавым для прасоўваньня праекта, праект спыніўся б.

## Гісторыя
Раньнім прыкладам такога запыту быў публічны запыт Майкла Маклея ў 1994 годзе, што здарылася б з мовай Python, калі б Гіда ван Росума зьбіў аўтобус.

„Нумар цяжкавіка“ ўжо быў апісаны ў кнізе „Organizational Patterns“, апублікаванай у 2004 годзе. Яна сама па сабе зьяўляецца эвалюцыяй працы, апублікаванай у першай кнізе сэрыі „Languages of Program Design“ у 1995 годзе, якая была публікацыяй запісу першай канфэрэнцыі па мовах шаблёнаў праґрам у жніўні 1994 году. Спасылка на чыньнік аўтобуса была ў шаблёнах, уключаючы Solo Virtuoso. Тэрмін быў выкарыстаны у галіне псыхічнага здароўя ў 1998 годзе.

Тэрмін быў заўважаны ў машынабудаваньні ў 2003 годзе і ў праекце Debian у 2005 годзе.

Дасьледаваньні, праведзеныя ў 2015 і 2016 гадах, падлічылі каэфіцыент аўтобусцяжкавік для 133 папулярных праектаў GitHub. Вынікі паказваюць, што большасьць сыстэмаў маюць малы каэфіцыент чыньніка аўтобуса (65 маюць каэфіцыент чыньніка ≤ 2) і значэньне больш за 10 для менш чым 10 сыстэмаў.

Тэрмін у асноўным выкарыстоўваецца ў кіраваньні бізнэсам, і асабліва ў галіне распрацоўкі праґрамнага забесьпячэньня.

## У розных абласьцях
### Распрацоўка праграмнага забесьпячэньня
У галіне распрацоўкі праґрамнага забесьпячэньня *bustruck factor* праекту&nbsp;— гэта мера засяроджваньня інфармацыі сярод асобных чальцоў праекту. *Bus factor* паказвае колькасьць распрацоўнікаў каманды праґрамістаў, пасьля страты якіх праект ня можа быць далей працягнуты. Праект будзе зьмяшчаць такую інфармацыю, зь якой астатнія распрацоўнікі ня змогуць разабрацца. Высокі *bus factor* праекту азначае, што праект будзе ўстойліва разьвівацца, калі яго пакіне нават вялікая колькасьць праґрамістаў.

Іншымі словамі, нізкі *bus factor*&nbsp;— гэта наяўнасьць спэцыфічных ведаў, якімі валодае абмежаваная колькасьць распрацоўнікаў каманды, заблытаны альбо малазразумелы код, выкарыстаньне тэхналёгіі, ведамі аб якой валодаюць усяго некалькі чалавек з каманды, адсутнасьць дакумэнтацыі, канфідэнцыяльнасьць і г.&nbsp;д.

## Спосабы вырашэньня праблемы
Існуе некалькі спосабаў павелічэньня значэньня гэтай мэтрыкі (што дазваляе зрабіць праект больш устойлівым):
* Памяншэньне складанасьці;
* Упраўленьне ведамі праекта:
** Фіксацыя ведаў, у тым ліку дакумэнтаваньне ўсіх працэсаў і падтрымка дакумэнтацыі ў актуальным стане;
** Выкарыстаньне перакрыжаванага навучаньня й іншых мэтодык кіраваньня ведамі.

## Крыніцы

## Літаратура
* Michele Marchesi, Giancarlo Succi, Don Wells, James Donovan Wells, Laurie Williams: *Extreme Programming Perspectives*. Addison-Wesley, Boston u. a. 2003, ISBN 0-201-77005-9
* Laurie Williams, Robert Kessler: *Pair Programming Illuminated*. Addison-Wesley, Boston u. a. 2002, ISBN 0-201-74576-3.
* Kent Beck: *Extreme Programming*. Das Manifest. Addison-Wesley, s. l. 2000, ISBN 3-8273-2139-5.

Катэгорыя:Кампутарная тэрміналёгія
Катэгорыя:Кіраваньне інфармацыйнымі рызыкамі
Катэгорыя:Бесьперабойнасьць бізнэсу
Катэгорыя:Эмпірычныя прынцыпы