Scrum (Agile) and CRM development

[Daniil]

Собственно, пишу, т.к. не увидел ничего на эту тему.
Я с недавних пор использую подход SCRUM при управлении процессом разработки CRM. Результат не заставил себя ждать. Затянувшийся вялотекущий проект (около полугода без осязаемого результата) был "разрулен" в течение 1,5-2месяцев.
После этого "показательного" проекта продолжаем в том же духе. Используем спринты (в основном 2х недельные), Юзер Стори и т.д.

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

Буду рад ответить узнать что-то новое или ответить на вопросы.

you are welcome!

[mnt_dx]

Расскажите, пож, как была построена работа раньше? Почему не было результатов?

[Daniil]

Цитата:

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

Расскажите, пож, как была построена работа раньше? Почему не было результатов?

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

[vaavr]

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

[drongo]

Цитата:

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

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

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

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

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

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

[oip]

Я на всякий случай оставлю тут информацию из Sure Step о том, когда по мнению MS имеет смысл применять данную методологию.

Цитата:

Purpose
The Agile project type represents a flexible and collaborative approach to implementing Microsoft Dynamics Solutions at a single site requiring specific features and moderate-to-complex customizations.

Description
The Agile Project Type is associated with an iterative, incremental process for developing Microsoft Dynamics Solutions. This Project Type gives customers greater control over the final solution because they can quickly change the direction of solution development and implementation from one sprint cycle to the next. This means that they are better placed to respond to their businesses needs as development of the solution progresses.

This Project type can be attractive to customers, but it does come with its own set of risks and potential problems that must be carefully explained to a customer before embarking on this implementation approach. This project type requires clear guidance from the customer and strong management from the implementation team. The frequency and intensity of communication associated with an Agile Project type is normally very high, resulting in a solution that reflects the customer’s business needs clearly. Additionally, because of the dynamic nature of the project approach, documentation is kept to a minimum throughout the project and is delivered with a barely-good-enough approach during requirement design.

The Agile Project Type is typically used in implementation projects where one or more of the following circumstances exist:
- Customer requirements are not fully defined or known up front.
- Customer requires implementation to be flexible to accommodate changing business priorities.
- Customer focus is on the delivery of solution and does not require complete documentation.
- Customer-specific features are required.
- Moderate-to-complex customizations are required.
- Independent software vendor (ISV) solutions are included.
- Simple-to-moderate infrastructure is involved.
- Customer-specific integrations or interfaces to third-party systems are required.
- Simple-to-complex data migration is involved.
- Small-to-medium number of users will use the solution.

[Daniil]

Цитата:

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

Я на всякий случай оставлю тут информацию из Sure Step о том, когда по мнению MS имеет смысл применять данную методологию.

Спасибо! Я знаю про эти варианты совмещенности SStep+Agile которые предлагает мелкомягкий. Но это теория, а меня интересует как это на практике.
Конечно все зависит от специфики проекта, его масштабов, и, в общем можно выразиться так: "Agile-это для маленьких и средних проектов, а Sure Step или "классика" для больших". Но не обязательно. Дело в том, что можно их успешно объединить! Например, начало и окончание проекта по классике водопада/каскада а серединка Agile (Scrum, Kanban...).
Т.к. Вы совершенно верно заметили "a barely-good-enough approach during requirement design...Customer focus is on the delivery of solution and does not require complete documentation.", то классика позволит решить задачу документации а Agile отлично закроет часть разработки.
Когда большой проект идет полностью по Agile, то тут основные проблемы:
зафиксированные сроки и деньги;
трассируемость требований (кот.всегда есть в классике, но как я уже знаю успешно решается и в Scrum).

[kashperuk]

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

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

[fed]

Цитата:

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

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

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

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

[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, который допустил такой подход.

[mnt_dx]

А вот эти митинги каждый день - они не напрягают?

[Daniil]

Цитата:

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

А вот эти митинги каждый день - они не напрягают?

Поначалу было трудно привыкнуть. Но сейчас я не откажусь от них ни за какие конфетки )
Они и правда начинают напрягать только когда перестает четко соблюдаться дисциплина, 15 мин и регламент (что делал? Что буду делать? С какими трудностями столкнулся.)

[NetBus]

Цитата:

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

Поначалу было трудно привыкнуть. Но сейчас я не откажусь от них ни за какие конфетки )
Они и правда начинают напрягать только когда перестает четко соблюдаться дисциплина, 15 мин и регламент (что делал? Что буду делать? С какими трудностями столкнулся.)

Программисты как отнеслись к новому подходу? Сопротивления были?

[Bondonello]

To Daniil: Опишите состав команды и все ли скрам активности используете? Product Owner со стороны заказчика или вашей? Как быстро и оперативно получают разработчики ответы на свои вопросы? Что берете в спринт? Как происходит демо и для кого? Commitment на спринт не меняется по ходу?
Как показываете результаты и как настроили среду для разработки: общая или каждому разрабочику вируалка - тестировщик - демо - лайв... ?

[Ivanhoe]

В начале темы вы описали решение проблемы, которая заключалась в связке Заказчик-Исполнитель. Как Заказчик участвует в проекте по новой методике: кто, когда и что делает со стороны Заказчика?

[Daniil]

Цитата:

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

Программисты как отнеслись к новому подходу? Сопротивления были?

этот смайлик не зря поставили, знаете что не в бровь а в глаз
конечно. но теперь, спустя время они уже совсем по-другому относятся к скраму. это не быстро. но это четкий подход, если не лениться. это, если хотите, ломка привычного мировоззрения. Но кто это понял, тот обречен на успех ))

Цитата:

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

To Daniil: Опишите состав команды и все ли скрам активности используете? Product Owner со стороны заказчика или вашей? Как быстро и оперативно получают разработчики ответы на свои вопросы? Что берете в спринт? Как происходит демо и для кого? Commitment на спринт не меняется по ходу?
Как показываете результаты и как настроили среду для разработки: общая или каждому разрабочику вируалка - тестировщик - демо - лайв... ?

слишком много вопросов в 3х строчках.
1. констультант\скрам-мастер
2. девелопер+иногда спец по отчетам и кастомизации
3. тестировщик
4. продукт овнер от заказчика
в одном проекте роль продукт овнера выполнял консультант.
ответы на вопросы поступали быстро-это главная задача скрам-мастера обеспечить быструю реакцию. здесь очень важны: адекватность продукт овнера, его доступность и время реакции.
в спринт берем все ЮСтори по приоритету на сумму, что превышает производительность команды.
Перечень ЮС на спринт не меняется за редким исключением.это жизнь. но продукт овнер должен понимать серьезность этого шага (аварийная остановка спринта как вариант). решает только команда.
все ведем в ТФС (ЮС, таски, баги и т.д.)
Демо показываем заказчику, при участии всех членов команды (не всегда получается). иногда есть предварительное внутреннее демо если директора очень дорожат заказчиком.
Демо не только для заказчика. Демо для КОМАНДЫ! это очень важно. это признание их профессионализма. жаль не всегда это понимают (даже сами разработчики или тестеры).
насчет инструментов и среды разработки-это не суть важно. Разр.среда+Тестовая+Продакшен. обычно так.

Цитата:

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

В начале темы вы описали решение проблемы, которая заключалась в связке Заказчик-Исполнитель. Как Заказчик участвует в проекте по новой методике: кто, когда и что делает со стороны Заказчика?

со стороны заказчика нужен 1 чел-продукт овнер (PO). он определяет объем работ и приоритеты. он отвечает на все вопросы (или помогает быстро получить информацию). это должно быть заинтересованное лицо.
PO участвует в:
мозговой штурм по написанию историй
моделировании ролей (если нужно)
в собрании по оценке (оценивает только команда, он наблюдает) и приоретизации историй
планировании спринта
обсуждение деталей требований и критериев приемки
ежедневных стенд-апах (в идеале на всех, конечно)
устранении препятствий в ходе спринта
принимает ЮСтори
демо

детальнее читайте книги Хенрика Книнберга, я все делал по ним. и сейчас постоянно перечитываю.
удачи! дело не простое, но интересное.

[NetBus]

По гибким методологиям есть хорошая вводная бесплатная книга
«Гибкие методологии разработки» от Бориса Вольфсона,
можно легко найти в интернете.

[Daniil]

Цитата:

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

детальнее читайте книги Хенрика Книнберга, я все делал по ним. и сейчас постоянно перечитываю.
удачи! дело не простое, но интересное.

Цитата:

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

По гибким методологиям есть хорошая вводная бесплатная книга
«Гибкие методологии разработки» от Бориса Вольфсона,
можно легко найти в интернете.

Scrum и XP: заметки с передовой
http://scrum.org.ua/wp-content/uploa...-rus-final.pdf

SCRUM И KANBAN:ВЫЖИМАЕМ МАКСИМУМ
http://scrum.org.ua/wp-content/uploa...banRuFinal.pdf

все просто как дважды два. это мега-книги, маленькие по размеру, огромные по значению!
качайте. все бесплатно и книги по 60стр каждая. с этого все началось у меня ))

+к этому доабвлю еще книги Майка Кона: Истории, Скрам, Оценка.