Прикольная штука этот скрам, прграммисты поднапряглись в прошлом проекте, не спали ночами, что бы сдать таск и отправится в отпуск и тут пришли манагеры, увидели как поработали над прошлым проектом и влепили такой же объем в план за такое же время 😂👍🌚
Я обожаю ваш канал! Вы мега-классный рассказчик! На Новый год пожелала, чтобы у Евгения прибавилось подписчиков☺🙏🏻 ну это жесть как несправедливо - такой классный канал и так мало людей смотрят 😒
Не все корректно. Agile не фреймворк, не методология и не метод. Это философия. 17 человек в 2001 году посидели в феврале на горнолыжном курорте в штате Юта и выдали 4 ценности и 12 принципов. Все. Ничего больше они не предложили. Но идея зашла. И на философии Agile позже был построен фреймворк SCRUM (и не только он). Придумал SCRUM господин Сазерленд и товарищи. Там действительно есть роли, алгоритм, требования и рекомендации. При этом это не стандарт и не методология, и именно фреймворк, т.е. предполагает адаптацию подхода под особенности разработки. Стандарт, как и методология более жесткие - нужно следовать только в рамках заявленного алгоритма. Ватерфолл - это тоже не методология и не стандарт. Это обозначение использовал в 1970 году в своей статье некий Ройс для характеристики каскадного планирования. Речь шла о визуализации проекта с помощью календарного графика или по-иному диаграммы Гантта (по имени инженера Гантта, рожденного в 19 веке и строившего железные дороги). Если уж говорить по классические методологии и стандарты, то это PERT, позднее Prince2 иные. Тот же Prince (Project in Controlled Environment) был разработан британцами в 1990е как попытка отойти от полностью последовательного планирования и сделать проекты более гибкими при реализации. Prince2 и ныне прекрасно живет, и в ряде стран (UK, Канада, Нидерланды и пр.) массово представлен. «Король» проектной классики - американский PMBoK (разработка PMI) уже с 6 издания интегрировал Agile подходы, сделав попытку «поженить» классику и гибкие фреймворки, а в 7 версии стандарта они в принципе отошли от процессов реализации проекта и существенно продвинулись в сторону гибридного проектного управления. Нельзя утверждать, что по SCRUM, или по гибким проектным подходам в целом сейчас разрабатывается больше проектов. Это не так. Вы не построите мост, торговый центр, дом, завод и прочее используя тот же SCRUM. Вернее, можно, н это будет странно, и вряд ли заказчик / инвестор согласится, потому что в SCRUM нет тройственного ограничения или так называемого «проектного треугольника»: ограничения разработки по параметрам ВРЕМЯ, СТОИМОСТЬ, СОДЕРЖАНИЕ (и связанный с ним объем работ). Из-за того, что SCRUM работает по инкрементальному и итерационному принципам, функциональность продукта наращивается постепенно, а порой и не возникает (в конце выясняется, что эксперимент был интересным, но продукт оказался неудачным, что не страшно, ибо проект - это всегда риски). SCRUM хорошо показал себя в ИТ сфере, продуктовой разработке (не только ИТ), отчасти консалтинге. Эта штуковина хороша для одного, и не очень подходит для другого. Спросите тех заказчиков, кому по SCRUM сделали продукт - совпали их ожидания по стоимости, времени и функционалу. Я многих спрашивал, и очень мало у кого совпало. Чаще всего это дольше, дороже и даже не всегда тот продукт, что планировался. Этим и классические подходы УП грешат, но там хотя бы на входе цена, сроки и функционал фиксируются и потом считаем отклонения план-факт. В гибкой истории все самое интересное и волнующее чаще узнаешь только в конце. Гибридные подходы стараются это нивелировать в проектах, но все равно нет одного крутого и правильного пути. Проекты разные по своей сути, и проектные подходы поэтому тоже нужно выбирать под ситуацию.
Зависит от компании. Сколько проектов поменял всегда был нормальный Скрам. Не всегда в чистом виде со всеми церемониями, но в хаус никогда процессами не скатывались
Отличное видео! Единственное замечание по-поводу veloctiy. Velocity - это скорость команды (производительность) , поэтому уместно ли говорить, что это сложность? Подскажите, пожалуйста
не понятно маленько: sprint backlog формирует тим лид или менеджер проекта. А где эти 2 роли в списке ролей? Есть продуктовнер и скраммастер и команда , которая самоорганизующаяся - то бишь без тимлида. Или я что-то не понял?
Формирует бэклог PO, приоритезируют его PO и SM. Беда в том, что не всегда получается работать по чистому скраму, поэтому кого-то может и не быть и этим занимается лид, или PM. Но вообще, PM и лид - это просто участники скрам-команды
@@YauhenKavalchuk кароче очередной програмисский фреймворк который без костылей в виде тим лида и менеджера проекта не фунциклирует. зачем придумывать тогда скрам если он практически не реализуем без костылей?
доброго всем вечера. У меня вот какой вопрос: а есть ли среди комментировавших кто-то, кто работал в подобной scrum команде? И готов поделиться своим мнением, трудностями и т.д.?
У нас в офисе эту дичь решили внедрить в том году. У нас удалёнка. Больше всего бесят ежедневные совещания. Каждый должен сказать, что он сделал за вчера и что будет делать сегодня. Ненавижу! Нас 10 человек. Каждый говорит по 2-3 минуты (бывает, что дольше!). После пары человек теряешь нить и перестаёшь слушать их. Бесполезно потраченные от получаса до часа каждый день. Я не могу программировать, пока в ухе коллеги долдонят. Да и суть этих отчётностей такая - избыточная хрень. Например сегодня среда и коллега говорит "Сегодня я буду делать и формировать сложный отчёт №41". Потом в четверг он говорит "Вчера я говорил, что собирался делать отчёт №41, вот я его вчера и делал. Сегодня буду продолжать заниматься отчётом №41". В пятницу он говорит "Вчера занимался отчётом №41. Если успею закончить, то начну отчёт №42". И так каждый из 10 человек! Большинство из других подгрупп и меня не интересуют их модули, я с ними не пересекаюсь, поэтому не слушаю. Это просто религия, никакой пользы она не приносит, но все верят, что это что-то изменило. А, ну и ещё дичь - если в течение дня тебя кто-то отвлёк по работе (техподдержка обратилась, или коллеге помогал с вопросом), то это надо запомнить и на следующий день рассказать, что помогал такому-то и подсказал такому-то. То есть каждый день тратить эмоциональную энергию на запоминание любого вопроса и пожара, с которым к тебе обратились, и не забыть об этом сказать на следующий день. Я отмечал в рабочем времени все эти созвоны, и получилось, что за 9 месяцев я около 3 недель рабочего времени просто сидел и тупо смотрел в мессенджер! Если это помножить на 10 человек и на их зарплату, то на эту хрень фирма потратила больше полумиллиона рублей за 9 месяцев. И что-то никто не хвастается, что фирма стала больше зарабатывать после введения этих совещаний, по-моему лучше не стало, а только хуже.
@@YauhenKavalchuk , супер! А вы согласились бы ответить на пару вопросов по scrum? На подобие предыдущего комментатора. Мы сейчас запускаем подобный проект, и обратная связь от тех, кто в теме, как говорится, бесценна была бы.
@@sergeychernikov8911 большое вам спасибо за мнение! Со стороны методика и правда кажется сильно упрощающей жизнь. А вон сколько камней подводных, оказывается.
@@ةىبةت оно и со стороны кажется сильно усложняющей жизнь, коим оно и является. Даже странно было что автор видео так это нахваливает. Наверное зависит от типа личности, но явно эта технология "очень не для всех"
Небольшая поправка, agile - не методология, а скорее подход или группа методологий, которая включает в себя scrum, kanban, scrumban..., то же касается и каскадных(waterfall). Также нельзя говорить что agile популярнее waterfall подхода, так как каждый подход лучше применим в разных проектах
Думаю автор все верно сказал, Scrum использует Agile, а не наоборот. Agile ничего не знает о scrum, kanban, scrumban... Так что не нужно путать зрителей ;)
@@grommaks я имел в виду, что agile - это обобщающий термин для целого ряда методологий, а не методология сама по себе. И да scrum, kanban... лишь реализация принципов, заложенная в определение agile и, как вы сказали agile ничего не знает о scrum...
@@YauhenKavalchuk про намного больше не уверен, так как пару лет назад согласно исследованию PMI, agile не был популярнее waterfall, но тут нужно сделать замечание, что берутся все проекты, не только IT.
Отличное видео. Подскажите, если владелец проекта начинает его с нанятым разработчиком вдвоём. За всю it-часть отвечает разраб (в том числе работа с серверами, бэкапами, безопасность сайта). Каким образом владельцу сохранять полный контроль над проектом? Чтобы в случае желания продажи бизнеса владелец был уверенным, что он действительно владеет всем необходимым для этого. И не придётся ни о чем потом договариваться с нанятым разработчиком и зависеть от него в этом вопросе.
Крутое и понятное видео, спасибо 👍🏻 но вы уверены, что не перепутали значения для capacity и velocity местами? Velocity - это же скорость. Как бы может скорость выполнения задач?
Людей практически нереально подогнать под эти правила так жестоко, как это можно сделать, скажем, с кодом. Я был на таком проекте - команда начала разваливаться из за токсичности некоторых индивидов. И никакие рерты не помогли с оценками.
Куда мир катится))) Собрались на юг оказались на западе, но мы были готовы, поэтому как там у вас дела, дорогой заказчик. Главное работает! А как похрену! Процесс важнее результата и главное что скоро это нахрен никому не нужно. Вот что я понял из этого урока))))
Баклог, фичи, загрумить, таск, скоуп задач, юзер стори, девелопить... кошмар какой-то... неужели нельзя оперировать русским языком. Есть же русские термины, например, задачи, свойства, объем работ/задач, список дел, история событий, ну и так далее.
@@YauhenKavalchuk Такой сленг не от большого ума. Английским терминам есть конкретный перевод. Многие начинают специально говорить на смешанном языке, думая, что это круто. Однако это лишь показывает неумение владением русского языка.
Если это для новичков, то для начального уровня слишком много сленга и терминов, которые не понятны. Если для тех, у кого уже есть знания и он не путается в понятиях и терминах, то для меня сомнительна полезность сего материала. ОЧЕНЬ много сленга и модных словечек, без объяснения.
Понты, одни понты. Лапшу на уши заказчику вешают. Все что он сказал можно сказать по-русски. Ещё в СССР был календарный план-график производства работ по каждому участку. И прекрасно работает и сейчас!
Agile никогда не была методологией, зачем людей вводить в заблуждение? Методология - это набор конкретных правил и руководств, а Agile - это культура и принципы для построения компаний нового типа, которые описаны в манифесте.
На самых начальных этапах изучения сурам вам не понадобится. В нём имеет смысл разобраться примерно через год production опыта. К этому времени вы уже будете понимать каждый специфичный термин
Нет. Условия контакта не менее важны, чем сотрудничество. Иначе вам будут копейки платить, заставлять работать в сверхурочное... Зачем вам это? Ах да. Заказчик то очень важен. Да я бы сразу слал таких заказчиков.
Прикольная штука этот скрам, прграммисты поднапряглись в прошлом проекте, не спали ночами, что бы сдать таск и отправится в отпуск и тут пришли манагеры, увидели как поработали над прошлым проектом и влепили такой же объем в план за такое же время 😂👍🌚
🤣
Готовность к изменениям
ВАЖНЕЕ следования первоначальному плану.
Заложили одно - успели сделать половину. За неверные эстимейты отвечать PM-у.
это конечно круто но к скраму никого отношения не имеет )))
@@alergeo1 вполне имеет.
Потому не может быть все расписано, импровизации тоже существует;)
Отличный полезный контент. А самое главное - объясняешь доступно! Все понятно. Спасибо за проделанную работу!
Что бы заганять всех в команде и выжать все соки за минимальное время и деньги - это SCRUM
¯\ _(ツ)_/¯
Жень, у тебя дар объяснять людям так, чтоб было понятно. Очень мало кто умеет это делать. Красавчик!
Спасибо за отзыв
Спасибо, четко выложенное объяснение понятий, но не сухо а доступно и понятно. Приятный голос и дикция
Спасибо большое за отзыв)
Огромное спасибо, отличная работа, уложил у себя в голове все по полочкам с вашей помощью!
Пожалуйста
Спасибо большое. Очень понятно стало после просмотра вашего видео❤
Всегда пожалуйста
Большое спасибо! Всё очень чётко и понятно
Пожалуйста
Я обожаю ваш канал! Вы мега-классный рассказчик!
На Новый год пожелала, чтобы у Евгения прибавилось подписчиков☺🙏🏻 ну это жесть как несправедливо - такой классный канал и так мало людей смотрят 😒
Спасибо большое за поддержку!
Не все корректно. Agile не фреймворк, не методология и не метод. Это философия. 17 человек в 2001 году посидели в феврале на горнолыжном курорте в штате Юта и выдали 4 ценности и 12 принципов. Все. Ничего больше они не предложили. Но идея зашла. И на философии Agile позже был построен фреймворк SCRUM (и не только он). Придумал SCRUM господин Сазерленд и товарищи. Там действительно есть роли, алгоритм, требования и рекомендации. При этом это не стандарт и не методология, и именно фреймворк, т.е. предполагает адаптацию подхода под особенности разработки. Стандарт, как и методология более жесткие - нужно следовать только в рамках заявленного алгоритма.
Ватерфолл - это тоже не методология и не стандарт. Это обозначение использовал в 1970 году в своей статье некий Ройс для характеристики каскадного планирования. Речь шла о визуализации проекта с помощью календарного графика или по-иному диаграммы Гантта (по имени инженера Гантта, рожденного в 19 веке и строившего железные дороги). Если уж говорить по классические методологии и стандарты, то это PERT, позднее Prince2 иные.
Тот же Prince (Project in Controlled Environment) был разработан британцами в 1990е как попытка отойти от полностью последовательного планирования и сделать проекты более гибкими при реализации. Prince2 и ныне прекрасно живет, и в ряде стран (UK, Канада, Нидерланды и пр.) массово представлен. «Король» проектной классики - американский PMBoK (разработка PMI) уже с 6 издания интегрировал Agile подходы, сделав попытку «поженить» классику и гибкие фреймворки, а в 7 версии стандарта они в принципе отошли от процессов реализации проекта и существенно продвинулись в сторону гибридного проектного управления.
Нельзя утверждать, что по SCRUM, или по гибким проектным подходам в целом сейчас разрабатывается больше проектов. Это не так. Вы не построите мост, торговый центр, дом, завод и прочее используя тот же SCRUM. Вернее, можно, н это будет странно, и вряд ли заказчик / инвестор согласится, потому что в SCRUM нет тройственного ограничения или так называемого «проектного треугольника»: ограничения разработки по параметрам ВРЕМЯ, СТОИМОСТЬ, СОДЕРЖАНИЕ (и связанный с ним объем работ). Из-за того, что SCRUM работает по инкрементальному и итерационному принципам, функциональность продукта наращивается постепенно, а порой и не возникает (в конце выясняется, что эксперимент был интересным, но продукт оказался неудачным, что не страшно, ибо проект - это всегда риски).
SCRUM хорошо показал себя в ИТ сфере, продуктовой разработке (не только ИТ), отчасти консалтинге. Эта штуковина хороша для одного, и не очень подходит для другого.
Спросите тех заказчиков, кому по SCRUM сделали продукт - совпали их ожидания по стоимости, времени и функционалу. Я многих спрашивал, и очень мало у кого совпало. Чаще всего это дольше, дороже и даже не всегда тот продукт, что планировался. Этим и классические подходы УП грешат, но там хотя бы на входе цена, сроки и функционал фиксируются и потом считаем отклонения план-факт. В гибкой истории все самое интересное и волнующее чаще узнаешь только в конце.
Гибридные подходы стараются это нивелировать в проектах, но все равно нет одного крутого и правильного пути. Проекты разные по своей сути, и проектные подходы поэтому тоже нужно выбирать под ситуацию.
спасибо, после этого коммента аж книжку захотелось почитать, углубиться в эту тему
Всем классом слушали! Всем очень понравилось
Спасибо)
Спасибо что кротко, понятно и по делу.
Пожалуйста
Лайк от фаната сталкера, потихоньку готовимся к нему в 2022)))
👍 спасибо
Спасибо за ролик, было полезно!
Всегда пожалуйста
отличные курсы)понятно,доступно и просто)спасибо
Пожалуйста
Спасибо большое за объяснение! Залетело с первого раза)
Спасибо за отзыв
все легко,понятно, объяснил на пальцах))) Спасибо!
Пожалуйста)
Лиля, привет
мега ролик, спасибо ❤
Спасибо за отзыв
Отличный обзор! Спасибо!!!
Пожалуйста
Спасибо огромное, понятно и нужно!
Пожалуйста
Про артефакт из сталкера в точку! 😂👍
😁👍
Очень полезно, спасибо
Пожалуйста
Спасибо большое, очень четко и понятно!
Спасибо за отзыв)
Спасибо за ролик) Да, в теории все звучит прекрасно, как обычно, а на деле в 90% все работают по лажайлу.
Зависит от компании. Сколько проектов поменял всегда был нормальный Скрам. Не всегда в чистом виде со всеми церемониями, но в хаус никогда процессами не скатывались
и как это можно для СМИ применить? в редакации например
Ставлю лайк за слово артефакт, но я не фанат сталкера, я фанат героев меча и магии))))
Спасибо за видео
Ага, тоже хорошая игра. Особенно 3-я часть)
"в случае фэйла виновата вся команда, а не оддин человек" - всякий раз смеюсь, когда слышу))))
Угу
Ну в гугле та же система, вроде не смешно)
@@Cringe_vlad какая та же?
На словах виноватых нет, а на деле - ищут крайнего, виноватого и валят на него все ?
Круто! Спасибо!
Thank you for teaching
Thanks for your feedback!
Отличное видео! Единственное замечание по-поводу veloctiy.
Velocity - это скорость команды (производительность) , поэтому уместно ли говорить, что это сложность?
Подскажите, пожалуйста
Вы правы. Сложность - это complexity, тоже может быть отдельной дополнительной метрикой
Спасибо, было все понятно, лайк)
Пожалуйста)
Пришлось прочитать целую статью чтоб понять слово скоуп. Переводится как содержание, масштаб, охват, обьем, рамки проекта.
Ага, причём может быть скоуп задачи, проектный скоуп, скоуп ответственности и т.д.
👍👍👍
👍
Спасибо за работу. Очень доступно и понятно👍
Спасибо за отзыв
спасибо за объяснение!!!
Пожалуйста
Спасибо! Буду рекомендовать)
Пожалуйста!
Спасибо большое!
Пожалуйста)
не понятно маленько: sprint backlog формирует тим лид или менеджер проекта. А где эти 2 роли в списке ролей? Есть продуктовнер и скраммастер и команда , которая самоорганизующаяся - то бишь без тимлида. Или я что-то не понял?
Формирует бэклог PO, приоритезируют его PO и SM. Беда в том, что не всегда получается работать по чистому скраму, поэтому кого-то может и не быть и этим занимается лид, или PM. Но вообще, PM и лид - это просто участники скрам-команды
@@YauhenKavalchuk кароче очередной програмисский фреймворк который без костылей в виде тим лида и менеджера проекта не фунциклирует. зачем придумывать тогда скрам если он практически не реализуем без костылей?
Спасибо)
Пожалуйста
А вы не перепутали Капасити с Вилосити?
Да, теперь могу сказать точно, что перепутал(
@@YauhenKavalchuk спасибо, что ответили а то мне скоро на собез) и внутри неуверенность в этом вопр
Благодарю
Пожалуйста)
После пары просмотров начинаю понимать)
Отлично)
лайк от сатаниста за церемонию
Оригинально)))
доброго всем вечера. У меня вот какой вопрос: а есть ли среди комментировавших кто-то, кто работал в подобной scrum команде? И готов поделиться своим мнением, трудностями и т.д.?
Я работаю)
У нас в офисе эту дичь решили внедрить в том году. У нас удалёнка. Больше всего бесят ежедневные совещания. Каждый должен сказать, что он сделал за вчера и что будет делать сегодня. Ненавижу! Нас 10 человек. Каждый говорит по 2-3 минуты (бывает, что дольше!). После пары человек теряешь нить и перестаёшь слушать их. Бесполезно потраченные от получаса до часа каждый день. Я не могу программировать, пока в ухе коллеги долдонят. Да и суть этих отчётностей такая - избыточная хрень. Например сегодня среда и коллега говорит "Сегодня я буду делать и формировать сложный отчёт №41". Потом в четверг он говорит "Вчера я говорил, что собирался делать отчёт №41, вот я его вчера и делал. Сегодня буду продолжать заниматься отчётом №41". В пятницу он говорит "Вчера занимался отчётом №41. Если успею закончить, то начну отчёт №42". И так каждый из 10 человек! Большинство из других подгрупп и меня не интересуют их модули, я с ними не пересекаюсь, поэтому не слушаю. Это просто религия, никакой пользы она не приносит, но все верят, что это что-то изменило. А, ну и ещё дичь - если в течение дня тебя кто-то отвлёк по работе (техподдержка обратилась, или коллеге помогал с вопросом), то это надо запомнить и на следующий день рассказать, что помогал такому-то и подсказал такому-то. То есть каждый день тратить эмоциональную энергию на запоминание любого вопроса и пожара, с которым к тебе обратились, и не забыть об этом сказать на следующий день. Я отмечал в рабочем времени все эти созвоны, и получилось, что за 9 месяцев я около 3 недель рабочего времени просто сидел и тупо смотрел в мессенджер! Если это помножить на 10 человек и на их зарплату, то на эту хрень фирма потратила больше полумиллиона рублей за 9 месяцев. И что-то никто не хвастается, что фирма стала больше зарабатывать после введения этих совещаний, по-моему лучше не стало, а только хуже.
@@YauhenKavalchuk , супер! А вы согласились бы ответить на пару вопросов по scrum? На подобие предыдущего комментатора.
Мы сейчас запускаем подобный проект, и обратная связь от тех, кто в теме, как говорится, бесценна была бы.
@@sergeychernikov8911 большое вам спасибо за мнение! Со стороны методика и правда кажется сильно упрощающей жизнь.
А вон сколько камней подводных, оказывается.
@@ةىبةت оно и со стороны кажется сильно усложняющей жизнь, коим оно и является. Даже странно было что автор видео так это нахваливает. Наверное зависит от типа личности, но явно эта технология "очень не для всех"
А про Epic и User Story?
Возможно в будущих выпусках)
Небольшая поправка, agile - не методология, а скорее подход или группа методологий, которая включает в себя scrum, kanban, scrumban..., то же касается и каскадных(waterfall). Также нельзя говорить что agile популярнее waterfall подхода, так как каждый подход лучше применим в разных проектах
Я не сказал, что Agail лучше Waterfall. Но объективно, на Agail работает намного больше проектов
Думаю автор все верно сказал, Scrum использует Agile, а не наоборот. Agile ничего не знает о scrum, kanban, scrumban...
Так что не нужно путать зрителей ;)
@@grommaks я имел в виду, что agile - это обобщающий термин для целого ряда методологий, а не методология сама по себе. И да scrum, kanban... лишь реализация принципов, заложенная в определение agile и, как вы сказали agile ничего не знает о scrum...
@@YauhenKavalchuk про намного больше не уверен, так как пару лет назад согласно исследованию PMI, agile не был популярнее waterfall, но тут нужно сделать замечание, что берутся все проекты, не только IT.
Скрам - это охрененно! То, что без скрама делает трое широкопрофильных разрабов, в скраме делает десяток узких спецов!
Есть такое
Эти "скрамы" - сферическая в вакууме технология "прибить или приклеить" (в поиске наберите, если кто не видел)
Если процесс построен нормально, то всё - огонь. Я 2 года работаю по практически чистому скрапу и всё ок
Скрам это фреймворк?
Scrum - это процессный фреймворк. Это значит, что он гибкий и у него очень широкая область применения.
Да
А как же эпики и сторисы? Почему о них ничего не сказали? :(
Решил сконцентрироваться на основном, без углубления
Спасиб)
Пожалуйста
По ходу было сказано, что есть такая сущность, как проектный менеджер. Он же скрам-мастер? Или это разные люди?
Зависимости от бюджета. Скрам мастер может быть отдельным человеком, но зачастую данную роль выполняет ПМ
Отличное видео. Подскажите, если владелец проекта начинает его с нанятым разработчиком вдвоём. За всю it-часть отвечает разраб (в том числе работа с серверами, бэкапами, безопасность сайта). Каким образом владельцу сохранять полный контроль над проектом? Чтобы в случае желания продажи бизнеса владелец был уверенным, что он действительно владеет всем необходимым для этого. И не придётся ни о чем потом договариваться с нанятым разработчиком и зависеть от него в этом вопросе.
Никак, если владелец ничего не понимает, мало вероятно что он сможет что-то контролировать толково
Крутое и понятное видео, спасибо 👍🏻 но вы уверены, что не перепутали значения для capacity и velocity местами? Velocity - это же скорость. Как бы может скорость выполнения задач?
Спасибо. Вроде, сказал всё верно
про стримы и трайбы интересно было бы подробнее
возможно, в будущих выпусках
10:02
Показалось Пиэм на заднем плане
😁
Подскажите кто оценивает задачи на собрании по планированию спринта?
Project Manager
Scrum Master
Development Team
Команда разработчиков оценивает сложность
@@YauhenKavalchuk спасибо
без шумной музыки есть?
нет
Это короче я получила задачу, бухала всю неделю и потом еду в последний день кодю в автобусе на коленке, воооо быстро зашибись. Выполнила
👍
Без тихой музыки есть?
Нет(
@@YauhenKavalchuk Шучу, мне все нравится, ничего менять не надо)👍
👍
А должен ли на покер голосовании фронтендер оценивать задачу по бэкенду?
А вот это вопрос интересны. Вообще говорится, что должен. Но лично я старался аргументировать почему не могу оценивать задачи такого плана.
без муз фона есть?
В открытом доступе нет
«Это Фреймворк» - в моем понимание , если Фреймворк , то надо что-то скачать, что-то установить и тд )
Если погуглить, фреймворк - это более широкое понятие)
кросс-функциональная команда - неотьемлемое условие scrum, но крайне сложно такую комаду вообще собрать.
Абсолютно согласен
2:50 Блин, учвак, сорян, я фанат jpeg с качеством 10% от оригинала. 😞
🤷♂️
А кто задачи пишет?
BA на основании общения с PO и выяснения всех нюансов
Вот эту дичь внедряют у нас на производстве. Вопрос мастерам, как это применимо в производстве шкафов-купе?
Ну на самом деле это не дичь, а инструмент который действительно помогает наладить процессы
Это подробная методология вытирания ..опы, для тех, кто смотрит ролики "Бери и делай". Альтернативно одаренных мамкиных хипсторов.
Вам тоже стало плохо, когда скрам назвали фреймворком?
🤔🤷♂️
Да, дичь какая-то
Людей практически нереально подогнать под эти правила так жестоко, как это можно сделать, скажем, с кодом.
Я был на таком проекте - команда начала разваливаться из за токсичности некоторых индивидов. И никакие рерты не помогли с оценками.
Я 4 года уже работаю по Scrum и никаких проблем. Да, прям в чистом виде на 100% его нет, но 90% подхода используем и всё ок
@@YauhenKavalchuk так это понятно. Но добавь вам в команду токсика и все развалится. Скрам - это в первую очередь люди.
Куда мир катится))) Собрались на юг оказались на западе, но мы были готовы, поэтому как там у вас дела, дорогой заказчик. Главное работает! А как похрену! Процесс важнее результата и главное что скоро это нахрен никому не нужно. Вот что я понял из этого урока))))
Ну, на самом деле Scrum очень сильно "засел" в современной разработке и мало вероятно что в ближайшее время от него откажутся
Баклог, фичи, загрумить, таск, скоуп задач, юзер стори, девелопить... кошмар какой-то... неужели нельзя оперировать русским языком.
Есть же русские термины, например, задачи, свойства, объем работ/задач, список дел, история событий, ну и так далее.
Я работаю в международной компании, где основной язык английский. За 5 лет на всех проектах использовались только эти термины.
@@YauhenKavalchuk Такой сленг не от большого ума. Английским терминам есть конкретный перевод. Многие начинают специально говорить на смешанном языке, думая, что это круто. Однако это лишь показывает неумение владением русского языка.
Ну вам виднее. Хотя обычно это называется проф. деформация и с умственными способностями человека использование сленга никак не связано
вроде бы просто, но забывается быстро - канбан уже забыл
Возможно, в будущем по Kanban будет отдельный видос)
это тоже самое что кабан только канбан (с)
git + trello и ничего больше для жизни не нужно )
Для небольших проектов) Для серьёзных, без jira не обойтись
А теперь можно на русском?
🤷♂️
за Сталкера два пальца вверх)
Благодарю)
scrum - это не фреймворк, а методология
Agile это методология, а Scrum Фреймворк этой методологии
А вот гугл с вами не согласится
Velocity - скорость
👍
@@YauhenKavalchuk от меня лайк, спасибо за видео
Если это для новичков, то для начального уровня слишком много сленга и терминов, которые не понятны. Если для тех, у кого уже есть знания и он не путается в понятиях и терминах, то для меня сомнительна полезность сего материала. ОЧЕНЬ много сленга и модных словечек, без объяснения.
Так получилось…
не объяснил в чем отличие Planning от Grooming, ну и самой последовательности митингов нет кто за кем идет
Ну, всё не объяснить...
@@YauhenKavalchuk ну вот я до сих пор этого момента не понял, даже погуглив) в какой момент происходит именно оценка, и чем отличаются эти два митинга
@@YauhenKavalchuk а в остальном формат очень крут, простыми словами о сложном
Понты, одни понты. Лапшу на уши заказчику вешают.
Все что он сказал можно сказать по-русски.
Ещё в СССР был календарный план-график производства работ по каждому участку. И прекрасно работает и сейчас!
Есть специальная терминология она и используется в видео
Agile никогда не была методологией, зачем людей вводить в заблуждение? Методология - это набор конкретных правил и руководств, а Agile - это культура и принципы для построения компаний нового типа, которые описаны в манифесте.
Услышал про скрам, выбрал видео, подкупило "просто" в названии. В ай ти в общем - то нуб, но половина слов - спец слова. Где эта простота?)
На самых начальных этапах изучения сурам вам не понадобится. В нём имеет смысл разобраться примерно через год production опыта. К этому времени вы уже будете понимать каждый специфичный термин
Нет. Условия контакта не менее важны, чем сотрудничество. Иначе вам будут копейки платить, заставлять работать в сверхурочное... Зачем вам это? Ах да. Заказчик то очень важен. Да я бы сразу слал таких заказчиков.
В этом видео как бы объясняются правила методологии, а не условия работы на проекте
Чрезмерное использование англицизмов аж уши режет 🤦
¯\ _(ツ)_/¯
Говори правильно, не WaterFall, а WaterFail 😆😆
🙂
не понимаю людей, поставивших дизлайк
Я тоже)
иди IT-дорогой, Сталкер
😁👍
сябки
👍
Scrum это гибкое управление гребцами на галере как правило((
Это ваше мнение
Agile - это не методология!
Спасибо за информацию