Comments 9
Помогает при постановке задач проекта, формировании Epic и Story (на habr.com есть отличные статьи на эту тему).
А ссылку дать можете?
FlyingDutchman2 прошу прощения, думал что нажал кнопку ответить и уже после написал ответ, как удалить сообщение не нашёл(((
Мне казалось что на Habr читал, продолжу искать, как найду отправлю сообщением.
Если коротко то ситуация такая
Необходимо проект разбить на Epic (у себя мы используем компоненты из архитектуры)
Каждый компонент состоит из набора функций, необходимо раздробить его на Story (тут по разному можно делать, у себя мы отталкиваемся от времени на разработку, 2-3 дня максимум)
Story уже наполняем задачами Бизнес анализ, Системный анализ, Дизайн, Фронт разработка, Бэк разработка, Базы данных, Инфраструктура, Тестирование, Авторская приемка (иногда применяются не все задачи)
Баги при функциональном тестировании крепим к Story
В итоге имеем очень понятную и связанную структуру.
Пользовательская функциональность затрагивает, как правило, несколько компонентов архитектуры. У вас эпики - компоненты.
Где вы формулируете US, UC для этой функциональности, если у вас самый верхний уровень - компонент?
Как внутри одного компонента можно делать US, если она обычно затрагивает несколько компонентов?
Как можно внутри компонента описывать БА, если он охватывает весь продукт (несколько компонентов)
Всё на самом деле довольно просто
Пример возьмём из медицины.
Есть система, например по неврологии
Цель системы: Автоматизировать рабочее место врача невролога
Компоненты (только пример, конечно их будет больше): Лечащий врач, Логистика пациента, Регистр Пациентов, Лабораторные исследования, Нейросеть (тренд), Инструментальные исследования, Мониторинг врачей, НСИ, Интеграция с внешними системами, BI, и т.д.
Рассмотрим компонент Лечащий врач
Цель компонента - ведение пациента во время лечения
Задачи компонента:
Провести первичный приём
Назначить исследования
Получить результаты исследований
Проанализировать результаты исследований, получить рекомендации от виртуального помощника (сейчас тренд, надо отобразить)
Поставить диагноз и определить программу лечения
...
Переводим на язык User Story
US Провести первичный приём - я как пользователь хочу провести приём пациента, получить историю болезни пациента, написать анамнез
US Назначить исследования - я как пользователь хочу назначить исследования инструментальные, лабораторные, физикальные
US Получить результаты исследований - я как пользователь хочу получить результаты исследований в историю болезни
US Проанализировать результаты исследований - я как пользователь хочу получить рекомендации от ИИ по направлениям:
Результаты исследований
Лекарственные средства при выбранной нозологии
Подборка статей в научном журнале по тематике
US Поставить диагноз и определить программу лечения - я как пользователь хочу поставить диагноз (их бывает сразу много, но упростим для примера) и хочу получить подсказки от ИИ при назначении диагноза (помним, сейчас тренд)
...
Одну US (смотри п.5) переведем в Use Case
Цель: Поставить диагноз, получить рекомендации от ИИ
Участники: Система, Врач, ИИ
Стартовые условия: Пользователь Врач зашёл в карточку пациента
Положительный сценарий 1
Врач видит экран Карточка пациента (смотри картинка 1)
Врач может нажать на кнопку получить рекомендации ИИ (смотри картинка 2)
Система открывает экран Рекомендации ИИ (смотри картинка 3) - работа с экраном описано в Use Case 4 в Компоненте Нейросеть (ссылка)
Врач может выбрать диагноз (смотри картинка 3)
....
Альтернативный сценарий
...
Негативный сценарий
Система при вызове экрана Рекомендации ИИ не смогла:)
На экран выводиться уведомление: "Произошла ошибка" (можно дополнить таблицей ошибок по бизнес логике, но сейчас излишне)
...
Вроде всё
Понятно что я упрощаю, но в целом думаю на ваш вопрос ответил, если нет, прошу задать уточняющий вопрос
Согласен, всё взаимосвязано, но каждый компонент решает свою задачу и сточки зрения разработки, проще решать конкретную задачу
Судя по описанию, компонент в системе - это микросервис, стало чуть понятнее.
Не ушло главное моё непонимание. Вы проектирует якобы для одного компонента только на том основании, что в нём будут проходить большинство процессов. При этом затронуты другие компоненты - это очевидно из приведённых US/UC.
Т.е., вместо того, чтобы описать пользовательскую функциональность как взаимодействие всех компонентов между собой, вы описываете как взаимодействие одного компонента со всеми остальными. Полное понимание процессов по конкретной пользовательской функциональности теперь только внутри одного компонента. Получаем, что все описания почти рандомно размазаны по компонентам. Каждый компонент теперь не понимает, что и зачем вот этот API в нём делает - надо идти к потребителю. А потребителей может быть более одного. То же самое, зачем компонент внезапно использует какой-то метод другого компонента. Теперь надо бегать по всей системе, искать "ответственный" компонент, чтобы сложить пазл.
Если это так, то это полный кошмар для аналитика.
Зачем вкладыватьверхнеуровневые (бизнес) артефакты в компоненты - не понимаю.
В компонентах должен содержаться исключительно системный анализ. Описание логики, данных, API - всё то, что касается работы исключительно данного компонента
Немного уточнений (US - это пользовательская история, UC - это пример использования, Компонент - это условный сервис микро или часть монолита для примера не принципиально)
Основной смысл в следующем (рассмотрим пересекающиеся компоненты по US)
В рамках US Поставить диагноз, получить рекомендации от ИИ вы верно заметили что участвуют несколько компонентов, Что бы их связать опишем канал (будут упрощения)
Лечащий врач. - Точка входа пользователя
Нейросеть (тренд). Канал - API GateWay - Нейросеть у нас в облаке, ест много ресурсов
НСИ - API. Лежит в отдельной БД, пользуются все
Регистр Пациентов - Брокер по событийной модели. При назначении пациенту врача, врач получает доступ к электронной медицинской карте пациента. Безопасность наше всё)
Лабораторные исследования - Брокер по событийной модели. При назначении на лабораторные исследования (создаётся задача на сбор материала)
Инструментальные исследования - Брокер по событийной модели. При назначении на инструментальные исследования (создаётся задача на исследования, формируется очередь расписания и т.д.)
Объектное хранилище (где то надо хранить артефакты по результатам в виде понятном нейросети) - API все артефакты, результаты исследований должны сохраняться в него
Итого
В примере видно, что для системного аналитика работы много. Бизнес логика отдельно (комментарий выше), системная логика отдельно.
За счет компонентов мы можем понимать построение системы, совместно с архитектором и/или лидом разработки уточнять каналы и форматы
Я смог ответить на вопрос?
Нет.
Каждый компонент состоит из набора функций, необходимо раздробить его на Story
В какую функцию какого компонента входит US "Поставить диагноз, получить рекомендации от ИИ"?
US "Поставить диагноз, получить рекомендации от ИИ"
Затрагивает несколько компонентов (компонент это про систему, US это про бизнес функционал, хотя технические функции можно так же описывать через US)
Компоненты:
Лечащий врач (ведение приема врача)
Функции: Приём пациента, электронная медицинская карточка и т.д. (тут функции по заполнению электронной медицинской карты пациента)
Реестр Пациентов (содержит данные о пациенте)
Функция: Предоставление данных о пациенте
Нейросеть (предлагает рекомендации)
Функция: Предоставление рекомендаций на основе диагноза, результатов исследований, анамнеза (эта прям сложная вещь, её бы расписать)
НСИ (врач выбирает диагноз по МКБ-10)
Функция: Предоставление справочных данных о диагнозе
К сожалению, приходилось работать на проектах с документацией написанной на этапе запуска. В том конкретном случае проект действительно держался на "Петровиче" из разработки, потому что запускавшие проект аналитики ушли, пришли новые со студенческой скамьи и не прониклись духом написания документации. Как показала практика, если руководитель проекта не станет гонять аналитиков, разработчики их писать не заставят((((
ИТ – Как быть с документацией?