Оценка автобусного фактора: сколько членов команды может попасть под автобус до того, как команда потерпит неудачу?

Немного истории

Хотя название может показаться довольно экстремальным, похожее предложение публично задал [Майкл Маклей в 1994 году] (https://en.wikipedia.org/wiki/Bus_factor#History):

Если Гвидо попал под автобус? (Гвидо ван Россум — создатель языка Python)

Этот вопрос привел к созданию автобусного фактора, известного также как автобусная проблема, грузовой фактор, грузовой фактор или даже лотерейный фактор.

Что такое «коэффициент шины»?

Хотя в Интернете есть несколько немного отличающихся определений, мы можем обобщить их следующим образом:

Фактор автобуса — это общее количество людей, которые должны быть выведены из строя, например, если их сбил автобус, чтобы проект остался мертвым.

Чтобы сделать это более наглядным, балл Bus Factor — это оценка людей, которые настолько важны для вашего проекта, что без них он остановится. Если эти люди исчезнут из проекта по какой-либо причине (например, «несчастный случай» или даже отпуск, их уволят или покинут проект), никто не сможет поддерживать проект.

Наименьший возможный балл Bus Factor равен всего 1, что означает, что если один человек покинет проект, он остановится или умрет. С более технической точки зрения это можно рассматривать как единственную точку отказа в рамках проекта. Гораздо больший показатель Bus Factor предпочтительнее, но его не всегда легко достичь. -04-09T14:48:15.265Z-cl1rz2081001b0as6gg9k7k9u)](https://xkcd.com/2347/)

Проблема сообщества PHP

В конце 2021 года сообщество PHP получило печальную информацию о том, что после 10 лет реализации бесчисленных исправлений ошибок, функций и поддержки PHP один из основных участников: Никита Попов, решил сосредоточиться на работе на совершенно другом языке. и коммьюнити (Rust & LLVM), от которых он уже несколько лет как отошел.

Подобно истории языка Python, это решение показало, что у языка PHP есть действительно большая проблема с таким низким показателем Bus Factor. Это поставило будущее языка, на котором работает ~78% Интернета, в опасное положение.

Чтобы улучшить текущее состояние, люди и компании, работающие над PHP, объединили свои усилия и запустили новую инициативу: [Фонд PHP] (https://opencollective.com/phpfoundation).

PHP Foundation — некоммерческая организация, миссия которой — обеспечить долгую жизнь и процветание языка PHP.

Первым решением, принятым фондом, было нанять / спонсировать новых разработчиков для работы над основными компонентами PHP. Таким образом, они могли начать повышать показатель Bus Factor до более безопасного уровня. Это один из многих шагов, которые должны быть предприняты сообществом, чтобы сделать будущее PHP безопасным и стабильным.

Проблемы компании

Множество компаний, в которых я работал, от стартапов до корпораций, часто сильно страдали от Bus Factor. Многие их команды (чаще всего непреднамеренно) попадали в NIH (Not Invented Here), что приводило к проблемам с обслуживанием , и более высокий начальный уровень для новичков, так как все больше вещей создавалось людьми, которые могли покинуть проект в любой момент. Это часто приводило к высокому техническому долгу (что я попытаюсь объяснить в следующем посте).

Низкий показатель Bus Factor часто является частью быстрорастущего времени, когда лишь несколько разработчиков создают большую часть функциональности, которая впоследствии становится основой для все более сложного проекта. Большинство компаний начинают масштабные планы по найму персонала во время такого роста, но это не то, что может увеличить коэффициент автобуса в одиночку.

Как увеличить низкий показатель Bus Factor?

Коуч-сессии и парное программирование

Каждый новый участник должен иметь как минимум 30 минут сеанса парного программирования с одним из старших людей в проекте, к которому он/она присоединяется. Во время таких сессий менее опытный человек должен выполнять большую часть кодирования, а старшие наставники подавать пример и предлагать части, которые могут помочь в достижении цели задачи.

Ваш человек Bus Factor как учитель

Когда вы определяете людей Bus Factor, вы должны сосредоточиться на том, как они могут поделиться знаниями, которые они накопили за все эти годы в вашем проекте. Их знания — одна из самых больших ценностей для вашей команды. Попросите их больше сосредоточиться на написании документации, создании шпаргалок, проведении внутренних презентаций и обмене знаниями на индивидуальных занятиях с товарищами по команде. Их внимание к программированию должно быть уменьшено.

Культура проверки кода

В то время как внедрение культуры проверки кода осуществляется командами для улучшения качества кода и процесса проверки, менее очевидным результатом является прямой обмен знаниями между людьми в проекте. Отзывы не должны быть похожи на одобрение. Они должны указать, почему что-то было сделано именно так, а не иначе, что привело бы к конструктивному обсуждению между старшими и другими товарищами по команде о том, что можно было бы сделать по-другому, с точки зрения старших. Обзоры должны вести к обсуждению.

Снижение сложности проекта(ов)

Часто проблема быстрорастущих компаний заключается в быстрорастущем техническом долге, что приводит к низкому показателю Bus Factor. Одним из эффективных методов является снижение сложности проектов путем их разделения на более мелкие и специализированные. Это приводит к более низкому начальному уровню, более быстрому внедрению и упрощению обслуживания. Все эти моменты позволяют достаточно эффективно увеличивать общий Bus Factor. Самая большая проблема, которую вы должны избегать при снижении сложности проектов, — это всегда вовлекать команды (даже небольшие) в рефакторинг, чтобы избежать создания той же самой проблемы в новых подпроектах.

Команда "тасовка"

Это может быть самый эффективный способ увеличить показатель Bus Factor, но также и самый сложный и опасный. Вам нужно тщательно продумать каждую возможность, чтобы не потерять боевой дух команды. «Перетасовку» следует не навязывать, а предлагать членам команды на регулярной основе, например: раз в две четверти; товарищи по команде не могут слишком часто менять команду, так как их нужно будет интегрировать, как новичка. При правильном планировании и выполнении ваши команды получат гораздо более широкий опыт в различных областях, делясь знаниями, полученными во время работы с другими командами.

Бюджет обучения

Планирование бюджетов на обучение ваших разработчиков также может повысить показатель Bus Factor, поскольку люди будут приобретать более широкий спектр опыта и расширять вашу команду, чтобы иметь больше людей в каждом ранге старшинства в иерархии вашей компании.

Резюме

Это не так просто, дешево или быстро увеличить показатель Bus Factor вашей команды. Бывают случаи, когда вы не хотите (или даже не можете) легко увеличить этот балл, например, когда проект содержит конфиденциальные данные, и вы не можете доверять своим новым сотрудникам, чтобы они начали их обрабатывать. Но теперь вы знаете некоторые основы, которые могут помочь вам предотвратить остановку вашей деятельности из-за «автобусной аварии».