Hola, Amigos!
Я Артём Салеев, руководитель backend-направления в компании Amiga. Мы занимаемся заказной разработкой мобильных приложений на Flutter, созданием веб-сайтов и корпоративных порталов.
Большинство советов, которые мы рассмотрим дальше, справедливы для заказной веб-разработки или проектной деятельности. Но если вы работаете в продукте, тоже сможете почерпнуть полезные рекомендации и применить на практике.
Эта статья вышла на основе моего выступления на конференции Merge 2022.
Ситуация: задача не выполнена вовремя, потратили на нее больше часов, чем планировалось, а по итогу появляется куча багов. Знакомо? А когда мы получаем такой результат, к кому все идут в первую очередь? Конечно, к разработчикам.
Но почему команда косячит и что-то идет не так? Мы задались этим вопросом и ретроспективно посмотрели на последний год. Основные причины можно разбить на 3 категории: проблемы с документацией, регламенты процессов, регламенты разработки. Поехали разбираться.
Чтобы избежать ошибок выше, у вас должна быть собрана вся информацию по проекту в одном месте. Мы храним данные в Confluence.
Я разделил блоки документации на 3 отдельные области в зависимости от ролей и их зоны ответственности (у вас разбивка может отличаться): общая информация, менеджерские документы, документы разработчика.
Оригинал: meme-arsenal.ru
В нашей команде за наполнение этого блока документации отвечает менеджер проекта, у кого-то может быть по-другому. Какое наполнение входит в зону его ответственности?
То, что влияет на процессы разработки, фиксирует тимлид и ведет следующую документацию:
Пример отображения информации по проекту в Confluence
Как я писал ранее, мы занимаемся заказной разработкой, и большая часть нашей работы сводится к выполнению различных задач. Поэтому рассмотрим, пожалуй, наиболее важный для нас — это регламент постановки задач. Мы на своем опыте пришли к следующим правилам:
Пример отображения дополнительных полей для упрощения менеджмента
Не менее важная часть задач — отчетность. Она необходима, чтобы на любом этапе задачи участники понимали, какая работа уже проделана, а что осталось реализовать. Также это способствует снижению количества узких горлышек в команде, когда при смене исполнителя или менеджера весь процесс встает. Что включает в себя такая отчетность:
Этот раздел напрямую влияет на качество проекта в техническом плане и кодовой базы.
Первое, с чего необходимо начать, это организация тестовых зон. Можно описать, какие площадки вы создаете, где вы их создаете. Следующее, это Readme проекта — информация, которая поможет понять, как развернуть проект у себя, где взять актуальный бэкап базы и т.д. Так при подключении новых разработчиков не будет необходимости проходить эти круги ада с каждым.
Code Style. Написание кода должно быть в едином стандарте, для этого придумали соответствующие правила, которые необходимо соблюдать.
Работа с Git. Изначально мы полагались на классическое Git Flow, но этого оказалось недостаточно. Поэтому выделили ряд необходимых правил:
Проанализировав опыт сотрудников, мы выделили 3 основные причины, почему команда работает не так эффективно, как хотелось бы: отсутствие или неполная информация по проекту, нет четко регламентированных процессов взаимодействия в команде, а также процессов разработки, которые нуждались в оптимизации и доработке.
Мы разобрали несколько советов из различных категорий, которые напрямую влияют на эффективность разработки. Они не помогут избежать всех ошибок и трудностей, но существенно минимизируют их количество.
Спасибо, что дочитали статью до конца, буду рад ответить на все ваши вопросы и подискутировать в комментариях!