Comments 10
Можете уточнить, как User Story из "Модели полезных инкрементов" связываются с Use Cases из "Модели сценариев"?
И, например, как это лучше оформлять с точки зрения артефактов? Один общий документ с usecases в конфлюенсе и отдельно юзер стори мэпа в миро?
"Колонка" на карте историй примерно соответствует кейсу, а строка - глубине реализации/проработки группы кейсов в очередной поставке. Соответственно, каждая UserStory - это одно содержательное, качественное, наблюдаемое и проверяемое изменение системы.
С точки зрения артефактов - простор для фантазии полный. Идеально, когда все в одной системе, перевязано ссылками и можно от одного прийти к другому, но я кроме Sparx EA подобных инструментов не видел.
Поэтому на практике это отдельная диаграмма юзкейсов (я рисовал в PlantUML, Archi, Draw.IO, в конце-концов, просто выписывал в виде списка), в которой юзкейсы как-то идентифицированны. Эту диаграмму полезно выкладывать в общий репозиторий для чтения и ознакомления всех заинтересованных. И отдельная карта историй, заголовки колонок которой коррелируют с названиями/идентификаторами юзкейсов. Читаемость и понятность важнее формализма. В последнее время в качестве артефакта для карты историй использую простую табличку в Confluence, где на месте UserStory поначалу (на этапе моделирования) просто краткое тезисное описание, которое по мере согласования/утверждения скоупа инкремента заменяется ссылкой на соответствующую Story в джире.
Спасибо за развернутый ответ! Общий принцип понял. Единственное, у меня в голове обратноя соотношение - юзер стори нечто более глобальное и общее, чем юзкейс. "Я как пользователь хочу, чтобы система позволяла управлять доступами, чтобы кто попало не прошел, а кто не попало - прошел". И дальше уже юзкейсы - это конкретные шаги. Возможно, даже не целые юзкейсы, а slices
Поэтому колонки бы у меня были в виде юзерсторях, а юзкейсы уже по нима бы двигались.
Прекрасно.
Системно, полно, закончено, иллюстрировано. Однозначно в закладки
В джентельменском наборе моделей почему-то отсутствует архитектура системы. Хотя тот же С4 упомянут.
Оно и так, по-моему, в виде статьи малость перегружено получилось, если сюда еще и архитектуру добавить - будет вообще нечитаемо. Про архитектурные модели я рассказывал на Archdays в 2022-м, кажется, а тут решил сфокусироваться именно на моделях "вокруг" архитектуры. А в C4 верхний уровень для этого как раз и предназначен.
По рис.2. Системы решают только проблемы? Просто задачи бизнеса они не решают?
Рис.4 противоречит содержанию всей статьи. Движение от разработки к решению задач бизнеса - как такое возможно?
Собираются, значит, разрабы и давай разворачивать программные компоненты чтобы... и постепенно так рождаются задачи бизнеса. Прямо пластилиновый мультик
Мой опыт говорит, что не бывает задачи без проблемы, которую она решает. Если есть задача, значит у кого-то что-то болит настолько, что он готов потратить ресурсы (и немалые: разработка - дорогое удовольствие) на уменьшение или устранение этой боли. И задача бизнеса чаще всего заключается в том, чтобы предложить этому "кому-то" какое-то решение, получив за это деньги. На которые и создается программное решение.
Стрелочки на рисунке 4 показывают не движение, а направление ответов на вопрос "зачем?".
Изменение в системе делаем зачем? - чтобы определенным образом изменить её поведение.
А поведение меняем зачем? - чтобы сценарии нужные выполнялись.
А сценарии такие нам нужны зачем? - чтобы решить определенные проблемы и достичь заявленных целей.
Без такой трассировки часто случается, что когда дело доходит до изменения системы, то уже забывается зачем все это делалось. И формально вроде все задачи выполнены, а цели не достигнуты. Явная трассировка помогает помнить, что, метафорически выражаясь, мы крутим педали не чтобы выдать определенный RPS оборотов колеса, а чтобы оказаться дома до того, как начнется гроза. И когда молния жалит в мокрое место, то уже не важно, что колеса крутились так, как было написано в джире.
Да, спасибо, понял вашу модель мира разработки. Резюме
Бизнес и разработка - это про проблемы и боль, а не про достижения новых целей. Только уменьшение или устранение этой боли. Команда разработки - это спасатели и врачеватели.
Сначала где-то в голове декомпозируем
задачупроблему до разработки, на этапе разработки спохватываемся и начинаем обратную композицию, не потеряли ли что по дороге (ведь артефактов декомпозиции нет, потому что на этапе разработки "уже забывается", верно? Если бы они были, то при обязательной валидации каждого последующего шага декомпозиции обратная цепочка говорит лишь об профессиональном провале всех уровней анализа проекта)
Ну, если доводить до крайности, то примерно так :). Отмечу только, что решение проблем не исключает постановки и достижения целей. Можно, к примеру, поставить бизнес-цель "заработать миллиард". Но, поскольку просто так миллиард никто не отдаст, нужно будет найти того, кто готов заплатить этот миллиард, понять за что он готов его заплатить, и предложить ему достойное решение. Ну, или найти миллиард людей, готовых заплатить за что-то по рублю и сделать одно решение для них всех. Но это уже ближе к бизнес-моделям, а не аналитическим.
Роль аналитика в разработке сложных информационных систем