Фактор автобуса

Фактор автобуса (англ. bus factor, либо truck factor^[1]) проекта — это мера сосредоточения информации среди отдельных членов проекта; фактор означает количество участников проекта, после потери которых (в оригинале — «попадания» которых под автобус или грузовик, варианты: увольнения, заболевания, рождения у них ребёнка, наступления несчастного случая и других форс-мажорных обстоятельств) проект не сможет быть завершён оставшимися участниками.

Не провалится ли проект, если один из членов будет сбит автобусом?

Применение в различных областяхПравить

Разработка программного обеспеченияПравить

В области разработки программного обеспечения bus factor (либо truck factor) проекта — это мера сосредоточения информации среди отдельных членов проекта. Bus factor показывает количество разработчиков команды программистов, после потери которых проект не может быть дальше продолжен^[2]. Проект будет содержать такую информацию, с которой оставшиеся разработчики не смогут разобраться. Высокий bus factor проекта означает, что проект будет устойчиво развиваться, если его покинет даже большое количество программистов.

Другими словами, низкий bus factor — это наличие специфических знаний, которыми владеют ограниченное число разработчиков команды, запутанный или малопонятный код, использование технологии, знаниями о которой владеют всего несколько человек из команды, отсутствие документации, конфиденциальность и т. д.

Термин был обычным явлением в сфере управления бизнесом^{[уточнить]} в 1998 году, встречался в документации по разработке программного обеспечения Ассоциации вычислительной техники в 1999 году.

Управление знаниямиПравить

В российской практике управления знаниями понятие также могут называть «фактором кирпича».

Фактор кирпича обобщает исходное значение и показывает количество участников бизнес-процесса — носителей незафиксированных знаний, после выбывания которых (от гипотетического падения кирпича на голову) бизнес-процесс не сможет быть продолжен. Используется для выявления критичных знаний и критичных для бизнеса экспертов.

Способы решения проблемыПравить

Существует несколько способов увеличения значения этой метрики (что позволяет сделать проект более устойчивым)^[3]:

Уменьшение сложности.
Управление знаниями проекта:
- Фиксация знаний, в том числе документирование всех процессов и поддержка документации в актуальном состоянии.
- Использование перекрёстного обучения и других методик управления знаниями.

ПримечанияПравить

↑ Bowler, Michael Truck Factor (неопр.). Agile Advice (15 мая 2005). Дата обращения: 2 августа 2016. Архивировано 29 апреля 2021 года.
↑ Brian W. Fitzpatrick, Ben Collins-Sussman. Team Geek: A Software Developer's Guide to Working Well with Others. — O'Reilly Media, 2012. — С. 7—8. — 194 с. — ISBN 9781449329891. Архивная копия от 20 августа 2016 на Wayback Machine
↑ Kailash Awati. Increasing your team’s bus factor (англ.) (3 сентября 2008). Дата обращения: 2 августа 2016. Архивировано 16 апреля 2016 года.

СсылкиПравить

How Open Source Projects Survive Poisonous People, Google I/O, 29 May 2008 Brian Fitzpatrick, Ben Collins-Sussman (видео) — выступление, в котором также обсуждается автобус-фактор и методы его увеличения (англ.)
Integrating GIS in the Engineering, Planning and Design Processes, статья Matthew C. Redmond и Paul Newton 2003 года, наиболее ранняя отсылка к автобус-фактору (англ.)
The Linus Torvalds Bus Factor, Shlomi Fish, Апрель 2007 (англ.)

[:0-1] Bowler, Michael Truck Factor (неопр.). Agile Advice (15 мая 2005). Дата обращения: 2 августа 2016. Архивировано 29 апреля 2021 года.

[teamgeek2012-busfactor-2] Brian W. Fitzpatrick, Ben Collins-Sussman. Team Geek: A Software Developer's Guide to Working Well with Others. — O'Reilly Media, 2012. — С. 7—8. — 194 с. — ISBN 9781449329891. Архивная копия от 20 августа 2016 на Wayback Machine

[eight2late-3] Kailash Awati. Increasing your team’s bus factor (англ.) (3 сентября 2008). Дата обращения: 2 августа 2016. Архивировано 16 апреля 2016 года.

[1]

[2]

[3]