Что может быть общего между бегом и разработкой программного обеспечения? На первый взгляд, ничего особенного. Потный и стройный бегун совершенно непохож на рыхлого, согнутого сколиозом программиста. Разработчикам не рукоплещут стадионы и никто не выдает им знамя страны для почетного круга по офису после выпущенного релиза. И, тем не менее, между бегом и разработкой много общего.

Недавно я прочитал одну тяжелую книгу — Surfaces and Essences ^[1]. Дуглас Хофштадтер ^[2] оттянулся по полной и сделал так, что после первых 50 страниц читать книгу просто не хочется. Я буквально заставлял себя осваивать пару десятков страниц в неделю, пока не дошел до последней трети книги — и там все стало очень круто.

Книга о том, как люди мыслят. А мыслят они аналогиями. Хофштадтер и Сандер довольно убедительно доказывают на миллионе примеров, как работают аналогии и чего можно с их помощью достигнуть.

У меня родилась простая идея — взять одну область знаний, проанализировать ее и применить к другой области знаний. Я выбрал бег.

Спойлер: Читайте дальше, чтобы узнать, почему

Для начала посмотрим, какие свойства есть у бега и какие аналогии можно провести с разработкой. У меня получилась такая табличка.

Бег	Поставка фич
Направление бега	Направление разработки
Дистанция	Релиз
Скорость бега	Скорость поставки фич
Выносливость	Когда меня все зае… т?
Травмы	Травмы

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

Какая цель бега вообще? Я бы сказал, такая

Бежать как можно быстрее как можно дальше без травм

Бегун на стометровке рассмеется мне в лицо, потому что бежать дальше ему не надо. Но любой бегун на средние и дальние дистанции одобрительно кивнет. Если вы начинали бегать, то знаете, как это бывает. Сначала вы пробегаете 2 километра с темпом 6:50. Со временем 5 километров с темпом 5:30. Потом 10 с темпом 4:50 и наконец перестаете бегать из-за проблем с коленом/ахилом/пяткой/голеностопом. Каждый раз, выходя на пробежку, вы хотите пробежать чуть дальше и чуть быстрее, чем в прошлый раз.

Давайте переключимся на программные продукты. И тут мы хотим

Разрабатывать как можно быстрее как можно дальше без травм

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

Мы возьмем свойства бега и сгенерируем новые гипотезы, которые можно будет попробовать в разработке.

Направление

Вообще бежать нужно в правильную сторону. В беге это настолько тривиальная вещь, что никто даже не задумывается об этом. Сложно себе представить, как Усейн Болт прикрепляет колодки в другую сторону и стартует на трибуны. Или как в середине 800 метровки Уилсон Кипкетер резко разворачивается и убегает назад, провожаемый недоуменным гулом стадиона и удивленными глазами соперников.

Однако, это довольно часто случается в разработке продуктов. В мире созданы десятки тысяч продуктов, которые оказались никому не нужными. Практически в каждом продукте есть фичи, которыми почти никто не пользуется. Возможно, они имеют внутри великолепный код и блестящую архитектуру, но nobody cares ^[3]. Разработчики этих продуктов и фич бежали не в ту сторону.

Выбор верного направления в разработке продуктов — невероятно сложная штука. Ошибаются все. Интуиция не работает. Коллективный разум выдает удивительно неверные решения. Формальную модель построить сложно. Даже опыт помогает далеко не всегда. Если мы побежали не в ту сторону, становится совершенно неважно, с какой скоростью мы бежим. Ну разве что мы окажется в неправильном месте быстрее. И там нас никто не ждет.

Что можно сделать, чтобы выбирать правильное направление? Делать быстрые прототипы и проверять концепции. Строить простые модели и учитывать паттерны поведения пользователей. Обложить систему статистикой и научиться понимать, какие фичи используют, а какие не очень. Решений много и все они несовершенны. Крайне важно понять, что выбор направления — это самая важная штука в разработке. Если направление верное — мы рано или поздно будем наслаждаться солнышком и морем. Если нет — нас ждут дождливые ночи в жопе мира.

Дистанция

В беге есть довольно много разных дистанций, но их можно разделить на три типа: спринт, средняя дистанция, марафон. Бегуны каждого типа не особенно похожи друг на друга. Вот забавное видео ^[4], которое неплохо все объясняет.

Есть ли разные типы разработчиков? Думаю, вполне можно выделить два типа по аналогии с бегом: спринтеров и стайеров.

Спринтеры	Стайеры
Делают очень быстро, не думают о поддержке	Делают медленно, сопровождение важно
Пишут крутой непонятный другим код	Пишут простой и понятный код
Прыгают с проекта на проект	Долго работают на одном проекте

Дистанция в разработке — это продолжительность релиза. Возникает вопрос, хорошо ли бегать марафон? Судя по всему, марафон может быть опасен для жизни. Не так много существует видов спорта, в которых люди умирают, не достигнув скорости в 30 километров в час. Марафон не полезен для здоровья и может вызывать множество побочных эффектов, включая остеоартрит, тендинит, проблемы с сердцем, уменьшение плотности костей и так далее ^[5].

Ну хорошо, марафон вообще опасен, а как насчет спринта? Как нетрудно догадаться, с ним тоже все не так радужно ^[6]. Бегая спринт, гораздо легче заработать растяжение да и нагрузка на сердце получается серьезная. Но все же бегать спринты гораздо безопаснее, чем марафон.

Как обычно, бег на средние дистанции с не очень высоким темпом выглядит золотой серединой ^[7].

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

Наша цель — исключить длинные релизы.

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

Скорость

Люди бегают довольно медленно. Выдающиеся личности могут бежать со скоростью 38 км/ч, но очень недолго. Другие выдающиеся личности могут бежать со скоростью 20 км/ч два часа. А некоторые могут бежать сутки со скоростью 12 км/ч. Вообще люди отличаются необычайной выносливостью, и вполне могу загнать антилопу ^[8] за несколько часов непрерывного преследования.

На длинной дистанции мы не можем бежать очень быстро. Что будет, если пытаться это делать?

И вот начинается забег на пять километров. Знаменитый спринтер Григорий Колодкин возглавляет забег и бежит в гордом одиночестве. Вот он преодолевает первые круги дистанции с невероятным отрывом. Он наращивает темп и ему кажется, что финиш вот-вот наступит. Григорий с удивлением выясняет, что до финиша еще 4 километра, а бежать дальше организм отказыватся. У организма есть существенные аргументы, он вообще удивлен, как смог пробежать целый километр в таком темпе. Григорий переходит на бег трусцой, восстанавливая дыхание и мышцы. Пелотон настигает Григория на третьем километре дистанции, последний бегун пелотона дружески хлопает Григория по плечу и легко устремляется вперед.

А теперь давайте возьмем команду программистов. Она спокойно, в своем темпе работает над релизом. Тут приходит менеджер проекта и говорит “ребята, надо быстрее! У нас важный дедлайн!” Команда говорит “надо, значит надо” и прибавляет темп. Через пару месяцев оказывается, что к дедлайну не успеть. Менеджер проекта произносит яркую мотивационную речь, после чего команда работает по воскресеньям, ночует в офисе, кушает пиццу, запивая ее Burn’ом, и колбасит код с невероятной скоростью. Но в один прекрасный момент наступает fuck it point. Менеджеру очень повезет, если fuck it point наступит после дедлайна. Достигнув этой знаменательной точки, команда работает в предельно низком темпе, с отвращением глядит на код, с омерзением исправляет новые баги и старается сделать все, чтобы не работать.

Чтобы бежать быстрее долго — нужна выносливость.

Возникает вопрос, как в беге тренируется выносливость? Один из хороших подходов — это интервальная тренировка ^[9].

Интервальная тренировка

Суть очень проста. Человек бегает, меняя темп. Сначала бежим с обычной скоростью, потом делаем ускорение, потом опять сбрасываем скоростью, потом вновь ускоряемся. Интервальная тренировка улучшает выносливость и увеличивает скорость.

Можно ли применить что-то похожее в разработке продуктов? Конечно же да. И это мы назовем интервальной разработкой.

Представим себе маленькую команду разработки, которая делает довольно большу фичу в продукте.

Фаза 1. Обычный темп (2 месяца)
Начинает команда в своем обычном темпе. Работает как умеет, не зацикливаясь ни на чем. Поработав так пару месяцев, команда переходит в ускоренный режим.

Фаза 2. Ускоренный темп (1 месяц)
Цель этого режима — фокус.

Команда убирает все собрания, которые не посвящены непосредственно фиче. Ежедневные стендап собрания, статус репорты и прочие собрания. Вы сможете прожить без них месяц. Точно сможете.

• На время работы выключатся все мессенджеры: Skype, ICQ (да ладно?), IRC и так далее. Если есть удаленные работники, канал оставляется только с ними. Можно выделять время на проверку почты и сообщений, но все равно нужно все минимизировать.
• Если людей из команды привыкли отвлекать представители других команд — вежливо попросите их подождать месяц. Пусть найдут себе других. Повесьте на дверь табличку “не беспокоить” и не отзывайтесь на мольбы о помощи.
• Попробуйте парное программирование. Когда сидишь в паре с другим человеком, не особенно овлечешься. Фокус будет держаться сам по себе.
• Никаких овертаймов!

Можете пробовать все, что угодно, но главная цель — сконцентрированно работать над фичей. Долой многозадачность! Долой все устоявшиеся рутинные дела! Через пару недель вас будет распирать от достигнутого. Чертовски приятно уходить домой, ощущая хороший прогресс и объем сделанных задач.

Четвертая неделя — это наш power lap. Последний рывок перед выпуском фичи в продакшн. Тут можно еще немножно ускориться, может зацепить какую субботу. Все доделать. И выпустить. Настоящие художники выпускают;

Фаза 3. Неделя релаксации (1 неделя)
Примерно через месяц первоначальный энтузиазм начинает спадать и сил двигаться дальше в таком же темпе не остается. И тут наступает момент релаксационной недели. В это время можно расслабиться, опаздывать на наботу, слоняться без дела и болтать о чем-то интересном. Можно недельку поработать над чем-то забавным.

Отдохнули? А теперь самое время взять новую фичу.

Такой режим работы имеет несколько теоретических преимуществ:

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

Фартлек

Кроме ритмичной интервальной тренировки есть еще и неструктурированная. Фартлек ^[10] придумали в Швеции для тренировки бегунов по пересеченной местности. Все очень просто:

В простейшей форме можно выделить 3 фазы: разогрев (бег в очень медленном темпе), быстрый бег и скоростной бег.

А что будет, если это применить к разработке?

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

Фаза 1. Медленная (1 месяц)
Неспеша создаем UX фичи, лениво пишем прототипы, исследуем архитектурные решения, думаем, читаем и обсуждаем все это за чашкой чая. Цель этой фазы — хорошенько понять, что же мы тут делаем и как это сделать лучше.

Фаза 2. Умеренная (2 недели)
Начинаем разработку в обычном темпе, разве что попытавшись немного притушить второстепенные активности.

Фаза 3. Ускоренная (2 недели)
Тут все так же, как и в обычной интервальной разработке — фокусируемся и изолируемся от внешнего мира. Впадаем в состояние потока и быстро двигаемся вперед.

Дальше мы пару раз чередуем фазы 2 и 3. И на выходе получаем готовую фичу.

В принципе, тут мы имеем просто другой микс интервалов. Что лучше работает я понятия не имею, но кажется это довольно индивидуально. Одной команде нужны частые смены темпа, другая может комфортно работать в высоком темпе месяц. Нужно посмотреть на контекст и попробовать.

Травмы

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

У разработчиков тоже есть свои травмы. Логическая цепочка будет такая:

Баги и малоподвижный образ жизни → Эмоциональное выгорание → Печеньки и кофе →
#безысходность ^[11].

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

Что же делать? “Ага, раньше же все бегали босиком. Почему бы нам не вернуться к истокам?” — подумали люди. И появилась техника бега босиком.

Кажется, решаются многие проблемы. Шаг становится короче и нет такой нагрузки на ноги. Босиком приземляться на пятку очень больно, так что приходится приземляться на носок. Кажется, всё прекрасно! Но не тут-то было ^[12]. Оказалось, что бег босиком увеличивает вероятность травм ахилла, голени и плюсневых костей стопы. Не говоря уже о мозолях.

Избавившись от одних проблемы, мы приобрели другие проблемы.

Тогда придумали смешные кроссовки, которые должны были, казалось, решить уже все проблемы. Вот они:

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

Так же выяснилось, что некоторым людям подходит тип бега на пятку, а некоторым — на носок. Так что все это очень индивидуально ^[13].

Ничего не напоминает? Давайте проведем аналогию с разработкой.

Бег	Разработка
Кроссовки — подушка безопасности между землей и ногой	Тестировщики — подушка безопасности между разработчиками и клиентами
Бег босиком	Выпуск фич без тестировщиков
Изменение техники бега, решение некоторых проблем, но увеличение других проблем	Изменение стиля разработки, решение некоторых проблем, но увеличение других проблем
Бег в смешных кроссовках	Выпуск фич без тестировщиков, но с автоматическими тестами

В самом деле, почти все разработчики не особенно любят тестировать. “На это есть тестировщики, чего нам тут возиться?” — резонно заявляют они. Это все прекрасно, но часто ведет к наплевательскому отношению. “Ну вот вроде все готово, сейчас отдадим тестерам, пусть поищут баги. Позитивные сценарии самим проходить некомильфо. Я лучше пойду почитаю про скалу”. В результате фича прыгает от тестировщика к разработчики несколько раз, пока все баги не поправят. Это увеличивает время разработки и снижает скорость (кстати, бег на носок на 5% быстрее, чем бег на пятку).

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

Можно немного подстраховаться и начать писать автоматические тесты. Уверенности станет побольше, но все равно не расслабишься.

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

Резюме

Давайте подведем итог. Мы провели четыре аналогии между бегом и разработкой.

1. Направление — выбор правильных фич
2. Сокращение дистанции — мелкие релизы и фичи
3. Увеличение скорости и выносливости — интервальная разработка
4. Снижение травматичности — выбор правильных практик

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

Автор: 9zloy

Источник ^[14]