Scrum (Agile) and CRM development

[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 никакие "ежедневные шплинты" дяде Пете из Выхино. И даже партнёрам Динамикса система достанется "как получилось" - а дальше делайте с ней, что хотите. Запросы конечного пользователя в лучшем случае поступят один раз - на входе.

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

[gl00mie]

Цитата:

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

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

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

Цитата:

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