Как достаточно привередливый РП с опытом реализации проектов порядка 20 лет, могу сказать, что это самое четкое, понятное и логичное видео по скраму, которое мне приходилось видеть на просторах ютуба ) А смотрел я немало. Спасибо.
Перечитав большое количество информации в разных сообществ, пересмотрев кучу видео не в одном канале это видео за 14 минут все по полочкам разложило. Спасибо автору, жму руку!
@@CEODEN, финансист по отношению к команде разработки выступает в роли стейкхолдера/заказчика? Тогда он выйдет в состав Value team / Discovery team. Это уже не Скрам, а одно из его расширений. Вот здесь описал подробнее dblinov.com/blog/tpost/bin2k1b261-protsessi-discovery-i-delivery-prostim-y Если прочитаете, напишите, отвечает ли это на ваш вопрос, пожалуйста 🙂
@@GroceryStore-k2b, забавно! :) Если честно, то это крутой вопрос, ответ длинный, и я хотел записать видео, но что-то пошло не так. Спасибо, что напомнили. Отвечу текстом ниже 👇🏼
@@ВячеславКоряковский-ч8л, хороший вопрос 👍🏼 Скрам хорошо подходит для продуктовой разработки. А продукты действительно развиваются бесконечно, пока живут. RUclips/Google, Яндекс и все их подпродукты, Zoom, Miro, и прочие. Бэклоги постоянно пополняются и приоритизируются. Ваш вопрос, похоже, про проекты с четким ТЗ. Для них Скрам подходит меньше, потому что по сути бэклог/ТЗ фиксирован. Однако можно использовать некоторые плюсы подхода. Например, с первых же спринтов выпускать что-то готовое (инкременты), и постепенно снижать риски: удовлетворенности заказчика, интеграции, несвоевременной поставки. Обратная сторона, что у заказчика, который увидит первые версии системы, будут появляться пожелания - это естественно. Но ведь у вас есть зафиксированное ТЗ, и тут могут начаться игрища типа: «Под этой формулировкой мы как раз это и имели в виду, так что давайте, делайте.» Заранее понимая это, при подписании договора стоит обсудить и зафиксировать используемый подход и частоту поставок, и выбрать соответствующий договор. Для полноценной итеративной инкрементальной разработки лучше подходит договор формата Time & material или рамочный договор на работы с заявками каждый месяц или квартал.
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
Как достаточно привередливый РП с опытом реализации проектов порядка 20 лет, могу сказать, что это самое четкое, понятное и логичное видео по скраму, которое мне приходилось видеть на просторах ютуба ) А смотрел я немало. Спасибо.
Павел, большое спасибо за такой отзыв! 🙏🏼
Как ИТшник и менеджер, начинавший с PMP, я оч стараюсь. И рад, когда получается помогать ☺️
Определенно есть талант в преподавании, доступно изложил основы. спасибо автору
Как же интересно, Дмитрий! Спасибо большое!
Наконец-то нормальное объяснение без воды. Спасибо!
Наталья, рад, что понравилось ☺️
Спасибо за комментарий 🙏🏼
Перечитав большое количество информации в разных сообществ, пересмотрев кучу видео не в одном канале это видео за 14 минут все по полочкам разложило. Спасибо автору, жму руку!
@@asilbekyusupov1220, большое спасибо за отзыв! Для меня это важно - создавать хороший контент в профессии 🤓
Вы - лучший!
Лучшее объяснение, которое слышал
Дима, всё чётко и по полочкам, как всегда. Восторг!
Спасииибо 😊
шикарное видео. лучшее на ютубе
Благодарю за очень понятный ящык. Всё доходчиво!
@@IrinaSukhorukova, спасибо за отзыв 🙏🏼 это ценно для меня.
Супер, спасибо ❤
Отличное видео
Спасибо за видео!
Может ли быть один человек в двух и более scrum командах?
Например, финансис, который ведет несколько проектов?
@@CEODEN, финансист по отношению к команде разработки выступает в роли стейкхолдера/заказчика? Тогда он выйдет в состав Value team / Discovery team. Это уже не Скрам, а одно из его расширений. Вот здесь описал подробнее dblinov.com/blog/tpost/bin2k1b261-protsessi-discovery-i-delivery-prostim-y Если прочитаете, напишите, отвечает ли это на ваш вопрос, пожалуйста 🙂
Очень понятно.
@@dvlopatin, спасибо за отзыв! 🙏🏼
Скажите, как избежать бесконечного пополнения бэклога? Ведь продукт можно бесконечно улучшать, так можно никогда не закончить проект
Автор отвечает только на похвалу, видимо)
@@GroceryStore-k2b, забавно! :)
Если честно, то это крутой вопрос, ответ длинный, и я хотел записать видео, но что-то пошло не так. Спасибо, что напомнили. Отвечу текстом ниже 👇🏼
@@ВячеславКоряковский-ч8л, хороший вопрос 👍🏼
Скрам хорошо подходит для продуктовой разработки. А продукты действительно развиваются бесконечно, пока живут. RUclips/Google, Яндекс и все их подпродукты, Zoom, Miro, и прочие. Бэклоги постоянно пополняются и приоритизируются.
Ваш вопрос, похоже, про проекты с четким ТЗ. Для них Скрам подходит меньше, потому что по сути бэклог/ТЗ фиксирован. Однако можно использовать некоторые плюсы подхода. Например, с первых же спринтов выпускать что-то готовое (инкременты), и постепенно снижать риски: удовлетворенности заказчика, интеграции, несвоевременной поставки. Обратная сторона, что у заказчика, который увидит первые версии системы, будут появляться пожелания - это естественно. Но ведь у вас есть зафиксированное ТЗ, и тут могут начаться игрища типа: «Под этой формулировкой мы как раз это и имели в виду, так что давайте, делайте.» Заранее понимая это, при подписании договора стоит обсудить и зафиксировать используемый подход и частоту поставок, и выбрать соответствующий договор. Для полноценной итеративной инкрементальной разработки лучше подходит договор формата Time & material или рамочный договор на работы с заявками каждый месяц или квартал.