AXForum  
Вернуться   AXForum > Рынок > Методология внедрения
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

Результаты опроса: Scrum, Agile это хорошая штука?
А что это вообще такое? 6 33.33%
хорошая 10 55.56%
плохая 0 0%
не для Microsoft Dynamics 2 11.11%
Голосовавшие: 18. Вы ещё не голосовали в этом опросе

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 13.11.2013, 16:09   #21  
mnt_dx is offline
mnt_dx
Участник
Axapta Retail User
Лучший по профессии 2014
 
1,744 / 188 (10) ++++++
Регистрация: 17.02.2011
Адрес: К Северу через Северо-Запад
А я подумал, что в опросе под Microsoft Dynamics подразумевается именно АХ.
Старый 16.11.2013, 17:27   #22  
Daniil is offline
Daniil
Участник
 
11 / 17 (1) ++
Регистрация: 11.06.2013
Адрес: Kyiv
Цитата:
Сообщение от fed Посмотреть сообщение
Я все-таки слегка добавлю насчет методологии. Хотя MS и оперирует понятием "Microsoft Dynamics", CRM и Ax - это принципиально разные по методологии внедрения продукты. CRM - по большому счету - инструмент разработки самописок. Ну то есть - да - конечно если в комманде есть опытный консультант по организации процесса продаж (я таких не видел в природе, правда. Только слышал через общих знакомых), то шансы на успешное внедрение увеличиваются. Если такого консультанта нету - ну будет еще одна самописка, только не на голом C# написаная с ноля, а на CRM. В худшем случае, клиент спустя пару лет осознает что он заплатил за софт N килобаксов и за внедрение 10*N килобаксов. Соответственно - вероятно проще было вообще с нуля писать чем CRM покупать.
Но вот в случае Аксапты, все таки нормально сделанный проект - это проект консалтинговый. А чтобы такой проект сделать, надо на предприятие придти, изучить как оно работает, какие проблемы видят стейкхолдеры, каких проблем они не видят, чего они хотят, чего им на самом деле надо, и тп. И только после этого можно как-то планировать разработку и реализацию. Если же применить модель прототипирования, то неизбежно дело кончиться провалом (много раз такое видел). На каждом цикле конкретные юзеры просят какие-то полезные лично для них формочки или мелкие отчетики, а в результате, к моменту когда дело доходит до планирования, финансовой отчетности, бюджетирования или себестоимости той же (то есть - не некоторым примитивным процессам ввода простейших данных, а к тем самым сложным и комплексным процессам, ради которых MRP и внедряется), оказывается что на ранних циклах забыли запрограммировать и настроить ввод половины необходимой информации. А даже та информация которая есть - она отструктурирована для удобства низовых пользоветелей, а не для удобства тех кто потом этой информацией пользуется в стратегических процессах. (типичный пример - вместо использования проводок по ГК и модульных проводок для финансового учета, по просьбе низовых финансистов вколбасили дополнительную табличку - как в Excel было. Данные из таблички удалять легко, но с встроенной отчетностью она ни разу не интегрирована). В итоге - на поздних стадиях проекта большая часть усилий сводиться к тому чтобы как-то интегрировать то что налажали по просьбе пользователей с тем что на самом деле необходимо топам и акционерам. В итоге проект как-то работает, но чтобы его поддерживать хоть как-то, заказчику приходиться по одному программисту на 10 пользователей держать...
вот тут конечно есть зерно истины, но...
для справки: SAP уже разработали и внедрили в свой продукт модуль ASAP для управления проектом внедрения своей системы. это не СКРАМ в чистом виде, но что-то типа Agile в своем варианте.
так что ERP подкоряется потихоньку под Agile тоже ))
мир динамичен. подходы меняются.
Старый 17.11.2013, 09:19   #23  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Daniil Посмотреть сообщение
вот тут конечно есть зерно истины, но...
для справки: SAP уже разработали и внедрили в свой продукт модуль ASAP для управления проектом внедрения своей системы. это не СКРАМ в чистом виде, но что-то типа Agile в своем варианте.
так что ERP подкоряется потихоньку под Agile тоже ))
мир динамичен. подходы меняются.
Для справки - ASAP основан на идее, что вместо того чтобы делать детальное исследование бизнес-процессов до внедрения и дизайн процессов после внедрения, мы просто берем некие типовые бизнес-процессы и настраиваем систему под них (не запариваясь о том что у заказчика сейчас и как он будет менять свой бизнес под новые бизнес-процессы). Я не буду обсуждать этот подход в деталях (коротко говоря - это такой большевизм от внедрения). Могу только сказать что НИ МАЛЕЙШЕГО отношения к Agile этот подход не имеет. Вполне себе классический водопад, просто из него убрали стадию изучения реального заказчика и заменили на библиотеку сферических заказчиков в вакууме..
За это сообщение автора поблагодарили: gl00mie (2).
Старый 18.11.2013, 14:45   #24  
komar is offline
komar
Шаман форума
Аватар для komar
Ex AND Project
 
5,571 / 600 (32) +++++++
Регистрация: 24.05.2002
Цитата:
Сообщение от Daniil Посмотреть сообщение

С бюджетом верно заметили. Но тут в двух словах не ответишь. Очень хорошо отвечает на подобные вопросы Майк Кон в одной из своих книг. Тут просто совсем иной принцип. Найду в книге - напишу. Тут целая философия, честное слово. Но она работает! Потому что заказчик получает то что хочет.
Но, как правильно Вы заметили идеальная картина - это "гибкий" бюджет.
Собственно, вот и весь Ваш скурум-бурум Я понимаю восторг от красивых картинок, книжек с иностранными словами и т.п. штуковин, но должен заметить, что данный подход (обычно без картинок и длинных слов) применяется на каждом первом проекте внутренней самописки. Выглядит это примерно так - Мариванна звонит программисту, программист что-то ваяет, и идёт показывать Мариванне. Потом что-то допиливает, Мариванна довольна, программист при работе. Лет через 5-10 ( в зависимости от количества и качества Мариванн и программистов) количество дописок доводит систему до состояния полного нестояния, и разработка начинается с очередного нуля (либо таки ставится коробочная система).

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

Альтернативный подход - выдача клиенту технологии для in-house разработки, при которой вполне подходит и описанный Вами подход.

P.S. Написатели книжек отлично знают, что выгоднее всего вообще ничего не внедрять, а писать книжки про то, "как надо". Рисков как-то меньше.
И, кстати, книжка - вещь безусловно тиражируемая, там так и написано - мол, тираж такой-то. А представьте, если бы писатель под каждого читателя отдельную книжку писал - одному подлиннее, другому покороче, третьему сюжет подправить, четвёртому на другой язык перевести и оглавление поудобнее... небось не так весело было бы методологу
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately.
За это сообщение автора поблагодарили: Ivanhoe (5), gl00mie (2), Player1 (1), handy-comp (2).
Старый 19.11.2013, 09:54   #25  
NetBus is offline
NetBus
Участник
 
200 / 85 (3) ++++
Регистрация: 08.07.2005
Адрес: Москва
Цитата:
Сообщение от komar Посмотреть сообщение
Выглядит это примерно так - Мариванна звонит программисту, программист что-то ваяет, и идёт показывать Мариванне. Потом что-то допиливает, Мариванна довольна, программист при работе. Лет через 5-10 ( в зависимости от количества и качества Мариванн и программистов)
Тут главное на первом месяце уволить директора по IT, который допустил такой подход.
Старый 19.11.2013, 10:29   #26  
Player1 is offline
Player1
Участник
Самостоятельные клиенты AX
 
305 / 137 (5) +++++
Регистрация: 21.04.2008
Цитата:
Сообщение от NetBus Посмотреть сообщение
Тут главное на первом месяце уволить директора по IT, который допустил такой подход.
Не везде есть директора IT, где-то простой начальник отдела, или даже бюро. А заму который курирует It-отдел глубоко пофиг как эти парни в свитерах делают работу, лишь бы бухи не ворчали и производственники не ругались.

Последний раз редактировалось Player1; 19.11.2013 в 10:29. Причина: очепятка
Старый 19.11.2013, 13:23   #27  
komar is offline
komar
Шаман форума
Аватар для komar
Ex AND Project
 
5,571 / 600 (32) +++++++
Регистрация: 24.05.2002
Цитата:
Сообщение от NetBus Посмотреть сообщение
Тут главное на первом месяце уволить директора по IT, который допустил такой подход.
Любой подход имеет право на жизнь, если он приводит к нужному результату и стоимость его разумна. Когда разработка ведётся силами своих сотрудников или пары фрилансеров, а функционал по сложности далёк от запуска ракет в космос - даже и так можно добиться сносного результата.

И ещё. Наверное, не нужно смешивать такие разные штуки, как разработка тиражного продукта (который затем расставляется пользователям as-is), и доработку продукта под конкретный проект под задачу, сформулированную как "нарисуй мне кунгуру". То есть при разработке Майкрософтом хоть Динамикса, хоть операционной системы весь "скрам-и-аджайл" - по сути, междусобойчик разработчиков. То есть никто в здравом уме никогда не понесёт при разработке Windows или Ax никакие "ежедневные шплинты" дяде Пете из Выхино. И даже партнёрам Динамикса система достанется "как получилось" - а дальше делайте с ней, что хотите. Запросы конечного пользователя в лучшем случае поступят один раз - на входе.

Тему же завели о применении подобных подходов с лепкой системы на ходу именно на внедрении фирмой-консультантом конечному пользователю, прямо перед "чел овнером от заказчика в ежедневных стенд-апах" - так при таком подходе либо сроки и бюджет изначально резиновые, либо команда получит под плановый срок сдачи "круглосуточный стенд-ап", "ночной фон-колл" и прочие "мозговые штормы", которые хорошее проектное управление должно как бы минимизировать.
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately.
Старый 20.11.2013, 10:38   #28  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от komar Посмотреть сообщение
P.S. Написатели книжек отлично знают, что выгоднее всего вообще ничего не внедрять, а писать книжки про то, "как надо".
ТОП-100 Аджайл книг всех времен (на конец 2013 года)

Даже не представлял себе что их столько
Старый 20.11.2013, 11:20   #29  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Вообще методология часто приобретает характер религии для программистов - со своей обрадностью (типа 10-минутных стенд-ап митингов), терминологией, отцами церкви и их трудами, бродячими проповедниками и тп. То есть - возможно сами авторы методологии к этому результату и не стремились, но в руках последователей их идеи приняли характер первобытной религии типа шаманизма.

Последний раз редактировалось fed; 20.11.2013 в 11:34.
Старый 20.11.2013, 11:27   #30  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
«Хочешь разбогатеть – придумай свою религию». (С) Рон Хаббард
Старый 20.11.2013, 14:05   #31  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от komar Посмотреть сообщение
Наверное, не нужно смешивать такие разные штуки, как разработка тиражного продукта и доработку продукта под конкретный проект под задачу. То есть при разработке Майкрософтом хоть Динамикса, хоть операционной системы весь "скрам-и-аджайл" - по сути, междусобойчик разработчиков. То есть никто в здравом уме никогда не понесёт при разработке Windows или Ax никакие "ежедневные шплинты" дяде Пете из Выхино. И даже партнёрам Динамикса система достанется "как получилось" - а дальше делайте с ней, что хотите. Запросы конечного пользователя в лучшем случае поступят один раз - на входе.
На эту тему, по-моему, очень удачно написано в книге I. M. Wright's "Hard Code" (цитату можно посмотреть здесь - она выделена в блоге курсивом)
Цитата:
Управление проектами происходит по-разному на разных уровнях масштаба и абстракции. Есть уровень команды или отдельной функции (около 10 человек), уровень проекта (от 50 до 5000 человек, работающих над определенным релизом) и уровень продукта (несколько релизов, которыми управляют менеджеры). Методы гибкой разработки прекрасно работают на уровне команды, формальные методы прекрасно работают на уровне проекта, а методы долгосрочного стратегического планирования прекрасно работают на уровне продукта. Однако, люди редко работают одновременно на нескольких уровнях; на самом деле, обычно проходят годы, прежде чем отдельный человек переходит от работы на одном уровне к работе на другом. Из-за этого люди думают, что методы, эффективные на одном уровне, должны быть применены и к другим, что зачастую приводит к трагическим последствиям. Мораль такова: небольшие слаженные группы работают иначе, нежели масштабные распределенные организации, поэтому выбирайте подход, соответствующий конкретной ситуации.

Последний раз редактировалось gl00mie; 20.11.2013 в 14:08. Причина: стилистика
Старый 20.11.2013, 15:40   #32  
mnt_dx is offline
mnt_dx
Участник
Axapta Retail User
Лучший по профессии 2014
 
1,744 / 188 (10) ++++++
Регистрация: 17.02.2011
Адрес: К Северу через Северо-Запад
А может скрам подходит для поддержки большого АХ решения?
Старый 20.11.2013, 15:51   #33  
AlexeyS is offline
AlexeyS
Участник
 
404 / 339 (12) ++++++
Регистрация: 15.06.2004
Адрес: москва
Цитата:
Сообщение от fed Посмотреть сообщение
Вообще методология часто приобретает характер религии для программистов - со своей обрадностью (типа 10-минутных стенд-ап митингов), терминологией, отцами церкви и их трудами, бродячими проповедниками и тп. То есть - возможно сами авторы методологии к этому результату и не стремились, но в руках последователей их идеи приняли характер первобытной религии типа шаманизма.
точно-точно!
Вообще идеализация чего-то - это от недостатка опыта и знаний. Под разные задачи нужны разные методологии
Старый 20.11.2013, 17:18   #34  
komar is offline
komar
Шаман форума
Аватар для komar
Ex AND Project
 
5,571 / 600 (32) +++++++
Регистрация: 24.05.2002
Цитата:
Сообщение от AlexeyS Посмотреть сообщение
точно-точно!
Вообще идеализация чего-то - это от недостатка опыта и знаний. Под разные задачи нужны разные методологии
С формальными методологиями программизма постоянно выходит конфуз. То какой-нибудь Торвальдс за пару месяцев напишет ядро для системы, над которым нормальная команда бьётся пару десятков лет, то ещё какая беда приключится...
Есть такая мысль, что программирование вообще куда ближе к искусству, чем к сборочному производству. А картину по методологии не очень-то нарисуешь. То есть критерий готовго результата - конечно есть. А вот пошаговую инструкцию для дрессированной обезьяны по достижению этого результата - поди придумай...

А где не сформулировать инструкцию - формулируется ритуал.
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately.
Старый 21.11.2013, 10:32   #35  
vaavr is offline
vaavr
Участник
 
72 / 16 (1) ++
Регистрация: 07.06.2002
По моему мнению вся суета вокруг "гибких" методологий проекта основана на предположении, что этот подход поможет решить проблему не адекватного заказчика. Может в каких-то конкретных случаях и удастся, но далеко не всегда, особенно в проектах внедрения ERP - систем.
Вообще в последнее время термин "внедрение" часто понимается в его буквальной трактовке, как "достижение результата при преодолении сопротивления окружающей среды". При таком подходе становится понятным интерес к гибким методологиям.
Старый 21.11.2013, 12:58   #36  
komar is offline
komar
Шаман форума
Аватар для komar
Ex AND Project
 
5,571 / 600 (32) +++++++
Регистрация: 24.05.2002
В буквальной трактовке внедрять твёрдый предмет легче
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately.
Старый 21.11.2013, 17:02   #37  
vaavr is offline
vaavr
Участник
 
72 / 16 (1) ++
Регистрация: 07.06.2002
Цитата:
В буквальной трактовке внедрять твёрдый предмет легче
Те, кто хоть раз делал колоноскопию, с вами не согласятся.
Старый 21.11.2013, 18:42   #38  
komar is offline
komar
Шаман форума
Аватар для komar
Ex AND Project
 
5,571 / 600 (32) +++++++
Регистрация: 24.05.2002
У меня внедрение с менее экзотическими действиями ассоциируется. Впрочем, не будем уходить от темы
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately.
Старый 22.11.2013, 15:18   #39  
AlexeyS is offline
AlexeyS
Участник
 
404 / 339 (12) ++++++
Регистрация: 15.06.2004
Адрес: москва
Цитата:
Сообщение от vaavr Посмотреть сообщение
По моему мнению вся суета вокруг "гибких" методологий проекта основана на предположении, что этот подход поможет решить проблему не адекватного заказчика. Может в каких-то конкретных случаях и удастся, но далеко не всегда, особенно в проектах внедрения ERP - систем.
Вообще в последнее время термин "внедрение" часто понимается в его буквальной трактовке, как "достижение результата при преодолении сопротивления окружающей среды". При таком подходе становится понятным интерес к гибким методологиям.
методология потому и называется гибкой, что позволяет подстраиваться под слишком быстрые изменения окружения и требований
а набор формальных правил и следование им дает если и не эффективный результат, то по меньшей мере ощущение контроля процесса, что уже немало
Старый 12.12.2013, 14:21   #40  
Daniil is offline
Daniil
Участник
 
11 / 17 (1) ++
Регистрация: 11.06.2013
Адрес: Kyiv
Цитата:
Сообщение от mnt_dx Посмотреть сообщение
А может скрам подходит для поддержки большого АХ решения?
в принципе может, если группировать куски хотелок в более-менее объемные и логичные блоки работ (Юзер Стори). но это вряд-ли получится, т.к. в поддержке более высокая степень неопределенности- не знаешь что вылезет завтра или через час.
Для поддержки более подходит Kanban. как раз такой пример применения Kanban в поддержке описывается в книге "SCRUM И KANBAN:ВЫЖИМАЕМ МАКСИМУМ":

"
Я сам из разработчиков, так что о сути технической поддержки я знал мало.
Но я не собирался
"ворваться и всѐ поменять".
Мне нужен был менее
конфликтный
подход, который бы, тем не менее,
научил нас нужному, убрал бы ненужное, и при этом был бы лѐгок в изучении.
Были рассмотрены следующие кандидаты:
1. Scrum – хорошо отработанный и проверенный подход для команд разработчиков.
2. Kanban – новый и непроверенный подход, который зато хорошо ложился на принципы Lean, которых нам как раз и не хватало.
После бесед с менеджерами, принципы Kanbanа и Lean показались хорошими ответами на вопросы, которые нас мучили.
С их точки зрения спринты нам не очень подходили, так как приоритеты
менялись каждый день.
Таким образом, логичной отправной точкой был выбран
Kanban, несмотря
даже на то, что никто из нас не знал, что же это за зверь
"
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Вакансия-Ведущий разработчик MS CRM (Москва) ЕкатеринаЗвездина Рынок труда Microsoft Dynamics 0 20.09.2010 16:53
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 13:43.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.