Чыньнік аўтобуса
Чы́ньнік аўто́буса (ад анг. bus factor) — мера засяроджваньня інфармацыі сярод асобных чальцоў праекту; чыньнік паказвае колькасьць удзельнікаў праекту, па „трапленьні якіх пад аўтобус“ (звальненьні, захворваньні, народзінах у іх дзіцяці, няшчасным выпадку, іншых форс-мажорных абставінах) праект ня можа быць завершаны астатнімі ўдзельнікамі. Зьява таксама вядомая пад назвамі праблема аўтобуса альбо нумар аўтобуса / цяжкавіка[1][2][3].
Асноўным пытаньнем для вызначэньня ключавой колькасьці зьяўляецца:
„Наколькі шмат ці мала людзей павінны патрапіць пад цяжкавік (альбо кінуць працу), перш чым праект будзе паралізаваны?“
Арыгінальны тэкст (анг.)„How many or few would have to be hit by a truck (or quit) before the project is incapacitated?“
— Джым Копліен, Pair Programming Illuminated[4]
Тэрмін быў упершыню ўжыты да распрацоўкі праґрамнага забесьпячэньня, дзе чалец каманды можа ствараць важныя кампанэнты шляхам распрацоўкі коду, які працуе добра, але які таксама недаступны для іншых чальцоў каманды, напрыклад, праца, якая была не задакумэнтаваная, ніколі не распаўсюджвалася, была зашыфраваная, заблытаная альбо не апублікаваная .
Такім чынам, ключавы кампанэнт будзе фактычна страчаны як прамое наступства адсутнасьці гэтага чальца каманды, што робіць удзельніка ключавым. Калі б гэты кампанэнт быў ключавым для прасоўваньня праекта, праект спыніўся б.
Гісторыя
рэдагавацьРаньнім прыкладам такога запыту быў публічны запыт Майкла Маклея ў 1994 годзе, што здарылася б з мовай Python, калі б Гіда ван Росума зьбіў аўтобус[5].
„Нумар цяжкавіка“ ўжо быў апісаны ў кнізе „Organizational Patterns“, апублікаванай у 2004 годзе[6]. Яна сама па сабе зьяўляецца эвалюцыяй працы, апублікаванай у першай кнізе сэрыі „Languages of Program Design“ у 1995 годзе[7], якая была публікацыяй запісу першай канфэрэнцыі па мовах шаблёнаў праґрам у жніўні 1994 году. Спасылка на чыньнік аўтобуса была ў шаблёнах, уключаючы Solo Virtuoso[8]. Тэрмін быў выкарыстаны у галіне псыхічнага здароўя ў 1998 годзе[9].
Тэрмін быў заўважаны ў машынабудаваньні ў 2003 годзе[10] і ў праекце Debian у 2005 годзе[11].
Дасьледаваньні, праведзеныя ў 2015 і 2016 гадах, падлічылі каэфіцыент аўтобус / цяжкавік для 133 папулярных праектаў GitHub. Вынікі паказваюць, што большасьць сыстэмаў маюць малы каэфіцыент чыньніка аўтобуса (65 % маюць каэфіцыент чыньніка ≤ 2) і значэньне больш за 10 для менш чым 10 % сыстэмаў[12][13].
Тэрмін у асноўным выкарыстоўваецца ў кіраваньні бізнэсам, і асабліва ў галіне распрацоўкі праґрамнага забесьпячэньня.
У розных абласьцях
рэдагавацьРаспрацоўка праграмнага забесьпячэньня
рэдагавацьУ галіне распрацоўкі праґрамнага забесьпячэньня bus / truck factor праекту — гэта мера засяроджваньня інфармацыі сярод асобных чальцоў праекту. Bus factor паказвае колькасьць распрацоўнікаў каманды праґрамістаў, пасьля страты якіх праект ня можа быць далей працягнуты[14]. Праект будзе зьмяшчаць такую інфармацыю, зь якой астатнія распрацоўнікі ня змогуць разабрацца. Высокі bus factor праекту азначае, што праект будзе ўстойліва разьвівацца, калі яго пакіне нават вялікая колькасьць праґрамістаў.
Іншымі словамі, нізкі bus factor — гэта наяўнасьць спэцыфічных ведаў, якімі валодае абмежаваная колькасьць распрацоўнікаў каманды, заблытаны альбо малазразумелы код, выкарыстаньне тэхналёгіі, ведамі аб якой валодаюць усяго некалькі чалавек з каманды, адсутнасьць дакумэнтацыі, канфідэнцыяльнасьць і г. д.
Спосабы вырашэньня праблемы
рэдагавацьІснуе некалькі спосабаў павелічэньня значэньня гэтай мэтрыкі (што дазваляе зрабіць праект больш устойлівым)[15]:
- Памяншэньне складанасьці;
- Упраўленьне ведамі праекта:
- Фіксацыя ведаў, у тым ліку дакумэнтаваньне ўсіх працэсаў і падтрымка дакумэнтацыі ў актуальным стане;
- Выкарыстаньне перакрыжаванага навучаньня й іншых мэтодык кіраваньня ведамі.
Крыніцы
рэдагаваць- ^ Michael Bowler (15 траўня 2005) Truck Factor (анг.). Agile Advice. Праверана 19 сьнежня 2023 г. Архіўная копія ад 9 красавіка 2014 г.
- ^ Guilherme Avelino, Marco Tulio Valente, Andre Hora (2017-01-02) What is the Truck Factor of Popular GitHub Applications? A First Assessment (анг.). peerj.com. Праверана 2021-08-19 г.
- ^ Sébastien Dubois (2020-05-13) What’s the bus factor and 7 ways to increase it (анг.). medium.com. Праверана 2021-08-19 г.
- ^ Laurie Williams, Robert Kessler: Pair Programming Illuminated. С. 41.
- ^ McLay, Michael (June 29, 1994) „If Guido was hit by a bus?“ (Mailing list) (анг.)
- ^ James Coplien, Neil Harrison Organizational patterns of agile software development (анг.).
- ^ James Coplien, Douglas Schmidt Chapter 13, A Generative Development-Process Pattern Language // Pattern Languages of Program Design (анг.).
- ^ Coplien, James (August 4, 1994), „A Generative Development-Process Pattern Language“, Internal proceedings of PLoP 1994, Allerton Park, Illinois: unpublished., archived from the original on September 12, 2014, retrieved September 12, 2014
- ^ Simon, Robert (анг.). — С. 69. — ISBN 0-674-69721-9
- ^ Matthew C. Redmond, Paul Newton Integrating GIS in the Engineering, Planning and Design Processes (анг.) Архіўная копія ад 2012-03-12 г.
- ^ Reinholdtsen, Petter (November 11, 2005). „Re: Resignation and uploads“ (Mailing list).
- ^ Avelino, Guilherme; Valente, Marco Tulio; Hora, Andre (September 10, 2015). „What is the Truck Factor of popular GitHub applications? A first assessment“. PeerJ Preprints. doi:10.7287/peerj.preprints.1233v3.
- ^ Avelino, Guilherme; Passos, Leonardo; Hora, Andre; Valente, Marco Tulio (2016). „A novel approach for estimating Truck Factors“. 2016 IEEE 24th International Conference on Program Comprehension (ICPC). pp. 1–10. arXiv:1604.06766v1. Bibcode:2016arXiv160406766A. doi:10.1109/ICPC.2016.7503718. ISBN 978-1-5090-1428-6. S2CID 19238548.
- ^ Brian W. Fitzpatrick, Ben Collins-Sussman Team Geek: A Software Developer’s Guide to Working Well with Others. — 2012. — С. 7—8. — 194 с. — ISBN 9781449329891
- ^ Kailash Awati (2008-09-03) Increasing your team’s bus factor (анг.) Архіўная копія ад 2016-04-16 г.
Літаратура
рэдагаваць- 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 (анг.).