Как вы оцениваете доработки D365FO Enterprise

[Ivanhoe]

Как вы подходите к оценке понятной модификации для AX 2009 - 2012, которую нужно сделать в D365 траляля - короче новой Аксапточке?

Какой коэффициент будет в среднем правильный? х2? х3? Или в принципе не стоит так делать, а нужно реально разобраться в возможности конкретной модификации (extension или еще как) и только потом давать "честную" оценку?

[EVGL]

x2

[ax_mct]

Quote:

Originally Posted by EVGL

x2

Возможно для back-end и возможно в том случае если нет условия реализации "без overlaying". Нет?

К примеру клиент хочет логику изменения передачи фокуса между контролами и/или через комбинацию клавиш.
Уже не x2. Нет?
Конечно речь не о прогулке на сервер, а о javascripts на странице, то есть front-end.

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

Думаю что x2 это коэффицент скорости разработки в силу различия инструментов,
но возросшую сложность разработки это не учитывает.

Возможно для экспертов вопрос сложности уже не стоит и их ограничивает только скорость инструментов. Но как много этих уже экспертов?

[Ivanhoe]

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

Про остальные более-менее не сильно поменявшие x++ блоки тоже склонен к x2 по вервости, минимум х1,5 после привыкания разработчика.

[raz]

ИМХО, x4.
x2 - чисто разработка,
еще x2 - анализ кода (сейчас не найдешь где идет присвоение, как раньше по перекресным ссылкам с типом write) и билдинг, синхронизация, рестарт (это просто нечто временами).

[EVGL]

Quote:

Originally Posted by raz

ИМХО, x4.
x2 - чисто разработка,
еще x2 - анализ кода (сейчас не найдешь где идет присвоение, как раньше по перекресным ссылкам с типом write) и билдинг, синхронизация, рестарт (это просто нечто временами).

Я свои x2 как раз из-за этого написал: большая трата времени на отладку. Особо пикантно становится, когда и ISV, и ваш код цепляет обработчик на один и тот же метод типа *JournalPost.run(). Начинает беспорядочно вызываться один, другой. Хотя это и в AX2012 уже было. Чего не было в AX2012, так это перезапусков и ожидания, пока отладчик все загрузит. Меня в свое время коллеги почему-то не понимали, когда я указывал на разницу в трудозатратах как между интерпретатором типа SQL или R и компилятором типа C#.

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

[belugin]

Quote:

Originally Posted by EVGL

Чего не было в AX2012, так это перезапусков и ожидания, пока отладчик все загрузит. Меня в свое время коллеги почему-то не понимали, когда я указывал на разницу в трудозатратах как между интерпретатором типа SQL или R и компилятором типа C#.

В C# есть Edit and continue JFYI.

Особенность Ax, в том что сейчас там есть гигантский монолитный модуль Application Suite, который превращается в гигантскую сборку, которую приходится разбивать на netmodules. Если работать внутри модуля поменьше и настроить VS так чтобы он не грузил символы для других сборок, то все более менее прилично.

[raz]

Quote:

Originally Posted by EVGL

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

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

[trud]

Quote:

Originally Posted by raz

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

А вот кстати интерестно зачем это делать?(кроме конечно случаев когда разработчику выгоднее потратить больше времени)
ну т.е. сейчас использование оверлея по большей части не является даже ошибкой Best practice(там где это возможно)
кроме того, даже для таких базовых вещей как дисплей методы extension возможности далеко не финализированы

Quote:

In an upcoming platform update we hope to provide a much more intuitive way of adding display methods, however the above approach will keep being supported.

и народ на яммере репортит кучу глюков по chain-of-command
т.е. на мой взгляд надо просто стараться не особо менять стандарт и делать более обособленные изменения, но тратить время на поиски куда вклиниться нужно только если клиент конкретно за это будет платить(плюс сюда еще включать часы на регистрацию extensions requests на коннект) т.е. данное время надо прибавлять к x2, причем занимает в отдельных случаях это довольно много(иногда больше чем выполнение модификации)

[dech]

А ведь делали продукт с изначальной целью как можно легче и быстрее внести изменения... А теперь увеличиваем время на вникание в задачу и сам процесс разработки. Ленинским путём идём, товарищи! Шаг вперёд, два назад.

[TasmanianDevil]

Quote:

Originally Posted by dech

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

Анекдот про Ржевского, его денщика и смену концепции помните ?

Quote:

Originally Posted by dech

Ленинским путём идём, товарищи! Шаг вперёд, два назад.

Про шаги - это вообще-то слова самого Ленина про путь сторонников Мартова, т.е. меньшевиков.

[fed]

Я бы сказал что в D365 надо еще очень прилично добавлять времени на администрирование и вообще troubleshooting. У нас первый проект смешной по масштабам (25 пользователей). Разработки там пока случилось всего два дня и в перспективе эта цифра дорастет где-то до 8-10 дней. Тем не менее на администирование и борьбу с разными глюками методом проб и ошибок я уже истратил минимум 15 рабочих дней (может даже уже к 20).
А еще я уже 4ую неделю инсталлирую on-premise у одного клиента... <всхлипывает, пытается биться головой о клавиатуру>

[Ace of Database]

Можно пару-тройку лет поработать у клиентов, которые купили АХ7, и клиенты будут лояльны, списывая баги на новизну системы. Потом, когда выйдет АХ8, можно быстренько уйти к купившим её клиентам, и те опять будут лояльно относиться к багам из-за новизны системы.

[DynamicsDevCons@yandex.ru]

Нда уж. Как прибыльно продаваться консалтингу с такими трудозатратами не представляю...

[trud]

Quote:

Originally Posted by DynamicsDevCons@yandex.ru

Нда уж. Как прибыльно продаваться консалтингу с такими трудозатратами не представляю...

Делать и использовать решения, а не пытаться все запрограммировать с нуля. в техническом плане в АХ7 именно ведение решений сделано на порядок более грамотно(загрузка данных, описание БП, теже экстеншены, магазин решений)

[fed]

Quote:

Originally Posted by trud

Делать и использовать решения, а не пытаться все запрограммировать с нуля. в техническом плане в АХ7 именно ведение решений сделано на порядок более грамотно(загрузка данных, описание БП, теже экстеншены, магазин решений)

Использование решений (в особенности таких как Dynamics Retail или Dynamics Integrator) позволяет минимизировать затраты на разработку и максимизировать затраты на борьбу с недокументированными особенностями системы и trial and error. Также вы сможете значительно улучшить свой Hindglish, благодаря регулярной возможности пообщаться с носителями языка из Bengaloru.

[Evgeniy_R]

Quote:

Originally Posted by trud

Делать и использовать решения, а не пытаться все запрограммировать с нуля. в техническом плане в АХ7 именно ведение решений сделано на порядок более грамотно(загрузка данных, описание БП, теже экстеншены, магазин решений)

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

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

Удручен показателями в x2-x4...

[DynamicsDevCons@yandex.ru]

Quote:

Originally Posted by trud

Делать и использовать решения, а не пытаться все запрограммировать с нуля. в техническом плане в АХ7 именно ведение решений сделано на порядок более грамотно(загрузка данных, описание БП, теже экстеншены, магазин решений)

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

[EVGL]

Quote:

Originally Posted by DynamicsDevCons@yandex.ru

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

Да, причем русские компании по сути выключены из этого процесса. Все, что я видел из России, полно местной специфики (всякие там "приказы", "спецодежда", "наряды"), не переведено или жутко плохо переведено на английский и международному клиенту не интересно.

[DynamicsDevCons@yandex.ru]

Quote:

Originally Posted by EVGL

Да, причем русские компании по сути выключены из этого процесса.

Еще и вопрос конкуренции. Одно дело "конкурировать" на локальном рынке. А другое дело с нашими коллегами из Индии. В общем российские компании точно в пролете с новой версией