Воркфлоу что это такое простыми словами

Управление проектами через workflow. Как я наладил производство в два шага

Управление задачами в плотном потоке проектов подобно жонглированию. Упал один шар из дюжины — это уже большая проблема. Пытаться поднять — увеличивать риски уронить остальные. Забыть про него — представление будет неполноценным. И при любом исходе доверие к профессионализму жонглёра подорвано.

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

Решение этой проблемы мы видим в использовании корпоративных стандартов моделей управления повторяющимися задачами. Корпоративных — потому что стандарты должны быть разработаны до момента найма пиэма. Менеджер может выбирать оптимальное решение для конкретного проекта/команды самостоятельно, исходя из заранее описанных регламентов, а не изобретать новые правила игры для каждого нового случая.

Как продвинуть банк в регионах?

Основная проблема — перегретый аукцион. Но если грамотно выбрать соцсеть, формат и настройки таргетинга, всё получится.

Основа стандартов — 2 типа документов

Воркфлоу (англ., workflow — «поток работ»)

Если новичок не сможет за 1 минуту разобраться, как устроено взаимодействие между участниками проекта и на какие этапы делится выполнение услуги, перед нами плохой воркфлоу. Хороший документ позволяет профессионалу за 5 секунд понять, на ком именно застрял процесс, если проект вдруг встал.

Регламенты

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

Я настроил бесперебойную работу в продакшне «Кинетики» в 2 этапа:

Шаг 1. Определяем единый процесс работы

Ключевые вопросы для формирования единых коммуникационных потоков:

Какова последовательность работ?

Кто несет ответственность за каждый этап?

Какова последовательность коммуникации между сотрудниками/отделами?

Какие именно происходят коммуникации?

В каждом регулярном процессе задействованы одни и те же специалисты. В коммуникации принимают участие 4 стороны: Специалисты, PM (проект-менеджер), АМ (аккаунт-менеджер) и Клиент. Одна из задач PM: строго следить за этапами производства и последовательностью коммуникаций.

Для наглядного представления взаимодействия я разбил работу по каждой услуге на блоки:

В схеме используются следующие обозначения:

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

— Проект-менеджер ставит задачу на формирование гипотез (1).

— Пиэм формирует техническое задание на внесение правок на сайт (2).

— После выполнения задания стратег информирует пиэма о готовности к запуску, пиэм проверяет, тестирует вариацию и дает добро на запуск тестирования. Это считается сдачей работ (4).

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

Шаг 2. Ретроспективы. Делаем поток более эффективным

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

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

Наверняка, у многих есть талмуд (своя wiki), где написано «все то же самое». Это здорово, но ускоренное восприятие информации через схему — весомый аргумент в пользу воркфлоу. Опыт показывает, что, по сравнению с текстовыми записями или mindmap схемами, такой воркфлоу откладывается в памяти в разы быстрее.

Актуализация воркфлоу и синхронизация бизнес-процессов

Необходимость в этом возникает в двух случаях:

Добавлена или изменена услуга;

В существующем процессе найден баг (неточность / неполнота / нарушены этапы).

По последнему пункту актуализация составляет 90% работы.

Для того, чтобы это было проще реализовывать, рекомендую следить за строгостью исполнения работ в связке CRM-Воркфлоу-Регламенты-Система управления проектами:

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

Вложенность задач / процедур, должна точно отражать структуру задач / хранения документов.

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

Баги во взаимодействии будут находить и сотрудники (но лучше на них не надеяться), или вы при аудите выполнения задач и фидбеков клиента. Но стоит выделять только повторяющиеся сигналы / недовольства / пожелания, а не бросаться править процессы по первому звонку клиента, ведь обновление процедур — непростой этап, который делится на:

Внесение изменений в регламентирующие документы;

Уведомление о изменениях заинтересованных лиц;

Контроль внедрения изменений (95% времени).

Зачастую все это требует серьезных временных затрат высокооплачиваемых сотрудников.

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

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

Итак, в управлении повторяющимися задачами важна согласованность работы команды и менеджера проектов. Ключевую роль в этом играют наглядное описание (бизнес-) процесcов и удобство работы с этими файлами. Я нарочно не пишу «с этими документами», т.к. люди плохо запоминают сложно структурированную информацию в тексте, будь то PDF или бумажный реферат. Зато блок-схемы воркфлоу усваиваются прекрасно. Попробуйте.

Источник

Сравнительный обзор систем workflow

Тогда американец в доходчивой форме, взяв ручку и листок
бумаги, разбил это слово на составляющие «work» и «flow» и разъяснил, что работа
делается, а информация пересылается.

Основные вопросы

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

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

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

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

Причина внедрения системы

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

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

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

Чем управлять?

созданных в собственном редакторе

созданных сторонними программными

Других типов данных

Рис.1 Редактор карт ActionWorkflow

Рис.2 Редактор карт WorkRoute II

Рис.3 Редактор карт FormFlow

Средства описания процесса

Наличие графического редактора карт

точка входа в карту

Наличие встроенной системы скриптов

Поддержка внутренних переменных карты

Кто управляет выполнением работ?

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

Источник

Современная workflow-система. Возможности, инструменты, Value Stream

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

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

Концепция появилась в 1990-х параллельно с развитием идеи об управлении бизнес-процессами (Business Process Management, BPM). Однако не стоит их путать. BPM — комплексный подход, который концентрируется на стратегических задачах, в то время как Workflow направлена на решение задач тактических. Управление бизнес-процессами работает над всей цепочкой взаимодействия с клиентом, а не только над отдельными этапами и видами процедур. Поэтому внедрение BPM требует более сложных изменений, чем Workflow.

Возможности workflow-систем

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

Создание и модификация workflow-процессов. В системе должны быть конкретные инструменты для их моделирования и изменения. Также важно реализовывать принцип If This Then That («если это, тогда то»), чтобы понимать, при каких условиях предпринимаются следующие шаги.

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

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

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

Low Code и No Code Workflow

По мере того как организации переживают цифровую трансформацию, их главным приоритетом становится модернизация процессов. Пользователям без опыта в разработке нужно быть гибкими, чтобы настраивать и модифицировать процессы для удовлетворения быстро меняющихся потребностей рынка. Речь идет не столько о работе со сложными схемами и диаграммами рабочих процессов, сколько об ускорении небольших, но трудоемких повседневных задач. Повсеместная диджитализация привела к появлению систем Low Code Workflow. В них заложены готовые сценарии и шаблоны, которые адаптированы к каждому типу рабочих процессов. Это требует от сотрудников минимальных технических навыков. Еще более прогрессивная концепция — системы No Code. Их разработали для того, чтобы пользователи без знаний в ИТ автоматизировали процессы и повышали эффективность за счет экономии на масштабе. Системы Low Code и No Code позволяют своевременно реагировать на постоянно меняющуюся рыночную среду, быстро создавая и корректируя рабочие процессы.

Система Workflow на практике

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

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

Современные workflow-системы: новый этап эволюции управления услугами

ITIL 4, последняя версия библиотеки лучших практик управления ИТ-услугами, была выпущена в 2019 году. Один из основных компонентов ее фреймворка — это сервисная система создания ценности (Service Value System, SVS). Ее основная идея заключается в том, что все процессы в организации направлены на достижение одной главной цели: предоставить ценный продукт конечному потребителю. Основа SVS — это цепочка создания ценности (Service Value Chain, SVC). Эта операционная модель объединяет различные виды деятельности для предоставления услуг. Их можно комбинировать разными способами, что позволяет создавать гибкие потоки создания ценности (Value Stream, VS). Правильно настроенная workflow-система может в этом помочь.

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

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

Преимущества использования систем Workflow

Согласно исследованию McKinsey, в 2020 году автоматизацией занялось две трети опрошенных компаний по сравнению с 57% двумя годами ранее. Организации, которые включают внедрение workflow-системы в список своих приоритетов, видят следующие позитивные изменения.

Для достижения всех этих целей и удовлетворения других потребностей организаций разработано множество различных систем Workflow (Low Code, No Code). Область управления услугами постоянно меняется и развивается, и сегодня перед workflow-системами стоит новая задача — стать частью потока создания ценности.

Источник

Как работает система Workflow в компании

Система Workflow – это ИТ-решение для управления «потоком работ», связанными с конкретным этапом бизнес-процесса.

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

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

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

Системы класса Workflow: назначение, состав, функции

Как работает Workflow? Главным назначением систем данного класса является оптимальная организация потока работ в каждом конкретном отделе. Фокус делается на регламенте работ и контроле за его соблюдением. Немаловажно в данном случае добиться хорошего понимания каждым сотрудником тех этапов и задач, которые должен решать конкретно он.

При этом приложение Workflow в той или иной степени обслуживает бизнес-процессы, однако его фокус сделан не на них, а на решении конкретных задач, стоящих перед предприятием или его отделом.

Автоматизация Workflow является идеальным решением, когда нужно автоматизировать отдельные шаги бизнес-процесса, не затрагивая его целиком. Если же речь идёт о полной автоматизации, то стоит использовать BPMS.

Отличия систем Workflow и BPMS

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

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

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

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

Особенности автоматизации с помощью систем Workflow и BPM

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

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

Чаще всего оптимизируют с помощью Workflow документооборот:

Что касается цифровой трансформации на основе систем BPM (BPMS), то здесь имеется большое количество отличий.

Наиболее часто BPMS является долговременной инвестицией, которая окупается не сразу, а спустя время, когда заканчивается этап настройки процессов и обучения сотрудников.

Сегодня существуют и такие системы, которые не относятся к Workflow и BPM в привычном понимании. Например, Low-code система Comindware Business Application Platform позволяют создавать решения обоих классов – workflow, BPMS – силами бизнес-аналитиков и внедрять их постепенно, без чрезмерных затрат. Таким образом, вы можете начать с внедрения workflow-решения, а при необходимости расширить его функциональность до уровня полноценной BPM-системы.

Закажите бесплатно демонстрацию возможностей Comindware Business Application Platform и оцените, насколько она подойдёт для вашей компании.

Если вас интересуют экономичные и удобные решения, закажите демонстрацию Comindware Business Application Platform.

Источник

Как 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. Он основан на внедрении в код «выключателей» (или «флагов»), которые включают/ выключают поведение определённой фичи. К слову, подход не зависит от вашей модели ветвления и может использоваться в любой из возможных.

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

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

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

Заключение

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

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

Источник