Что такое продуктивность и эффективность?
В первую очередь определим, что такое продуктивность и эффективность разработчиков.
Продуктивность — это мера, которая позволяет оценить результаты деятельности. Продуктивность определяет количество продукции, произведенное в единицу времени.
Эффективность — это способность выполнять работу и достигать необходимого результата с наименьшей затратой усилий. Эффективность — это соотношение между достигнутым результатом и использованными ресурсами.
Виды потерь
Далее рассмотрим виды потерь в процессе разработки контейнеризованных приложений по аналогии с категориями потерь в промышленном производстве (модельные потери), проиллюстрируем механизмы уменьшения потерь в HealthOS и укажем мультипликатор прироста продуктивности и эффективности разработчиков в HealthOS.
| No | Модельные потери | Потери при разработке контейнеризованных приложений | Механизмы уменьшения потерь в HealthOS | Мультипликатор HealthOS |
| 1 | Перепроизводство | Разработка невостребованных функций, АРМ, документации | Автоматизация разработки карт знаний; компиляция исполняемого кода приложений на основе карт знаний; автоматизация жизненного цикла релиза, включая канареечные релизы; движение релиза приложений по кнопке | 100 |
| 2 | Ожидания | Ожидание доступа технической учётной записи к кластеру, согласования ролевой модели ServiceAccount микросервиса и т.д. | Автоматическое развёртывание скомпилированных компонентов, прохождение QualityGate по меткам автоматических средств тестирования, анализа и аудита; эластичная инфраструктура в облаке | 100 |
| 3 | Лишние запасы | Незавершенная работа, разработка утилит «про запас» и т.д. | Расширение объёма прикладных знаний путём разработки новых разделов тезауруса и карт знаний; релиз нового приложения по запросу | 100 |
| 4 | Транспортировка | Передача артефактов между исполнителями в рамках производственных процессов | Автоматическая передача артефактов в рамках автоматических процессов производства (гиперавтоматизация pipeline) | 100 |
| 5 | Лишние перемещения | Переключение контекста внимания разработчика с одного инструментального интерфейса на другой и так до 8-10 разных интерфейсов | Снижение количества интерфейсов разработчика: во время разработки используется Конструктор; во время тестирования — EBPM Engine Control plane и Ассистент | 2 |
| 6 | Брак | Ошибки в архитектурной постановке, программном коде, параметрах конфигурации, документации пользователя, разработчика и администратора | Автоматизация выявления ошибок в тезаурусе, карте знаний, конфигурационных параметрах приложений — это снижение брака путём включения тестирования в начальные этапы разработки (shift left testing) | 10 |
| 7 | Ненужная обработка | Составление отчётов, согласование действий и тд | Автогенерация документации (отчётов); панели управления; автоматическое выполнение действий в рамках модели доступа роли | 100 |
| 8 | Нереализованный потенциал | Отказ от саморазвити в области своей компетенции из-за многочисленных изменений инструментов и методов разработки | Фокус на освоении новых знаний в целевой предметной области и упрощении инструментальных интерфейсов | 10 |
Ролевая модель HealthOS
Рассмотрим ролевую модель команды разработки контейнеризованных приложений (роли типовой команды разработки) и сравним её с ролевой моделью HealthOS (роли команды разработки HealthOS), а также определим коэффициент использования роли в проекте HealthOS и технологический стек роли HealthOS.
| No | Роли типовой команды разработки | Роли команды разработки HealthOS | Коэффициент использования роли в проекте HealthOS | Техстек роли HealthOS |
| 1 | Лидер команды | Лидер команды | 1 | Локальные LLM; Конструктор; Ассистент; BPMN Engine control plane; Аудитор рисков; Карты знаний |
| 2 | Менеджер продукта | Врач-методист | 0,25 — 1 | Локальные LLM; Конструктор; Ассистент; Аудитор рисков; Карты знаний |
| 3 | Архитектор | Архитектор | 0,25 — 0,5 | Architecture as code (data model, API design, data processing pipeline, ML-pipeline); BPMN Engine control plane; Аудитор рисков; Локальные LLM; Карты знаний |
| 4 | Data Scientist | Модельер | 0,25 — 1 | Стандартный ML-стек; Локальные LLM; Карты знаний |
| 5 | ML-разработчик | ML-разработчик | 0,25 — 1 | Linux, CUDA, Kubernetes, Python, Postgres, Redis, QDrant, Kafka, OpenAPI; Локальные LLM; Карты знаний |
| 6 | Аналитик | Аналитик | 1 | Локальные LLM; Конструктор; Ассистент; Аудитор рисков; Карты знаний |
| 7 | Дизайнер интерфейса | Отсутствует | — | — |
| 8 | UX-аналитик | UX-аналитик | 0,1 — 0,25 | Конструктор; Ассистент; Локальные LLM |
| 9 | Frontend разработчик | Frontend разработчик | 0,25 — 0,5 | JS, React, OpenAPI; Локальные LLMI |
| 10 | Backend разработчик | Backend разработчик | 0,25 — 1 | Java, Python, Postgres, Elasticsearch, Redis, QDrant, Kafka, OpenAPI; Локальные LLM |
| 11 | Тестировщик | Тестировщик | 0,25 — 1 | Python, Postgres, Elasticsearch, Redis, QDrant, Kafka, OpenAPI; Локальные LLM |
| 12 | DevOps инженер | DevOps инженер | 0,25 — 0,5 | Linux, CUDA, Kubernetes, Postgres, Elasticsearch, Redis, QDrant, Kafka, Nexus, GitLab, Ansible; Локальные LLM |
Генерации кода на основе карт знаний
В последнее время получило распространение совмещение процессов разработки ИИ-систем на основе графов знаний и автогенераторов. HealthOS в этом движении является новатором. Автоматическая генерация программного кода в HealthOS построена на следующей цепочке преобразований:
- При помощи графа знаний формируется достаточно полное, семантически и логически согласованное описание предметной области. Такое описание получило название “карты знаний”.
- Далее на основе карты знаний генерируется набор спецификаций, определяющих требования, сценарии использования, сценарии тестирования, взаимосвязи между сущностями.
- Далее на основе спецификаций происходит генерация программного кода.
Данный подход является весьма перспективным для технологий разработки программного обеспечения, так как значительно ускоряет процесс разработки, снижает вероятность ошибок и повышает уровень абстракции при создании программных продуктов.
Особенности генерации кода на основе карт знаний включают:
-
- Использование шаблонов описания требований, тестовых сценариев, сценариев использования и ORM-сценариев в соответствии со стандартами и требованиями проекта.
- Использование параметризованных шаблонов кода для отображения различных сценариев в текст программы. Генераторы кода работают на основе шаблонов, которые могут быть адаптированы под конкретные требования проекта. Это позволяет быстро создавать код, соответствующий стандартам и требованиям проекта.
- Абстракция бизнес-логики в виде сценариев использования. Абстрагирование сложной бизнес-логики в виде алгоритмизированных сценариев из конечного набора формализмов, делает её более понятной и доступной для разработчиков. Это упрощает процесс разработки и снижает вероятность ошибок.
- Абстракция логики ORM (Object-Relational Mapping) в виде ORM-сценариев. Абстрагирование ORM-представления сложной виртуальной объектной базы данных в виде алгоритмизированных сценариев из конечного набора формализмов, делает её более понятной и доступной для разработчиков. Это упрощает процесс разработки и снижает вероятность ошибок.
- Повторное использование кода. Генераторы кода повторно используют общий код, что сокращает время разработки и улучшает качество программ.
Интеграция с системами управления версиями. Генераторы кода интегрируются с системами управления версиями, что позволяет отслеживать изменения в коде и выстраивать процессы управления релизами. - Генерация кода на основе сценариев использования. Генераторы кода могут работать на основе сценариев использования или формальных моделей, созданных с использованием BPMN, UML и других нотаций. Это позволяет создавать код, соответствующий структуре и логике сценария или модели.
- Генерация кода на основе ORM-сценариев. Генераторы кода могут анализировать ORM-сценарии и генерировать код по созданию объектов базы данных и соответствующих программных компонентов сервера приложений. Это ускоряет процесс разработки и снижает вероятность ошибок.
- Генерация кода на основе сценариев требований. Генераторы кода могут анализировать сценарии требований и генерировать код производных сценариев, таких как сценарии использования, ORM-сценарии или отдельных компонентов. Это ускоряет процесс разработки и снижает вероятность ошибок.
- Генерация кода на основе тестовых сценариев. Генераторы кода могут анализировать тестовые сценарии и генерировать соответствующий код тестовых компонентов, выполняющих проверку корректности работы программы.
Автоматическая генерация кода является мощным инструментом, который может значительно улучшить процесс разработки программного обеспечения. Однако важно понимать, что генераторы кода не могут заменить опыт и знания разработчиков. Они должны использоваться в сочетании с традиционными методами разработки для достижения наилучших результатов.
Приоритеты заказчиков
На мероприятии Arch.Meetup (запись здесь), которое прошло 14 мая 2024 года в Sber Agile Home на Кутузовском проспекте 32, участники в кулуарах активно обсуждали результаты опроса крупных корпоративных заказчиков, в состав которых входят такие компании, как Сбер, ВТБ, Альфабанк, Сибур, на предмет направлений повышения продуктивности и эффективности команд разработки контейнеризованных приложений.
Обсуждались результаты 12 интервью и 50 заполненных анкет. Приводим ТОП5 проблем потери производительности и эффективности:
- Порочная пропорция «работа с кодом/все остальное» — «20/80». Необходимо её привести к виду «80/20».
- Нет автоматического развертывания инфраструктуры. Необходимо автоматизировать.
- Нет автоматические доступы. Необходимо автоматизировать.
- Нет автоматического интеграционного тестирования. Необходимо автоматизировать.
- Нет времени на долгие согласования постановок на сценарии интеграции. Необходимо автоматизировать.
Выводы
С учетом вклада механизмов устранения потерь в продуктивность и эффективность команды разработчиков, а также с учётом того, что ролевая модель меньше по составу и позволяет одновременно использовать некоторые роли разработчиков в нескольких проектах одновременно, HealthOS может обеспечить суммарный прирост продуктивности и эффективности команды разработчиков проекта в 10 и более раз по отношению к типовой команде. Что полностью отвечает приоритетам крупных корпоративных заказчиков.
Автор: Александр Александрович Прозоров, РТЛАБ.