ТЕХНОЛОГИИ
Форма тебя
Чем отличается ваша команда разработчиков?
Это статья не об Эде Ширане. Я никогда не был большим поклонником Эда Ширана, но мне интересно, начинает ли он привязываться ко мне. Мне нравятся некоторые синтезаторы, которые он использует :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 или посетить его веб-сайт, >ИЦКрис Шелдон