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 (текущей работы) править найденные заказчиком ошибки или работать над следующими по списку хотелками которые не вошли в этот спринт.

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