Комментарии 13
Интересно, зачем в заголовке словосочетание "архитектура сервиса"?
а что вас смутило?)
Отсутствие раскрытия вопроса :)
Под "сервисом" имели ввиду разрабатываемый программный продукт. "Архитектура" — как слой бизнес-логики приложения, карта функций системы, разбитых на бизнес-блоки. Возможно, слово "сервис" могло немного запутать, поэтому удалили его)
Понимаете, архитектура - это всегда минимум квадратики и связи. Т.е. это не просто декомпозиция, не важно на каком уровне. А связи - это и есть суть архитектуры, так как декомпозируя, вам надо понимать, какого рода связи вы порождаете в месте "разреза".
Т.е. архитектура - она всегда про декомпозицию и связи, а не про суть квадратиков. Квадратик - это white (контракт сервиса) и black (реализация сервиса), где в первую очередь интересует white-половинка. Это понятно очень абстрактно, но по сути так и есть.
И если вы пишете про сторьки, то важно это разделение. Так как оно концептуально помогает понять: это внутренняя часть сервиса и мы ее оставляем разработчику либо следующему уровню декомпозиции. А эта внешняя часть, глядя на которую мы определим тех, кто будет пользовать этот сервис и как это будет влиять на решение в целом (какие могуть быть варианты ответов, что делать в случае отказа - короче классический контракт)
А у вам просто сторьки, который (я могу ошибаться) никак это явно не дают. Т.е. четкое описание контратка со ВСЕМИ возможными результатами. А просто описания "я делаю что-то" дает только описание незначительного числа позитивных исходов. И как строить архитектуру при таком неполноценном описании контракта?
То что у вас описано - не архитектура ни разу. Вот хоть тут поглядите: https://ru.wikipedia.org/wiki/Архитектура_программного_обеспечения, а потом найдите там хоть одно упоминание user story.
Это разве не оно?
Компоненты системы и связи между ними? Нет конечно. User story - это что должна делать система, а архитектура и компоненты (а еще глубже код) - это как делать, какие компоненты, какими данными обмениваться, то есть таки да, квадратики и стрелочки, по большому счету. Они конечно связаны друг с другом, но это совершенно разные вещи. Я конечно могу допустить, что автор где-то в части 4 своего повествования дойдет до архитектуры, но это уже будет заход очень издалека.
Интересная статья, спасибо!
Спасибо, сохранил в закладках)
А DOR/DOD вы добавляете в US?
Или это отдельными артефактами идет в PRD?
От проекта к проекту критерии готовности к разработке и критерии завершенности не очень сильно меняются, мы описываем их как часть проектной документации для заказчика. Команда уже и так знает эти критерии, они в том числе описаны в нашем внутреннем документе как флоу работы над проектом. Команде достаточно управлять фичами проекта как сторями с помощью статусов в таск-трекере, дейли, синхронов и ретро. Не хотим плодить лишнюю документацию, например, чтобы разработчик прорывался сквозь текст вместо того, чтобы фокусироваться на работе) Возможно, это тема для следующей статьи) Спасибо за идею)
Проектирование архитектуры через User Stories, часть 1. Вовлекаем в процесс заказчика