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

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

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

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

GitHub как таск-трекер

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

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

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

Спринты в интерфейсе GitHub
Спринты в интерфейсе GitHub

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

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

Рост: отдельный проект для задач (и Trello)

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

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

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

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

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

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

Шаблоны задач вместо дополнительных полей

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

Постановка задачи по шаблону в GitHub
Постановка задачи по шаблону в GitHub

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

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

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

API и готовые расширения

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

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

Результат проверки пулл-реквеста, наша проверялка — первая в списке
Результат проверки пулл-реквеста, наша проверялка — первая в списке

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

Такое письмо приходит каждому участнику команды
Такое письмо приходит каждому участнику команды

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

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

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

3434
25 комментариев
25
Ответить

У вас в результате получился какой-то набор костылей и компот из самописных скриптов, трелло, github'a, телеграмма.

Да и вообще статья больше похожа на пример как не надо делать. Во всяком случае сразу возникает куча вопросов:
1. Почему вы не взяли нечто вроде yandex connect, gitlab, asana?
2. Каким образом разработчики общаются между собой в режиме чата? Не через комменты на github'e же?
3. У вас бэклог в трелло вышел, а где держит бэклог бизнес? Вообще, кто является владельцем бэклога - программисты или бизнес?
4. Каким образом осуществляется code-review/деплой и как вы его встроили в свой процесс в github'e?
5. Где базу знаний ведет бизнес? На wiki github'a или у них отдельное место и они часть копипастят на GitHub?
6. Каким образом проводится аналитика по результатам спринта, хотя бы замер скорости команды? Если этого не делается, но откуда вы знаете сколько задач вообще сможете взять в спринт?
7. Какой план Б на случай падения/блокировки github'a? Что кстати бывает периодически.

2
Ответить

Почему вы не взяли нечто вроде yandex connect, gitlab, asana?

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


Каким образом разработчики общаются между собой в режиме чата?

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


У вас бэклог в трелло вышел, а где держит бэклог бизнес?

Он у всех в трелло, у бизнеса нет отдельного беклога.


Каким образом осуществляется code-review/деплой и как вы его встроили в свой процесс в github'e?

Code Review — стандартными средствами гитхаба. Деплой — через серкл: https://vc.ru/dev/56022-opyt-ispolzovaniya-circle-ci


Где базу знаний ведет бизнес?

В Notion


Каким образом проводится аналитика по результатам спринта, хотя бы замер скорости команды? Если этого не делается, но откуда вы знаете сколько задач вообще сможете взять в спринт?

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


Какой план Б на случай падения/блокировки github'a? Что кстати бывает периодически.

Блокировка — не страшно, у всех давно VPN есть, пригождается, к примеру для netlify. За два года использования гитхаб серьезно падал один раз, почти день общались только по почте. Никакого влияния на скорость это не оказало.

Если станет совсем плохо — переедем на GitHub Enterprise, есть программы миграции.

9
Ответить

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

1
Ответить

Круто!
Тоже думал о переходе на GitHub, останавливали необходимость обучения работы GitHub (дизайнерам, менеджерам нужно завести аккаунты и показать, как работать) и плата за каждого участника приватного репозитория (компания 150+ человек, > $1300/мес).

Для небольших команд думаю — GitHub хороший вариант, спасибо за статью!

Ответить

Вот когда мемы в гитхабе будете постить это и будет средство общение, а пока нет

1
Ответить