Эволюция команды разработки

    Весной 2019 года меня пригласили руководить разработкой в небольшой стартап, занимающийся обработкой Big Data.

    За год руководства было решено немало важных вопросов и их решений, о которых я сегодня буду рассказывать. Статья в большей степени предназначена для руководителей и тимлидов разработки, в команде которой требуются перемены. У читателя может сложиться мнение, что у меня и команды не было скучных рутинных задач, это не так. Эта часть работы будет пропущена.

    Команда разработки включала в себя 10 сотрудников: тимлид, front-end разработчики, back-end разработчики, системный администратор и DevOps. Стэк разработки: Python, PHP, JavaScript. Мои глобальные задачи были стандартны, но это не делало их простым. Я упорядочил их по порядку решения задач:

    1. Повысить качество и отказоустойчивость инфраструктуры

    2. Повысить квалификацию разработчиков

    3. Повысить качество ПО

    Повышение качества и отказоустойчивости инфраструктуры

    Проблема №1: Команда работала “по старинке”.Каждый разработчик сам управлял локальным окружением разработки. Это приводило ко всем знакомой ситуации при возникновении ошибок на production’е: у меня локально работало. Окружение должно быть единым для всех ваших окружений. С приходом контейнеризации (в частности, Docker’а) в массы, эта задача стала легко решаемой.

    Решение: Контейнизируйте ваши приложения. Выберите единую ОС для вашего базового образа (на тот момент у нас был Ubuntu 18.04 LTS). Устанавливайте 3-rd party пакеты с точной версией, вплоть до хотфиксной. Пусть поддержкой занимаются системные админстраторы и DevOps’ы, разработчикам делать там нечего.

    Проблема №2: Много self-hosted сервисов, мало системных администраторов

    Все проекты и их компоненты были на выделенных серверах, которые поддерживались двумя (а долгое время одним) системным администратором. Большая часть работы была рутинным админством: тут "подкрутить", там "отшлифовать".

    Решение: Освободите руки системного администратора от рутинных задач насколько это возможно. Автоматизируйте свои процессы с помощью Terraform и Ansible. На уровне малого бизнеса/стартапа зачастую дешевле делегировать часть работы, чем нанять еще одного системного администратора. Возьмите managed СУБД и K8s, за одно решив таким образом такие проблемы как отказоустойчивость, масштабируемость и админством этой инфраструктуры.

    Проблема №3: Вшитые в код ключи/пароли/сертификаты (секреты) от production сервисов

    Решение: Внедрите систему хранения секретами, такой как Vault. Настройте политику доступа к этим данным. Перенесите все секреты из кода в хранилище и запрашивайте их при инициализации приложения.

    Повышение квалификации разработчиков

    На момент моего прихода в команде были в основном junior разработчики.

    Проблема №1: Низкая квалификация разработчиков

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

    Решение: Оставьте только талантливых людей (даже если они junior’ы), которые быстро учатся и самое главное, хотят учиться. На остальных не тратьте время. Новичков вполне могут позволить другие крупные и состоявшиеся компании. Наберите вместо 5 новичков 2 хороших специалиста, которые будут качественно выполнять свою работу. Старайтесь находить тех, у кого вы бы сами могли чему-нибудь научиться в узкой области.

    Проблема №2: Каждый разработчик пишет код в своем стиле

    Разработчикам сложно (читайте долго) переходить из одной области проекта в другой, потому что его писал другой разработчик. Во всех оркестрах играют профессиональные музыканты, отлично знающие свое дело. Тем не менее у оркестра есть свой дирижер, который задает свой ритм и стиль работы.

    Решение: Дирижируйте свою команду. Прививайте разработчиков к единому стилю написания кода. Используйте линтеры типа we-make-python-styleguide (сборник плагинов к flake8) для поддержания единого стиля.

    Проблема №3: Отсутствие технологического развития

    Разработчики не развиваются в технологическом плане, решая задачи так, как они привыкли их решать.

    Решение: Много читайте и постоянно следите за новинками вашей области. Внедряйте и обучайте этому вашу команду. Вместе с ростом квалификации вашей команды растет и ваша.

    Повысить качество ПО

    Из предыдущего раздела можно сделать вывод, что код, написанный подавляющим большинством junior’ов был низкого качества. Смешанные предметные области, ООП не по назначению, спаггети-код. Отсутствие автотестов или их нечитабельность.

    Проблема №1: Плохо спроектированный код

    Cотни и тысячи строк кода смешанных предметных областей, в который сложно вникнуть, поддерживать и улучшать.

    Решение: Внедрите DDD и Twelve-Factor App.

    Проблема №2: Классы, классы и еще раз классы по всюду

    Проектировать большой набор абстракций с одной реализацией не есть хорошо. Не нужно использовать классы только ради группировки вашей бизнес-логики

    Решение: Для группировки сойдут модули и пакеты. Функцию не обязательно оборачивать в класс. Прочитайте о YAGNI, KISS, а также о функциональном программировании.

    Проблема №3: Слишком сложные для понимания автотесты

    Сразу взять и понять как работает та область, которой вам поручили заняться сложно.

    Решение: Описывайте логику в виде BDD сценария. Вникать в предметную область гораздо проще прочитав его сценарии, чем программный код.

    Заключение

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

    С наступающим, Новым годом!

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

      +4
      Я так понял итоговая метрика это «руководство осталось довольным?»
      Да и результаты не описаны.
      Эта статья самый обычный самопиар и все.
        –2
        Результаты описаны в виде решений описанных проблем. Более подробно описал раздел «Заключение». С наступающим вас!
          +3

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

          –1
          Не слушайте этих нудных чуваков :), статья интересна именно вашим опытом. Кармы поставить лайк не хватает, зачтите за него просто мои аплодисменты.
          +2

          Нормально делай — нормально будет! У кого-нибудь нормально BDD получилось вкрутить? Их же бизнес в том числе должен писать

            –1

            Одна из немногих полезных на хабре статей от технического руководителя на фоне 100500 статей в стиле "Люся, я тимлид".

              +2
              Это был сарказм?
              Статья — сплошная вода. Все описанное это обычная рутина руководителя, никакого подвига и «бестпрактис» тут нет. То есть совет уволить 5 новчок и нанять 2х профи — много ума не нужно, но у автора явно не было такого кейса (с учетом, что там всего было 10чел), но тем не менее подается это так, как будто это пройденный личный опыт.
              Ну и наконец, если такие были обязанности у руководителя, то чем же занимался тимлид в проекте в конце концов, педалил код?)
                0

                Нет это не был сарказм. Мой учитель по нормированию, Алексей Антонович Сытин (легендарная личность) на одной лекции рассказал основные принципы построения систем премирования (сейчас это называют кипиай). Принципы эти были очень просты, но очень действенны. И стоили десятка книжек с картинками по кипиай. Здесь тот же случай.

                  0
                  Так а расскажите что за принципы?
                    0

                    Если Вам не понравилась эта статья то не понравится и эти принципы.
                    1) Показатели должны быть поятными (для тех кого премируют).
                    2) Показатели должны быть достижимыми.
                    3) Минимальный процент премии должгы получать все.

              0
              Весной 2019 года меня пригласили руководить разработкой в небольшой стартап, занимающийся обработкой Big Data.
              На момент моего прихода в команде были в основном junior разработчики.
              Во время запуска проекта приходится экспериментировать и срезать углы. Иначе шанс растерять инвестиции до выхода на окупаемость.
              Накапливается тех. долг и вас пригласили его погасить.
              А дальше 2 сценария консультанта:
              — чел работает с командой над исправлением SDLC и тех. долга (профессионал);
              — чел зарабатывает себе очки (не зря же наняли, смотрите что я нарыл у этих джунов).
              Затем увольняет толпу старых джунов и набирает крутых ребят.
              Допускаю, что в вашей статье вы описали второй сценарий, сделали себя героем и решили попиариться.
              Поправьте, если я неверно понял посыл вашей статьи.
                0

                Я не воспринял это статью как кейс убрать джунов (это один из вариантов). Действительно у любой команды (пусть это будет кафедра в институте или автомойка) есть такая непопулярная функция. Сначала нужно собрать команду, которая поверила бы в успех, сорвалась с места работы и начала пахать за идею. Потом если идея развивается и становится успешной есть дилемма: тянуть "первую" команду, закрепить за ними статус первопроходцев или начинать усиление команды (за счет замены слабых игроков более сильными). Если Вы скажете что "первый" вариант более гуманный чем второй. Я и соглашусь и нет. Я встречался с "первым" вариантом. Выглядит он довольно нелепо, иногда комично. Группа "аксакалов" перестает развиваться и в результате вырождается как специалисты, нанося прежде всего себе вред в своей карьере. Любой "новенький" практически не может сработаться с такой командой, так как начинает работать эффект свой/чужой. В особо тяжких случаях, микроклимат в таких командах больше похож на психиатрический стационар (там где раньше Наполеон Буонопарт был).

                  0
                  Дело не в гуманности, а в профессионализме подхода.
                  Встречал оба сценария. Второй сценарий породил токсичную атмосферу и текучку.
                  В результате замены новые толковые ребята не захотели вникать в проект. Действительно, разбираться в чужой логике — нелегкая задача. Спустя время ребята просто сливались на более интересные проекты. Выкатывать релизы становилось сложнее и дольше. Бизнес недоволен.
                  Профессиональный подход: тренировать существующие кадры до нового уровня и добирать новых толковых ребят. Затратно, но эффективно в долгосрочной перспективе. На этом этапе у компании уже есть стабильные деньги.
                  0
                  Не совсем. Дорога «прокладывалась» мной в качестве руководителя и тимлида этой команды. Это не просто «уволить джунов и нанять специалистов», работали все вместе. На счет пиара, вы правы, это статья из серии «смотрите что мы сделали», которые пишут как организации так и частные лица. С наступившим вас!)
                  0
                  Команда разработки включала в себя 10 сотрудников: тимлид, front-end разработчики, back-end разработчики, системный администратор и DevOps.
                  А где тестировщик(и)?
                    0

                    ПО покрывалось юнит-тестами и интеграционными BDD сценариями разработчиками. Бюджета на отдельных автотестеров к сожалению не выделили.

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

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