Лучший рабочий процесс веб-разработки: Confluence, Airtable, Jira и Abstract

Слияние, Jira, Airtable и Abstract

中文 版 連結 (китайская версия) / Первоначально опубликовано на vinceshao.com

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

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

Основываясь на своем опыте и с помощью моих друзей-дизайнеров и разработчиков, я разработал рабочий процесс разработки веб-сайтов, предназначенный для небольшой группы (5–15 человек). Система состоит из Confluence, Jira, Airtable и Abstract. В этой статье я расскажу, почему и как этот рабочий процесс.

Мотивация для создания нового рабочего процесса

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

И я начал решать эту проблему.

Огромные ресурсы рабочего процесса поиска Google: функции систем проектирования, ресурсы руководства по стилю и определение рабочего процесса

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

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

Проблемы и цели

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

1. Методология водопада

модель водопада абстрактный демо

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

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

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

жетоны дизайна от Salesforce

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

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

3. Точная обновленная панель прогресса

нам нужна редактируемая и доступная панель прогресса

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

Цель: Создать систему панели управления, которая предоставляет разрешение на редактирование лицам, отвечающим за конкретные задачи.

Диаграмма рабочего процесса

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

схема рабочего процесса, которую я разработал

1. Оценка разработчика

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

2. Единственный источник правды

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

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

Стек инструментов

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

атомный дизайн и ABEM

Примечание: система предполагает, что команда разработчиков использует методологию атомарного проектирования и систему имен ABEM.

1. Слияние

Роль: информационно-ресурсный центр

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

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

Мое любимое преимущество Confluence - возможность настраивать шаблоны документов. Эта особенность делает действительно удобным стандартизировать рабочий процесс.

этап оценки разработчика

Пример: обзор функциональности компонента

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

пользовательский шаблон для обзора компонентов в Confluence

2. Джира

Роль: отслеживание проблем и управление типами действий

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

дизайнерское обновление дизайн магазина

Пример: Обновление разработчика по изменениям дизайна магазина по типу проблемы

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

Функция типов вопросов Jira

3. Airtable

Роль: управление компонентами и панель мониторинга прогресса

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

разработчик начинает работать над задачей

Пример 1: Управление компонентами

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

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

таблица компонентов

После того, как вновь зарегистрированное представление проекта, готовое к программной разработке, будет предоставлено разработчику, оно оценит представление на основе системы ABEM и зарегистрирует его в таблице. В таблице 9 столбцов, в том числе:

1. Название: наименование компонента по принципу ABEM

2. Предварительный просмотр: скриншот или экспортированное изображение компонента

3. Связанная страница: ссылка на страницу содержит этот компонент

4. Детский компонент: ссылка на дочерние компоненты содержит этот

5. Модификатор: проверяет, есть ли варианты стиля (например: - активный, - красный)

6. Категория компонента: общая категория классификации (например: текст, герой, боковая панель)

7. Статус разработки: статус прогресса разработки (ожидает, назначен, в процессе, завершен, в редакции)

8. Правопреемник: разработчик, ответственный за этот компонент

9. Атомный уровень: атомная категория этого компонента (атом, молекула, организм)

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

Пример 2: Состояние разработки страницы

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

таблица списка страниц

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

4. Аннотация

Роль: единый источник контроля правдивости и дизайна активов

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

Абстрактный ветка шаблон

Больше работы предстоит сделать

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

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