Imagine_ksu

8 методов декомпозиции в Agile

2024-04-07T17:54:07.397Z

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

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

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

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

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

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

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

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

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

вход в личный кабинет
просмотр товаров в «корзине»
формирование счета на оплату
отправка счета по почте
выполнение оплаты различными способами: банковский перевод, карта и т.п., подтверждение оплаты.

Каждый такой этап можно выделить и описать в виде отдельной пользовательской истории.

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

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

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

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

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

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

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

Позитивный сценарий: пользователь заходит в свою учетную запись на сайте и совершает покупку оплачивая ее по карте. Или в формате пользовательской истории: «как клиент я могу войти в свою учетную запись, чтобы совершить покупку по карте».
Негативный сценарий 1: клиент пробует совершить покупку без авторизации.
Негативный сценарий 2: пользователь пробует совершить покупку, но у него на счету не хватает средств и оплата не проходит.
Негативный сценарий n: клиент пробует совершить покупку, но его учетная запись заблокируется из-за неправильного ввода пароля.

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

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

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

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

Определена минимальная сумма, если сумма покупки меньше, то клиенту показывается соответствующая подсказка.
Если сумма покупки превышает определенное значение, то клиенту предлагаются дополнительные варианты оплаты.
Если выставленный счет не оплачен в течение 2 дней, то заказ автоматически отменяется.

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

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

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

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

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

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

Create - создание нового продукта в интернет магазине
Read - просмотр описания продукта
Update - редактирование\обновление описания продукта
Delete - удаление продукта из магазина

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

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

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

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

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

Для разных платформ: персональные компьютеры, планшеты, смартфоны.
Для разных ОС: Windows, iOS, Android.
Для работы в различных браузерах.

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

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

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

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

Поиск с использованием текста (наименование товара)
Поиск с использованием числовых значений (номер товара)
Поиск с использованием регулярных выражений

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

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

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

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

Владелец интернет магазина:

Создание\удаление продукта в интернет магазине.
Просмотр и редактирование описания продукта.

Администратор интернет магазина:

Просмотр и редактирование описания продукта.
Отработка запросов\комментариев клиентов.

Клиент\покупатель:

Просмотр описания продукта.
Резерв\покупка товаров в интернет магазине.

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

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

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

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

Товар есть в наличии и он доступен покупки.
Товар есть в наличии, но он уже зарезервирован другим покупателем
Товара нет в наличии

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

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

Условия и правила бизнес процесса
Позитивные и негативные сценарии использования функционала
Форматы данных и параметров.

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

Корректное завершение проектов

2024-03-09T17:44:09.183Z

Данный материал написан на основании открытого вебинара Т. Федорука "How to close projects and take lessons forward for current projects."

Группа процессов закрытия в PMBoK — как бедный родственник. В этот раздел "книги знаний управления проектами" заглядывают редко, да и информации там всего на пару абзацев. Собственно вся группа процессов состоит из одного процесса "Закрытие проекта или фазы".

PMBoK 6-е издание

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

PRINCE2

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

Задачи процесса закрытия проекта:

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

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

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

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

Цель процесса закрытия проекта и ключевые выгоды, как следует из PMBoK:

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

Какие же практики и артефакты используются в процессе закрытия проекта или фазы?

Сбор данных от внешних заинтересованных лиц

На данном этапе мы собираем обратную связь от заказчика — ключевых заинтересованных лиц с его стороны. Как они оценивают завершенный проект, общий уровень сотрудничества с компанией, что понравилось или вызвало негативную реакцию. Удобно это делать в форме короткого опросника, например в Google Forms, состоящего из нескольких вопросов. Делать слишком большой опросник, больше 3-4 пунктов, не советуют — есть риск что клиент вообще не станет его заполнять. Лучше дать ему возможность высказать любые подробности в отдельном текстовом поле, если сочтёт нужным.
Популярный формат опросника — 3 вопроса:

Как вы оцените завершенный проект? (Или последний раунд сотрудничества, зависит от того как часто вы хотите собирать обратную связь) — Оценка от 1 до 10
Почему вы поставили такую оценку? — Текстовое поле
Порекомендуете ли своим коллегам или партнерам нашу компанию для сотрудничества? — Оценка от 1 до 10
Этот вопрос по сути является сбором метрики NPS — Net Promoter Score.Что такое NPS

Сбор данных от команды проекта

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

Эффективность внутрикомандной работы
Эффективность внешнего взаимодействия — заказчик, руководство, субподрядчики
В какой мере мы как команда реализовали ожидания заказчика
В какой мере мы как команда достигли целей проекта
Доставлены ли заказчику все необходимые компоненты поставки (deliverables)
Общее качество нашей работы как команды

Для простоты можно шкалу оценок сделать аналогичной клиентской, от 1 до 10.

Ретроспективная сессия с командой проекта.

Строго говоря, это правильнее было бы назвать Post-mortem анализ. Условная разница между ретроспективой и пост-мортем (посмертным) анализом — первая проводится во время работы над проектом и предложенные улучшения внедряются сразу же, второй — проводится после завершения работы, и выходом являются не локальные улучшения, а скорее вынесенные уроки (Lessons learned), которые должны быть сохранены в общей базы и могут быть использованы в масштабах всей компании для улучшения процессов.

Рекомендации для проведения сессии следующие:

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

Для проведения сессии можно использовать формат встречи Open -> Navigate -> Close.

Open — приветствие, можно использовать какие-то ice breakers для создания открытой неформальной обстановки, даём контекст встречи: общий обзор завершенного проекта, можно сделать короткую презентацию по уставу проекта, если таковой имеется. Озвучить цели проекта, ограничения, допущения, основные этапы.
Navigate — фасилитируем обсуждение, можно показать таймлайн проекта или основые вехи, может быть даты поставки основных компонент, и просим по очереди высказаться о проекте. Можно попробовать использовать какой-нибудь тул для предварительного сбора мнений от команды (в т.ч. анонимного), например easyretro.io Если команда достаточно большая, можно попробовать для упорядочивания обсуждения использовать какие-то техники из Liberаtion Structures
Close — совместно формулируем вынесенные уроки (lessons learned), фиксируем фидбэки от членов команды (придерживаемся позитивного тона, или хотя бы конструктива), благодарим команду за работу. Пицца, пиво, все довольны ))

Организация собранных данных

Отчет о закрытии проекта (Close-out report)

На основании собранных с опросников и ретро-сессии данных составляем главный документ процесса — Отчет о закрытии (Close-out report). Хорошо если есть хотя бы карточка проекта — можно использовать этот документ как основу для отчета, описывая в прошедшем времени сделанную работу, полученные результаты и т. п. И обязательно добавляя аналитику — достигнута ли цель проекта и в какой степени, какие риски сработали, насколько успешными были стратегии смягчения рисков, собранные метрики на проекте, успехи / неудачи / вынесенные уроки и тому подобное. Здесь пригодятся все имеющиеся документы проекта — реестр рисков, журнал изменений, журнал истории проекта, отчеты о поставках, бизнес-документы.

Хранилище выученных уроков (Lessons learned repository)

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

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

Область знания. Некоторые используют для этого прямой копипаст Областей знаний из PMBoK:
- Project Integration
- Project Scope
- Project Schedule
- Project Cost
- Project Quality
- Project Resources
- Project Communications
- Project Risks
- Project Procurement
- Project Stakeholders
Краткое описание проблемы и решение
План действий по внедрению решения
(опционально) Ключевые слова, кодовое название проекта и т. п.

Формализация завершения проекта

Финальный отчет заказчику

Отправляем заказчику финальный отчет, включающий:
- цели проекта
- достигнутые результаты
- критерии успешной приемки и завершения (success / exit criteria)
- перечень поставляемых компонент и/или адрес где они находятся

Внутреннее информационное письмо о завершении проекта

Часто бывает ситуация, когда о новых проектах информирование сотрудников успешно налажено, а вот о закрытии проектов сообщают редко. В информационном письме перечисляем членов проектной команды, благодарим всех за хорошую работу, можно приложить благодарственные письма от заказчика если таковые имеются. Этим письмом вы уведомляем о высвобождении ресурсов, используемых в проекте (сотрудники, инфраструктура, другие ресурсы).
Данное письмо также подводит некую логическую финальную черту для сотрудников, принимавших участие в проектах. Это достаточно важный аспект с психологической точки зрения, сильно влияющий на дальнейшую мотивацию сотрудников - ощутить логическое завершение проделанной работы, услышать благодарность за потраченные усилия и внутренне собраться для следующего этапа/проекта.
Адресаты — в зависимости от размера и структуры компании. В небольших компаниях до 250-300 человек, по моему мнению, есть смылс рассылать такие письма на всех. Если больше, можно ограничиться отделом или департаментом, включив туда отделы продаж, маркетинга, руководство.

Архивация проектной документации

Обычная формальность — помечаем как заархивированные пространства в Confluence, архивируем документы на дисках Google, закрываем каналы или группы в используемых мессенджерах, закрываем проект в Jira и так далее.

Использование накопленных знаний

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

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

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

Чеклист для проверки корректности завершения проекта:

Форма обратной связи для заказчика создана и отправлена
Форма обратной связи для команды создана и разослана
Ретро-сессия (post-mortem анализ) проведена с командой, выученные уроки внесены в хранилище
Отчет о закрытии проекта (Close-out report) написан
Финальный отчет клиенту отправлен
Внутреннее информационное письмо о завершении проекта разослано
Проектная информация заархивирована

А ВЫ КУПИЛИ ЯЙЦА ?

2023-12-25T19:16:14.262Z

https://t.me/analytic_is

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

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

Фактор 1. Яйца входят в список товаров первой необходимости, еще с 2010 года. Полный список можно посмотреть тут. Если цены на такие товары возрастают более чем на 30% в месяц, то государство в праве искусственно их ограничить. Поэтому часто федеральные поставщики продают в розничные сети товары с невысокой наценкой, чтобы соблюсти все правила, или незначительно поднимают цены каждый месяц/квартал.

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

Фактор 3. Кредиты бизнеса. Чтобы поддерживать оборотку на определенном уровне, компании берут кредиты. Как мы знаем, ключевая ставка ЦБ поднималась неоднократно в течении последних месяцев, за ней подтянулись и процентные ставки банков. Если ключевая ставка поднимается выше чем несколько пунктов за год, а у нас она выросла с 7,5 до 16 %, кредиторы в праве пересмотреть ставки по действующим кредитным линиям или предложить открыть новые кредитные линии для бизнеса, на новых условиях. С таким ростом процентных ставок, банки перестроились, смирились и переработали продуктовую линейку с учетом новых реалий. Спойлер, резкого снижения ключевой ставки с 2024 никто особо не ожидает.

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

А что это значит для кухарки: к госуправлению ее все еще не пустят, а вот непортящимися товарами закупиться стоит, хотя бы на пару месяцев, ведь с января мы начнем жить в новом дивном мире цен на ЖКХ и гречку

Диаграммы действия

2023-12-25T19:24:57.697Z

Диаграмма действий — важная поведенческая диаграмма в диаграмме UML , описывающая динамические аспекты системы. Диаграмма действий — это, по сути, расширенная версия блок-схемы, моделирующая переход от одного действия к другому.

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

Критерии достижения результат, если его нужно изобразить с помощью диаграммы действия:

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

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

Базовая диаграмма деятельности – блок-схема типа

Основная диаграмма деятельности

Диаграмма деятельности — моделирование текстового процессора

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

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

Обратите внимание:

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

Пример диаграммы деятельности — текстовый процессор

Пример диаграммы действий ниже визуализирует поток в графической форме.

Диаграмма действий — технологический порядок

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

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

Дорожка для плавания (пулл, pool) — это способ группировать действия, выполняемые одним и тем же актором (Тут нужно вспомнить, кто что может являться актором), на диаграмме действий или диаграмме действий, либо группировать действия в одном потоке. Вот пример диаграммы деятельности для моделирования представления расходов на персонал:

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

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

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

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

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

Диаграмма активности (с дорожкой для плавания)

Использовать дорожки или нет - решать вам, но важно помнить, что схема не должна превратиться в сложно читаемый лабиринт

Обозначения диаграммы деятельности

Активность

Используется для представления набора действий

Обозначение диаграммы активности — активность

Действие

Задача, которую нужно выполнить

Обозначение диаграммы деятельности — действие

Поток управления

Показывает последовательность выполнения

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

Поток объектов

Покажите поток объекта от одного действия к другому действию

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

Начальный узел

Изображает начало набора действий или действий.

Обозначение диаграммы деятельности — начальный узел

Конечный узел активности

Остановить все потоки управления и потоки объектов в действии. Графики активности могут иметь только одну начальную точку, но могут иметь несколько конечных точек.

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

Узел объекта

Представлять объект, подключенный к набору потоков объектов.

Обозначение диаграммы деятельности — узел объекта

Узел принятия решений

Условие, гарантирующее, что поток управления или поток объектов идет только по одному пути.

Обозначение диаграммы деятельности — узел принятия решения

Объединить в узел

Объедините различные пути принятия решений, созданные с помощью узла принятия решений. Необязательно, что ветки будут сливаться в один узел принятия решений

Обозначение диаграммы деятельности — узел слияния

Форк-узел

Разделите поведение на набор параллельных или параллельных потоков действий.

Обозначение диаграммы деятельности — узел разветвления

Присоединиться к узлу - джойн

Соберите вместе набор параллельных или параллельных потоков деятельности .

Обозначение диаграммы деятельности — узел присоединения

Fork и Join должны использоваться в комбинации для представления одновременных действий.

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

Форк — это действие, которое указывает на несколько точек, а соединение — это действие, возникающее в результате схождения нескольких точек.

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

Дорожка для плавания и перегородка

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

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

Синхронное и асинхронное взаимодействие

2023-12-25T19:26:44.952Z

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

Картинка не моя, но она прекрасна:

Синхронное взаимодействие

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

Плюсы синхронного взаимодействия:

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

Минусы синхронного взаимодействия:

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

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

Асинхронное взаимодействие

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

Плюсы асинхронного взаимодействия:

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

Минусы асинхронного взаимодействия:

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

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

Что выбрать?

Правильный выбор подхода от следующих факторов:

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

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