[Разработка мобильных приложений, Управление разработкой, Управление проектами, Управление персоналом] Масштабируем команду мобильной разработки: как мы в Ozon справились с ростом до 44 iOS, Android и QA на одном приложении
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет, меня зовут Влад, я iOS-разработчик в команде мобильной разработки Ozon.У нас в компании 8 мобильных приложений и почти столько же мобильных команд. Конкретно наша работает с приложением для покупателей. Когда нас было немного, по 6-10 человек в iOS, Android и QA–командах, мы отлично справлялись с задачами. Однако с ростом столкнулись с проблемой: чем больше у тимлида людей в подчинении, тем меньше времени он может уделить каждому и меньше времени имеет на погружение в задачи. В итоге качество управления команд начинало ухудшаться и с этим нужно было что-то делать. Решение мы нашли в распределении команд по стримам. В этой статье расскажу как у нас организована работа для 30+ мобильных разработчиков и 14 QA: как мы планируем, делимся знаниями и что нам даёт этот подход.Как распределена мобильная команда и с чего всё началось Началось всё с небольшой команды из нескольких iOS, Android и QA, вместе работающих над приложением.
Когда мы столкнулись с проблемой ухудшения качества управления командой из-за роста числа людей в мобильной разработке, мы перебрали разные схемы реорганизации и в итоге остановились на концепции стримов: разделении всех мобильных разработчиков и тестировщиков на небольшие команды.Как устроены стримыКаждый стрим — это отдельная продуктовая команда, состоящая из 3–6 человек (iOS, Android, QA), вместе работающих над одной задачей. Состав всегда фиксированный и не меняется от проекта к проекту. В каждой команде есть свой лид – это разработчик или тестировщик, совмещающий основную роль и роль менеджера проекта команды. Такой человек не меняется от проекта к проекту и занят взаимодействием с внутренними заказчиками, предварительной оценкой сроков и сложности задач и планированием кто, чем и когда будет заниматься. В общем и целом, лид организовывает работу своего стрима. Это даёт возможность каждой команде работать как самостоятельный юнит.
Вопросами архитектуры, скорости работы приложения и тому подобным занимается команда стрима платформы. Её курирует два лида, которые одновременно являются тимлидами всей iOS и Android–команды. Вопросами обновления приложений занимаются релиз-мастера. Это двое разработчиков (по одному на каждую платформу – iOS и Android), которые занимаются всем, что связано с обновлением: от создания релиз-кандидатов до исправления или делегирования релизных багов. У нас еженедельный цикл обновления, поэтому новые релиз-мастера назначаются каждую неделю.Как мы планируем работуУ нас существует три типа планирования:
- командное планирование с внутренними заказчиками;
- между всеми командами мобильной разработки;
- внутри каждой команды.
Командное планирование с внутренними заказчикамиВнутренние заказчики – это менеджеры проектов вертикали, где вертикаль – это выделенное направление бизнеса. Например, у нас есть вертикали: маркетинга, товаров, избранного, личного кабинета и так далее. Лиды стримов самостоятельно планируют ресурсы своей команды, задачи и приоритеты с вертикалями. По новым задачам назначаются собрания, на которых встречаются: менеджер вертикали, фронт, бэк, мобильная разработка и дизайнеры. Все вместе разбираем дизайн, планируем реализацию, а потом прорабатываем контракт – то, как будут приходить данные с бэка, приступаем к разработке.
Планирование между командамиТут формат такой: ежедневный стендап (Lead Sync), на котором руководитель отдела мобильной разработки обсуждает вместе с лидами команд текущие и планируемые задачи, регулируют приоритеты и иногда делится интересными историями.
С приходом удалённой работы Lead Sync стали проводиться в формате видео–конференции, куда может прийти любой сотрудник. Своего рода политика открытости. Отдельно от Lead Sync проводим короткий Release Sync, где встречаются все причастные к обновлению: представители или лиды из продуктовых команд, команд Travel, Express, релиз-мастера, руководители QA и мобильной разработки. Вместе смотрим критичные баги, определяем, какие задачи идут в обновление, проверяем метрики. Release Sync также открыт для всех желающих. Из особенностей: команды Travel и Express – обособленные. У них свои внутренние заказчики, своё планирование задач и свой бэклог, но мы живём в одном приложении, поэтому релиз планируем все вместе.Локальное планирование на уровне командыКаждый разработчик пишет Daily Report в чат своего стрима: что удалось сделать вчера и что планирует сделать сегодня. Дополнительно может проводиться общий звонок, на котором лид рассказывает новости, а также проходит обсуждение статусов, рабочих вопросов или разбор новых задач.
Обмен знаниями между командамиС приходом удаленной работы основным способом шаринга знаний между командами стали: комментарии и обсуждения на merge request, переписки в чатах, общие звонки по рабочим вопросам, Lead Sync и Tech Talk. Мы придерживаемся концепции: каждый разработчик проводит code review каждого. На практике, на свой merge request нужно получить два апрува. Если разрабатывается core–компонент, обязательно code review от кого-то из платформенного стрима, для всего остального один апрув нужен от своего стрима, а второй от любого разработчика из своей команды (iOS или Android). Такой подход позволяет получить code review с глубоким пониманием контекста и немного делиться знаниями между разработчиками. Но даже при таком подходе внимание разработчиков остается сосредоточенным на своих задачах и модулях, и они не могут уследить за всем, что делают другие команды. У нас есть библиотека компонентов, но если не актуализировать знания стримов, можно не знать о похожем виджете и заниматься разработкой мало отличающегося дубля. Эту проблему помогает решить Lead Sync, то есть шаринг знаний о проекте между лидами стримов. Остальное покрывает еженедельный Tech Talk , один для iOS, другой для Android-разработчиков основного приложения. На время удалённой работы Tech Talk проводим онлайн. На нём делимся новостями, рассказываем, что интересного сделали за последнее время, выступаем с докладами или обсуждаем новые технологии. Ещё проводим Mobile Demo, на котором менеджеры проектов презентуют разработанные фичи, отвечают на вопросы и собирают обратную связь. Это позволяет шарить знания о проекте между вертикалями и командами приложения для покупателей.Что нам даёт распределение по стримамС точки зрения управления, преимущество распределённых команд в том, что менеджмент делегирован лидам. Это позволяет командам самостоятельно взаимодействовать с заказчиками вертикалей, планировать и организовывать свою работу. Состав стрима – от 2–6 человек, (или по 1–2 тройки iOS+Android+QA), позволяет лиду уделять должное внимание каждому человеку из команды. При условии, что каждая пара iOS+Android работает одновременно над одной задачей, это даёт возможность прорабатывать весь поток задач от менеджеров вертикалей, а также качественно планировать и контролировать результат. Это не значит, что стримы можно предоставить самим себе и пустить всё на самотёк. Им обязательно нужна синхронизация между собой и регулировка приоритетов. С точки зрения разработчика схема со стримами даёт возможность сосредоточиться непосредственно на разработке—лид уже всё обсудил с вертикалями, провёл предварительную оценку и подготовил задачи. Вдобавок, распределение по стримам позволяет не распылять внимание по всему большому приложению, а сосредоточиться на своей небольшой части. При разработке новых фич или исправлении багов такой подход даёт разработчику более глубокое понимание, с чем он имеет дело.Кому подходит схема масштабирования мобильной разработки по стримамТут в статье я рассказал о борьбе с проблемами масштабирования команды мобильной разработки – о нашем опыте, но не методологии. Для нас сработали стримы, три уровня планирования и ритуалы удалённого шаринга знаний. Если разобраться, то новая структура – это воспроизведение старой схемы, только в меньшем масштабе, с вариациями; не революционное изменение, но эволюционное. Пойдёте делить у себя одну большую команду мобильной разработки на несколько небольших, посмотрите не только на чужой опыт (вроде нашего в Ozon), но и на то, как прямо сейчас устроена та самая изначальная большая команда. Думаю, там будут отличные идеи по развитию, в уже существующей структуре. Обязательно рассказывайте, что у вас получится в масштабировании мобильной разработки! Очень любопытно сравнить с нашим опытом.
===========
Источник:
habr.com
===========
Похожие новости:
- [Управление разработкой, Управление проектами, Agile, Управление продуктом] Топ-10 граблей начинающего скрам-мастера
- [IT-инфраструктура, Дизайн мобильных приложений, Дизайн] Дизайн-система IVI. Взгляд изнутри. Часть 2
- [Управление персоналом] Дисциплина — это хорошо или плохо?
- [Управление персоналом, Карьера в IT-индустрии, Читальный зал] Где сядешь — там и слезешь. Тенденциозные вопросы программистам и их последствия
- [IT-компании] Dropbox открывает в США Dropbox Studios — постпандемийные офисные пространства
- [Разработка мобильных приложений, Разработка под Android, Монетизация мобильных приложений, Законодательство в IT] Google начала препятствовать открытию магазина Samsung Galaxy Store
- [Программирование, Разработка мобильных приложений, Конференции, Flutter] Анонс эфира Flutter live-coding сессии
- [IT-инфраструктура, CRM-системы, Service Desk, Управление персоналом] Если сотрудник убьёт сервис, он убьёт вашу компанию. Остановите его
- [Управление проектами, Управление продуктом, Конференции, IT-компании] BeeTech 2021: обзор докладов про менеджмент, RPA, управление продуктом, исследования и стартапы
- [Разработка мобильных приложений, Законодательство в IT, IT-компании] ДИТ собрался отдать на аутсорсинг обслуживание системы мониторинга местоположения граждан с подтвержденным коронавирусом
Теги для поиска: #_razrabotka_mobilnyh_prilozhenij (Разработка мобильных приложений), #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_proektami (Управление проектами), #_upravlenie_personalom (Управление персоналом), #_timlid (тимлид), #_ios, #_android, #_blog_kompanii_ozon_tech (
Блог компании Ozon Tech
), #_razrabotka_mobilnyh_prilozhenij (
Разработка мобильных приложений
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_proektami (
Управление проектами
), #_upravlenie_personalom (
Управление персоналом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 07:56
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Привет, меня зовут Влад, я iOS-разработчик в команде мобильной разработки Ozon.У нас в компании 8 мобильных приложений и почти столько же мобильных команд. Конкретно наша работает с приложением для покупателей. Когда нас было немного, по 6-10 человек в iOS, Android и QA–командах, мы отлично справлялись с задачами. Однако с ростом столкнулись с проблемой: чем больше у тимлида людей в подчинении, тем меньше времени он может уделить каждому и меньше времени имеет на погружение в задачи. В итоге качество управления команд начинало ухудшаться и с этим нужно было что-то делать. Решение мы нашли в распределении команд по стримам. В этой статье расскажу как у нас организована работа для 30+ мобильных разработчиков и 14 QA: как мы планируем, делимся знаниями и что нам даёт этот подход.Как распределена мобильная команда и с чего всё началось Началось всё с небольшой команды из нескольких iOS, Android и QA, вместе работающих над приложением.  Когда мы столкнулись с проблемой ухудшения качества управления командой из-за роста числа людей в мобильной разработке, мы перебрали разные схемы реорганизации и в итоге остановились на концепции стримов: разделении всех мобильных разработчиков и тестировщиков на небольшие команды.Как устроены стримыКаждый стрим — это отдельная продуктовая команда, состоящая из 3–6 человек (iOS, Android, QA), вместе работающих над одной задачей. Состав всегда фиксированный и не меняется от проекта к проекту. В каждой команде есть свой лид – это разработчик или тестировщик, совмещающий основную роль и роль менеджера проекта команды. Такой человек не меняется от проекта к проекту и занят взаимодействием с внутренними заказчиками, предварительной оценкой сроков и сложности задач и планированием кто, чем и когда будет заниматься. В общем и целом, лид организовывает работу своего стрима. Это даёт возможность каждой команде работать как самостоятельный юнит.  Вопросами архитектуры, скорости работы приложения и тому подобным занимается команда стрима платформы. Её курирует два лида, которые одновременно являются тимлидами всей iOS и Android–команды. Вопросами обновления приложений занимаются релиз-мастера. Это двое разработчиков (по одному на каждую платформу – iOS и Android), которые занимаются всем, что связано с обновлением: от создания релиз-кандидатов до исправления или делегирования релизных багов. У нас еженедельный цикл обновления, поэтому новые релиз-мастера назначаются каждую неделю.Как мы планируем работуУ нас существует три типа планирования:
 Планирование между командамиТут формат такой: ежедневный стендап (Lead Sync), на котором руководитель отдела мобильной разработки обсуждает вместе с лидами команд текущие и планируемые задачи, регулируют приоритеты и иногда делится интересными историями.  С приходом удалённой работы Lead Sync стали проводиться в формате видео–конференции, куда может прийти любой сотрудник. Своего рода политика открытости. Отдельно от Lead Sync проводим короткий Release Sync, где встречаются все причастные к обновлению: представители или лиды из продуктовых команд, команд Travel, Express, релиз-мастера, руководители QA и мобильной разработки. Вместе смотрим критичные баги, определяем, какие задачи идут в обновление, проверяем метрики. Release Sync также открыт для всех желающих. Из особенностей: команды Travel и Express – обособленные. У них свои внутренние заказчики, своё планирование задач и свой бэклог, но мы живём в одном приложении, поэтому релиз планируем все вместе.Локальное планирование на уровне командыКаждый разработчик пишет Daily Report в чат своего стрима: что удалось сделать вчера и что планирует сделать сегодня. Дополнительно может проводиться общий звонок, на котором лид рассказывает новости, а также проходит обсуждение статусов, рабочих вопросов или разбор новых задач.  Обмен знаниями между командамиС приходом удаленной работы основным способом шаринга знаний между командами стали: комментарии и обсуждения на merge request, переписки в чатах, общие звонки по рабочим вопросам, Lead Sync и Tech Talk. Мы придерживаемся концепции: каждый разработчик проводит code review каждого. На практике, на свой merge request нужно получить два апрува. Если разрабатывается core–компонент, обязательно code review от кого-то из платформенного стрима, для всего остального один апрув нужен от своего стрима, а второй от любого разработчика из своей команды (iOS или Android). Такой подход позволяет получить code review с глубоким пониманием контекста и немного делиться знаниями между разработчиками. Но даже при таком подходе внимание разработчиков остается сосредоточенным на своих задачах и модулях, и они не могут уследить за всем, что делают другие команды. У нас есть библиотека компонентов, но если не актуализировать знания стримов, можно не знать о похожем виджете и заниматься разработкой мало отличающегося дубля. Эту проблему помогает решить Lead Sync, то есть шаринг знаний о проекте между лидами стримов. Остальное покрывает еженедельный Tech Talk , один для iOS, другой для Android-разработчиков основного приложения. На время удалённой работы Tech Talk проводим онлайн. На нём делимся новостями, рассказываем, что интересного сделали за последнее время, выступаем с докладами или обсуждаем новые технологии. Ещё проводим Mobile Demo, на котором менеджеры проектов презентуют разработанные фичи, отвечают на вопросы и собирают обратную связь. Это позволяет шарить знания о проекте между вертикалями и командами приложения для покупателей.Что нам даёт распределение по стримамС точки зрения управления, преимущество распределённых команд в том, что менеджмент делегирован лидам. Это позволяет командам самостоятельно взаимодействовать с заказчиками вертикалей, планировать и организовывать свою работу. Состав стрима – от 2–6 человек, (или по 1–2 тройки iOS+Android+QA), позволяет лиду уделять должное внимание каждому человеку из команды. При условии, что каждая пара iOS+Android работает одновременно над одной задачей, это даёт возможность прорабатывать весь поток задач от менеджеров вертикалей, а также качественно планировать и контролировать результат. Это не значит, что стримы можно предоставить самим себе и пустить всё на самотёк. Им обязательно нужна синхронизация между собой и регулировка приоритетов. С точки зрения разработчика схема со стримами даёт возможность сосредоточиться непосредственно на разработке—лид уже всё обсудил с вертикалями, провёл предварительную оценку и подготовил задачи. Вдобавок, распределение по стримам позволяет не распылять внимание по всему большому приложению, а сосредоточиться на своей небольшой части. При разработке новых фич или исправлении багов такой подход даёт разработчику более глубокое понимание, с чем он имеет дело.Кому подходит схема масштабирования мобильной разработки по стримамТут в статье я рассказал о борьбе с проблемами масштабирования команды мобильной разработки – о нашем опыте, но не методологии. Для нас сработали стримы, три уровня планирования и ритуалы удалённого шаринга знаний. Если разобраться, то новая структура – это воспроизведение старой схемы, только в меньшем масштабе, с вариациями; не революционное изменение, но эволюционное. Пойдёте делить у себя одну большую команду мобильной разработки на несколько небольших, посмотрите не только на чужой опыт (вроде нашего в Ozon), но и на то, как прямо сейчас устроена та самая изначальная большая команда. Думаю, там будут отличные идеи по развитию, в уже существующей структуре. Обязательно рассказывайте, что у вас получится в масштабировании мобильной разработки! Очень любопытно сравнить с нашим опытом. =========== Источник: habr.com =========== Похожие новости:
Блог компании Ozon Tech ), #_razrabotka_mobilnyh_prilozhenij ( Разработка мобильных приложений ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_upravlenie_proektami ( Управление проектами ), #_upravlenie_personalom ( Управление персоналом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 07:56
Часовой пояс: UTC + 5