Моделирование бизнес-логики с использованием технологий без технологий

Question

Настройка: Winform / ASP.NET MVC проекты. Обучение NHibernate Приложения, управляемые SQL-сервером

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

Например, клиент запросит экран ввода заказа. Экран должен требовать «продукт». Это хорошо и денди. Однако клиент не знал, чтобы сказать мне, что пользователь не может заказать продукт «класса А», если только не вторник.

Или им нужен экран ввода времени. За 2 дня до начала производства они случайно забыли упомянуть, что определенные действия действительны только для определенных ситуаций. Эти ситуации составляют неделю кодирования.

Это, конечно, несколько грубых примеров (ненамного!). Но проблема заключается в том, чтобы заставить этих нетехнических клиентов выстроить свою бизнес-логику. Они почему-то не понимали, что проблема «класса А» возникнет через две недели и т. Д.

Я всецело за гибкое программирование, но есть ли простой способ каким-то образом сделать бизнес-логику, подобную этой, чрезвычайно простой в реализации и изменении почти ежедневно?

Я, конечно, делю проект на, надеюсь, интеллектуальные части, используя NHibernate и т. Д. Но из-за того, что такая логика BI настолько динамична, на самом деле трудно проектировать временные шкалы и т. Д.

Есть предложения? Я знаю, что никогда не будет идеального клиента (или идеального поставщика), но как вы, ребята, справляетесь с постоянным неправильным пониманием?

Спасибо.

Answer 1

Проблема заключается в том, что клиент всегда может придумать какие-то совершенно левые идеи. «О, если покупатель заказывает продукт класса А во вторник, а это его день рождения, предоставьте ему скидку 50% и бесплатный продукт класса В. И уведомите председателя, чтобы он позвонил им».

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

Может быть, я старомоден, или, может быть, потому что у меня было слишком много плохого опыта, но я совсем не заинтересован в гибкой разработке. Как вы знаете, в каком направлении путешествовать, если вы не знаете, куда вы хотите пойти? Для чего-то большего, чем маленькое, тривиальное приложение с одной функцией, я (примерно) следую итеративному методу Водопада, сохраняя циклы маленькими Убедитесь, что у вас есть полный документ обо всем, что будет делать система. После того, как клиент подписал его, это то, что он получает. Если у них есть какие-либо изменения, все они переходят в «версию 2», которая будет запущена после развертывания версии 1 в производство. Немного раздражает их, но в итоге все становятся намного счастливее.

Да, всегда есть исключения, например, когда руководство нуждается в системе ввода данных в течение 2 дней. Но затем дайте понять, что если они будут добавлять какие-либо требования по мере вашего продвижения, они автоматически предоставят вам столько дополнительного времени, сколько вам нужно для их выполнения.

Answer 2

Я настоятельно рекомендую книгу Эрика Эванса «Управление через домены: решение сложных задач в основе программного обеспечения» . Это ОТЛИЧНАЯ книга, которая учит, как общаться с вашими клиентами, чтобы вы были лучше подготовлены для моделирования их потребностей.

Центральное место в книге занимает концепция повсеместного языка ... языка, который вы, как архитектор программного обеспечения, создаете во время бесед со своими клиентами с помощью инструмента, называемого моделированием.

Как архитектор, есть фундаментальное правило, которое вы должны принять, так как оно очень поможет вам в ваших усилиях по обеспечению ценности бизнеса для ваших клиентов: заказчик не должен полностью удовлетворять ваши требования и аккуратно упакован в красивую коробку, которую можно просто развернуть и собрать. Как посредник между заказчиком и разработчиком, вам важно понимать, что ваша задача - извлекать требования у ваших клиентов.

Почему я так говорю? Ваша роль клиентов - это бизнес, а не разработка программного обеспечения. Они заботятся о том, чтобы заработать деньги, чтобы они могли платить своим сотрудникам, рекламодателям, другим своим счетам ... и, возможно, получать некоторую прибыль в процессе. Их не волнуют детали того, как программное обеспечение ... инструменты, которые они используют для выполнения работы ... работают. Они просто заботятся о том, чтобы инструмент делал то, что ему нужно.

Если вы узнаете, что, как архитектор, одна из ваших ролей - это роль «экстрактора требований», вы станете более успешным. С этим успехом ваши клиенты должны быть счастливее, что должно привести к тому, что вы будете счастливее и более довольны своей работой и программным обеспечением, которое вы и ваши разработчики создаете. Это не легко сделать ... это требует совершенно другого подхода. Это требует большего присутствия ума и дальновидности, которые дают вам понимание потребностей ваших клиентов ... позволяя вам знать, что им нужно, прежде чем они это сделают. Если вы разрабатываете и используете вездесущий язык, а ваш проект продолжается, каждая встреча с вашими клиентами будет улучшаться по мере того, как вы двое научитесь общаться на общих терминах, имеющих четко определенные значения.

Учитывая все это, вот несколько примеров, которые могли бы помочь вам получить более высокие требования ранее:

---

Cust: Итак, нам нужен экран ввода заказа , в который мы можем ввести продукт заказы на.
Arch: Хорошо, это выполнимо. Можете ли вы дать мне больше подробностей об этом экране ввода заказа ?
Cust: Хм, ну .... я не уверен ...

Arch: Если можно, вот несколько мыслей о бизнес-правилах :
Арка: Есть ли какие-либо ограничения относительно того, что можно заказать?
Cust: О! Да, мы не хотим, чтобы наши клиенты заказывали продукты из класса A , кроме вторника.

Arch: Отлично, это полезно. Вы предлагаете какие-либо комбинированные предложения, чтобы, если клиент заказывает Продукт X, он мог получить Продукт Y со скидкой?
Cust: Хм, не совсем так. У нас есть рекламные предложения , если покупатель вводит определенный промо-код , он может заключить сделку с одним или несколькими продуктами.
Arch: Хорошо, есть ограничения класса и рекламные предложения . Что-нибудь еще, что может повлиять на поведение экрана заказа?

Cust: Хм, теперь, когда вы упомянули это ...

---

Это распространенный сценарий при выполнении DDD. (Обратите внимание, что это также очень Agile, так как DDD и Agile работают рука об руку.) В приведенном выше диалоговом окне я выделил жирным шрифтом и курсивом термины, которые должны стать частью вас и вашего клиента Ubiquitous Language . Вещи, выделенные жирным шрифтом, - это термины, которые ваш клиент использует для описания определенных вещей в своем бизнесе. Эти термины становятся частью вашей «программной области», которая является программной моделью бизнеса ваших клиентов (по крайней мере, частей, для которых вы пишете программное обеспечение). У меня есть выделенные курсивом термины, которые используют архитекторы и разработчики, например бизнес-правила. Если вы читаете книгу Эвана, он более подробно объясняет, как разрабатывать вездесущий язык и как использовать специальное визуальное моделирование для разработки вашего программного обеспечения, используя термины из этого вездесущего языка.

Надеюсь, это поможет. И, надеюсь, книга «DDD: борьба со сложностями в основе программного обеспечения» поможет еще больше. Конечная цель, как только у вас будет правильное взаимопонимание с вашим клиентом, не будет (или будет очень мало) недоразумений.

Answer 3

Способность выявить требования затруднена в любой отрасли, не только в ИТ, хотя, вероятно, она немного усложняется из-за «загадки», связанной с тем, как происходит ИТ, и предположений, которые люди делают из-за этого.

Открытое общение, частая и регулярная (я не могу подчеркнуть, регулярная и достаточно частая) обратная связь с клиентом, реалистичные ожидания и некий «сплошной» разговор о том, как строятся системы, и как изменения могут запустить вещи рельсы привели к тому, что большинство людей, с которыми я сталкиваюсь, понимают, что им нужно потратить значительное время и усилия на то, чтобы со мной заранее сообщить своим головам 80% того, что нужно сделать.

Оставшиеся 20% - это работа с угадыванием, и она либо произойдет с помощью осмоса, либо не произойдет, либо произойдет после задержки до первоначального срока.

Но поскольку они знают об этом заранее, они не удивляются, и в итоге все работает хорошо.

Другая важная реализация IMO заключается в том, что клиент всегда осознает, что хочет чего-то другого. Это нормально и не ограничивается IT. По мере того, как их видение оживает, и они начинают его использовать, понимают, что в некоторых отношениях они просто неправильно поняли свою идею. Открытое общение, частая и регулярная обратная связь позволяют легко и быстро приспособиться к этому неправильному курсу, чтобы он не вызвал слишком большого ущерба.

Поскольку они платят мне и своей системе, они могут запросить любое изменение, которое они хотят, если они также понимают, что оно будет иметь вариации, почти всегда по стоимости и часто по времени.

Answer 4

Получите ИХ, чтобы написать это!

AFAIK, огурец можно использовать с .NET

Огурец позволяет клиенту (с минимальным обучением) напишите, как бы они хотели, чтобы приложение вело себя.Я провел информационное интервью с магазином, в котором клиентам было написано все BL в огурцах, так что было небольшое недопонимание, и в качестве бонуса, это побуждает не-техников начать понимать, как мы должны думать о проблемах .-