Адаптация к меняющимся требованиям бизнеса?

Question

Идеи о том, как разработать программное обеспечение, способное адаптироваться к меняющимся требованиям бизнеса? Любые шаблоны, архитектуры и т. Д. Возможно, некоторые примеры из анекдота будут великолепны. Это скорее опрос, чем конкретные вопросы. Спасибо

Answer 1

Вы хотите узнать больше обо всем движении Agile Development . Agile - это то, что он говорит: способен быстро адаптироваться.

• Книга Роберта Мартина 2002 года - классика.

• Agile в C # - это то, что я использую

• Посмотреть этот список книг

• Вы захотите прочитать Agile Manifesto!

• Только еще один: Работа Кента Бека - особенно разработка через тестирование

Answer 2

Вы можете использовать Agile-процесс разработки , если это ваша среда разработки.

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

Только будьте осторожны, чтобы не сделать ваш прототип визуально привлекательным. Если прототип выглядит графически отполированным, есть большая вероятность, что люди, занимающиеся разработкой вашего бизнеса, сочтут, что программное обеспечение гораздо более полно чем это на самом деле. Вместо этого я бы порекомендовал стараться, чтобы он выглядел менее отточенным и больше фокусировался на функциях. Например, если вы работаете в Java Swing, вам поможет отличный внешний вид Napkin . Он позволяет вам создавать столько функций, сколько вы хотите, но экран выглядит так, как будто он нарисован на салфетке. Поэтому внимание и внимание людей уделяется функциональности, а не графическим деталям.

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

Я думаю, что статья "Как справиться с изменяющимися требованиями" Стивена Меллора рассматривает это очень интересным образом.

Answer 7

Рассмотрим механизм бизнес-правил. Не всегда уместно, но может помочь отделить бизнес-логику и требования от вашей технической архитектуры / решения. Например, представьте, что у вас есть требование установить классификацию безопасности автомобиля на основе набора результатов испытаний. Испытания, проведенные на автомобиле, могут измениться, как и критерии классификации (включая фактическое количество классификаций, например, от системы 5 звезд до системы 10 звезд). Учитывая этот сценарий, двигатель бизнес-правил может быть хорошим способом классификации автомобиля.

Механизм правил будет снабжен текстовыми или основанными на XML правилами, которые, по крайней мере, теоретически, могут быть написаны и поддерживаться не программирующим персоналом (например, бизнес-аналитиком). Эти правила будут применяться к объекту Car (предполагается, что объект Car содержит ссылку на объект TestResults). Механизм правил / правил будет анализировать результаты теста и соответственно устанавливать свойство SafetyClassification объекта Car.

Фактические правила могут находиться в базе данных или в общем расположении или даже быть предоставлены системе через инфраструктуру обмена сообщениями или вызов веб-службы. Новые правила могут быть введены в систему и активированы без перекомпиляции / повторного развертывания системы.

Различные технологии имеют разные доступные движки правил. Например, в .Net есть Drools.Net, механизм правил WWF, + несколько других. В Java есть правила JBoss и множество других.

Answer 8

Рассмотрим, в каком масштабе меняются требования бизнеса:

• если мелкие требования часто меняются, то есть люди меняют свое мнение о том, что они хотят, но то, что им нужно сделать, на самом деле не изменилось, тогда перенесите Agile-методы и сделайте ваши итерации очень короткими (короткие, как одно-итерационные итерации) , если нужно действительно что-то доделать!)
• если часто меняются более масштабные требования, то есть какая инфраструктура необходима для ведения бизнеса, это может быть отражением меняющихся прихотей менеджмента (что я называю «синдромом последнего продавца») - что бы ни продавал последний продавец, вдруг Путь Будущего). Если вы участвуете в этих решениях, постарайтесь свести технические проблемы к основам (коммуникация, хранение, вычисления, взаимодействие, доступ, ...) и не отвлекайтесь на навороты и свистки уровня продукта. Помните, что ничто не может быть на 100% подходящим, но стоимость слишком частого изменения вашего мнения может перевесить выгоду от изменения платформ или архитектур. Если вы не участвовали в этих решениях, вы ничего не можете с этим поделать, кроме как быстро учиться и мягко поощрять более глубокие обязательства, когда можете; -)
• если характер бизнеса часто меняется, то есть каждые несколько недель нужны новые виды бизнеса, консолидируются старые линии и т. Д., И вы участвуете в дискуссиях на этом уровне, вы можете попытаться предвидеть будущие изменения, исследуя глубже в планы компании. Если вы не вовлечены на этом уровне, постарайтесь быть гибкими и бесценными, пока не найдете работу в более стабильной компании; -)

Answer 9

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