Здравствуйте, Baudolino, Вы писали:

B>Здравствуйте, okon, Вы писали:

B>>>1. В ходе интервью с заказчиком вы выявляете его основные потребности (user needs).
B>>>Интервью проводится таким образом, чтобы избежать формулировки заказчиком возможных решений — главное уловить бизнес-цель, зафиксировать понятийную базу и бизнес-процессы.
B>>>На выходе получаете список потребностей заказчика в свободной форме.

O>>Тут проблема , в том что заказчик или его представители как правило занимается своим бизнесом и у него нет времени объяснять долго, порой даже не продумывая как это все должно работать
B>Вот тут как раз не надо долго! Надо кратко и с точки зрения бизнеса. Заказчик не должен продумывать, как все должно работать, — это задача команды разработчиков.
B>Пример правильно записанной хотелки: "Я банкир, я хочу, чтобы мои клиенты могли переводить друг другу деньги с помощью мобильного приложения, потому что это повысит привлекательность моих банковских продуктов."
B>Всё. Как именно это будет происходить — ваша задача предложить.

B>Или: "Я специалист по продажам, мне нужно знать, какие постоянные клиенты давно ничего не заказывали, чтобы предложить им сделать новый заказ".
B>Обратите внимание на вторую часть хотелки — конечная бизнес-цель. Ее знать не обязательно, но полезно, поскольку может помочь связать разные требования воедино (во втором примере можно сразу автоматизировать подготовку коммерческого предложения клиенту). Никаких форм, кнопок, серверов здесь не должно упоминаться. Исключение: у заказчика есть пользователи, уже привыкшие работать с определенным интерфейсом/в рамках определенного процесса — это знание пригодится, хотя и не должно являться требованием скопировать существующее решение.

O>>Как правило после интервью остается больше вопросов и ответы уже ищутся по ходу реализации, т.к. не понятно что спрашивать
B>Спрашивать всегда нужно три вещи:
B>1. Каковы бизнес-цели заказчика? ("Я владелец фирмы-дистрибьютора элитной сантехники, хочу продавать свои товары через интернет. Хочу чтобы сайтом пользовались и дизайнеры интерьеров, получая информацию о новых сериях.")
B>2. Кто пользователи? (количество, демография, их связь с интервьюируемым)
B>3. Каковы их цели? ("Пользователь должен иметь возможность подобрать товар, подходящий к дизайну его ванной комнаты по стилю и цвету.")



Мне кажется это совсем не техническая задача, это маркетологи, бизнес-аналитики, юристы должны придумать бизнес продукт, т.е. как это будет работать с т.з. бизнеса , выделить в этом части которые нуждаются в ПО, и привлечь на эти работы уже разработчиков. Например чтобы переводить друг другу деньги с помощью мобильного там от ПО наверное 10% работы. Одна из сложностей например это законодательство, можно написать классное с технической точки зрения приложение, но им нельзя будет пользоваться , например оно будет противоречить какому-либо закону. ЦБ, налоговая, банковская сфера , все это нужно хорошо понимать чтобы придумать продукт такой как перевод друг другу денег. И разработчики тут бессильны им нужно чтобы кто-то это все объяснил, а понять это достаточно сложно не каждому дано 2-3 образования иметь ( не в смысле корочик или дипломы а чтобы это все оставалось в светлой голове )






O>>Получается что пока не понятно что делать нет возможности приступить к разработке, это не практично.
B>Как вы себе представляете разработку в условиях, когда не понятно, что делать?
B>Если серьезно, хороший анализ экономит массу времени и, в конечном счете, уйму денег. Лишняя неделя на подумать спасет вас от пары месяцев переделок и вероятных срывов сроков.
Анализ это дорого, аналитики очень дорогие и показывает практика могут думать бесконечно, причем пока они думают меняется законодательство , технологии и к тому времени уже пора думать заново.
Поэтому реальность диктует гибкие методологии где слона едять очень маленькими порциями ( живут сегодняшним днем ) и каждый день делают шаг не к какой-то цели которая была изначально а постоянно корректируя курс.
Когда совсем ничего не понятно, тогда конечно писать нечего, но когда немного схвачено и кажется что что-то понятно уже можно это сделать и показать как 1 фича продукта.


O>>Приходилось сталкиваться с проектами как сопровождения так и разработки полностью с нуля , никогда не бывает что сразу все понятно, но разработка как правило начинается с некого прототипа, который как правило не похож на финальное решение, которое получилось бы если сразу все знать и понимать.
B>Согласен, никогда не бывает так, что вся картинка складывается сразу. Даже если вы получили всю необходимую информацию и быстро спроектировали систему по состоянию дел в момент времени Т, через полгода бизнес заказчика изменится и требования вместе с ним. Но DDD не противоречит итеративной разработке — это аналитический подход, который защищает вас от ненужных ошибок, а не от вынужденных переделок.

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

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