Не стройте процессы ради процессов. Необходимо понимать, зачем нужен процесс, желательно, чтобы вся команда понимала это. Из предыдущих лекций вы знаете, что из себя представляют фреймворки по управлению проектами Scrum, Agile (подробнее здесь). Мы тоже строим процессы, но все бессмысленно, если вы не отвечаете на три главных вопроса: Зачем вы строите процесс? Когда вы начинаете строить процесс? О каких процессах идет речь? Если нет ответа на эти вопросы, ни одна философия управления проектами не поможет.
Синхронизация (daily standup/ weekly …)
Команда должна понимать, кто что делает и куда она движется в целом. Неважно, какой формат синхронизации вы выберете, он должен быть удобен для вас. Может получиться так, что вам удобнее всего писать в чат, и это нормально.
Одна из практик, которую применяют приверженцы принципов Agile, – стендап митинг. В рамках стендапа все делятся результатами своей деятельности. Однако зачастую стендап скучен и неэффективен, и вообще далек от своего идеального вида. Скучным стендап бывает, потому что сотрудники не понимают, чем занимаются другие, или им неинтересно, или все происходящее длится слишком долго. Может случиться так, что стендап вообще не нужен. Для нашей команды стендапы эффективны – они позволяют нам быстро синхронизироваться, а главное – дают мне понимание того, кто чем занимается. Есть команды, которым нужно синхронизироваться не каждый день, а, скажем, раз в неделю. Однако даже в случае с обычным стендапом нужно понимать, каковы цели этого мероприятия. Когда мы вводим новые процессы, это мешает людям работать, особенно если работа уже была налажена. Для эффективной работы лучше, чтобы всем было интересно заниматься своими задачами. Если людям неинтересно, на стендапе вы это поймете.
EAP, Feature Freeze и CD/CI
Каждый бизнес ставит свои задачи. В нашем случае это выпуск релизов каждые четыре месяца с функциональностью и качеством, соответствующим ожиданиям пользователя. В отделе .NET-разработок JetBrains мы делаем множество продуктов. В отделе работают 100 человек с 200 тысячами файлов и суммарным объемом более 20 миллионов строк кода, при этом все наши продукты должны работать на нескольких платформах. В последнее время мы делаем около 1000 коммитов каждый день. Соответственно, нужны процессы, которые позволят стабильно двигаться с таким багажом.
Так, нам помогает планирование bugfix (исправление программных ошибок). Будьте готовы к тому, что, помимо планового, может понадобиться bugfix через час после релиза. Процессы существуют для того, чтобы свести вероятность этого к минимуму, но 100% гарантию никто не даст.
Чтобы укладываться в срок, мы делаем EAP (Early Access Program) – этот инструмент мы придумали 15 лет назад в JetBrains, сегодня им пользуются и другие команды разработчиков. EAP обеспечивает ранний доступ к тому, что мы делаем. В начале релизного цикла мы открываем EAP, это значит, что в начале релизного цикла мы доделываем фичи, которые остались с прошлого раза, просто творим и затем выходим на еженедельный цикл, когда стабильно выпускаем версию (программы), которой будут пользоваться. Это необходимая мера, потому что мы работаем с desktop продуктом, это не веб-сервер, доступ к которому можно предоставить пользователю, а если что-то не получилось, откатиться на рабочую версию. Мы работаем с продуктом, который пользователь должен себе установить сам, поэтому нам нужен механизм, позволяющий большому числу людей его протестировать (протестировать руками 20 миллионов строк кода нельзя, а 100% покрытие кода – это фантастика). В результате 5-10 % пользователей готовы пользоваться ЕАР-версиями.
Вторая важная вещь – в определенный момент мы начинаем работать циклично и знаем, чего ожидать. Если разработчик хочет, чтобы фича попала к пользователю, это значит, что она до определенного момента должна оказаться в основной рабочей ветке и быть протестированной. Если разработчик не успевает, фича не попадает в этот цикл (но может попасть в следующий). Это понимание важно, потому что дает представление, как все будет работать, как устроены приоритеты, что тебе больше нужно – завершить фичу или починить баги. EAP – это способ доставить пользователю то, что мы уже сделали, однако хочется также не утонуть в потоке фидбека от пользователя, поэтому стоит выпускать версию в приличном виде.
Feature Freeze – это место, после которого никакого нового функционала в разработку мы не добавляем, иначе мы не стабилизируем систему (любую новую функциональность нужно протестировать сначала внутри, потом предоставить пользователю, написать по ней документацию, поэтому чем меньше остается времени до релиза, тем меньше вероятность, что это будет сделано качественно). Feature Freeze в нашем случае назначается за месяц до релиза. Поэтому за месяц до релиза и после можно только чинить то, что уже загружено в версию. Мы намеренно отводим месяц на стабилизацию, потому что важно предоставлять качественный продукт – пусть в нем будет меньше фич, но он будет стабильным.
Нужно останавливать разработку, особенно если система большая. Остановка разработки нужна не всем: если вы делаете сайт, вы можете предоставить доступ к пробной версии для небольшого количества пользователей, а параллельно будет работать стабильная версия. Но, если речь о desktop продукте или чем-то большом, важно остановить разработку и стабилизировать систему.
CD (Continuous delivery – «непрерывная доставка») — это программный подход, в котором пользователю постоянно доставляется новая версия продукта с новым функционалом. CD гарантирует, что у вас всегда все в рабочем состоянии.
CI (Continuous integration – «непрерывная интеграция») — это практика разработки программного обеспечения, которая заключается в слиянии рабочих копий в общую основную ветвь разработки несколько раз в день и выполнении частых автоматизированных сборок проекта для скорейшего выявления потенциальных дефектов и решения интеграционных проблем. Без CI не сможет работать все вышеперечисленное, особенно CD. Все, что вы разрабатываете, должно постоянно собираться и тестироваться, желательно автоматически, без вашего участия (1000 коммитов в день никто руками не протестирует). В результате вы получаете автоматическую систему сборки проекта, которая включает в себя маленькие подсистемы сборки – это и компиляция отдельных частей продукта, сборка продукта целиком, запуск всех тестов (в нашем случае их больше 100 тысяч) и другое. Кроме того, CI позволяет тестировать производительность вашего продукта (узнать подробнее можно здесь и здесь) – без дополнительных усилий вы получаете систему, которая мониторит, насколько хорошо работает приложение.
Тематические недели – эту технику мы ввели совсем недавно. Последняя неделя была посвящена bugfix. Как правило, отдел тестирования подготавливает для команды разработчиков список всего, что им необходимо починить. Никто из разработчиков не любит чинить баги, но, когда поле деятельности подготовлено заранее, такая работа не вызывает раздражения, наоборот, воодушевляет. Это очень полезная практика.
Тестов много не бывает. Тесты позволяют убедиться, что после внесения изменений в код, продукт продолжает работать. Если у вас много тестов, когда вы что-то меняете, и ваши тесты продолжают быть зелеными, значит, ваш продукт в стабильном состоянии.
Роботы-протекторы
Если есть возможность, делайте роботов. Это триггер, который сработает до того, как что-то пошло не так. Мы всегда боремся за зеленые тесты, которые означают, что билд, который вы возьмете с CI, скорее всего рабочий. Мы завели merge-robot – конструкцию, которая построена поверх CI. Merge-robot гарантирует, что тесты, которые мы написали, проходят. Но они покрывают только известные потенциальные проблемы. Ручное тестирование позволяет найти то, о чем не подумали, и после починки написать на это новый тест. Чем лучше набор тестов, тем больше вероятность, что продуктом можно пользоваться сразу.
Однако merge robot решает далеко не все проблемы. Первая проблема состоит в том, что избавиться от всех внешних зависимостей очень сложно, а эти внешние зависимости могут оказаться недоступны. Например, при попытке заблокировать Telegram сервера nuget.org оказались недоступны, что заблокировало нам возможность выкладки продукта. Другая проблема – нестабильно работающие тесты (то, с чем надо бороться в первую очередь). Пока мы не изжили все нестабильно работающие тесты, у нас есть практика четырех прогонов, иначе из-за случайно падающих тестов слишком много мержей может не пройти. Одна из тематических недель посвящена починке моргающих тестов (тесты, которые работают нестабильно).
Робота можно обучить полезным трюкам, например, сообщать в чат, что происходит. Отдел тестирования очень любит наблюдать за тем, как робот оповещает, кто из разработчиков над чем работает в данный момент времени. Это удобно, потому что у нас минимум бумажек, в которых написано кто чем занимается, а отдел тестирования понимает, что происходит.
Хвастаться и хвалить
Важно, чтобы внутри команды была культура позитивного общения, вы можете хвалить и хвастаться. Чатик используется также для хвастовства – разработчики после создания новой фичи могут рассказать об этом в чате и сразу же получить мотивирующий фидбек. В чатике можно оценить проделанную работу, поставив лайк. Что еще важнее – ниже образуется обсуждение, сотрудники подсказывают много классных идей. Когда обсудили и все пожелания учли, мы переходим к практике «фиче-порка».
Фиче-бранчи и «порки»
Прежде чем новая функциональность выходит в продакшн, все желающие (в том числе из других офисов) могут прийти и задать разработчику вопросы, как фича будет работать в определенных условиях, могут что-то порекомендовать. Обычно качество фич становится намного выше после таких «экзекуций». Это занимает полтора часа времени, но заметно улучшается качество, сотрудники технической поддержки и технические писатели узнают подробности новой функциональности прямо от автора, им проще описывать ее в документации.
