@@РУПор-революционноеуправлениеп ну незнаю. Наоборот - если мужчина в теле - это просто супер! Не надо ни под кого подстраиваться. Только так, как комфортно Вам и Вашей половинке. Остальные пусть идут лесом. Автору браво и огромное спасибо! Чётко, предельно понятно, наглядно и без заумной никому не нужной часовой болтовни! Просто апплодирую
50 на 50%. Перечитайте еще раз Scum guide. (по умолчанию все что в нем описано - это SCRUM). Очень много ошибок и некорректных вещей, например: 1) Беклог НЕ обязательно должен быть описан в юзер стори. 2) Требования в беклоге НЕ обязательно описывать в человеко\часах (да и вообще это не рекомендуется - лучшая практика это стори поинты) 3) Откуда взялось что конкретное требование должно быть декомпозировано до задач в один человеко-день? об этом нигде не упоминается. Задачи из беклога должны браться в спринт что бы их можно было выполнить в один спринт! Если нельзя - нужно делить дальше. 4) Ничего не сказано про импиреческий процесс - это вся суть Scum (вообще зачем он нужен и причем тут он Scum и Agile) 5) Доска НЕ обязательна, ее можно использовать, но строго говоря это НЕ must have 6) Scrum master НЕ обязан присутствовать на Daily Scrum, он обязан обучить команду проводить daily scrum за 15 минут. Dailyu scrum это событие команды, оно является управляемым самой командой. Мы, например, сутра ходим пить кофе и обсуждаем план на день 7) Daily scrum НЕ обязан проходить стоя. 8) Sprint review - это НЕ ДЕМО 8) Ничего НЕ сказано про DoD! и т.д. ... Ничего не сказано про атрибуты скарам - их 11. Ничего не сказано про ценности скрама. Думаю это все можно было уместить еще в минуту
Хорошо и понятно рассказано, но не понятно когда проводить аналитику и тестирование - в видео рассказано только про разработку. Одновременно эти этапы невозможно выполнять. Так же не рассказано про церемонии груминга и pbr. И когда они должны происходить. Дополните пожалуйста этими данными
Великолепное преподнесение материала! Очень понравилось! Спасибо! А нельзя ли сделать подобное видео по Экстремальное программирование (Extreme Programming, XP)?
Как мне "нравятся" люди, которые думают, что они могут чему-то учить только лишь на основании того, что они что-то прочитали. Они выдают такие анекдоты, что только удивляешься как такое могло прийти в голову. "В команду входит команда" - это шедевр. Ну и к сведению автора ролика, продукт-овнер и скрам-мастер в команду НЕ ВХОДЯТ. Ну и далее еще ряд подобных малограмотных перлов.
Ошибки - это нормально. Если пожар, то будем тушить. Если не пожар - поставим в бэклог. Демо не обязательно в пятницу. Варианты есть. Я про классический тайм-боксинг рассказывал.
Тут немного неправильны подход у тренера, я бы сказал, что рекомедуется все делать так, чтоб ивенты в первую очередь были удобны команде и в хорошей практике, они должны быть в телении одной недели, так как во время Sprint Review вы собираете отзыв от заитересованных лиц и делаете апдэйт Product Backloga. А во время планинга, набираете элементы из продукт бэклога с учетом отзыва от заинтересованных сторон. Если разделять эти встречи выходными, то команда может потерять мысль заитересованных сторон и не доконца конкретно составить Sprint Backlog. Теперь, то что по поводу ошибок и ошибок выявленных на демо. Вообще, ошибки это нормально, мы с них учимся и постоянно улучшаем процесс и организация должна предоставлять право на ошибку. Но ошибки на демо должны быть лимитированы, так как каждую итерацию мы должны доставлять часть ГОТОВОГО продукта. Теперь появляется вопрос, что в вашем понимании является готовым продуктом? Для этого организации создают документ, который называется Definition of Done в котором четко прописанно, какой продукт является готовымю Обычно, Definition of Done идет от лица организации и является обшим для всех.
Скрам-масте отводит того, у кого проблема, в угол, достает дубину и хреначит тебя, пока ты не выдашь решение. А спустя дне недели уволят нахрен ))) Вот так все работает. Мне показалось что эта система - система "натянутых улыбок". Все улыбаются, мол создаем условия для работы, что бы ты был на работе как дома с семьёй, ты думаешь что всё ок, расслабляешься, но все трясутся исключительно за свою шкуру. Верить (и доверять) никому нельзя. Вот так я вижу эту систему в работе.
После митинга, люди которые могу помочь друг другу в решении проблемы созваниваются/встречаются и решают. На мите важно проблему озвучить чтобы понять, кто из команды может помочь ее решить.
ппц... не удержался. Чем это лучше классики? Чем существующая модель: бриф/тз, постановка задачи, распределение зон ответственности и функционала по проекту, управление временем и ресурсами, управление проектом, реперные точки, сроки, прототипирование (эскиз), фокус группа, доработка, продукт и т.д. отличается от Срама? Неужели что-то поменялось с введением новых терминов? Как это в конечном счете влияет на процесс создания прототипа, продукта? Чем "Фасилитатор" (неприличное что-то приходит на ум) отличается от Руководителя проекта, кроме отсутствия руководящей роли и снижения ответственности? Конечно здорово делегировать руководящую роль и размазывать ее по группе, "умно". Как определить, в какой момент кто-то из команды осознанно возьмет все в свои руки и возглавит проект на отдельном блоке? Можно ведь изначально определить уровень компетенций и зон ответственности в команде и руководить без снижения потенциалов группы. И зачем столько нерусских слов? Неужели у нас нет своего понимания бизнес-процессов? Неужели нужно обязательно натягивать иностранную футболку чтобы делать реальные дела? При чем тут Революционное управление? В чем революция? То, что вы рассказываете наверное круто, но мне кажется тут ничего нет Революционного? Без обид.
Это не лучше классики и не хуже. По-моему это просто другой способ, который лучше всего подходит когда ещё не знаем как будет конкретно выглядит конечный продукт или услуга. Если знаем конкретно какой будет продукт - достаточно логично проводить проекты по методу "Водопада". Метод управление совсем разный, люди и клиент тут важнее процессов, инструментов, менеджмента и всего другого. Для некоторых компаний это революция, для других нет. В конце-концов это просто инструмент. Надо знать где как и когда его использовать. Надо будет самому сделать видео про принципы "Скрама" с образцами обоих методов :)
Кирилл, это всем лучше классики той, которую вы описали. Просто этот "тренер" который снял это видио, недостаточно компетентен в вопросе Скрама, в видио много недочетов и не соответсвий + полное непонимание отличий Гибких методологий от Водопада. Вся судь в том, что компания используящая гибкие методологии - стоновится гибкой и в любой момент может меняться, адаптироваться под клиента и приносить наймольшую ценность, но об этом почему-то ничего не сказано. Все суть в том что вы как команда регулярно доставляете рабочую часть продукта, каждую итеррацию и получаете отзыв от клиента и добавляете элементы в соответсвии с отзывом клиента. В скраме нету распределения ответсвенности, что сделано для того, чтоб команда как единое целое была ответсвенна за то, что она делает. Это помогает команде быть вовличенными в разработку, влиять на продукт и на его исход. И многое другое, если вы не отличаете скрам мастера от руководителя проекта, то вы совсем не понимаете скрам и то как на самом деле идет разработка в гибкой среде. Я думаю, что не стоит писать, что Срам глупость и ничем не отличается от классики не являясь компетентным в этом вопросе. В этом видио все подвязано к процессу и непонятным летучкам, которые должны проводиться обязательно стоя (что полный бред). Так же тут много другого бреда, если бы создатели скрама, так объяснили всем вой скрам, то он бы умер не родившись. Сейчас большинство крупных фирм переходят на гибкие методологии разработки так как они улучшают процесс и увеличивают общюю производительность до 200 %. Это типо, как будующее, перестаем копать огород палкой копалкой, а используем пуг. Но чтоб эфективно пользоваться плугом, сперва надо научиться его использовать.
Поменялось то, что scrum стал общераспространенным протоколом взаимодействия команды и заказчика. Понимание скрама заказчиком и его принятие с его стороны тут очень важны. Другое, что все его элементы - это ключевые элементы, те он минималистичен, эффективен и широко применим, те обладает качествами стандарта.
М-да.... Этот человек в самом деле разбирается в теме или одну доку прочитал?! Он вообще в курсе, кто такой product owner??? Это сотрудник этой же компании, может быть даже техническим специалистом в прошлом, а никакой там "из реального сектора"! В задачи product owner'а входит сбор требований к ПО с заказчика (из общения с заказчиком), с маркетологов и т.д. (в зависимости от проекта). Роль product owner'а может играть project manager, например. Для тех, кому интересно разобраться, рекомендую, например, это видео ruclips.net/video/2uFA3f74D0Q/видео.htmlm6s
Больше 20 лет все кто занимается управлением используют понятную и изложенную на русском языке теорию управления, ruclips.net/video/50CV0FSv398/видео.html где вы без труда найдёте свой скрам.)))
Крутяк просто невероятный! Отлично! Спасибо вам большое!
Очень примитивно. Даже с ремонтом бы не справились :)))
Хотя, конечно, есть здравые зернышки ...
@@СергейЛукьянович-с3у , так объяснение же не для опытных, а для начинающих. Так что автор со своей задачей справился на отлично
Настолько понятно, что теперь мне гораздо легче то, как работать в аспро аджайл. Спасибо огромное!
Спасибо! ))
Мне этого видео вполне достаточно для прохождения собеседования завтра.
Вы - первый, кто разложил все по полочкам и кратко описал. Спасибо!)
Наконец-то. Адекватный лектор.
Только смотрел на ускорении. Но это личное. )
Очень круто коротко и ясно! Без воды которую остальные льют по два часа!
Емко, толково, по существу. Смотреть на скорости х 1,5. Благодарю!
Полгода пыталась понять, оказалось нужно было всего лишь это видео!
Спасибо!
Всё чётко и ясно.....Смотрел много видео с этим циклом и только голову забивало.....А здесь всё просто и понятно даже для начинающего чайника как я
Пока смотрел видео, не покидала мысль, что у докладчика нижние пуговицы на рубашке оторвутся :) Шутка - хорошее видео, докладчик молодец!
Дмитрий, спасибо! Над фигурой работаю!
@@РУПор-революционноеуправлениеп ну незнаю. Наоборот - если мужчина в теле - это просто супер!
Не надо ни под кого подстраиваться. Только так, как комфортно Вам и Вашей половинке. Остальные пусть идут лесом.
Автору браво и огромное спасибо! Чётко, предельно понятно, наглядно и без заумной никому не нужной часовой болтовни! Просто апплодирую
на скорости 1.5 уже хорошо воспринимается
Да, да. Иначе никак
Невероятный ролик. Спасибо за подачу
По-моему, это лучший концентрат по Scrum.
Лучшее видео по SCRUM-у за целый день просмотра всякого мусора...
Отлично. Доступно и понятно.
Благодарю 👍
Спасибо, всё чётко и понятно. Единственное, что смотрел со скоростью 1.25 иначе очень медленно :)
Спасибо большое, удобная подача информации. Было бы интересно послушать Ваши новые ролики.
Очень хорошо объясняете! Спасибо большое!
Очень четко и ясно, спасибо! Продолжайте дайльше)
Очень интересно рассказываете, приятно слушать
Спасибо!!!
Годный видос! Спасибо, товарищ:)
Отличное видео, понятным языком. Спасибо вам
спасибо за видео.. Понятно по процессам.
(и еще понятнее стало - какая же это надость ваш аджайл и скрам...но как все на него надрачивают)
Отличный гайд, спасибо большое!
Спасибо за видео! Хотелось бы услышать про измеримость и прогнозирование в скраме, стори поинты, доступные метрики.
Благодарю, очень доходчиво 👍🏻
Спасибо вам, все понятно объяснили! :)
Шикарно объяснил! Спасибо!
Супер! Спасибо ! Очень помог ! )
Тренер, бомба. Спасибоооо
Спасибо, очень доходчиво.
Отлично , спасибо большое
Интересная понятная подача. Спасибо.
Спасибо! Коротко и доходчиво, автору респект!
Очень подробно и понятно!
Спасибо. Достаточно подробно и понятно 👍👍👍
Спасибо!!!
М-да. Мир сильно сильно изменился. Теперь СТЕНДАПЫ СИДЯ ПРОВОДИМ, сидя дома за своим компьютером.
Коротко и понятно.
Супер, прекрасно разъясняет!
Очень спасибо!!
Видео отличное. Скрам подходит не только для программистов, но и для обычных бизнесов типа ремонта?
Чётко и ясно. Спасибо.
класс.....все четко и по сути. Спасибо!!
50 на 50%. Перечитайте еще раз Scum guide. (по умолчанию все что в нем описано - это SCRUM). Очень много ошибок и некорректных вещей, например: 1) Беклог НЕ обязательно должен быть описан в юзер стори. 2) Требования в беклоге НЕ обязательно описывать в человеко\часах (да и вообще это не рекомендуется - лучшая практика это стори поинты) 3) Откуда взялось что конкретное требование должно быть декомпозировано до задач в один человеко-день? об этом нигде не упоминается. Задачи из беклога должны браться в спринт что бы их можно было выполнить в один спринт! Если нельзя - нужно делить дальше. 4) Ничего не сказано про импиреческий процесс - это вся суть Scum (вообще зачем он нужен и причем тут он Scum и Agile) 5) Доска НЕ обязательна, ее можно использовать, но строго говоря это НЕ must have 6) Scrum master НЕ обязан присутствовать на Daily Scrum, он обязан обучить команду проводить daily scrum за 15 минут. Dailyu scrum это событие команды, оно является управляемым самой командой. Мы, например, сутра ходим пить кофе и обсуждаем план на день 7) Daily scrum НЕ обязан проходить стоя. 8) Sprint review - это НЕ ДЕМО 8) Ничего НЕ сказано про DoD! и т.д. ... Ничего не сказано про атрибуты скарам - их 11. Ничего не сказано про ценности скрама. Думаю это все можно было уместить еще в минуту
Хорошо и понятно рассказано, но не понятно когда проводить аналитику и тестирование - в видео рассказано только про разработку. Одновременно эти этапы невозможно выполнять. Так же не рассказано про церемонии груминга и pbr. И когда они должны происходить. Дополните пожалуйста этими данными
Зашел посмотреть про 5 инструментов, а получил очередное базовое описание фреймворка, к тому же полное косяков.
Великолепное преподнесение материала! Очень понравилось! Спасибо! А нельзя ли сделать подобное видео по Экстремальное программирование (Extreme Programming, XP)?
Хорошо
Спасибо за видео!
А что если в команде я один!? Не, ну были ещё два джуна, но они уволились... Я себе и политрук и скрам-мастер и исполнитель...
Это реальность, коллега
Спасибо все более чем доступно. А нам препод уже год жуёт кашу и нихрена не понятно
Толково 👍
Спасибо
Только если я не ошибаюсь это скрам с некоторыми элементами канбана
про safe также коротко можете рассказать ?
супер
Spasibo!!!!
СПАСИБО ДОХОДЧИВО
Как мне "нравятся" люди, которые думают, что они могут чему-то учить только лишь на основании того, что они что-то прочитали. Они выдают такие анекдоты, что только удивляешься как такое могло прийти в голову.
"В команду входит команда" - это шедевр.
Ну и к сведению автора ролика, продукт-овнер и скрам-мастер в команду НЕ ВХОДЯТ.
Ну и далее еще ряд подобных малограмотных перлов.
Почему нет звука
С каких пор ядро в скраме - это команда?
слишком медленно, смотрел на х2
котелось на примере услышать отличие методологий скама от вотерфал и канбана
А что делать - если на демо нашлись ошибки? Всё таки пятница - когда фиксить?
Ошибки - это нормально. Если пожар, то будем тушить. Если не пожар - поставим в бэклог. Демо не обязательно в пятницу. Варианты есть. Я про классический тайм-боксинг рассказывал.
Тут немного неправильны подход у тренера, я бы сказал, что рекомедуется все делать так, чтоб ивенты в первую очередь были удобны команде и в хорошей практике, они должны быть в телении одной недели, так как во время Sprint Review вы собираете отзыв от заитересованных лиц и делаете апдэйт Product Backloga. А во время планинга, набираете элементы из продукт бэклога с учетом отзыва от заинтересованных сторон. Если разделять эти встречи выходными, то команда может потерять мысль заитересованных сторон и не доконца конкретно составить Sprint Backlog. Теперь, то что по поводу ошибок и ошибок выявленных на демо. Вообще, ошибки это нормально, мы с них учимся и постоянно улучшаем процесс и организация должна предоставлять право на ошибку. Но ошибки на демо должны быть лимитированы, так как каждую итерацию мы должны доставлять часть ГОТОВОГО продукта. Теперь появляется вопрос, что в вашем понимании является готовым продуктом? Для этого организации создают документ, который называется Definition of Done в котором четко прописанно, какой продукт является готовымю Обычно, Definition of Done идет от лица организации и является обшим для всех.
1. Купить душ.
2. Провести к нему канализацию...
А когда и как проблемы озвученные на стендапе обсуждать и решать?
Скрам-масте отводит того, у кого проблема, в угол, достает дубину и хреначит тебя, пока ты не выдашь решение. А спустя дне недели уволят нахрен ))) Вот так все работает. Мне показалось что эта система - система "натянутых улыбок". Все улыбаются, мол создаем условия для работы, что бы ты был на работе как дома с семьёй, ты думаешь что всё ок, расслабляешься, но все трясутся исключительно за свою шкуру. Верить (и доверять) никому нельзя. Вот так я вижу эту систему в работе.
После митинга, люди которые могу помочь друг другу в решении проблемы созваниваются/встречаются и решают. На мите важно проблему озвучить чтобы понять, кто из команды может помочь ее решить.
Да никак. Пошумели - разбежались. Скрам не умеют проводить 90% команд. Технология слишком гибкая для понимания
А зачем к душу подводить канализацию? 7:42
ппц... не удержался.
Чем это лучше классики?
Чем существующая модель: бриф/тз, постановка задачи, распределение зон ответственности и функционала по проекту, управление временем и ресурсами, управление проектом, реперные точки, сроки, прототипирование (эскиз), фокус группа, доработка, продукт и т.д. отличается от Срама? Неужели что-то поменялось с введением новых терминов?
Как это в конечном счете влияет на процесс создания прототипа, продукта? Чем "Фасилитатор" (неприличное что-то приходит на ум) отличается от Руководителя проекта, кроме отсутствия руководящей роли и снижения ответственности? Конечно здорово делегировать руководящую роль и размазывать ее по группе, "умно". Как определить, в какой момент кто-то из команды осознанно возьмет все в свои руки и возглавит проект на отдельном блоке? Можно ведь изначально определить уровень компетенций и зон ответственности в команде и руководить без снижения потенциалов группы.
И зачем столько нерусских слов? Неужели у нас нет своего понимания бизнес-процессов? Неужели нужно обязательно натягивать иностранную футболку чтобы делать реальные дела?
При чем тут Революционное управление? В чем революция?
То, что вы рассказываете наверное круто, но мне кажется тут ничего нет Революционного?
Без обид.
Абсолютно с вами согласен.
Это не лучше классики и не хуже. По-моему это просто другой способ, который лучше всего подходит когда ещё не знаем как будет конкретно выглядит конечный продукт или услуга. Если знаем конкретно какой будет продукт - достаточно логично проводить проекты по методу "Водопада".
Метод управление совсем разный, люди и клиент тут важнее процессов, инструментов, менеджмента и всего другого. Для некоторых компаний это революция, для других нет. В конце-концов это просто инструмент. Надо знать где как и когда его использовать.
Надо будет самому сделать видео про принципы "Скрама" с образцами обоих методов :)
Кирилл, это всем лучше классики той, которую вы описали. Просто этот "тренер" который снял это видио, недостаточно компетентен в вопросе Скрама, в видио много недочетов и не соответсвий + полное непонимание отличий Гибких методологий от Водопада. Вся судь в том, что компания используящая гибкие методологии - стоновится гибкой и в любой момент может меняться, адаптироваться под клиента и приносить наймольшую ценность, но об этом почему-то ничего не сказано. Все суть в том что вы как команда регулярно доставляете рабочую часть продукта, каждую итеррацию и получаете отзыв от клиента и добавляете элементы в соответсвии с отзывом клиента. В скраме нету распределения ответсвенности, что сделано для того, чтоб команда как единое целое была ответсвенна за то, что она делает. Это помогает команде быть вовличенными в разработку, влиять на продукт и на его исход. И многое другое, если вы не отличаете скрам мастера от руководителя проекта, то вы совсем не понимаете скрам и то как на самом деле идет разработка в гибкой среде. Я думаю, что не стоит писать, что Срам глупость и ничем не отличается от классики не являясь компетентным в этом вопросе. В этом видио все подвязано к процессу и непонятным летучкам, которые должны проводиться обязательно стоя (что полный бред). Так же тут много другого бреда, если бы создатели скрама, так объяснили всем вой скрам, то он бы умер не родившись. Сейчас большинство крупных фирм переходят на гибкие методологии разработки так как они улучшают процесс и увеличивают общюю производительность до 200 %. Это типо, как будующее, перестаем копать огород палкой копалкой, а используем пуг. Но чтоб эфективно пользоваться плугом, сперва надо научиться его использовать.
Мб почитать все же оригинал, а потом писать что там нового?
Поменялось то, что scrum стал общераспространенным протоколом взаимодействия команды и заказчика. Понимание скрама заказчиком и его принятие с его стороны тут очень важны. Другое, что все его элементы - это ключевые элементы, те он минималистичен, эффективен и широко применим, те обладает качествами стандарта.
не, не зашел докладчик...
М-да.... Этот человек в самом деле разбирается в теме или одну доку прочитал?! Он вообще в курсе, кто такой product owner??? Это сотрудник этой же компании, может быть даже техническим специалистом в прошлом, а никакой там "из реального сектора"! В задачи product owner'а входит сбор требований к ПО с заказчика (из общения с заказчиком), с маркетологов и т.д. (в зависимости от проекта). Роль product owner'а может играть project manager, например.
Для тех, кому интересно разобраться, рекомендую, например, это видео ruclips.net/video/2uFA3f74D0Q/видео.htmlm6s
Голос только у тебя мягко говоря не презентабельный!)))
Читаю телеграмм канал про управлению проектами @multi_manager
Поможет и новичкам в том числе. Много практических советов.
+++++
Убил бы за манеру говорить.
Обыкновенная, система работы от планирования до результата , обозванная чужим словом...
ты бы перевод терминов, которые употребляет, говорил, было бы лучше..в голову не приходила такая мысля, тренер?
Молодой человеа, попробуйте не демонстрировать знание терминологии на английском, а сразу "совсем по-русски". То-то будет здорово !
Больше 20 лет все кто занимается управлением используют понятную и изложенную на русском языке теорию управления,
ruclips.net/video/50CV0FSv398/видео.html
где вы без труда найдёте свой скрам.)))
Скучно и очень много воды.
Очень четко, все по делу! Спасибо!!
Спасибо!