![]() |
#1 |
Участник
|
![]()
Собственно, пишу, т.к. не увидел ничего на эту тему.
Я с недавних пор использую подход SCRUM при управлении процессом разработки CRM. Результат не заставил себя ждать. Затянувшийся вялотекущий проект (около полугода без осязаемого результата) был "разрулен" в течение 1,5-2месяцев. После этого "показательного" проекта продолжаем в том же духе. Используем спринты (в основном 2х недельные), Юзер Стори и т.д. Возможно у кого-то есть идеи по этой теме. Возможно, кто-то слышал, что Agile да и Scrum в частности работает только для тех, кто пишет код "с нуля" или только для аутсорсинговых компаний и поэтому даже и не пробовал применять в своей разработке... Буду рад ответить узнать что-то новое или ответить на вопросы. you are welcome! |
|
![]() |
#2 |
Участник
|
Расскажите, пож, как была построена работа раньше? Почему не было результатов?
|
|
![]() |
#3 |
Axapta
|
Я на всякий случай оставлю тут информацию из 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.
__________________
С уважением, Олег. |
|
![]() |
#4 |
Участник
|
раньше работали в рамках классики водопада: собираем сначала все требования (+возможно проводим демонстрацию прототипа), заказчик подписывает и только потом мы разрабатываем. Т.к. после утверждения громоздких требований на их разработку требовалось много времени, то заказчик после утверждения ТЗ мог увидеть реальный результат только после разработки (правда иногда еще мы проводили демонстрации "прототипа" до окончания разработки) через 1-3 месяца. За это время он уже забыл что было написано в ТЗ+постоянно меняется "видение" результата. Соответственно через 1-3мес он смотрел на результаты как "... на новые ворота" и говорит, что это не то что он хотел.
|
|
![]() |
#5 |
Участник
|
Цитата:
Конечно все зависит от специфики проекта, его масштабов, и, в общем можно выразиться так: "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). |
|
![]() |
#6 |
Участник
|
Кстати, возможно это неизвестно большинству, но Майкрософт перешла на использование agile в команде разработки Microsoft Dynamics
Так что - ждем хороших результатов. ![]() |
|
![]() |
#7 |
Участник
|
Любопытно. Я всегда считал, что Scrum 'эффективен, когда заказчик адекватен, но сам бизнес быстро изменяется и нет смысла фиксировать его в ТЗ и оценивать результат разработки на соответствие его ТЗ. В вашем случае. если я правильно понял, заказчик "не понимает чего он хочет или забывает что требовал ранее". Удивлен, что в этом случае методология позволяет разрулить ситуацию. В любом случае подход заслуживает внимания и обсуждения.
|
|
![]() |
#8 |
Участник
|
Цитата:
Сообщение от Daniil
![]() раньше работали в рамках классики водопада: собираем сначала все требования (+возможно проводим демонстрацию прототипа), заказчик подписывает и только потом мы разрабатываем. Т.к. после утверждения громоздких требований на их разработку требовалось много времени, то заказчик после утверждения ТЗ мог увидеть реальный результат только после разработки (правда иногда еще мы проводили демонстрации "прототипа" до окончания разработки) через 1-3 месяца. За это время он уже забыл что было написано в ТЗ+постоянно меняется "видение" результата. Соответственно через 1-3мес он смотрел на результаты как "... на новые ворота" и говорит, что это не то что он хотел.
Как вы этот вопрос решили на своем проекте? И еще - вы после каждого спринта только систему демонстрируете и правите ошибки, или же делаете какие-то доработки, не включенные в первоначальний план на этот спринт? PS. Извините, если сумбурно выражаюсь, но надеюсь суть ясна :-) |
|
![]() |
#9 |
Moderator
|
Цитата:
![]() |
|
![]() |
#10 |
Участник
|
Цитата:
это говорит только о том, что давно пора было. Цитата:
Цитата:
Проблема отсутствия хоть минимальной документации очень быстро ощущается через 2-3 месяца большого проекта, когда в голове уже не умещается )) вообще Скрам - это перенос акцента с документирования на общение (collaboration). Очень много общения (например обязательные ежедневные стандапы по 15мин). Это основная черта. И поэтому меньше документации и меньше непоняток и недовольств в итоге. Но Скрам - это тоже водопадики, только мноого маааленькич водопадиков: Цитата:
Конечно Скрам не панацея. Да и вообще возможно есть или будет что-то лучше. Но на данном этапе это очень неплохо. Цитата:
Сообщение от drongo
![]() Действительно, периодический "мониторинг" проекта (в том числе и показ заказчику) очень полезен. Сам с таким сталкиваюсь в процессе работ. С другой стороны, не совсем понятно, как в данном быть с бюджетом на проект? Ведь многие заказчики хотят на самых ранних этапах (анализ, дизайн, ТЗ) узнать размер бюджета на проект и утвердить его. Получается, что вам надо либо брать бюджет с запасом, либо согласовывать, что бюджет постоянно меняется.
Как вы этот вопрос решили на своем проекте? И еще - вы после каждого спринта только систему демонстрируете и правите ошибки, или же делаете какие-то доработки, не включенные в первоначальний план на этот спринт? PS. Извините, если сумбурно выражаюсь, но надеюсь суть ясна :-) Но, как правильно Вы заметили идеальная картина - это "гибкий" бюджет. В своем проекте мы не смогли добиться изменения бюджета, но зато смогли отсеять кучу (действительно много) лишней, ненужной или второ-третьестепенной работы. А это экономия трудозатрат и, соответственно, денег ). За счет более детальной оценки, приоретизации требований (в виде ЮзерСторий). После спринта мы проводим Демо полностью протестированного функционала (без багов) заказчику. Ошибки устраняются во время спринта. Это один из постулатов Скрама: мы должны поставлять в конце каждого спринта полностью рабочий, протестированный, качественный (и, желательно, отрефакторенный) код. Ну а после Демо у нас Ретроспектива, небольшой отдых и Планирование нового Спринта ). Иногда бывает небольшой вынужденный перерыв между спринтами, тогда мы можем в режиме Kanbana (текущей работы) править найденные заказчиком ошибки или работать над следующими по списку хотелками которые не вошли в этот спринт. Прошу прощения за отсутствие четкости изложения. Я не мастер в этом, но надеюсь что и моя мысль ясна )) |
|
![]() |
#11 |
Участник
|
А вот эти митинги каждый день - они не напрягают?
|
|
![]() |
#12 |
Участник
|
Поначалу было трудно привыкнуть. Но сейчас я не откажусь от них ни за какие конфетки )
Они и правда начинают напрягать только когда перестает четко соблюдаться дисциплина, 15 мин и регламент (что делал? Что буду делать? С какими трудностями столкнулся.) |
|
![]() |
#13 |
Участник
|
Цитата:
![]() |
|
![]() |
#14 |
Kostya Afendikov
|
To Daniil: Опишите состав команды и все ли скрам активности используете? Product Owner со стороны заказчика или вашей? Как быстро и оперативно получают разработчики ответы на свои вопросы? Что берете в спринт? Как происходит демо и для кого? Commitment на спринт не меняется по ходу?
Как показываете результаты и как настроили среду для разработки: общая или каждому разрабочику вируалка - тестировщик - демо - лайв... ? |
|
![]() |
#15 |
Участник
|
В начале темы вы описали решение проблемы, которая заключалась в связке Заказчик-Исполнитель. Как Заказчик участвует в проекте по новой методике: кто, когда и что делает со стороны Заказчика?
__________________
Ivanhoe as is.. |
|
![]() |
#16 |
Участник
|
этот смайлик не зря поставили, знаете что не в бровь а в глаз
![]() конечно. но теперь, спустя время они уже совсем по-другому относятся к скраму. это не быстро. но это четкий подход, если не лениться. это, если хотите, ломка привычного мировоззрения. Но кто это понял, тот обречен на успех )) Цитата:
Сообщение от Bondonello
![]() To Daniil: Опишите состав команды и все ли скрам активности используете? Product Owner со стороны заказчика или вашей? Как быстро и оперативно получают разработчики ответы на свои вопросы? Что берете в спринт? Как происходит демо и для кого? Commitment на спринт не меняется по ходу?
Как показываете результаты и как настроили среду для разработки: общая или каждому разрабочику вируалка - тестировщик - демо - лайв... ? 1. констультант\скрам-мастер 2. девелопер+иногда спец по отчетам и кастомизации 3. тестировщик 4. продукт овнер от заказчика в одном проекте роль продукт овнера выполнял консультант. ответы на вопросы поступали быстро-это главная задача скрам-мастера обеспечить быструю реакцию. здесь очень важны: адекватность продукт овнера, его доступность и время реакции. в спринт берем все ЮСтори по приоритету на сумму, что превышает производительность команды. Перечень ЮС на спринт не меняется за редким исключением.это жизнь. но продукт овнер должен понимать серьезность этого шага (аварийная остановка спринта как вариант). решает только команда. все ведем в ТФС (ЮС, таски, баги и т.д.) Демо показываем заказчику, при участии всех членов команды (не всегда получается). иногда есть предварительное внутреннее демо если директора очень дорожат заказчиком. Демо не только для заказчика. Демо для КОМАНДЫ! это очень важно. это признание их профессионализма. жаль не всегда это понимают (даже сами разработчики или тестеры). насчет инструментов и среды разработки-это не суть важно. Разр.среда+Тестовая+Продакшен. обычно так. Цитата:
PO участвует в: мозговой штурм по написанию историй моделировании ролей (если нужно) в собрании по оценке (оценивает только команда, он наблюдает) и приоретизации историй планировании спринта обсуждение деталей требований и критериев приемки ежедневных стенд-апах (в идеале на всех, конечно) устранении препятствий в ходе спринта принимает ЮСтори демо детальнее читайте книги Хенрика Книнберга, я все делал по ним. и сейчас постоянно перечитываю. удачи! дело не простое, но интересное. Последний раз редактировалось Daniil; 12.11.2013 в 00:10. |
|
|
За это сообщение автора поблагодарили: kALVINS (4), NetBus (1). |
![]() |
#17 |
Участник
|
По гибким методологиям есть хорошая вводная бесплатная книга
«Гибкие методологии разработки» от Бориса Вольфсона, можно легко найти в интернете. |
|
![]() |
#18 |
Участник
|
книги
Цитата:
Цитата:
http://scrum.org.ua/wp-content/uploa...-rus-final.pdf SCRUM И KANBAN:ВЫЖИМАЕМ МАКСИМУМ http://scrum.org.ua/wp-content/uploa...banRuFinal.pdf все просто как дважды два. это мега-книги, маленькие по размеру, огромные по значению! качайте. все бесплатно и книги по 60стр каждая. с этого все началось у меня )) +к этому доабвлю еще книги Майка Кона: Истории, Скрам, Оценка. Последний раз редактировалось Daniil; 13.11.2013 в 13:34. |
|
|
За это сообщение автора поблагодарили: mnt_dx (2). |
![]() |
#19 |
Moderator
|
Я все-таки слегка добавлю насчет методологии. Хотя MS и оперирует понятием "Microsoft Dynamics", CRM и Ax - это принципиально разные по методологии внедрения продукты. CRM - по большому счету - инструмент разработки самописок. Ну то есть - да - конечно если в комманде есть опытный консультант по организации процесса продаж (я таких не видел в природе, правда. Только слышал через общих знакомых), то шансы на успешное внедрение увеличиваются. Если такого консультанта нету - ну будет еще одна самописка, только не на голом C# написаная с ноля, а на CRM. В худшем случае, клиент спустя пару лет осознает что он заплатил за софт N килобаксов и за внедрение 10*N килобаксов. Соответственно - вероятно проще было вообще с нуля писать чем CRM покупать.
Но вот в случае Аксапты, все таки нормально сделанный проект - это проект консалтинговый. А чтобы такой проект сделать, надо на предприятие придти, изучить как оно работает, какие проблемы видят стейкхолдеры, каких проблем они не видят, чего они хотят, чего им на самом деле надо, и тп. И только после этого можно как-то планировать разработку и реализацию. Если же применить модель прототипирования, то неизбежно дело кончиться провалом (много раз такое видел). На каждом цикле конкретные юзеры просят какие-то полезные лично для них формочки или мелкие отчетики, а в результате, к моменту когда дело доходит до планирования, финансовой отчетности, бюджетирования или себестоимости той же (то есть - не некоторым примитивным процессам ввода простейших данных, а к тем самым сложным и комплексным процессам, ради которых MRP и внедряется), оказывается что на ранних циклах забыли запрограммировать и настроить ввод половины необходимой информации. А даже та информация которая есть - она отструктурирована для удобства низовых пользоветелей, а не для удобства тех кто потом этой информацией пользуется в стратегических процессах. (типичный пример - вместо использования проводок по ГК и модульных проводок для финансового учета, по просьбе низовых финансистов вколбасили дополнительную табличку - как в Excel было. Данные из таблички удалять легко, но с встроенной отчетностью она ни разу не интегрирована). В итоге - на поздних стадиях проекта большая часть усилий сводиться к тому чтобы как-то интегрировать то что налажали по просьбе пользователей с тем что на самом деле необходимо топам и акционерам. В итоге проект как-то работает, но чтобы его поддерживать хоть как-то, заказчику приходиться по одному программисту на 10 пользователей держать... Последний раз редактировалось fed; 13.11.2013 в 13:54. |
|
|
За это сообщение автора поблагодарили: Lucky13 (6), NetBus (2), gl00mie (3). |
![]() |
#20 |
Участник
|
Поддержу. В опросе стоило бы явно прописать MS CRM, а не весь Dynamics.
__________________
Ivanhoe as is.. |
|