Scrum (Agile) and CRM development

[Daniil]

Цитата:

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

Кстати, возможно это неизвестно большинству, но Майкрософт перешла на использование agile в команде разработки Microsoft Dynamics

Так что - ждем хороших результатов.

о, да они прямо как Nokia, внедряют только проверенные временем инновации ))
это говорит только о том, что давно пора было.

Цитата:

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

Любопытно. Я всегда считал, что Scrum 'эффективен, когда заказчик адекватен

если заказчик адекватен, то любой подход эффективен )

Цитата:

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

нет смысла фиксировать его в ТЗ и оценивать результат разработки на соответствие его ТЗ.

тут не могу согласиться. это одна из распространенных "крайностей" в которые обычно попадаю новички скрама и аджайла. Agile говорит про "необходимый минимум документации" ("documentation is kept to a minimum throughout the project and is delivered with a barely-good-enough approach during requirement design"), но єто не означает ее полное отсутствие. Просто ее нужно меньше, ровно столько сколько будут читать, а не складировать томами.
Проблема отсутствия хоть минимальной документации очень быстро ощущается через 2-3 месяца большого проекта, когда в голове уже не умещается ))
вообще Скрам - это перенос акцента с документирования на общение (collaboration). Очень много общения (например обязательные ежедневные стандапы по 15мин). Это основная черта. И поэтому меньше документации и меньше непоняток и недовольств в итоге.
Но Скрам - это тоже водопадики, только мноого маааленькич водопадиков:

Цитата:

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

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

совершенно верно. в нашем случае так и было (и есть)). Разруление больше в том, что мы сами наконец-то поняли четко "что сделано а чего не сделано и еще предстоит" и сколько на это нужно времени (трудозатрат). Т.е. мы пол года что-то делали, много делали, но на выходе как будто ничего. так, всего понемного но в основном ничего конкретного. А Скрам позволил нам после каждого спринта выдавать абсолютно точно определенный объем функционала, протестированный и полностью рабочий. Это очень круто. Это...да что говорить.
Конечно Скрам не панацея. Да и вообще возможно есть или будет что-то лучше. Но на данном этапе это очень неплохо.

Цитата:

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

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

Как вы этот вопрос решили на своем проекте?

И еще - вы после каждого спринта только систему демонстрируете и правите ошибки, или же делаете какие-то доработки, не включенные в первоначальний план на этот спринт?

PS. Извините, если сумбурно выражаюсь, но надеюсь суть ясна :-)

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

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

Прошу прощения за отсутствие четкости изложения. Я не мастер в этом, но надеюсь что и моя мысль ясна ))

[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 человек, работающих над определенным релизом) и уровень продукта (несколько релизов, которыми управляют менеджеры). Методы гибкой разработки прекрасно работают на уровне команды, формальные методы прекрасно работают на уровне проекта, а методы долгосрочного стратегического планирования прекрасно работают на уровне продукта. Однако, люди редко работают одновременно на нескольких уровнях; на самом деле, обычно проходят годы, прежде чем отдельный человек переходит от работы на одном уровне к работе на другом. Из-за этого люди думают, что методы, эффективные на одном уровне, должны быть применены и к другим, что зачастую приводит к трагическим последствиям. Мораль такова: небольшие слаженные группы работают иначе, нежели масштабные распределенные организации, поэтому выбирайте подход, соответствующий конкретной ситуации.