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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0
25 комментариев
Написать комментарий...
Peters Wolfgang
Ответить
Развернуть ветку
Konstantin Kiselev

У вас в результате получился какой-то набор костылей и компот из самописных скриптов, трелло, 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? Что кстати бывает периодически.

Ответить
Развернуть ветку
Fedor Borshev
Автор
Почему вы не взяли нечто вроде 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, есть программы миграции.

Ответить
Развернуть ветку
Alex Baumgertner

Пробовали github projects (https://help.github.com/en/articles/creating-a-project-board)?

Ответить
Развернуть ветку
Fedor Borshev
Автор

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

Ответить
Развернуть ветку
Alex Baumgertner

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

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

Ответить
Развернуть ветку
Илитный Иксперт

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

Ответить
Развернуть ветку
Paul Marlow

Здравствуйте, пробовали ли GitHub CI? Если да - то как впечатления?

Ответить
Развернуть ветку
Dmitriy Ignatiev
мы просто включили в GitHub, с инструкцией ничего не трогать и лишь отвечать на комментарии

вы серьезно?) "ничего не трогать" уже реально работает?

Ответить
Развернуть ветку
Fedor Borshev
Автор

Ну да, у нас вроде бы взрослые люди работают :-)

А даже если и тронут — что страшного случится?

Ответить
Развернуть ветку
Dmitriy Ignatiev

да все мы взрослые люди, но вам просто везет пока что. Или у вас 2 представителя бизнеса... ну серьезно?! Даже просто промахнуться мимо нужной кнопочки по запарке - и вот уже что-то произошло. В целом, если вы довольны - отлично! Но такой подход в век повсеместного распределения прав выглядит слишком наивным. имхо.

Ответить
Развернуть ветку
Fedor Borshev
Автор

Кажется странным тратить время на настройку и поддержку контроля доступа только потому, что сейчас время такое.

Ответить
Развернуть ветку
Alex Baumgertner

Нужно выставить "Только чтение" по умолчанию и ничего страшного не случится.

Ответить
Развернуть ветку
Sergei Timofeyev

Внезапно это очень хорошо работает почти везде. Только забывают говорить что можно трогать, а что нет...

Ответить
Развернуть ветку
Denis Mokhin

Класс, спасибо! Узнал много нового: и про trello, и про notion... приходится постоянно учиться и осваивать что-то новое.

Ответить
Развернуть ветку
Viktor Mann

Обязательно держите нас в курсе!

Ответить
Развернуть ветку
Anton Kuzmich

ключевое слово во всей статье - "команда из десяти человек"

Ответить
Развернуть ветку
Alex Baumgertner

Команды большего размера очень часто неэффективны, по своему опыту могу сказать. Долгие согласования, утомительные стендапы (пока 15 человек выговорятся) и тд.

Оптимальный размер команды — 5-7 человек, см. правило двух пицц —https://habr.com/ru/company/omnidesk/blog/296620/

Ответить
Развернуть ветку
Victor Krylov

А есть расширение, которое ганта делает.

Ответить
Развернуть ветку
Victor Krylov

А есть расширение, которое ганта делает. как для трелло Элегант?

Ответить
Развернуть ветку
Alex Babak

Нужно ли выкладывать ли свой приватный код в чужой, не self-hosted, git — уже над этим можно подумать.

А если хочется по кусочкам переизобретать продукты Atlassian — почему бы и нет, всё развлечение.

Ответить
Развернуть ветку
Ivan Ganev

Жду статью "Комментарии в коде как единственное средство общения".

Ответить
Развернуть ветку
Семён Бочкарёв

Интерфейсы продуктов Atlassian действительно отличаются несколько... м, несколько альтернативным представлением о UX. Но вы фактически вместо ограничений одной платформы выбрали ограничения другой.
Из наиболее интересного для небольшой компании я видел Phabricator. Я не знаю, как он смотрится со стороны менеджера, но для разработчиков всё было удобно. Плюс он бесплатный при локальном развертывании.

Ответить
Развернуть ветку
Sebastian Pereiro
Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
22 комментария
Раскрывать всегда