Во-первых, хочу написать про доклад-иинтервью с Максимом Цепковым про DDD и работу без требований. Сам формат интересный, можно задать вопросы и направлять этим рассказ, а не идти в логике докладчика. Хотя 45 минут — это очень мало, понимаю теперь, почему у Дудя интервью по 2-3 часа длятся.
Что я вынес из разговора с Максом:
1️⃣ Словом требования называют разные по назначению сущности. Первая - это требования внешних стейкхолдеров, которые вообще-то не говорят о том, как система должна быть устроена внутри, а выражают некоторые пожелания или ограничения по её свойствам и возможностям. Вторая — требования как постановка задачи архитекторам и разработчикам, промежуточный артефакт внутри процесса производства ПО. То есть, бизнес-аналитики строят модель предметной области (бизнес-модель, модель использования системы, концепцию операций...) а системные аналитики и архитекторы строят модель самой системы. И заголовок интервью — про вторые требования, без них можно жить, если использовать единую модель. Забегая вперед, идея пересекается с моим докладом про скрытое проектирование, и с работами Пола Ральфа, который первый вид требований предлагает называть "desiderata", чтобы не путаться. Ну или попросту "хотелки" 😆
2️⃣ И вот если мы меняем способ общения между людьми внутри проекта, нам не нужен "переводчик" с языка заказчика на язык разработки, как часто называют аналитика. У нас общий язык! Ubiquitous language, одна из ключевых идей DDD. Не нужно фиксировать отдельно бизнес-требования, а отдельно их превращать в функциональные требования (спецификации), тексты в тексты. Нужно построить модель, которую поймут все - и заказчики, и разработчики, причем это должна быть одновременно модель бизнеса, и она же - модель системы.
3️⃣ Таким образом, DDD - это, в первую очередь, про способ общения, про коммуникацию между людьми. (Да что там, всё наше производство софта - это на 2/3 про коммуникацию - от сбора требований до проектирования архитектуры, развертывания и мониторинга.)
4️⃣ Соответственно, модель должна быть понятной и разработчикам, и стейкхолдерам. И тут нужно разделять модель и диаграмму - как некоторое представление модели (или одного из аспектов модели). Модель - формализованное упрощенное представление системы. Диаграмма или описание -- представление одного из аспектов модели (Максим показывал расположенные рядом диаграмму активности и диаграмму состояний - довольно наглядно, что на каком шаге происходит). Тут, конечно, бооольшой вопрос - как такую модель построить, и что это за средства и формализмы для её построения. В практике у нас тут в ИТ используются в подавляющем большинстве эвристические модели, то есть умозрительные - кто что придумал, как смог представить, так и ладно. Математических моделей у нас, как правило, нет. Пожалуй, единственная математически строго обоснованная модель -- это реляционная, да и то там есть проблема с 5НФ, которая на практике не решается чисто математически, без понимания бизнес-правил.
Тут подключился Денис Бесков, и мы немного поговорили про нотацию моделирования: у Макса в примерах UML, а Денис говорил про Event Storming. Я, со своей стороны, тоже склоняюсь к ES - и именно в контексте понимания - кажется, она гораздо лучше понимается и стейкхолдерами, и разработчиками, и содержит почти всё необходимое.
5️⃣ Имея единую модель системы, мы можем оценивать "хотелки" стейкхолдеров в отношении этой модели, не заглядывая в саму систему (если гарантировано, что система имплементирует именно эту модель). Так можно, а так нельзя, а вот это будет сложно сделать. Тут мы поговорили про нефункциональные требования (которые всё-таки внешние, зависят от сценариев использования, или, в широком смысле, от операционной концепции - см. ConOps и OpsCon). Про сценарии использования Максим таки проговорился, что они всё же есть, но "это просто текстовые описания" :) Вот тут, кстати, Event Storming дает фору, так как включает сценарии (через реакции актора на события).
Что я вынес из разговора с Максом:
1️⃣ Словом требования называют разные по назначению сущности. Первая - это требования внешних стейкхолдеров, которые вообще-то не говорят о том, как система должна быть устроена внутри, а выражают некоторые пожелания или ограничения по её свойствам и возможностям. Вторая — требования как постановка задачи архитекторам и разработчикам, промежуточный артефакт внутри процесса производства ПО. То есть, бизнес-аналитики строят модель предметной области (бизнес-модель, модель использования системы, концепцию операций...) а системные аналитики и архитекторы строят модель самой системы. И заголовок интервью — про вторые требования, без них можно жить, если использовать единую модель. Забегая вперед, идея пересекается с моим докладом про скрытое проектирование, и с работами Пола Ральфа, который первый вид требований предлагает называть "desiderata", чтобы не путаться. Ну или попросту "хотелки" 😆
2️⃣ И вот если мы меняем способ общения между людьми внутри проекта, нам не нужен "переводчик" с языка заказчика на язык разработки, как часто называют аналитика. У нас общий язык! Ubiquitous language, одна из ключевых идей DDD. Не нужно фиксировать отдельно бизнес-требования, а отдельно их превращать в функциональные требования (спецификации), тексты в тексты. Нужно построить модель, которую поймут все - и заказчики, и разработчики, причем это должна быть одновременно модель бизнеса, и она же - модель системы.
3️⃣ Таким образом, DDD - это, в первую очередь, про способ общения, про коммуникацию между людьми. (Да что там, всё наше производство софта - это на 2/3 про коммуникацию - от сбора требований до проектирования архитектуры, развертывания и мониторинга.)
4️⃣ Соответственно, модель должна быть понятной и разработчикам, и стейкхолдерам. И тут нужно разделять модель и диаграмму - как некоторое представление модели (или одного из аспектов модели). Модель - формализованное упрощенное представление системы. Диаграмма или описание -- представление одного из аспектов модели (Максим показывал расположенные рядом диаграмму активности и диаграмму состояний - довольно наглядно, что на каком шаге происходит). Тут, конечно, бооольшой вопрос - как такую модель построить, и что это за средства и формализмы для её построения. В практике у нас тут в ИТ используются в подавляющем большинстве эвристические модели, то есть умозрительные - кто что придумал, как смог представить, так и ладно. Математических моделей у нас, как правило, нет. Пожалуй, единственная математически строго обоснованная модель -- это реляционная, да и то там есть проблема с 5НФ, которая на практике не решается чисто математически, без понимания бизнес-правил.
Тут подключился Денис Бесков, и мы немного поговорили про нотацию моделирования: у Макса в примерах UML, а Денис говорил про Event Storming. Я, со своей стороны, тоже склоняюсь к ES - и именно в контексте понимания - кажется, она гораздо лучше понимается и стейкхолдерами, и разработчиками, и содержит почти всё необходимое.
5️⃣ Имея единую модель системы, мы можем оценивать "хотелки" стейкхолдеров в отношении этой модели, не заглядывая в саму систему (если гарантировано, что система имплементирует именно эту модель). Так можно, а так нельзя, а вот это будет сложно сделать. Тут мы поговорили про нефункциональные требования (которые всё-таки внешние, зависят от сценариев использования, или, в широком смысле, от операционной концепции - см. ConOps и OpsCon). Про сценарии использования Максим таки проговорился, что они всё же есть, но "это просто текстовые описания" :) Вот тут, кстати, Event Storming дает фору, так как включает сценарии (через реакции актора на события).