Опыт внедрения компонентной разработки
Привет! Меня зовут Александр Омельяненко, я работаю тимлидом Flutter-команды в AGIMA. Расскажу, как и почему на одном из наших проектов мы внедрили компонентный подход к разработке и какие плоды нам это дало. В статье покажу основные плюсы и минусы нашего решения. А еще затрону прикладные моменты: на какие позиции мы поделили участников команды, какие обязанности им поручили и как документировали работу.
Описание методологии
Компонентная разработка подразумевает деление мобильного приложения на отдельные компоненты (фичи). За каждый из них отвечает конкретный разработчик — Feature-оунер. Часть времени он посвящает задачам компонента, а часть — технической документации (Roadmap). Feature-оунер также контролирует работу остальных разработчиков, прикрепленных к фиче.
По сути, Feature-оунер — это тимлид внутри своей фичи. Поэтому он знает мельчайшие нюансы разработки компонента. Плюс сам компонент отлично задокументирован. А это впоследствии позволяет другим разработчикам быстро разобраться с фичей.
Почему мы решили перейти на новую методологию? Причин было две:
У тимлида на проекте было мало времени, его нужно было разгрузить.
Проект смело можно назвать супераппом, он большой. И чтобы новый разработчик полноценно въехал в работу, обычно уходило 3–4 недели. Нам нужно было этот процесс ускорить.
Далее объясню, как мы работали.
Что считать компонентом
Под компонентом, как правило, подразумевается каждая крупная фича.
Если проект стартует «из коробки», к компонентам не стоит относить авторизацию, работу с сетью и навигацию. А если проект стартует с нуля и базовая логика не заложена «в коробку», то и эти задачи нужно заводить как отдельные компоненты.
Плюсы методологии
Тимлид тратит на проект меньше времени, потому что ему не приходится решать верхнеуровневые задачи (код-ревью каждой фичи, поиск виновных и ответственных и т. п.).
Все участники команды знают, как работает каждый компонент, потому у всех в доступе Roadmap, ТЗ и видеопрезентации. Об этом расскажу ниже.
Ознакомление с проектом и работой компонентов занимает меньше времени, что ускоряет разработку.
Роли и обязанности в команде
Роль Feature-оунерa в жизненных циклах
Как выглядит жизненный цикл разработки:
Приложение разбивается на компоненты.
Для каждого компонента создается Epic.
Для каждого компонента назначается Feature-оунер.
Для каждого компонента создается пул задач.
Как выглядит жизненный цикл компонента:
Для компонента создается компонентная ветка. Например, «components/имя-компонента/номер-задачи-component-имя-компонента» или «components/auth/MPB2B-123-component-auth».
В бэклог добавляются задачи, связанные с компонентом.
Feature-оунер разрабатывает Roadmap компонента, согласовывает ее с тимлидом и добавляет ее в Epic. Согласовывать ее с тимлидом нужно, чтобы все компоненты имели похожую структуру, не было переиспользования.
Все задачи нужно выполнять в соответствии с их жизненным циклом (см. следующий список).
После выполнения всех задач Feature-оунер передает компонентную ветку на код-ревью тимлиду.
После код-ревью тимлид вливает ветку в ветку релиза.
Также после код-ревью Feature-оунер собирает релизную ветку и передает сборку в тестирование.
Если тестирование выявило дефекты, то Feature-оунер устраняет баги.
Feature-оунер делает МР с фиксами по дефектам сразу в релизную ветку.
Feature-оунер презентует компонент всем участникам команды. Презентация записывается на видео.
Feature-оунер актуализирует Roadmap.
Видеопрезентация добавляется в документацию, а ссылка — в Epic.
Как выглядит жизненный цикл задачи:
Руководитель проекта или тимлид берет задачи из бэклога и добавляет их на доску.
Feature-оунер создает ветку от компонентной ветки. Например, «components/имя-компонента/номер-задачи-в-трекере» или «components/auth/MPB2B-123».
Feature-оунер приступает к выполнению задачи. Если задач много, распределяет их между собой и свободными разработчиками.
Если разработчик первый раз работает с компонентом, первым делом он открывает Epic и знакомиться с Roadmap и ТЗ.
Если над задачей работал Feature-оунер, по готовности она вливается в компонентную ветку. Если ее выполнял другой разработчик, она уходит на код-ревью к Feature-оунеру.
В таск-трекере задача со статусом Waiting for test переводится на тестировщика.
Документация компонента
1. Epic компонента собирает ссылки на всю документацию, связанную с компонентом. Это первое, что увидит новый разработчик. Вот что он там найдет:
Описание, составленное аналитиком.
Имя и контакты Feature-оунера.
Ссылка на документацию, согласованную с аналитиком.
Ссылка на Roadmap, техническое описание компонента.
Ссылка на видеопрезентацию готового компонента.
2. Roadmap — это техническое описание слоев компонента, где можно увидеть иерархию файлов и папок, задействованных в работе компонента, их взаимодействие и краткое описание их работы.
Цель Roadmap — чтобы сторонний разработчик, получив задачу по компоненту, понял по Roadmap, в каких файлах ему придется работать. Это значительно сокращает время ознакомления с задачей.
Пример Roadmap
3. Видеопрезентация нужна, чтобы все участники команды знали, как работает компонент, какую полезную нагрузку несет, где начинается сценарий компонента и где он заканчивается. Эти знания нужны для понимания общего контекста всего приложения.
Вывод
И наконец расскажу, как себя показал этот подход. Но сразу отмечу, что мы остались довольны.
Методология подходит для больших команд — от 6 разработчиков. Идеально, если часть команды — это стажеры или джуниор-разработчики. В этом случае на позиции Feature-оунеров подходят миддлы, а в их команды можно добавлять стажеров или джунов.
Спорным моментом для нас оказалась запись видео после реализации фичи. Мы придерживались изначального плана, но на следующих проектах решили отказаться от этого.
Ну и конечно, посмотрим, все ли наши ожидание сбылись.
Тимлид действительно стал тратить меньше времени на проекте и выполнял только ключевые задачи, что позволило уделить больше времени другим проектам.
Документация проекта оказалась полезной уже в этом проекте. В среднем новый разработчик тратил на 20% времени меньше на ресерч и общение с другими разработчиками, чтобы понять, как работает фича.
На выходе у нас получился полностью задокументированный проект. Даже если мы вернемся к нему через пару лет, мы быстро вспомним, как он реализован, и не будем тратить много времени на ознакомление. А если другая команда начнет с ним работать, для них это не будет темным лесом.
Если у вас остались вопросы, задавайте их в комментариях — постараюсь ответить. Также рассказывайте про свой опыт работы с компонентным подходом. Еще у нас есть телеграм-канал для Flutter-разработчиков — там мой коллега Саша Ворожищев каждый день делится свежими новостями мобильной разработки.
Что еще почитать
Habrahabr.ru прочитано 2698 раз
