비지니스 도메인에 대한 공유 문제?

DDD를 읽는중에 재미있는 구절이 하나 있어서 적어놉니다.

==
In the old waterfall method, the business experts talk to the analysts, and analysts digest and abstract and pass the result along to the programmers, who code the software. This approach fails because it completely lacks feedback. The analysts have full responsibility for creating the model, based only on input from the business experts. They have no opportunity to learn from the programmers or gain experience with early versions of software. Knowledge trickles in one direction, but does not accumulate.

Other projects use an iterative process, but they fail to build up knowledge because they don't abstract. Developers get the experts to describe a desired feature and then they go build it. They show the experts the result and ask what to do next. If the programmers practice refactoring, they can keep the software clean enough to continue extending it, but if programmers are not interested in the domain, they learn only what the application should do, not the principles behind it. Useful software can be built that way, but the project will never arrive at a point where powerful new features unfold as corollaries to older features.

==
상당히 현실적인 이야기 같은데, 전통적인 Water-fall model에서는 시스템을 분석하는 사람이 분석업무 전문가와 함께 분석을 끝내기 때문에, 개발에 대한 경험이나 기술적인 내용이 반영이 되지 않기 때문에, 문제가 되고,
Iterative 한 Agile 방법론에서는 개발자 중심으로 이루어지되, 각 Iteration별로 해야할일에 대해서만 Scope를 가지기 때문에, 전체를 보지 못하고, 시야가 좁아지는 문제점이 생깁니다.

양쪽다, 비지니스 도메인에 대한 이해가 비지니스에서 개발단으로 공유되지 못하는 문제를 가지는 원인들입니다.

사실 어떻게 해결해야 할까는 더 읽어보고 고민해봐야 하는 일이지만 맞는 내용 같습니다.
특히 Agile에 대한 내용은 뜨끔 하더군요. Scope를 잘라서 iteration단위로 움직이는 것은 좋지만, 전체 그림을 보는 것을 놓쳐 버리는 실수를 범할 수 있기 때문입니다.

그런데, 전체 구성원들이 비지니스 도메인에 대한 전체적인 이해를 한다는게 많은 시간과 노력이 필요할텐데, 도대체 얼마만큼 범위와 그리고 어느정도 시간을 투자해서 이해를 해야하는건가 생각해볼만한 이슈입니다.