GitHub как единственное средство общения

GitHub в нашем стартапе — единственный инструмент общения для команды из десяти разработчиков. У нас нет Jira, Slack или Asana, Telegram-чат мы завели для мемов, а Trello используем только для общения с бизнесом.

Мы делаем платформу «ГдеМатериал», которая даёт доступ рыночным поставщикам стройматериалов к крупным заказчикам, а заказчикам — доступ к отличным ценам, гарантиям наличия и быстрой логистике. У нас полностью распределённая команда разработки, построенная по принципам Basecamp: мы не учитываем рабочие часы, уважительно относимся к личному времени, а вместо чата используем почту.

Ниже не будет рассказа о том, как закрывать задачи при помощи коммитов или настраивать автодеплой. Это статья про роль GitHub во внутренних процессах небольшой команды разработки.

Менеджеры спорят про выбор таск-трекера не меньше, чем программисты про выбор IDE. Лично меня тошнит от Jira с её тормознутостью и жёсткими конвейерными воркфлоу. Функции Jira хороши для больших команд, но мы пока стартап, и хочется тратить больше денег на зарплату специалистов, а не на настройку инфраструктуры.

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

В основном нам хватает стоковой функциональности — открытого и закрытого состояния задачи (а вам правда нужно больше?), назначения ответственного и возможности комментирования. Для планирования спринтов идеально подходят встроенные майлстоуны. Спринты в них выглядят примерно так:

Раз в две недели руководитель команды закидывает задачи в следующий майлстоун, согласовывает распределение ресурсов сначала с руководителем команды, а затем с каждым участником отдельно. После начинается новый спринт.

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

Достаточно быстро количество репозиториев выросло до пяти, и нам стало неудобно ставить задачи, по которым нужно коммитить в несколько мест — к примеру, одновременно во фронтенд и в бэкенд или в два микросервиса.

Чтобы хранить задачи в одном месте, мы создали отдельный административный проект, который так и назвали — «А». Проект содержит общие вещи для всех репозиториев: документацию, задачи, планы на спринт.

После появления где-то шестого разработчика нам захотелось прозрачности в отношениях с бизнесом — мы решили публиковать общедоступном месте статусы задач и бэклог (берём или не берём в спринт), а так же напрямую соединять заказчика и программиста в задачах, где это уместно.

Для публикации статусов мы завели доску в Trello, который интегрировали в GitHub. Она состоит из шести колонок — Backlog, Discuss, Next Sprint, Active, Deploy и Done. В карточках отчитываемся о ходе работ, публикуем промежуточные результаты и деплой-превью.

Задачи в GitHub привязаны к карточкам, но никакой синхронизации между ними нет. Какие-то плагины для синхронизации доступны в маркетплейсе Trello, но мы спокойно обходимся без них — просто раз в неделю проводим статус-чек с каждым стейкхолдером, где вместе перетаскиваем карточки между колонками.

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

У GitHub очень клёвые шаблоны задач. Шаблоны исключительно текстовые, а значит, никого ни к чему не обязывают. Если вы точно знаете, чего хотите, — можно всегда выкинуть штатный шаблон и просто написать свой текст.

У нас всего два шаблона — «Задача» и «Баг». Шаблоны максимально простые. Главное, для чего они нужны, — отвечать для всех на вопрос «мы делаем эту задачу, чтобы что?». Что изменится в бизнесе, когда выполним задачу?

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

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

У GitHub очень развитая система интеграций. Документация там настолько простая, что справится даже программист без большого опыта. Пример из реальной практики — мы в «ГдеМатериале» вводили стандарты оформления пулл-реквестов. Ничего особенного — просто называем их по-русски и требуем указать ссылку на задачу.

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

Вот ещё пример удачного расширения. Недавно мы осознали: команда выросла настолько, что пора бы уже начать более оперативно рассказывать всем об изменениях в проекте — не в конце спринта, как раньше, а сразу, как только закрыли задачу. Всего за два часа на Python написали простой скрипт, который ходит в API GitHub и рассылает всем письмо со списком закрытых вчера задач:

В небольших командах можно отказаться от зоопарка средств коллаборации — вам вполне хватит GitHub. Если хотите прозрачности, добавьте Trello.

Если вы задумываетесь, что вам не хватает функциональности GitHub — почитайте повнимательнее документацию. Возможно, лучше потратить пару дней на написание кода, чем убивать производительность и мотивацию переходом на толстую Jira.

Хотите почитать больше про управление командой разработки в стартапе? Подписывайтесь на мой Telegram-канал.

#github #инструменты