Изменения

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

# '''DDD - Domain Driven Design''', Эрик Эванс. Это - наиболее продвинутый метод работы с требованиями для сложных предметных областей.

#* DDD обеспечивает '''коммуникацию всех участников проекта''' с обсуждением системы не в виде черного ящика, как делает BDD, а раскрытием ее внутреннего устройства через построение модели системы, то есть позволяет заказчику обсуждать систему как прозрачный ящик. Для этого в рамках проекта создается специальный Единый Язык (ubiquitous language), описывающий предметную область, используемый для работы с требованиями и описания модели предметной области - которая является предметом согласования (контракта) разработчика с заказчиком. В отличие от обычной многостадийной формулировки требований с переводами (модель предметной области на одном языке, проект системы на другом, и так далее). При этом объекты модели должны трассироваться в код реализации, то есть '''перевод модели в код идет формально''' - что и позволяет говорить о представлении системы как прозрачном ящике.

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