ТЕХНОЛОГИИ

Форма тебя

Чем отличается ваша команда разработчиков?

Это статья не об Эде Ширане. Я никогда не был большим поклонником Эда Ширана, но мне интересно, начинает ли он привязываться ко мне. Мне нравятся некоторые синтезаторы, которые он использует :D

Помимо этого, одна из его песен «Shape of You» странным образом переходит к теме этой недели.

Вот так распределяется работа в нашей команде. Форма нашей команды как таковая — форма нас — или вас с вашей точки зрения.

Раньше нашим текущим ассортиментом продуктов управляли 3 команды. Со временем 3 команды объединились и… ну, теперь остались только мы.

У нас есть 8 разработчиков (включая архитектора, DevOps и руководителя SRE), руководитель группы и я владелец продукта. Всего 10 человек.

Как владелец продукта, я часто теряю счет приложениям, за которыми мы следим. Это где-то 40-60. Многие из них — маленькие приложения, но у нас есть и большие звери. Индивидуальные системы HR, Payroll, Rostering и Recruitment также находятся под нашим крылом.

Стандартный размер команды для нашего отдела — 6 разработчиков, но мы получаем еще двоих из-за нашей нелепой нагрузки на техподдержку!

Поддерживать

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

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

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

СРЭ

Итак, у поддержки есть топор, но вода для тушения этих пожаров поступает в виде SRE — Site Reliability Engineering.

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

В то редкое время затишья, которое бывает у техподдержки, они могут посвятить свое внимание небольшим тикетам SRE до того, как рухнет следующее здание.

Вот некоторые вещи, которые делает SRE:

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

Два человека работают над SRE одновременно и также чередуются в соответствии с поддержкой.

При доработке с помощью плагина Foxly Jira приоритет отдается работе SRE.

Функция

Остается 4 человека, работающих над Feature. Эти люди предъявляют новые требования и улучшают наши существующие системы. Иногда и новые системы. Вещи как:

  • Новые расчеты отпускных по заработной плате
  • Функциональность массовой загрузки для системы управления персоналом
  • Отправка данных в BigQuery
  • Интеграция с другими API в бизнесе

Я отдаю приоритет работе над функциями 😉 на основе таких вещей, как стоимость задержки, влияние на бизнес и миссию нашей команды.

Вращения

Поскольку поддержка чередуется в течение двухнедельного цикла — так же как и SRE — но это также распространяется на работу над функциями. Это означает, что все разработчики в команде имеют возможность заниматься тем, что они считают «интересной работой». Это не всегда Feature (у меня много предубеждений). Иногда SRE будет предпочтительнее!

Архитектор работает над поддержкой, а DevOps также просматривает некоторые заявки на кодирование. Только SRE Lead освобождается от ротации Feature work.

Тяни и толкай

По замыслу 50% команды заняты поддержкой и SRE, а остальные 50% будут активно работать над функциями. Этот процент может сместиться в пользу любого из 3-х потоков.

Если есть критическое бизнес-требование, Feature может позаимствовать у службы поддержки. Если одна из систем израсходовала весь свой бюджет SRE, то SRE возьмет взаймы у Feature и т. д.

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

Отслеживание проблем

У нас есть одна доска проектов в Jira. Запустив Канбан, у нас есть следующие дорожки:

  • Для поддержки
  • Ускорить SRE
  • СРЭ
  • Ускорить функцию
  • Особенность

Иногда на доске может быть немного тесно, но это излучатель информации!

Процесс

У нас есть документ о нормах сроков, в котором подробно описан наш процесс доставки. В качестве изюминки у нас есть следующие столбцы на нашей канбан-доске:

  • Отставание
  • Делать
  • В ходе выполнения
  • Заблокировано
  • Чтение для обзора
  • На рассмотрении (обзор должен быть сделан 2 разработчиками)
  • Готов к тесту
  • В тесте (тест должен быть выполнен 1 разработчиком)
  • Готов идти вперед
  • Сделанный

Как ни странно, снова Эд Ширан

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

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

Поскольку 50%-ное разделение системно интегрировано в наш процесс, я могу быть уверен, что все наши продукты со временем становятся лучше.

Это наша форма на очень высоком уровне. Как и в любой команде, наши процессы развивались с течением времени; я ожидаю, что они будут продолжать развиваться.

Может быть, немного похоже на музыку Эда Ширана.

Спасибо, что прочитали эту статью! Пожалуйста, оставьте комментарий ниже, если у вас есть какие-либо вопросы или отзывы.

Если вам понравилась эта статья, то, пожалуйста, купите мне кофе:

Крис Шелдон — руководитель проектов в DataArt Ltd. DataArt – это глобальная компания по разработке программного обеспечения, которая использует уникальный человеческий подход к решению проблем.

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

Крис окончил Университет Рединга в Великобритании по специальности «Электронная инженерия и кибернетика».

Немного энтузиаст Agile, ботаник продуктивности и Wantrepreneur Крис действительно должен решить, чем он хочет заниматься в жизни, и сосредоточиться.

Вы можете связаться с ним в LinkedIn, Twitter, Facebook или посетить его веб-сайт, >ИЦКрис Шелдон