Scrum (Agile) and CRM development

[mnt_dx]

А я подумал, что в опросе под Microsoft Dynamics подразумевается именно АХ.

[Daniil]

Цитата:

Сообщение от fed

Я все-таки слегка добавлю насчет методологии. Хотя MS и оперирует понятием "Microsoft Dynamics", CRM и Ax - это принципиально разные по методологии внедрения продукты. CRM - по большому счету - инструмент разработки самописок. Ну то есть - да - конечно если в комманде есть опытный консультант по организации процесса продаж (я таких не видел в природе, правда. Только слышал через общих знакомых), то шансы на успешное внедрение увеличиваются. Если такого консультанта нету - ну будет еще одна самописка, только не на голом C# написаная с ноля, а на CRM. В худшем случае, клиент спустя пару лет осознает что он заплатил за софт N килобаксов и за внедрение 10*N килобаксов. Соответственно - вероятно проще было вообще с нуля писать чем CRM покупать.
Но вот в случае Аксапты, все таки нормально сделанный проект - это проект консалтинговый. А чтобы такой проект сделать, надо на предприятие придти, изучить как оно работает, какие проблемы видят стейкхолдеры, каких проблем они не видят, чего они хотят, чего им на самом деле надо, и тп. И только после этого можно как-то планировать разработку и реализацию. Если же применить модель прототипирования, то неизбежно дело кончиться провалом (много раз такое видел). На каждом цикле конкретные юзеры просят какие-то полезные лично для них формочки или мелкие отчетики, а в результате, к моменту когда дело доходит до планирования, финансовой отчетности, бюджетирования или себестоимости той же (то есть - не некоторым примитивным процессам ввода простейших данных, а к тем самым сложным и комплексным процессам, ради которых MRP и внедряется), оказывается что на ранних циклах забыли запрограммировать и настроить ввод половины необходимой информации. А даже та информация которая есть - она отструктурирована для удобства низовых пользоветелей, а не для удобства тех кто потом этой информацией пользуется в стратегических процессах. (типичный пример - вместо использования проводок по ГК и модульных проводок для финансового учета, по просьбе низовых финансистов вколбасили дополнительную табличку - как в Excel было. Данные из таблички удалять легко, но с встроенной отчетностью она ни разу не интегрирована). В итоге - на поздних стадиях проекта большая часть усилий сводиться к тому чтобы как-то интегрировать то что налажали по просьбе пользователей с тем что на самом деле необходимо топам и акционерам. В итоге проект как-то работает, но чтобы его поддерживать хоть как-то, заказчику приходиться по одному программисту на 10 пользователей держать...

вот тут конечно есть зерно истины, но...
для справки: SAP уже разработали и внедрили в свой продукт модуль ASAP для управления проектом внедрения своей системы. это не СКРАМ в чистом виде, но что-то типа Agile в своем варианте.
так что ERP подкоряется потихоньку под Agile тоже ))
мир динамичен. подходы меняются.

[fed]

Цитата:

Сообщение от Daniil

вот тут конечно есть зерно истины, но...
для справки: SAP уже разработали и внедрили в свой продукт модуль ASAP для управления проектом внедрения своей системы. это не СКРАМ в чистом виде, но что-то типа Agile в своем варианте.
так что ERP подкоряется потихоньку под Agile тоже ))
мир динамичен. подходы меняются.

Для справки - ASAP основан на идее, что вместо того чтобы делать детальное исследование бизнес-процессов до внедрения и дизайн процессов после внедрения, мы просто берем некие типовые бизнес-процессы и настраиваем систему под них (не запариваясь о том что у заказчика сейчас и как он будет менять свой бизнес под новые бизнес-процессы). Я не буду обсуждать этот подход в деталях (коротко говоря - это такой большевизм от внедрения). Могу только сказать что НИ МАЛЕЙШЕГО отношения к Agile этот подход не имеет. Вполне себе классический водопад, просто из него убрали стадию изучения реального заказчика и заменили на библиотеку сферических заказчиков в вакууме..

[komar]

Цитата:

Сообщение от Daniil

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

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

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

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

P.S. Написатели книжек отлично знают, что выгоднее всего вообще ничего не внедрять, а писать книжки про то, "как надо". Рисков как-то меньше.
И, кстати, книжка - вещь безусловно тиражируемая, там так и написано - мол, тираж такой-то. А представьте, если бы писатель под каждого читателя отдельную книжку писал - одному подлиннее, другому покороче, третьему сюжет подправить, четвёртому на другой язык перевести и оглавление поудобнее... небось не так весело было бы методологу

[NetBus]

Цитата:

Сообщение от komar

Выглядит это примерно так - Мариванна звонит программисту, программист что-то ваяет, и идёт показывать Мариванне. Потом что-то допиливает, Мариванна довольна, программист при работе. Лет через 5-10 ( в зависимости от количества и качества Мариванн и программистов)

Тут главное на первом месяце уволить директора по IT, который допустил такой подход.

[Player1]

Цитата:

Сообщение от NetBus

Тут главное на первом месяце уволить директора по IT, который допустил такой подход.

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

[komar]

Цитата:

Сообщение от NetBus

Тут главное на первом месяце уволить директора по IT, который допустил такой подход.

Любой подход имеет право на жизнь, если он приводит к нужному результату и стоимость его разумна. Когда разработка ведётся силами своих сотрудников или пары фрилансеров, а функционал по сложности далёк от запуска ракет в космос - даже и так можно добиться сносного результата.

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

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

[S.Kuskov]

Цитата:

Сообщение от komar

P.S. Написатели книжек отлично знают, что выгоднее всего вообще ничего не внедрять, а писать книжки про то, "как надо".

ТОП-100 Аджайл книг всех времен (на конец 2013 года)

Даже не представлял себе что их столько

[fed]

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

[S.Kuskov]

«Хочешь разбогатеть – придумай свою религию». (С) Рон Хаббард

[gl00mie]

Цитата:

Сообщение от komar

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

На эту тему, по-моему, очень удачно написано в книге I. M. Wright's "Hard Code" (цитату можно посмотреть здесь - она выделена в блоге курсивом)

Цитата:

Управление проектами происходит по-разному на разных уровнях масштаба и абстракции. Есть уровень команды или отдельной функции (около 10 человек), уровень проекта (от 50 до 5000 человек, работающих над определенным релизом) и уровень продукта (несколько релизов, которыми управляют менеджеры). Методы гибкой разработки прекрасно работают на уровне команды, формальные методы прекрасно работают на уровне проекта, а методы долгосрочного стратегического планирования прекрасно работают на уровне продукта. Однако, люди редко работают одновременно на нескольких уровнях; на самом деле, обычно проходят годы, прежде чем отдельный человек переходит от работы на одном уровне к работе на другом. Из-за этого люди думают, что методы, эффективные на одном уровне, должны быть применены и к другим, что зачастую приводит к трагическим последствиям. Мораль такова: небольшие слаженные группы работают иначе, нежели масштабные распределенные организации, поэтому выбирайте подход, соответствующий конкретной ситуации.

[mnt_dx]

А может скрам подходит для поддержки большого АХ решения?

[AlexeyS]

Цитата:

Сообщение от fed

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

точно-точно!
Вообще идеализация чего-то - это от недостатка опыта и знаний. Под разные задачи нужны разные методологии

[komar]

Цитата:

Сообщение от AlexeyS

точно-точно!
Вообще идеализация чего-то - это от недостатка опыта и знаний. Под разные задачи нужны разные методологии

С формальными методологиями программизма постоянно выходит конфуз. То какой-нибудь Торвальдс за пару месяцев напишет ядро для системы, над которым нормальная команда бьётся пару десятков лет, то ещё какая беда приключится...
Есть такая мысль, что программирование вообще куда ближе к искусству, чем к сборочному производству. А картину по методологии не очень-то нарисуешь. То есть критерий готовго результата - конечно есть. А вот пошаговую инструкцию для дрессированной обезьяны по достижению этого результата - поди придумай...

А где не сформулировать инструкцию - формулируется ритуал.

[vaavr]

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

[komar]

В буквальной трактовке внедрять твёрдый предмет легче

[vaavr]

Цитата:

В буквальной трактовке внедрять твёрдый предмет легче

Те, кто хоть раз делал колоноскопию, с вами не согласятся.

[komar]

У меня внедрение с менее экзотическими действиями ассоциируется. Впрочем, не будем уходить от темы

[AlexeyS]

Цитата:

Сообщение от vaavr

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

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

[Daniil]

Цитата:

Сообщение от mnt_dx

А может скрам подходит для поддержки большого АХ решения?

в принципе может, если группировать куски хотелок в более-менее объемные и логичные блоки работ (Юзер Стори). но это вряд-ли получится, т.к. в поддержке более высокая степень неопределенности- не знаешь что вылезет завтра или через час.
Для поддержки более подходит Kanban. как раз такой пример применения Kanban в поддержке описывается в книге "SCRUM И KANBAN:ВЫЖИМАЕМ МАКСИМУМ":

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