|
![]() |
#1 |
Участник
|
![]()
Собственно, пишу, т.к. не увидел ничего на эту тему.
Я с недавних пор использую подход SCRUM при управлении процессом разработки CRM. Результат не заставил себя ждать. Затянувшийся вялотекущий проект (около полугода без осязаемого результата) был "разрулен" в течение 1,5-2месяцев. После этого "показательного" проекта продолжаем в том же духе. Используем спринты (в основном 2х недельные), Юзер Стори и т.д. Возможно у кого-то есть идеи по этой теме. Возможно, кто-то слышал, что Agile да и Scrum в частности работает только для тех, кто пишет код "с нуля" или только для аутсорсинговых компаний и поэтому даже и не пробовал применять в своей разработке... Буду рад ответить узнать что-то новое или ответить на вопросы. you are welcome! |
|
![]() |
#2 |
Участник
|
Расскажите, пож, как была построена работа раньше? Почему не было результатов?
|
|
![]() |
#3 |
Участник
|
раньше работали в рамках классики водопада: собираем сначала все требования (+возможно проводим демонстрацию прототипа), заказчик подписывает и только потом мы разрабатываем. Т.к. после утверждения громоздких требований на их разработку требовалось много времени, то заказчик после утверждения ТЗ мог увидеть реальный результат только после разработки (правда иногда еще мы проводили демонстрации "прототипа" до окончания разработки) через 1-3 месяца. За это время он уже забыл что было написано в ТЗ+постоянно меняется "видение" результата. Соответственно через 1-3мес он смотрел на результаты как "... на новые ворота" и говорит, что это не то что он хотел.
|
|
![]() |
#4 |
Участник
|
Любопытно. Я всегда считал, что Scrum 'эффективен, когда заказчик адекватен, но сам бизнес быстро изменяется и нет смысла фиксировать его в ТЗ и оценивать результат разработки на соответствие его ТЗ. В вашем случае. если я правильно понял, заказчик "не понимает чего он хочет или забывает что требовал ранее". Удивлен, что в этом случае методология позволяет разрулить ситуацию. В любом случае подход заслуживает внимания и обсуждения.
|
|
![]() |
#5 |
Участник
|
Цитата:
Сообщение от Daniil
![]() раньше работали в рамках классики водопада: собираем сначала все требования (+возможно проводим демонстрацию прототипа), заказчик подписывает и только потом мы разрабатываем. Т.к. после утверждения громоздких требований на их разработку требовалось много времени, то заказчик после утверждения ТЗ мог увидеть реальный результат только после разработки (правда иногда еще мы проводили демонстрации "прототипа" до окончания разработки) через 1-3 месяца. За это время он уже забыл что было написано в ТЗ+постоянно меняется "видение" результата. Соответственно через 1-3мес он смотрел на результаты как "... на новые ворота" и говорит, что это не то что он хотел.
Как вы этот вопрос решили на своем проекте? И еще - вы после каждого спринта только систему демонстрируете и правите ошибки, или же делаете какие-то доработки, не включенные в первоначальний план на этот спринт? PS. Извините, если сумбурно выражаюсь, но надеюсь суть ясна :-) |
|
![]() |
#6 |
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.
__________________
С уважением, Олег. |
|
![]() |
#7 |
Участник
|
Цитата:
Конечно все зависит от специфики проекта, его масштабов, и, в общем можно выразиться так: "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). |
|
![]() |
#8 |
Участник
|
Кстати, возможно это неизвестно большинству, но Майкрософт перешла на использование agile в команде разработки Microsoft Dynamics
Так что - ждем хороших результатов. ![]() |
|
![]() |
#9 |
Moderator
|
Цитата:
![]() |
|
![]() |
#10 |
Участник
|
Цитата:
это говорит только о том, что давно пора было. Цитата:
Цитата:
Проблема отсутствия хоть минимальной документации очень быстро ощущается через 2-3 месяца большого проекта, когда в голове уже не умещается )) вообще Скрам - это перенос акцента с документирования на общение (collaboration). Очень много общения (например обязательные ежедневные стандапы по 15мин). Это основная черта. И поэтому меньше документации и меньше непоняток и недовольств в итоге. Но Скрам - это тоже водопадики, только мноого маааленькич водопадиков: Цитата:
Конечно Скрам не панацея. Да и вообще возможно есть или будет что-то лучше. Но на данном этапе это очень неплохо. Цитата:
Сообщение от drongo
![]() Действительно, периодический "мониторинг" проекта (в том числе и показ заказчику) очень полезен. Сам с таким сталкиваюсь в процессе работ. С другой стороны, не совсем понятно, как в данном быть с бюджетом на проект? Ведь многие заказчики хотят на самых ранних этапах (анализ, дизайн, ТЗ) узнать размер бюджета на проект и утвердить его. Получается, что вам надо либо брать бюджет с запасом, либо согласовывать, что бюджет постоянно меняется.
Как вы этот вопрос решили на своем проекте? И еще - вы после каждого спринта только систему демонстрируете и правите ошибки, или же делаете какие-то доработки, не включенные в первоначальний план на этот спринт? PS. Извините, если сумбурно выражаюсь, но надеюсь суть ясна :-) Но, как правильно Вы заметили идеальная картина - это "гибкий" бюджет. В своем проекте мы не смогли добиться изменения бюджета, но зато смогли отсеять кучу (действительно много) лишней, ненужной или второ-третьестепенной работы. А это экономия трудозатрат и, соответственно, денег ). За счет более детальной оценки, приоретизации требований (в виде ЮзерСторий). После спринта мы проводим Демо полностью протестированного функционала (без багов) заказчику. Ошибки устраняются во время спринта. Это один из постулатов Скрама: мы должны поставлять в конце каждого спринта полностью рабочий, протестированный, качественный (и, желательно, отрефакторенный) код. Ну а после Демо у нас Ретроспектива, небольшой отдых и Планирование нового Спринта ). Иногда бывает небольшой вынужденный перерыв между спринтами, тогда мы можем в режиме Kanbana (текущей работы) править найденные заказчиком ошибки или работать над следующими по списку хотелками которые не вошли в этот спринт. Прошу прощения за отсутствие четкости изложения. Я не мастер в этом, но надеюсь что и моя мысль ясна )) |
|
![]() |
#11 |
Шаман форума
|
Цитата:
Сообщение от Daniil
![]() С бюджетом верно заметили. Но тут в двух словах не ответишь. Очень хорошо отвечает на подобные вопросы Майк Кон в одной из своих книг. Тут просто совсем иной принцип. Найду в книге - напишу. Тут целая философия, честное слово. Но она работает! Потому что заказчик получает то что хочет. Но, как правильно Вы заметили идеальная картина - это "гибкий" бюджет. ![]() В случае разработки сторонним консультантом для отдельного от него заказчика встаёт таки вопрос бюджета. То есть консультанту интересно получить с проекта прибыль, а не сидеть годами на зарплате сочиняя формочки с овальными кнопками. Посему выгоднее всего для консультанта напяливание всем подряд типового решения для типовых задач. В экономической теории это известно как "эффект масштаба" - то есть гибкость системы сознательно ограничивается во имя тиражируемости. С коробочными системами это - наилучший для консультанта вариант, так как ему (консультанту) полагается покрывать постоянные издержки, а также одновременно ваять для нескольких заказчиков. Альтернативный подход - выдача клиенту технологии для in-house разработки, при которой вполне подходит и описанный Вами подход. P.S. Написатели книжек отлично знают, что выгоднее всего вообще ничего не внедрять, а писать книжки про то, "как надо". Рисков как-то меньше. И, кстати, книжка - вещь безусловно тиражируемая, там так и написано - мол, тираж такой-то. А представьте, если бы писатель под каждого читателя отдельную книжку писал - одному подлиннее, другому покороче, третьему сюжет подправить, четвёртому на другой язык перевести и оглавление поудобнее... небось не так весело было бы методологу ![]()
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately. |
|
|
За это сообщение автора поблагодарили: Ivanhoe (5), gl00mie (2), Player1 (1), handy-comp (2). |
![]() |
#12 |
Участник
|
Тут главное на первом месяце уволить директора по IT, который допустил такой подход.
|
|
![]() |
#13 |
Участник
|
А вот эти митинги каждый день - они не напрягают?
|
|
![]() |
#14 |
Участник
|
Поначалу было трудно привыкнуть. Но сейчас я не откажусь от них ни за какие конфетки )
Они и правда начинают напрягать только когда перестает четко соблюдаться дисциплина, 15 мин и регламент (что делал? Что буду делать? С какими трудностями столкнулся.) |
|
![]() |
#15 |
Участник
|
Цитата:
![]() |
|
![]() |
#16 |
Kostya Afendikov
|
To Daniil: Опишите состав команды и все ли скрам активности используете? Product Owner со стороны заказчика или вашей? Как быстро и оперативно получают разработчики ответы на свои вопросы? Что берете в спринт? Как происходит демо и для кого? Commitment на спринт не меняется по ходу?
Как показываете результаты и как настроили среду для разработки: общая или каждому разрабочику вируалка - тестировщик - демо - лайв... ? |
|
![]() |
#17 |
Участник
|
В начале темы вы описали решение проблемы, которая заключалась в связке Заказчик-Исполнитель. Как Заказчик участвует в проекте по новой методике: кто, когда и что делает со стороны Заказчика?
__________________
Ivanhoe as is.. |
|
![]() |
#18 |
Участник
|
этот смайлик не зря поставили, знаете что не в бровь а в глаз
![]() конечно. но теперь, спустя время они уже совсем по-другому относятся к скраму. это не быстро. но это четкий подход, если не лениться. это, если хотите, ломка привычного мировоззрения. Но кто это понял, тот обречен на успех )) Цитата:
Сообщение от Bondonello
![]() To Daniil: Опишите состав команды и все ли скрам активности используете? Product Owner со стороны заказчика или вашей? Как быстро и оперативно получают разработчики ответы на свои вопросы? Что берете в спринт? Как происходит демо и для кого? Commitment на спринт не меняется по ходу?
Как показываете результаты и как настроили среду для разработки: общая или каждому разрабочику вируалка - тестировщик - демо - лайв... ? 1. констультант\скрам-мастер 2. девелопер+иногда спец по отчетам и кастомизации 3. тестировщик 4. продукт овнер от заказчика в одном проекте роль продукт овнера выполнял консультант. ответы на вопросы поступали быстро-это главная задача скрам-мастера обеспечить быструю реакцию. здесь очень важны: адекватность продукт овнера, его доступность и время реакции. в спринт берем все ЮСтори по приоритету на сумму, что превышает производительность команды. Перечень ЮС на спринт не меняется за редким исключением.это жизнь. но продукт овнер должен понимать серьезность этого шага (аварийная остановка спринта как вариант). решает только команда. все ведем в ТФС (ЮС, таски, баги и т.д.) Демо показываем заказчику, при участии всех членов команды (не всегда получается). иногда есть предварительное внутреннее демо если директора очень дорожат заказчиком. Демо не только для заказчика. Демо для КОМАНДЫ! это очень важно. это признание их профессионализма. жаль не всегда это понимают (даже сами разработчики или тестеры). насчет инструментов и среды разработки-это не суть важно. Разр.среда+Тестовая+Продакшен. обычно так. Цитата:
PO участвует в: мозговой штурм по написанию историй моделировании ролей (если нужно) в собрании по оценке (оценивает только команда, он наблюдает) и приоретизации историй планировании спринта обсуждение деталей требований и критериев приемки ежедневных стенд-апах (в идеале на всех, конечно) устранении препятствий в ходе спринта принимает ЮСтори демо детальнее читайте книги Хенрика Книнберга, я все делал по ним. и сейчас постоянно перечитываю. удачи! дело не простое, но интересное. Последний раз редактировалось Daniil; 12.11.2013 в 00:10. |
|
|
За это сообщение автора поблагодарили: kALVINS (4), NetBus (1). |
![]() |
#19 |
Участник
|
По гибким методологиям есть хорошая вводная бесплатная книга
«Гибкие методологии разработки» от Бориса Вольфсона, можно легко найти в интернете. |
|
![]() |
#20 |
Участник
|
книги
Цитата:
Цитата:
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). |