Что лучше – 1 команда мобильной разработки или 15?

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

    Главное, без чего трудно представить современный банк – это адекватное приложение для мобильных устройств. Человек – существо, любящее комфорт, и быстро к нему привыкающее. Поэтому, если сейчас взять и вернуть всех в парадигму, в которой банк и любое взаимодействие с ним – это походы в отделения и заполнение бумаг для любой рядовой операции, всем резко взгрустнется.

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



    В Альфа-Банке у нас для этого есть Альфа-Мобайл и Альфа Бизнес-Мобайл.

    Меня зовут Илья Царев, я Head of iOS, и сегодня я расскажу вам, как у нас устроен процесс разработки мобильных приложений.

    Я работаю в Альфа-Банке более 2 лет, начинал со старшего разработчика, а сейчас отвечаю за всю iOS-разработку. Год назад у нас было шесть iOS-разработчиков на все про все. Сейчас нас 19. Нам удалось нормально масштабировать процесс разработки, не потеряв в качестве и сильно прибавив в скорости.

    Тогда


    Периодов бурного развития у нас было несколько. Началось все 2 года назад, мы полностью поменяли команду разработки, в то время это была одна большая команда – 2 iOS, 2 android, несколько дизайнеров, один продакт, аналитики, и вся эта толпа (суммарно около 20 человек) разрабатывала Альфа-Мобайл.

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

    Во второй половине 2016-го мы поделили эту толпу на три части. В итоге получилось, что существует приложение «Альфа-Мобайл», над которым работают три команды, у каждой из которых – свой конкретный кусок работы. Команды эти небольшие, по 5-8 человек. В каждой – по одному участнику каждой роли, то есть 1 iOS-разработчик, 1 android-разработчик, 1 дизайнер, 1 продакт, и так далее.

    При этом каждая команда может пилить свои штуки независимо от остальных команд. К примеру, команда №1 занимается платежами и переводами. Команда №2 – affluent-клиентами (это такие ребята, которые обычно тратят ощутимо выше среднего, и, само собой, являются для банка довольно важными). Команда №3 – редизайном и всякими общими улучшалками.

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

    И именно это с 2017-го мы начали делать.

    Сейчас


    На сегодня у нас 15 команд (включая и «Альфа-Мобайл», и «Альфа Бизнес-Мобайл»), раздроблено это все весьма сильно, и каждая команда снова делает свой кусок работы. Кто-то делает платежи и переводы, кто-то – узконаправленные фичи, например, под наше сотрудничество с FIFA. При этом, если у ребят из этой команды получается так, что прямо сейчас у них нет задач по FIFA – они начинают делать что-то другое, например, улучшают процесс авторизации и прочее.

    В итоге получаем, что у нас 15 команд, они параллельно что-то делают, благодаря чему мы релизимся уже раз в 2 недели, при этом в каждый релиз входит сильно больше фич (около 10) и правок, чем ранее.

    На словах такая переделка звучит довольно просто, мол, взяли и раскидали людей по командам, каждая из которых делает что-то свое, но на самом деле это повлекло довольно сложные изменения техпроцесса. Ведь команда изолирована, общается по большей части внутри себя, вокруг этого всего еще и прослойки – iOS, Android, дизайн. Все это необходимо синхронизировать, иначе всё :)

    Техпроцесс


    Чтобы все это не развалилось на ходу, мы привели техпроцесс вот к такому виду:

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

    При этом у нас есть ряд автоматических проверок, мы проверяем такой код статическим анализатором (swiftlint), он позволяет быстро зафиксировать проблемные моменты, например, где-то скобочки нет, или есть риск утечки памяти. Говоря чуть больше про swiftlint – у нас включены практически все стандартные правила, а также есть несколько своих. Все это позволяет сэкономить время на код ревью.

    Continuous Integration сервер (в нашем случае используется Jenkins) прогоняет статический анализатор кода, прогоняет тесты в приложении, помогает собирать и запускать его, а также пишет обо всем этом в Slack. После всего этого уже проводится ручное код-ревью.

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

    AppStore с недавнего времени позволяет выкатывать новый релиз не на всех людей, как раньше, а на определенный процент пользователей. Поэтому новые фичи мы сначала выкатываем на 1-5 процентов пользователей, смотрим, что там и как в целом. При необходимости исправляем что-то, выкатываем уже на 10 процентов, и так далее. Кроме того, у нас есть собственное решение, которое позволяет раскатывать конкретные фичи на определенные группы пользователей и гибко всем этим управлять. Эти два механизма позволяют нам не бояться проводить как технические, так и продуктовые эксперименты.

    Все это внутри обвешано подробной аналитикой, позволяющей вовремя понять, что и где пошло не так, и как это быстро поправить. Можно также определить, что на какой-то раздел приложения заходят только 2 процента пользователей, а остальные 98% – игнорируют его. Обычно это намекает на удобство расположение раздела или на его смысл вообще.

    Команды


    Сейчас над «Альфа-Мобайлом» трудятся 15 iOS-разработчиков. Над «Альфа Бизнес-Мобайлом» – 3.



    Кроме продуктовых команд, ребята активно участвуют в так называемых технических командах, которые появились параллельно с нашим масштабированием. У нас есть команда, которая следит за архитектурой (кстати, эта команда разработала собственное решение, которое мы применяем в Альфа-Мобайле), команда, которая разрабатывает дизайн-систему, и команда, которая улучшает наш CI/CD. На все это ребятам выделяется время в продуктовых командах.

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

    К слову, об идеальной численности команды. Как руководитель я могу сказать, что нас уже слишком много (без паники, мы все равно активно нанимаем мобильных разработчиков). Я просто к тому, что чем больше людей – тем больше времени тратится на синхронизацию, и это нормально. Кстати, по этой причине мы не рассматриваем junior-разработчиков (хотя, признаюсь, бывают исключения).

    Нанимаем в основном middle, middle+ разработчиков. Это люди, которые уже достаточно уверенно знают нужные технологии, но при этом их можно заточить под себя и натаскать именно для работы в текущих командах. Мы используем много новых технологий, например, у нас более половины кода на Swift, своя собственная архитектура и есть еще несколько вещей, которые обычно не так активно используют. Конечно, стоящий senior тоже будет оценен по достоинству. А вот лидов мы предпочитаем формировать уже внутри компании.

    Прямо сейчас у нас идет активный набор мобильных разработчиков, у нас есть ряд новых команд (есть много продактов с идеями, и им нужны люди в команду), поэтому, если вы чувствуете в себе силы и желание попробовать себя в разработке мобильных приложений для Альфа-Банка, не стесняйтесь – https://hr.alfabank.ru/vacancies/ios-dev

    Буду рад ответить на вопросы об особенности разработки мобильных приложений в банке или об общих принципах работы у нас.
    Альфа-Банк
    260,00
    Компания
    Поделиться публикацией

    Комментарии 24

      0

      Заценил архитектуру, весьма напоминает Riblets от убера. А что используете для Android?

        +3
        В Android используется clean architecture (адаптированный под него). В presentation слое ребята используют MVP.
          +1
          Ай, как больно это звучит
          В presentation слое ребята используют MVP
        0
        Рекомендую изучить опыт построения интерфейсов приложений у «забугорных» банков. Например у Millennium можно увидеть баланс не вводя пин в приложении. Очень удобно. Многие велосипеды уже изобретены, нужно уметь подобрать комплектующие под наших «велосипедистов» )
          +2
          Спасибо! У нас команда дизайнеров днями и ночами трудится над удобством интерфейса. Ребята проводят кучу разных исследований и экспериментов. А по поводу баланса – у нас тоже можно :) На iOS достаточно добавить виджет в центр уведомлений или использовать 3D Touch на иконке приложения.
            +2
            Удивительно, но наши ИТ решения, в частности сайты и приложения, зачастую превосходят зарубежные. Видимо, сказывается доступность разработчиков.
            0
            Насколько я правильно понял, у вас несколько «модулей» разработки и в каждом по одному iOs/Android? Вам не кажется, что данный подход завышает «Bus Factor»?

            В описании было сказано, что после сборки на Jenkins проект отдается QA на тестирование. Как обстоят дела с написанием AT (Automation Tests)?

            Вы нанимаете «Middle & Middle+» — в целом, это обычная ситуация для рынка найма в России (Не хочу винить вашу компанию). И, на мой взгляд тут все гораздо проще. В России цены на Junior завышены (Вы можете нанять iOS Junior и он может просить у вас 1-1.3k$ и это нормально, вы потратите больше ресурсов на обучение). Middle же стоит дороже, но по бизнес модели это лучший способ вложения денег (1.5-2.2k$) и вы уже не тратите денег на обучение, однако он выполняет задачи бизнеса (Зачастую с косяками, но это работает… сейчас). Однако если вы хотите нанять Senior (3 — 4к$) то в рамках бизнеса это дорого. Гораздо проще нанять мидла, потратить полгода год на его заточку, а потом возникает «Период оседлости» когда уже и место нагрето и привык к команде.
              +1
              Да, все верно. В одном «модуле» находится один представитель каждой роли. Такой подход позволяет сфокусироваться на определенной функциональности и реализовать её максимально качественно. Наша архитектура позволяет нам строго разделять ответственность каждого компонента, поэтому разобраться в новом модуле разработчику не составляет труда. Кроме того, у нас проводится кросс-командное ревью кода.

              После сборки проект не отдается QA в прямом смысле. Представитель QA уже находится внутри команды. По поводу автотестов – они пишутся внутри команды, параллельно разработке. Таким образом, по завершению итерации разработки, у нас есть функциональность, юнит тесты и автотесты. Автотесты пишет тестировщик (тот самый представитель QA).
              0

              А тесты в процессе разработки пишутся по TDD? Или потом, когда весь код уже написан?

                +1
                Скажу честно, сейчас в разных командах процесс может отличаться. Где-то ребята используют TDD, а где-то пишут тесты после того, как код написан. В нескольких командах мы пилотируем использование BDD. В итоге, конечно, процесс будет централизован, но пока проходят эксперименты.
                  0

                  Ну и в каких командах разработчики счастливее? В тех, что используют TDD, или в тех, где TDD не используется?


                  Считаете ли вы важной возможность повторного использования кода? Практикуется ли повторное использование кода, в том числе кода, написанного другой командой?

                    +1
                    Разработчики, которые познали дзен TDD, как минимум меньше переписывают свой код. Мы сейчас проводим внутреннее обучение, так что скоро все наши разработчики будут уметь разрабатывать код с использованием TDD.

                    При таком количестве команд и том количестве кода, которое они производят было бы неразумно отметать возможность переиспользовать что-либо. У нас есть дизайн система и библиотека UI-компонент, которые позволяют достаточно быстро собирать UI для новых разделов или целых приложений. Бизнес логика, которая может быть переиспользована тоже выносится в отдельные компоненты (и обязательно покрывается тестами).
                      0

                      Улучшает ли использование TDD внутренний дизайн приложений? Позволяет ли качество написанных тестов считать их исполняемой документацией по коду?

                        +1
                        Использование TDD помогает эффективнее разделять обязанности компонент. Тесты тоже проходят процесс код ревью, поэтому в нашем случае являются исполняемой документацией.
                          0

                          Бальзам на душу. А я то уж думал что у меня одного такое положительное ощущение от использования TDD.

                0

                Как-то непонятно в течении статьи пропадает Android разработка.
                Сначала упоминается в составе команды Android разработчики,
                а потом swift, appstore и остался только iOS. По ходу статьи всех разработчиков под Android уволили?

                  +1
                  Никого не уволили :) Статья описывает общие процессы, которые в Android-разработке очень похожи. Если есть какие-то конкретные вопросы, то я с радостью узнаю у коллег и напишу ответ.
                  0
                  А под Windows уже все? Обновлений не будет?
                    +1
                    Имеется в виду Windows Phone? Если да, то Microsoft остановил разработку и поэтому мы больше не развиваем приложение под эту платформу.
                      +1
                      Windows 10 Mobile.
                      Жаль :( — MS, конечно нехорошие люди! По мне так платформа гораздо лучше, чем Android.
                    0
                    на какой-то раздел приложения заходят только 2 процента пользователей, а остальные 98% – игнорируют его. Обычно это намекает на удобство расположение раздела или на его смысл вообще

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


                    (Неужели я вхожу в те 2%, которые в приложении только смотрят, когда кончается льготный период.)

                      +1
                      Мы проводим много экспериментов и это как раз один из них. Раздел дорабатывается и скоро будет ряд улучшений.
                      0
                      Используете ли вы A/B Testing?
                        +1
                        Да, мы разработали гибкую систему, которая позволяет проводить большое количество экспериментов одновременно.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое