Процессы

Состав Surf

На данный момент в Surf сушествует несколько четко определенных отделов:

• iOS
• Android
• Flutter
• Back-end и Front-end
• QA
• Дизайн-отдел
• Аналитика
• Управление проектами
• Marketing
• DevRel
• Продажи
• DevOps
• Отдел автоматизации и аналитики
• HR и рекрутинг
• Административный отдел

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

Рост и развитие сложно произвести без подобного разделения, где каждый будет заниматься своим делом, а вертикаль власти позволяет совершать более эффективное управление рабочими процессами. Но с ростом мы постарались сохранить дружескую и доверительную атмосферу: стоящая инициатива любого сотрудника по изменению любых процессов может воплотиться в жизнь. Либо после проведенного 1-1а с руководителем, либо пройдя через орг коммитет по принятию подобных глобальных инициатив в рамках всей студии.

Состав команд

Классическая команда на среднестатистическом проекте состоит из:

• платформенных разработчиков (либо по 2-4 iOS разработчика, и столько же на Android, либо 3-5 Flutter разработчиков);
  • может быть как и меньшее количество разработчиков, так и большее, в зависимости от масштаба проекта;
• аналитика (BA);
• тестировщика (QA);
• менеджера проекта (PM);
• дизайнера.

В зависимости от проекта некоторые роли могут быть отсутствовать, например, дизайнер или аналитик могут быть со стороны заказчика. Либо наоборот добавляться новые роли, например backend-разработчкик со стороны Surf. Но в целом стараемся придерживать именно такого формата команд, который позволяет вести проект более полноценно, вникая во все его аспекты, и позволяя выдать наиболее эффективное решение, как с точки зрения технической реализации, так и с точки зрения UX.

Backend команда в основном находятся либо на стороне клиента, либо реализуется силами другого подрядчика. В любом случае, между командами фронта и бэка налаживается коммуникация для решения повседневных вопросов.

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

Как ведется разработка

Flow работ может варьироваться в зависимости от проекта, далее представлен традиционный вариант реализации MVP-версии приложения, который поддерживается на большинстве проектов студии:

• начинается все с “нулевого спринта”, когда команда аналитиков, дизайнеров, лиды платформенных команд разработки и ЛПР со стороны клиента договариваются о базовых требованиях к проекту, проектируется и утверждается основной дизайн и ТЗ к нему;
• скоуп оценивается лидами платформенных команд, подбирается команда, утверждается смета проекта и даты сдачи;
• задачи всего скоупа делятся на спринты, каждый спринт содержит законченную фичу и идет приблизительно 2-3 недели;
• далее следует итеративная работа в рамках спринтов, где:
  • на вход команде разработке и QA поступают требования в виде ТЗ и макетов дизайна;
  • требования уточняются, устраняются все несоответствия между ТЗ, макетами и ожиданиями клиента;
  • задачи декомпозируются командой (верхнеуровневая декомпозиция проводится лидом команды, более детальная - в зависимости от проекта, может проводиться как лидом, так и разработчиками);
  • производится оценка скоупа (в зависимости от проекта может быть использован так и простой механизм с оценкой в часах, так и в story-поинтах, возможно применение poker-planning);
  • далее следует этап разработки;
  • этап отладки;
  • и все начинается по-новой.

Планирование и реализация задач построены следующим образом:

• во время этапы реализации спринта лид команды проводит планирование и доуточнение всех требований ТЗ для следующего спринта, производится верхнеуровневая декомпозиция
• когда задачи спринта сдаются и отправляются на тестирование - команда уже может приступать к более детальному проективанию и оценке задач следующей итерации, параллельно производя отладку по фидбеку от QA
• чтобы сразу после этого вступить в новую итерацию

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

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

Обеспечение качества

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

• code-review перед мержем любого изменения как неотемлемая часть работы любой команды
• осуществляется учет и работа с техдолгом: потенциально опасные места вносятся в реестр, дается оценка времени исправления, оценка риска влияния на продукт, выделяется время на решение основных угроз проекту
• design-review позволяет убедиться в корректности верстки и верной работе спроектированного UX
• периодические техретро и общекомандные ретро дают возможность обсудить назревшие проблемы, проанализировать прошедшие этапы, выявить ошибки и принять действия, которые не допустят совершения подобных ошибок в будущем