декомпозиция задач что это

Декомпозиция задач: что это и зачем нужно

И как сделать так, чтобы всё шло по плану.

Приходит маркетолог интернет-магазина к разработчику с задачей:

Для маркетолога это одна строчка текста. Он думает, что такую простую задачку можно сделать за 15 минут. А разработчик пожимает плечами: «Подумаю, потом назову срок». Что за дичь? А вот так.

Прежде чем эту задачу делать, её было бы неплохо декомпозировать — то есть понять, из чего она состоит, на что влияет и в каком порядке её стоит делать. В случае со счётчиком покупок это получится такой набор подзадач:

В зависимости от архитектуры системы могут быть и другие действия. Поэтому назвать срок сразу разработчик не может: сначала надо понять, что вообще нужно делать и сколько времени займёт каждый пункт.

Чем крупнее задача, тем сложнее обойтись без декомпозиции. «Покрасить кнопку в красный» можно не раскладывать. А «Добавить новый раздел в админку» точно стоит сначала разобрать по частям: тут работа и для фронтенда, и для бэкенда. Декомпозиция нужна не всегда, но очень часто.

Зачем декомпозировать

Понять, что и в каком порядке делать. «Добавить счётчик на страницу» кажется задачей для фронтенд-разработчика. Но на самом деле он сможет сделать свою часть, только когда будет готова база данных и АПИ — механизм, по которому эти данные подтягиваются на сайт.

Если фронтенд попробует сам предположить, как будет выглядеть запрос, то после интеграции могут всплыть непредвиденные баги: бэкенд мог реализовать АПИ не так, как думал фронтенд-разработчик. Декомпозиция поможет понять, с какой стороны подступиться и в какой последовательности двигаться.

Оценить сроки. Когда задача разложена на части, можно оценить по времени каждую и понять, сколько потребуется на всё вместе. Понятно, что не получится запустить счётчик за день, если только на базу данных и АПИ нужно два.

Упростить тестирование. Тестировать проще, когда понятно, что нужно проверить. В случае со счётчиком: базу данных, метод и вёрстку.

Расставить приоритеты. Декомпозиция может показать, что задача большая и требует времени. Например, если маркетолог хочет указать не только количество покупок, но и количество городов, в которые товар доставляли. Разработчик может показать, что делать всё вместе — две недели, но счётчик покупок можно выкатить быстрее. А маркетолог уже решит, как лучше поступить.

Как декомпозировать

Декомпозировать можно по-разному, это зависит от масштаба и сути задачи.

Например, запуск мобильного приложения можно декомпозировать сначала на уровне платформ: iOS и Android. Потом — на уровне пользовательских сценариев: регистрация, просмотр контента, покупка, переписка с контактами. Сценарии можно разложить на интерфейс и серверную часть. А их — на отдельные конкретные задачи.

Чаще всего задачи раскладывают вертикально и горизонтально. Вертикально — значит по типам работ. Горизонтально — значит вглубь одного типа работы. Вот как это работает со счётчиком покупок в интернет-магазине:

Вертикальная декомпозиция:

Бэкенд: считать количество покупок и отдавать данные на фронт.

Фронтенд: запрашивать данные при загрузке страницы и выводить.

Горизонтальная декомпозиция:

Кто должен декомпозировать

Декомпозировать задачу может сам разработчик, тимлид, менеджер проекта или другой компетентный сотрудник: универсальных правил здесь нет. Руководитель службы разработки Яндекс.Практикума Александр Трегер рассказывает, как это работает у них:

Когда появляется новая большая задача, один из опытных разработчиков берёт её на себя. С этого момента он за неё отвечает: собирает встречи, даёт заказчикам обратную связь, определяет, как решить задачу, декомпозирует её. Для разработчиков это возможность расширить свою зону ответственности, попробовать себя в роли архитектора и менеджера проекта.

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

Почитайте полное интервью с Александром Трегером. Там больше подробностей о разработке Практикума.

Источник

Декомпозиция: что это и как использовать в маркетинге

директор по маркетингу

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

Декомпозиция: что это простыми словами

Декомпозиция — это деление целого на части. В маркетинге можно декомпозировать большую цель на несколько маленьких. Например, не просто поставить задачу «привести 1 000 лидов», а разбить её на несколько более мелких: «привести 400 лидов с Google Ads», «получить 300 лидов с Яндекс.Директ» и «привлечь 100 лидов с рекламы в Facebook».

Представьте, что нужно помыть Boeing 737. Это большой самолёт, на мойку не сдать — он не влезет в помещение, где моют машины. Пройтись с ведром и губкой не получится — самолёт стоит на шасси, с него можно упасть. Позовём две бригады с кёрхерами на кране — одна будет мыть кузов самолета, другая крылья и хвост. Внутри будут работать уборщики — они почистят салон, кабину, туалеты, отсеки для хранения багажа.

Мы составили план по уборке самолёта. Большую задачу «помыть Boeing 737» разбили на два уровня — уборка снаружи и внутри. Каждый уровень разбили ещё на несколько задач. Это и есть декомпозиция. Это инструмент упрощения — от большого к малому, от сложного к простому. Сделать одну большую задачу непросто, а разобраться с десятком мелких — легко.

Что такое декомпозиция цели на задачи

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

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

Но пока Женя замотивирована, ей хочется настраивать классные рекламные кампании и помогать бизнесу получать прибыль от запусков рекламы. К счастью, Женя знает, что такое декомпозиция. Ведь если продумать, из каких составляющих складывается путь от текущих навыков Жени к тем, что нужны настоящему маркетологу, можно повысить свою мотивацию. Выполняя мелкие задачи и наблюдая за прогрессом, проще дойти до конца и освоить профессию.

С помощью декомпозиции Женя разбивает свою цель — стать маркетологом — на несколько задач:

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

Каждый шаг внутри задачи — простое и понятное действие. Например, пройти первый урок курса по маркетингу, сделать домашнее задание или почитать Фила Бадена.

Рассказали в блоге о 5 полезных маркетологу книгах.

Зачем нужна декомпозиция целей

Возьмём одну цель — купить новую машину. Какой из вариантов достижения цели нравится больше?

Одна цель — непонятно, что с ней делать, с чего начинать

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

Вариант справа даёт развернутую картину действий. Понятно, какие шаги нужно предпринять, чтобы купить машину. Декомпозиция разворачивает изнанку цели — чем подробнее расписать шаги и задачи, тем проще достичь результата.

Преимущества декомпозиции целей:

3 способа декомпозировать цели

1. Разбить цель на шаги

Это самый простой способ — разбить цель на задачи и записать их подряд, друг за другом. Можно ручкой в блокноте, в заметках в телефоне или в любом планере (например, Todoist). Внутри задач можно прописывать шаги и ставить сроки для выполнения. Примеры: список покупок, чек-лист, инструкция.

2. Построить майндмэп

Майндмэп (от англ. mind map) или ментальная карта визуально отображает структуру цели — какие есть задачи, как они связаны друг с другом, в какой последовательности их выполнять, кто за какую задачу отвечает.

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

3. Использовать метод SMART

SMART — метод декомпозиции и оценки целей, это аббревиатура на английском языке. Состоит из 5 слов, — каждое слово определяет, какой должна быть цель:

Декомпозиция в маркетинге

Маркетологи используют декомпозицию для работы с воронкой продаж. Они переворачивают воронку на 180 градусов и раскладывают её по этапам — от последнего к первому.

Обычная воронка продаж — от знакомства с продуктом до конечного действия

Обратная или декомпозированная воронка продаж — от целевого действия до знакомства

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

Декомпозиция помогает определить приоритетные этапы воронки с целью понять, как можно повлиять на рост прибыли.

Например, Павел владеет интернет-магазином детских игрушек. Он хочет увеличить прибыль в два раза и идёт к маркетологам из компании А. Они предлагают увеличить рекламный бюджет в два раза. Но Павел понимает, что маркетологи ошибаются. Увеличение бюджета не гарантирует, что прибыль автоматически вырастет. К тому же Павел хочет больше зарабатывать, а не больше тратить.

Павел идёт к маркетологам из компании Б и узнаёт про декомпозицию. Ему рассказывают, что это способ по-другому взглянуть на воронку продаж, и помогают увеличить прибыль.

Как декомпозировать воронку продаж

1. Берём воронку продаж для интернет-магазина.

Читайте подробно о том, что такое воронка продаж и как её использовать в маркетинге.

2. Переворачиваем воронку и собираем в обратном порядке.

3. Разбираемся в причинах перехода от этапа к этапу — что влияет на движение по воронке. Получается такая декомпозиция:

Что маркетологу делать после декомпозиции воронки продаж

Необходимо изучить путь клиента по воронке — посмотреть конверсию на каждом этапе и перед запуском новой рекламы отследить эффективность текущей кампании. Для этого можно использовать сервис сквозной аналитики — такой есть у Roistat. В нём можно отследить путь клиента от первого клика по рекламе до целевого действия — в нашем случае до покупки.

Анализируем конверсию и замечаем низкий CTR объявления. Его можно увеличить с помощью выбора позиции объявления и ставки. Чем ниже позиция в поисковой выдаче, тем ниже CTR. Ещё одна проблема — много пользователей заходят на страницу с продуктом, но не добавляют его в корзину. Для повышения конверсии можно улучшить оформление карточки — добавить яркие картинки товаров, видеоотзыв, сделать более заметной кнопку «Добавить в корзину», предлагать рассрочку в способах оплаты.

И дальше разбираем так каждый этап — смотрим статистику, обнаруживаем барьеры и думаем, как их можно убрать и улучшить конверсию.

Для работы с собственной воронкой проще использовать отчёт «Воронка событий» в Roistat. Нужно добавить события под свою воронку и указать период для анализа. Сэкономите время на декомпозиции.

Главное

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

Будьте в курсе новостей

Присоединяйтесь к нашему каналу в Telegram или подпишитесь по E-mail

Маркетинговая платформа сквозной аналитики,
привлечения трафика, повышения конверсии и лояльности

Источник

Менеджмент в ИТ

Agile in IT: 8 методов декомпозиции задач

Первый и, возможно, самый главный этап работы с Product Backlog в Agile заключается в декомпозиции задач, разбиении разноплановых требований на атомарные, понятные пользовательские истории (User Stories). Чем качественнее разбиты требования, тем понятнее их смысл и способы реализации, а также тем точнее можно запланировать время работы над ними. Чем задачи, тем выше шансы достичь целей спринта, тем более прогнозируемые составы релизов.

Как же провести декомпозицию требований в Product Backlog? Рассмотрим 8 техник, которые помогут эффективно выполнить разбивку требований на User Stories. В работе по Agile большим плюсом будет одновременное применение нескольких вариантов декомпозиции, поэтому важно представлять спектр возможных методов.

Зачем и в какой момент следует проводить декомпозицию требований?

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

Декомпозицию задач можно проводить как в начале очередного спринта при его планировании, так и во время спринта, выполняя разбивку требований для последующих итераций. Второй вариант предпочтительнее. Лучше не привязывать декомпозицию задач к конкретному спринту, чтобы приходить к его планированию с уже готовым, разбитым на пользовательские истории бэклогом. В этом случае, если имеется запас декомпозированных требований, то:

Два основных подхода к декомпозиции.

Существует две концепции, два базовых подхода к декомпозиции крупных задач на пользовательские истории – «горизонтальное» и «вертикальное» разбиение:

Разбиение задач с использованием «вертикального» метода больше соответствует Agile принципам и его применение гораздо более эффективным, основные причины в следующем:

Теперь, когда с необходимостью и принципами декомпозиции все ясно, рассмотрим различные методы разбиения больших задач бэклога на атомарные пользовательские истории. Во всех этих вариантах и техниках применяется принцип «вертикальный» декомпозиции.

Техники декомпозиции требований в Agile

Метод 1: Разбиение по этапам\фазам бизнес процесса.

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

Метод 2: Разбиение по позитивным и негативным сценариям.

Фактически каждая функциональность имеет правильный\прямой сценарий использования, который приводит к ожидаемому\позитивному результату. Однако, когда пользователь работает с тем или иным функционалом могут произойти отклонения от правильного процесса: переданы не те данные, выполнены не все обязательные условия, нет необходимых прав доступа и т.п. Такие отклонения от прямого сценария работы приведут к негативным результатам (действие не выполнится, функция отработает некорректно и т.п.).

Соответственно мы можем выполнить декомпозицию на ожидаемый сценарий использования функционала и на неправильные, но возможные и вероятные сценарии работы. Для каждого сценария важно выделить отдельные пользовательские истории:

В качестве примера декомпозиции требований на позитивные\негативные сценарии снова рассмотрим функцию покупки в интернет магазине:

Подобный тип декомпозиции позволяет выделить, проанализировать и запланировать отработку различных исключений и неверных сценариев использования ПО, которые в любом случае будут возникать.

Метод 3: Разбиение по правилам\условиям бизнес процесса.

В отличии от предыдущего метода в данном случае мы разбиваем процесс не на этапы а на логические ветки, возможные варианты отработки функционала. Фактически мы определяем набор сценариев, по которым может выполняться процесс при выполнении тех или иных правил\условий.

Данный метод разбиения требований позволяет:

Метод 4: Разбиение по видам операций.

Существует ряд относительно стандартных операций, которые часто встречаются в различных функциях. Эти операции можно отнести к разряду набора действий «по умолчанию»: создать, читать, обновить или удалить. Сокращенно метод называется CRUD – от слов Create, Read, Update, Delete. Операции CRUD очень распространены в случаях, когда функциональность включает управление объектами, такими как продукты, заказы, пользователи, файлы и т.д.

На примере все того же интернет магазина можно сделать такую декомпозицию функциональности по работе с карточкой продукта:

Декомпозируя функциональность таким образом достаточно легко ответить на следующие вопросы:

Метод 5: Декомпозиция по типам платформы/ОС.

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

Например, нам необходимо разработать в веб-приложении функцию оплаты пользователем какой-то покупки. В этом случае можно декомпозировать требование на задачи по реализации функции покупки:

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

Метод 6: Разбиение по типам данных и параметрам.

Для некоторых функций можно можно выделить различные типы данных или параметров, которые они должны обрабатывать. Соответственно, мы можем разбить большое требование\фичу на ряд мелких пользовательских историй, в рамках каждой из которых нужно реализовать работу только с каким-то одним типом данных.

В качестве примера можно рассмотреть функцию поиска для интернет-магазина. В данном случае декомпозиция на подзадачи может быть выполнена на основе разных запросов с строке поиска, например:

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

Метод 7: Разбиение по ролям\правам доступа.

Многие бизнес процессы и функциональности часто подразумевают участие\работу с ними нескольких ролей и групп пользователей. Каждая группа пользователей с определенной ролью и правами доступа, может выполнять только определенную часть функций из общего процесса.

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

Разбивая общую функциональность на роли, которые должны выполнять ее части, мы более четко понимаем, какие именно функции необходимы и кто имеет права для их исполнения. В этом случае на первых этапах можно приоритезировать и реализовать только базовые наборы функций для каждой из ролей, а в последствии расширять их возможности.

Метод 8: Декомпозиция по сценариям тестирования\тест-кейсам.

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

Рассмотрим пример функциональности – клиент выбирает товар в интернет магазине и откладывает его в «корзину» для совершения покупки. В рамках этой функциональности могут быть выделены следующие тестовые сценарии (ниже только пример части возможных тест-кейсов):

Какие преимущества дает использование данного метода декомпозиции:

Источник

Как workflow разработки влияет на декомпозицию задач

Одним из самых важных факторов, влияющих на скорость разработки и успех запуска проекта, является правильная декомпозиция идеи продакт-менеджера в задачи для непосредственно программирования. Как правильно это делать? Взять сценарий работы новой фичи от продакта и сразу начать кодить? Сначала написать приёмочные тесты, а потом – код, который будет обеспечивать их прохождение? А, может, переложить всё на плечи разработчиков – и пусть они в ходе скрам-покера сами решают?

Давайте подумаем и обозначим проблемы, которые могут возникнуть в процессе разделения задач, и способы их решения. В этом посте будут рассмотрены основные принципы декомпозиции задач при работе в команде. Меня зовут Илья Агеев, я – глава QA в Badoo. Сегодня расскажу, как workflow влияет на декомпозицию, насколько отличаются тестирование и выкладка задач, которые появляются в результате декомпозиции, и каких правил стоит придерживаться, чтобы процесс разработки проходил гладко для всех участников.

Почему это важно?

Необходимо помнить о том, что процесс разработки – это не только непосредственно сеанс написания кода. Когда мы говорим о разработке, я призываю смотреть на весь процесс целиком, начиная от постановки задачи и заканчивая стабильной работой фичи у наших пользователей. Если не брать в расчёт все этапы, которые предшествуют кодированию и следуют за ним, то очень легко можно попасть в ситуацию, когда все что-то делают, выполняют свои KPI, получают бонусы, а результат получается плачевный. Бизнес загибается, конкуренты «душат», но при этом все – молодцы.

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

Это не плохо и не хорошо – мы ценим разработчиков именно за вдумчивое и грамотное решение технических задач. Но узкий взгляд на проблемы часто останавливает развитие. И речь о развитии не только конкретных людей, но и компании в целом. Ведь рост компании и совершенствование корпоративной культуры возможны только с ростом каждого сотрудника. Поэтому нам важно иногда вылезать из «кокона» и заставлять себя смотреть на проблемы шире, чтобы этот рост стимулировать.

И, разумеется, если такой важный этап, как декомпозиция, поручить человеку, который смотрит на всё исключительно с точки зрения собственного удобства, есть реальный риск огрести кучу проблем на последующих этапах: при слиянии результатов его работы с результатами других, при code review, при тестировании, выкладке в продакшн, и т. д.

Таким образом, определяя для себя, как правильно разбить ту или иную задачу, прикидывая, с чего следует начать и куда в итоге прийти, важно учитывать как можно больше факторов, а не смотреть на проблему только «со своей колокольни». Иногда для того чтобы всё работало быстрее и эффективнее на следующих этапах, приходится делать что-то сложнее и медленнее на том этапе, за который отвечаете вы.

Хороший пример – написание юнит-тестов. Зачем мне тратить своё драгоценное время на написание тестов, если у нас есть тестировщики, которые потом и так всё протестируют? А затем, что юнит-тесты необходимы не только для облегчения процесса кодинга – они нужны также и на последующих этапах. И нужны как воздух: с ними процесс интеграции и проверки регрессии ускоряется в десятки, сотни раз, на них базируется пирамида автоматизации. И это даже если не брать в расчёт ускорение вашей собственной работы: ведь «потрогав» код в каком-то месте, вам самому нужно убедиться в том, что вы ненароком что-нибудь не сломали. И один из самых быстрых способов это сделать – прогнать юнит-тесты.

Workflow

Многие команды, чтобы как-то формализовать отношения между участниками процесса, договариваются о правилах работы в коллективе: согласовывают стандарты кодирования, общий workflow в системе контроля версий, устанавливают расписание релизов и т. д.

Стоит ли говорить, что если изначально договориться о процессе, не принимая во внимание весь жизненный цикл фичи, то можно получить замедление и «грабли» в будущем? Особенно если учесть рост проекта и компании. О преждевременной оптимизации не забываем, но если есть процесс, который хорошо работает на разных масштабах, то почему бы его не использовать изначально?

Говоря о workflow разработки, многие, кто использует Git, сразу вспоминают (всуе) о некоем «стандартном git-flow», считая его идеальным, правильным, и часто внедряют его у себя. Даже на конференциях, где я выступал, рассказывая про workflow в Badoo, меня несколько раз спрашивали: «Зачем вы изобрели своё, почему не используете стандартный git-flow?» Давайте разбираться.

Во-первых, обычно, говоря про этот флоу, имеют в виду вот эту картинку. Я взял её из статьи Vincent Driessen “A successful Git branching model”, в которой описывается схема, довольно успешно работавшая на нескольких его проектах (было это в далёком 2010 году).

Сегодня некоторые крупные игроки на рынке хостинга кода вообще предлагают свой флоу, критикуя «стандартный git-flow» и описывая его недостатки; дают свои схемы, рекомендации, приёмы.

Если же поискать на git-scm.com (хорошо бы вообще погуглить), то с удивлением можно обнаружить, что никакого рекомендованного (и уж тем более «стандартного») workflow не существует. Всё потому, что Git – это, по сути, фреймворк для систем хранения версий кода, и то, как вы организуете это самое хранение и совместную работу, зависит только от вас самих. Всегда нужно помнить о том, что, если какой-то флоу «взлетел» на каких-то проектах, это вовсе не означает, что вам он тоже полностью подойдёт.

Во-вторых, даже у нас в компании у разных команд разный флоу. Флоу разработки серверного кода на PHP, демонов на С/ С++ и Go, флоу мобильных команд – они разные. И пришли мы к этому не сразу: пробовали разные варианты, прежде чем остановиться на чём-то конкретном. К слову, отличается в этих командах не только workflow, но ещё и методологии тестирования, постановки задач, релизы и сам принцип доставки: то, что поставляется на ваши личные серверы и на компьютеры (смартфоны) конечных пользователей, не может разрабатываться одинаково по определению.

В-третьих, даже принятый workflow является скорее рекомендацией, чем непререкаемым правилом. Задачи у бизнеса бывают разные, и хорошо, если вам удалось выбрать процесс, покрывающий 95% случаев. Если же ваша текущая задача не вписывается в выбранный флоу, имеет смысл посмотреть на ситуацию с прагматической точки зрения: если правила мешают вам сделать эффективно, к чёрту такие правила! Но обязательно посоветуйтесь с вашим менеджером перед принятием окончательного решения – иначе может начаться бардак. Вы можете банально не учесть какие-то важные моменты, которые известны вашему руководителю. А, возможно, всё пойдёт как по маслу – и вы сумеете изменить существующие правила так, что это приведёт к прогрессу и станет залогом роста для всех.

Если всё так сложно, да ещё и флоу – это не догма, а всего лишь рекомендация, то почему бы не использовать одну ветку для всего: Master для Git или Trunk для SVN? Зачем усложнять?

Тем, кто смотрит на проблему однобоко, этот подход с одной веткой может показаться очень удобным. Зачем мучиться с какими-то ветками, париться со стабилизацией кода в них, если можно написать код, закоммитить (запушить) в общее хранилище – и радоваться жизни? И правда, если в команде работает не очень много человек, это может быть удобно, поскольку избавляет от необходимости слияния веток и организации веток для релиза. Однако данный подход имеет один очень существенный недостаток: код в общем хранилище может быть нестабильным. Вася, работающий над задачей №1, может легко сломать код других задач в общем хранилище, залив свои изменения; и пока он их не исправит/ не откатит, код выкладывать нельзя, даже если все остальные задачи готовы и работают.

Конечно, можно использовать теги в системе контроля версий и код-фриз, но очевидно, что подход с тегами мало отличается от подхода с ветками, как минимум потому что усложняет изначально простую схему. А уж код-фриз тем более не добавляет скорости работе, вынуждая всех участников останавливать разработку до стабилизации и выкладки релиза.

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

Feature branches

При всём многообразии вариантов workflow у нас в компании у них есть общая черта – они все основаны на отдельных ветках для фич. Такая модель позволяет нам работать независимо на разных этапах, разрабатывать разные фичи, не мешая друг другу. А ещё мы можем тестировать их и сливать в общее хранилище, только убедившись, что они работают и ничего не ломают.

Но и такой подход имеет свои недостатки, основанные на самой природе фичебранчей. В конце концов, после изоляции результат вашей работы нужно будет слить в общее для всех место. На этом этапе можно огрести немало проблем, начиная от мерж-конфликтов и заканчивая очень длительным тестированием/ багфиксингом. Ведь отделяясь в свою ветку кода, вы изолируете не только общее хранилище от ваших изменений, но и ваш код – от изменений других разработчиков. В результате, когда приходит время слить свою задачу в общий код, даже если она проверена и работает, начинаются «танцы с бубном», потому что Вася и Петя в своих ветках затронули одни и те же строки кода в одних и тех же файлах – конфликт.

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

Ещё опаснее конфликты, связанные с логикой кода, когда SCM сливает код без проблем (ведь по строкам в файлах конфликтов нет), но из-за изоляции разработки какие-то общие методы и функции в коде изменили своё поведение или вообще удалены из кода. В компилируемых языках проблема, как может показаться, стоит менее остро – компилятор валидирует код. Но ситуации, когда сигнатуры методов не поменялись, а логика изменилась, никто не отменял. Такие проблемы сложно обнаруживать, и они ещё более отдаляют счастливый релиз и заставляют перетестировать код много раз после каждого слияния. А когда разработчиков много, кода много, файлов много и конфликтов много, всё превращается в сущий ад, ибо пока мы исправляли код и перепроверяли его, основная версия кода уже ушла далеко вперёд, и надо всё повторять заново. Вы всё ещё не верите в юнит-тесты? Хе-хе-хе!

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

Отсюда – второе правило хорошей декомпозиции: фичебранчи должны содержать как можно меньше изменений, чтобы как можно быстрее попадать в общий код.

Параллельная работа

Хорошо, но как же тогда работать в отдельных ветках, если несколько программистов трудятся над одной и той же задачей, разбитой на части? Или если им нужны изменения в общих для разных задач частях кода? И Петя, и Вася используют общий метод, который в рамках задачи Пети должен работать по одному сценарию, а в задаче Васи – по другому. Как им быть?

Тут многое зависит от вашего цикла релизов, потому что моментом завершения задачи мы считаем момент попадания её на продакшн. Ведь только этот момент гарантирует нам, что код стабилен и работает. Если не пришлось откатывать изменения с продакшна, конечно.

Если цикл релизов быстрый (несколько раз в день вы выкладываетесь на свои серверы), то вполне можно сделать фичи зависимыми друг от друга по стадиям готовности. В примере с Петей и Васей выше создаём не две задачи, а три. Соответственно, первая звучит как «меняем общий метод так, чтобы он работал в двух вариантах» (или заводим новый метод для Пети), а две другие задачи – это задачи Васи и Пети, которые могут начать работу после завершения первой задачи, не пересекаясь и не мешая друг другу.

Если же цикл релизов не позволяет вам выкладываться часто, то пример, описанный выше, будет непомерно дорогим удовольствием, ведь тогда Васе и Пете придётся ждать дни и недели (а в некоторых циклах разработки и года), пока они смогут начать работать над своими задачами.

В этом случае можно использовать промежуточную ветку, общую для нескольких разработчиков, но ещё недостаточно стабильную, чтобы быть выложенной на продакшн (Master или Trunk). В нашем флоу для мобильных приложений такая ветка называется Dev, на схеме Vincent Driessen она называется develop.

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

Также важно понимать, что, даже если мы используем промежуточную разработческую ветку кода, которая может быть не самой стабильной, задачи или их кусочки в ней должны быть более-менее завершёнными. Ведь нам необходимо в какой-то момент зарелизиться. А если в этой ветке код фич будет ломать друг друга, то выложиться мы не сможем – наш продукт работать не будет. Соответственно, протестировав интеграцию фич, нужно как можно скорее исправить баги. Иначе мы получим ситуацию, похожую на ту, когда используется одна ветка для всех.

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

Feature flags

Но как же быть в ситуации, когда новое изменение бизнес-логики – большое? Только на программирование такой задачи может уйти несколько дней (недель, месяцев). Не будем же мы сливать в общее хранилище недоделанные куски фич?

А вот и будем! В этом нет ничего страшного. Подход, который может быть применён в этой ситуации, – feature flags. Он основан на внедрении в код «выключателей» (или «флагов»), которые включают/ выключают поведение определённой фичи. К слову, подход не зависит от вашей модели ветвления и может использоваться в любой из возможных.

Простым и понятным аналогом может быть, например, пункт в меню для новой страницы в приложении. Пока новая страница разрабатывается по кусочкам, пункт в меню не добавляется. Но как только мы всё закончили и собрали воедино, добавляем пункт меню. Так же и с фичефлагом: новую логику оборачиваем в условие включённости флага и меняем поведение кода в зависимости от него.

Последней задачей в процессе разработки новой большой фичи в этом случае будет задача «включить фичефлаг» (или «добавить пункт меню» в примере с новой страницей).

Единственное, что нужно иметь в виду, используя фичефлаги, – это увеличение времени тестирования фичи. Ведь продукт необходимо протестировать два раза: с включённым и выключенным фичефлагом. Сэкономить тут можно, но действовать следует крайне деликатно: например, тестировать только то состояние флага, которое выкладывается пользователю. Тогда в процессе разработки (и выкладки по частям) задачи её тестировать вообще не будут, а проведут тестирование только во время проверки последней задачи «включить фичефлаг». Но тут надо быть готовым к тому, что интеграция кусков фичи после включения флага может пройти с проблемами: могут обнаружиться баги, допущенные на ранних этапах, и в этом случае поиск источника проблемы и устранение ошибок могут дорого стоить.

Заключение

Итак, при декомпозиции задач важно помнить три простых правила:

Куда уж проще? Кстати, независимая выкладка, на мой взгляд, — самый важный критерий. Из него так или иначе проистекают остальные пункты.

Источник