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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Направление

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

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

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

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

Дистанция

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

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

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

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

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

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

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

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

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

Скорость

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фартлек

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

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

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

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

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

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

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

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

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

Травмы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

Автор: 9zloy

Источник