Не все корректно. 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 сделали продукт - совпали их ожидания по стоимости, времени и функционалу. Я многих спрашивал, и очень мало у кого совпало. Чаще всего это дольше, дороже и даже не всегда тот продукт, что планировался. Этим и классические подходы УП грешат, но там хотя бы на входе цена, сроки и функционал фиксируются и потом считаем отклонения план-факт. В гибкой истории все самое интересное и волнующее чаще узнаешь только в конце. Гибридные подходы стараются это нивелировать в проектах, но все равно нет одного крутого и правильного пути. Проекты разные по своей сути, и проектные подходы поэтому тоже нужно выбирать под ситуацию.
Я обожаю ваш канал! Вы мега-классный рассказчик! На Новый год пожелала, чтобы у Евгения прибавилось подписчиков☺🙏🏻 ну это жесть как несправедливо - такой классный канал и так мало людей смотрят 😒
Прикольная штука этот скрам, прграммисты поднапряглись в прошлом проекте, не спали ночами, что бы сдать таск и отправится в отпуск и тут пришли манагеры, увидели как поработали над прошлым проектом и влепили такой же объем в план за такое же время 😂👍🌚
Зависит от компании. Сколько проектов поменял всегда был нормальный Скрам. Не всегда в чистом виде со всеми церемониями, но в хаус никогда процессами не скатывались
Баклог, фичи, загрумить, таск, скоуп задач, юзер стори, девелопить... кошмар какой-то... неужели нельзя оперировать русским языком. Есть же русские термины, например, задачи, свойства, объем работ/задач, список дел, история событий, ну и так далее.
@@YauhenKavalchuk Такой сленг не от большого ума. Английским терминам есть конкретный перевод. Многие начинают специально говорить на смешанном языке, думая, что это круто. Однако это лишь показывает неумение владением русского языка.
Небольшая поправка, 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.
Крутое и понятное видео, спасибо 👍🏻 но вы уверены, что не перепутали значения для capacity и velocity местами? Velocity - это же скорость. Как бы может скорость выполнения задач?
Отличное видео! Единственное замечание по-поводу veloctiy. Velocity - это скорость команды (производительность) , поэтому уместно ли говорить, что это сложность? Подскажите, пожалуйста
Если это для новичков, то для начального уровня слишком много сленга и терминов, которые не понятны. Если для тех, у кого уже есть знания и он не путается в понятиях и терминах, то для меня сомнительна полезность сего материала. ОЧЕНЬ много сленга и модных словечек, без объяснения.
Людей практически нереально подогнать под эти правила так жестоко, как это можно сделать, скажем, с кодом. Я был на таком проекте - команда начала разваливаться из за токсичности некоторых индивидов. И никакие рерты не помогли с оценками.
Куда мир катится))) Собрались на юг оказались на западе, но мы были готовы, поэтому как там у вас дела, дорогой заказчик. Главное работает! А как похрену! Процесс важнее результата и главное что скоро это нахрен никому не нужно. Вот что я понял из этого урока))))
не понятно маленько: sprint backlog формирует тим лид или менеджер проекта. А где эти 2 роли в списке ролей? Есть продуктовнер и скраммастер и команда , которая самоорганизующаяся - то бишь без тимлида. Или я что-то не понял?
Формирует бэклог PO, приоритезируют его PO и SM. Беда в том, что не всегда получается работать по чистому скраму, поэтому кого-то может и не быть и этим занимается лид, или PM. Но вообще, PM и лид - это просто участники скрам-команды
@@YauhenKavalchuk кароче очередной програмисский фреймворк который без костылей в виде тим лида и менеджера проекта не фунциклирует. зачем придумывать тогда скрам если он практически не реализуем без костылей?
Понты, одни понты. Лапшу на уши заказчику вешают. Все что он сказал можно сказать по-русски. Ещё в СССР был календарный план-график производства работ по каждому участку. И прекрасно работает и сейчас!
Agile никогда не была методологией, зачем людей вводить в заблуждение? Методология - это набор конкретных правил и руководств, а Agile - это культура и принципы для построения компаний нового типа, которые описаны в манифесте.
Нет. Условия контакта не менее важны, чем сотрудничество. Иначе вам будут копейки платить, заставлять работать в сверхурочное... Зачем вам это? Ах да. Заказчик то очень важен. Да я бы сразу слал таких заказчиков.
На самых начальных этапах изучения сурам вам не понадобится. В нём имеет смысл разобраться примерно через год production опыта. К этому времени вы уже будете понимать каждый специфичный термин
доброго всем вечера. У меня вот какой вопрос: а есть ли среди комментировавших кто-то, кто работал в подобной scrum команде? И готов поделиться своим мнением, трудностями и т.д.?
У нас в офисе эту дичь решили внедрить в том году. У нас удалёнка. Больше всего бесят ежедневные совещания. Каждый должен сказать, что он сделал за вчера и что будет делать сегодня. Ненавижу! Нас 10 человек. Каждый говорит по 2-3 минуты (бывает, что дольше!). После пары человек теряешь нить и перестаёшь слушать их. Бесполезно потраченные от получаса до часа каждый день. Я не могу программировать, пока в ухе коллеги долдонят. Да и суть этих отчётностей такая - избыточная хрень. Например сегодня среда и коллега говорит "Сегодня я буду делать и формировать сложный отчёт №41". Потом в четверг он говорит "Вчера я говорил, что собирался делать отчёт №41, вот я его вчера и делал. Сегодня буду продолжать заниматься отчётом №41". В пятницу он говорит "Вчера занимался отчётом №41. Если успею закончить, то начну отчёт №42". И так каждый из 10 человек! Большинство из других подгрупп и меня не интересуют их модули, я с ними не пересекаюсь, поэтому не слушаю. Это просто религия, никакой пользы она не приносит, но все верят, что это что-то изменило. А, ну и ещё дичь - если в течение дня тебя кто-то отвлёк по работе (техподдержка обратилась, или коллеге помогал с вопросом), то это надо запомнить и на следующий день рассказать, что помогал такому-то и подсказал такому-то. То есть каждый день тратить эмоциональную энергию на запоминание любого вопроса и пожара, с которым к тебе обратились, и не забыть об этом сказать на следующий день. Я отмечал в рабочем времени все эти созвоны, и получилось, что за 9 месяцев я около 3 недель рабочего времени просто сидел и тупо смотрел в мессенджер! Если это помножить на 10 человек и на их зарплату, то на эту хрень фирма потратила больше полумиллиона рублей за 9 месяцев. И что-то никто не хвастается, что фирма стала больше зарабатывать после введения этих совещаний, по-моему лучше не стало, а только хуже.
@@YauhenKavalchuk , супер! А вы согласились бы ответить на пару вопросов по scrum? На подобие предыдущего комментатора. Мы сейчас запускаем подобный проект, и обратная связь от тех, кто в теме, как говорится, бесценна была бы.
@@sergeychernikov8911 большое вам спасибо за мнение! Со стороны методика и правда кажется сильно упрощающей жизнь. А вон сколько камней подводных, оказывается.
@@ةىبةت оно и со стороны кажется сильно усложняющей жизнь, коим оно и является. Даже странно было что автор видео так это нахваливает. Наверное зависит от типа личности, но явно эта технология "очень не для всех"
Отличное видео. Подскажите, если владелец проекта начинает его с нанятым разработчиком вдвоём. За всю it-часть отвечает разраб (в том числе работа с серверами, бэкапами, безопасность сайта). Каким образом владельцу сохранять полный контроль над проектом? Чтобы в случае желания продажи бизнеса владелец был уверенным, что он действительно владеет всем необходимым для этого. И не придётся ни о чем потом договариваться с нанятым разработчиком и зависеть от него в этом вопросе.
