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

nvb>Давайте создадим модель проблемы, которую Вы хотите решить Для начала, в виде декомпозированного списка, в котором элементы не связаны друг с другом (будем есть слона по кусочкам).

nvb>1. Аналитики не всегда могут корректно перевести англоязычные термины
nvb>2. Аналитики не могут создать модель, с достаточной степенью приближения отображающую реальность
nvb>3. Время, затрачиваемое на реализацию бизнес-требований заказчика, увеличивается вследствие трех-четырех этапного процесса реализации (эксперт-аналитики-тимлид-проектировщики)
nvb>4. Вследствие того, что программисты-исполнители не участвуют и не хотят участвовать в создании модели, есть риск возникновения проблем с реализацией этой модели.

nvb>Это все? Можно дополнить.
2) —
1)Нет, проблема не в переводе аналитика. Все таки дело в том что аналитик один не может полностью спроектировать модель без участи разработчиков (в частиности проэктировщиков, тимлидов, etс)
3)Да, самое прискорбное
4)Да, но чаще рядовые программисты исполнители редко имеют большое значение. Скорее речь о сеньер девелоперах, которые реализуют базовую часть приложения: модель, инфраструктуру.

nvb>Теперь давайте попробуем реализовать эту модель в виде стандартных решений для каждого пункта

nvb>1. Зачем переводить одно английское слово одним русским словом? Переведите десятью, поставьте гипертекстовые ссылки на термины и т.п. В общем, создайте словарь.
На данный момент словарь единственный выход. Так фактически у нас сейчас и есть.
nvb>2. Пусть аналитики проведут несколько этапов анализа и синтеза необходимых элементов модели для получения достаточной степени приближения.
nvb>3. С этим ничего не поделаешь. Рядовые программисты не могут по умолчанию работать системными аналитиками. Но попробуйте подойти к проблеме с противоположной стороны. Представьте, что все программисты смогли бы это делать. Тогда бы они предпочли только этим и заниматься, откладывая написание кода на потом, пока не нашли бы действительно идеальное решение (к тому же еще и устраивающее их всех). Это ведет к срыву сроков и претензиям заказчика. Сравните с существующей сейчас у Вас и работающей трехступенчатой схемой. Вы все еще уверены, что хотите поменять ее? Как сказали в соседней ветке — посадите рядом десять Линусов Торвальдсов и получите такую массу проблем, что Вам и не снилась

Нет, я не говорю о всех программистах ) В этом естественно нет смысла
Речь о тех кто реализуют базовую часть приложения: модель, инфраструктуру. А рядовые программисты иногда активно против вникания в это все.

nvb>4. Вот тут уже труднее. Посоветовать ничего не могу – сильно зависит от конкретных людей и организации. Можно тянуть за уши к свету всех на тренингах и совещаниях, можно не всех, а только тимлидов или старших программистов. Можно декомпозировать модель до уровня, касающегося непосредственно исполнителей и предложить им самим декомпозировать дальше. Можно хотя бы попросить документировать проблемы, которые они видят при реализации этой модели (охаять чужое творение всякий рад ) Конечно, идеальное решение здесь – повышать командную сплоченность, тогда все участники будут сами принимать активное участие в обсуждении модели, но это труднее всего вышеперечисленного. Кстати, при этом сильно уменьшится время из п.3,
На данный момент наверное это первый более или менее командный проект у нас. Командная сплоченность проблема, и скорее всего мы прибегаем к плотной декомпозиции. Каждый знает только о том что пишет.

nvb>Конечно, я не верю в то, что это все — в яблочко, и поможет вот прямо завтра решить все проблемы Это всего лишь иллюстрация того, каким путем можно пойти.
=^__^=


На данный момент, так как мы не используем Domain Driven Design как таковой, вышеприведенные решения которые приняты у нас работают. Просто, в связи изучением книг по данной практике разработки и дизайна, хотелось знать что делают те кто придерживаются этой практики

Сейчас, используя Data Driven Design, модель имеет более 100 сущностей (исключительно анемичных, использующихся для передачи данных). При этом модель постоянно совершенствуется. Используется словарь терминов (в виде двух человек у который можно уточнить соответсвие терминов в ТЗ, с моделью %)), а так всего один человек как связка между разработчиками и бизнес экспертами заказчика. Плюсом у нас то что, аналитик занимается так же проектированием, и не далек от кода. Минус — он не один проектирует, и это все ведет к "эксперт-аналитики-проектировщики".