Автобусный фактор (Реквием по моей команде)

Возможно, вы слышали о “автобусном факторе”. Для тех, кто этого не сделал, фактор автобуса - это мера риска: “Минимальное количество членов команды, которых должен сбить автобус, прежде чем проект остановится”. Люди, которые предпочитают формулировать вещи в более позитивном ключе, иногда называют это “фактором лотереи”.

Каков автобусный фактор вашей команды? В идеале у вас должен быть такой ответ: “90% команды должны были бы исчезнуть, чтобы приостановить проект, но если бы к команде присоединились новые люди с похожими навыками, мы могли бы вернуться к тому же уровню производительности в течение недели или двух”. Это звучит потрясающе, но достижимо ли это? Я верю, что это так!

Давайте рассмотрим две команды: команду A и команду B. В обеих этих командах одинаковое количество людей с одинаковыми навыками: четыре разработчика, один ведущий разработчик или технический руководитель, один QA, один ops, один BA, один DL и один специалист по продукту. Обе команды выполняют все обычные Agile-ритуалы; они сохраняют видимость своей работы на стене, вокруг которой собираются каждое утро. Каждую вторую неделю они проводят сеанс обратной связи / терапии, который называется "ретроспектива’. Они начинают каждую часть работы с начала. Разработчики обычно работают над задачами в парах не потому, что не решаются работать самостоятельно, а потому, что им нравится вести философские беседы во время сборки или развертывания своего кода.

Однажды один разработчик в каждой команде заболел, возможно, потому, что накануне вечером они все вместе тусовались в баре. Во время выступления в команде B ведущий доставки говорит: “Боб сегодня болен, но вчера Стив был с ним в паре. Стив, ты можешь продолжать и тебе нужен другой партнер? ”

Стив отвечает: “Я понятия не имею, в каком он состоянии, все было на ноутбуке Боба. Вчера я рано ушел. Мы должны подождать, пока он вернется, я буду работать над чем-нибудь другим”.

DL очень расстраивается, потому что все важные задачи на данном этапе в бэклоге могут быть выполнены только последовательно, и говорит: “Хорошо, похоже, нам придется привлечь к этому больше людей и начать эту задачу с самого начала”.

В команде А такая же ситуация, но команда А-Стив отвечает по-другому: “Да, я хотел бы иметь партнера. Все, что мы сделали вчера, находится на ветке / развилке, мы выполнили 40% объема, и я рад продолжать работать над этим с кем-то; все присутствовали при запуске, и объем задокументирован ”.

Никакого стресса, никакой драмы. Та же ситуация, но разные результаты.

Теперь второй сценарий: два разработчика, оба работающие над одной и той же картой, заболели в один и тот же день, потому что продолжали тусоваться в одном и том же баре. Беседа в группе B на следующий день проходит примерно так:

ДЛ: “Итак, Боб и Стив заболели, может кто-нибудь забрать их работу?”

Барбара говорит: “Я понятия не имею, над чем работали эти двое, на карточке нет подробностей о том, где находится код или даже что они решили создать, поэтому мне нужно будет начать все сначала”.

В команде А такая же ситуация, но Барбара отвечает: “О, я могу это исправить. Я присутствовал при запуске, и проблема с git содержит всю информацию о области применения, кодовых базах и вовлеченных людях. Плюс в ветке должны быть коммиты с прогрессом”. Никакого стресса, никакой драмы.

Давайте теперь представим, что QA из обеих команд зависали с разработчиками в одном и том же сомнительном баре. На следующее утро разговор в команде B начинается так: “Хорошо, команда, у нас сегодня мало что готово для тестирования, к сожалению, наш QA Джек тоже заболел. Кто может проверить карты?”

Команда B отвечает: “О, мы понятия не имеем, что делал Джек, он не оставлял никаких комментариев на карточке. Мы не уверены точно, что нужно проверить, и что Боб и Стив сделали с ним до того, как их передали Джеку ”.

Команда А отвечает по-другому: “Любой может это проверить, на всех картах есть стратегия тестирования и область действия, должным образом задокументированная, и Джек присутствовал при старте”. Опять же, никакого стресса и никакой драмы.

Теперь вы, вероятно, хотите спросить: “Что происходит в этом баре? Почему все, кто входит в него, заболевают на следующий день?!” Но лучше задать такой вопрос: “Почему команды А и В в одной компании так отличаются друг от друга?” Я уже работал в группах B в REA раньше. Надеюсь, в наши дни у большинства команд коэффициент использования автобусов ближе к коэффициенту команды А, но не у всех. Некоторые команды могут сказать: ”Мы можем потерять 40% разработчиков, но если этот один сотрудник или технический руководитель исчезнет — у нас большие проблемы!” Итак, могут ли все B-команды стать A-командами? Конечно, они могут!

На мгновение представьте, что каждый месяц один человек покидает вашу команду и к вам присоединяется один новый человек. Например, в одном месяце это может быть разработчик, который сменяется, в следующем месяце QA или BA и т. Д. При постоянных изменениях в моей компании мы можем легко предсказать, что через два года проект, над которым вы работаете, будет поддерживаться совершенно другой командой, если она вообще существует. Теперь давайте подумаем о процессах, которые мы можем настроить в команде, зная, что каждый месяц случайный человек в команде будет меняться местами. В этой ситуации важность эффективной коммуникации и документирования становится очевидной. У вас также, вероятно, есть какой-то набор основных правил, которые все знают и которым следуют, например: выкладывайте свой код в ветку в конце дня, делайте откаты для карточек и документируйте результаты, работайте в парах, имейте четкое правило приоритета задач.

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

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

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