Жизненный цикл разработки на low-code

Чем low-code отличается от классической разработки, в чем особенности таких проектов и какая команда нужна для их реализации? В статье автор дает пошаговое руководство по организации процесса low-code-разработки и делится практическими рекомендациями.

Чем low-code-проекты отличаются от классической разработки?

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

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

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

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

Этапы low-code-проекта

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

Постановка целей

На этапе запуска проекта формулируется бизнес-цель, которую необходимо достичь за счет автоматизации — например, уменьшить количество рекламаций (претензий) от клиентов, сократить трудозатраты или ускорить процесс. С этого шага начинается не только low-code-разработка, но и любой проект автоматизации. Как правило, приоритет выставляют не ИT-подразделения заказчика, а люди от бизнеса — директора по развитию, по менеджменту, корпоративные архитекторы, либо аналитик, который обслуживает развитие бизнеса у заказчика.

Планирование и подбор инструментов

На этапе планирования определяется, как именно будет осуществляться проект. При этом большое значение имеет, впервые ли компания обращается к данной теме или уже имеет опыт применения low-code-платформы.

При планировании первого проекта приоритетными становятся задачи интеграции системы в ИT-ландшафт, ее настройки и инфраструктуры. Это то, без чего low-code-проект не «взлетит». Также требуется познакомить пользователей с системой и преодолеть их первичное сопротивление.

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

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

Отмечу важный момент, связанный с планированием обслуживания системы. Как только вы успешно реализовали первый проект на low-code, часть времени разработчиков придется выделить на его поддержку и развитие. На этом этапе может показаться, что это ведет к сокращению доступного времени (или команды — в случае если вы выделили под эти задачи отдельного сотрудника). Однако здесь нет линейной зависимости. Действительно, чем масштабнее разработка (особенно сразу после запуска), тем больше ресурсов будет затрачиваться на поддержку. Однако спустя некоторое время процесс стабилизируется и не будет требовать повышенного внимания — в такой момент ресурсы команды на поддержку заметно снизятся.

Состав команды на low-code-проектах

А теперь о ролях в команде low-code-разработки. Один сотрудник может совмещать несколько ролей, компания может нанять подрядчика или консультанта с почасовой оплатой, однако набор ролей при этом достаточно универсален.

Заказчик

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

Руководитель проекта

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

Архитектор

Человек, который отвечает за принятие решений и балансировку в технической части: каким способом реализовать то или иное решение, с кем будет интеграция, какие возникают взаимосвязи и зависимости между проектами. Как правило, выбирают одного архитектора на внедрение независимо от того, сколько решений строится на платформе. Он должен иметь опыт и экспертизу в разработке на выбранной low-code-платформе, следить за соблюдением баланса между простотой разработки и степенью реализации требований. Важно грамотно разделять решения и находить точки их взаимодействия, переиспользовать готовые компоненты, не забывать про оптимизацию вычислительной сложности, выбирать такой способ реализации, чтобы его было легко изменять и поддерживать. И при этом оставаться в рамках ключевых Аналитик

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

Лоукодер

Занимается тем, что воплощает само решение с помощью инструментов разработки, которые есть в low-code. Часто функции лоукодера и аналитика совмещает один человек, преобразующий требования заказчика в исполняемое решение на платформе. Но эти роли встречаются и по отдельности. В таком случае в более крупных проектах используется моделирование, что подразумевает взаимодействие архитектора и аналитика по предварительному выстраиванию архитектуры — как будет работать платформа, как будут взаимодействовать все решения, как проект будет разворачиваться. Создается задокументированная основа, база знаний того, как всё работает. Она позволяет визуализировать процесс и принимать дальнейшие решения, исходя из того, каков он сейчас.

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

Какие инструменты low-code-разработки использует лоукодер? Перечислим основные из них, чтобы понять, в чем заключаются его ежедневные задачи.

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

● Конструкторы форм для визуального проектирования и создания интерфейсов без глубокой разработки.

● Конструктор отчетности описывает выборку и визуализацию данных для последующего анализа.

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

● Написание скриптов или небольшое программирование.

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

Программист

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

DevOps

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

Тестировщик

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

Процесс low-code разработки

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

Жизненный цикл разрабатываемого решения будет состоять из повторяющейся последовательности действий согласно готовой модели PDCA (Plan, Do, Check, Act), что означает «планируй, делай, проверяй, корректируй». Это нужно для более раннего вовлечения бизнес-заказчиков, для проверки гипотез и уточнения требований. Low-code-платформы позволяют значительно сократить количество первых итераций, быстро собрать прототип, продемонстрировать заказчику результат, корректировать и дальше дорабатывать. Другими словами, low-code дает возможность сократить длительность всех циклов и получить максимальную степень готовности продукта. Скажем еще пару слов о каждом из этапов PDCA.

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

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

Этап Check — это тестирование исполняемого решения и получение обратной связи от заказчика: замечаний, уточнений и комментариев.

На этапе Act происходит запуск продукта в работу и составление плана предстоящих действий: что еще требуется сделать, доработать, исправить.

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

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

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

Своими силами или нужен подрядчик?

В low-code, как и в классическом программировании, существует внутренняя и внешняя разработка. Когда выгоднее купить чужие знания? Часто привлечь внешнего опытного подрядчика кажется хорошим решением, чтобы минимизировать количество собственных ошибок и продолжить развитие. Но важно понимать, что low-code-проекты — это корпоративные системы, и на 100% передать все подрядчику будет сложно. В крупных корпорациях обычно есть свои разработчики, и когда появляется необходимость стыковки с другими системами, часть компетенций все равно переходит внутрь компании. Кроме того, важно сохранять (особенно в документированном виде) некий центр компетенции относительно того, как это работает — как реализована бизнес-логика, какие решения приняты. Почему? Если информацией владеет только подрядчик, он будет использовать зависимость разработчика в своих целях, может диктовать цены и назначать сроки.

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

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

Заключение

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

Основные этапы low-code-проекта:

• постановка целей;
• планирование и выбор инструментов;
• подбор команды;
• low-code-разработка и тестирование.

Планирование и реализация первого проекта существенно отличается от последующих: вам уже не нужно будет думать о встраивании системы в ИT-ландшафт, базовых настройках и инфраструктуре, но придется иметь дело с legacy. Команда low-code-проекта включает следующие роли: заказчик, руководитель проекта, архитектор, аналитик, лоукодер, программист, DevOps-инженер и тестировщик. Хорошее решение — строить центр компетенций внутри компании и привлекать сторонние команды под отдельные блоки задач. Это позволит увеличить скорость разработки и минимизировать риски.

Источник: IT-World