Как работают программисты? Scrum фреймворк (с точки зрения разработчика)

[@itwithvitaly]

00:00 Начало 0:49 - что такое Scrum 1:15 - зачем он нужен 2:46 - что разработчик должен знать о Scrum 4:11 - пример использования Scrum-a в работе 5:19 - основные принципы системы Scrum. Что такое sprint-ы 7:19 - планирование спринта (sprint planning) 11:28 - Daily scrum 12:22 - основные роли в скраме 15:07 - что такое Sprint demo и review 16:51 - Sprint retrospective 17:55 - Backlog refinement 18:46 - ограничения в Scrum

[@vvp726]

Спасибо! Ты это, моргай хоть иногда)

[@itwithvitaly]

Спасибо! Я стараюсь :)

[@vs8418]

Это профессиональная деформация)). Чаще моргайте, смотрите в даль в окно(меняйте фокусные расстояния) иначе зрительному аппарату годам к 40 придёт пушной зверёк.

[@ПетрМельников-н2у]

Даа, скрам это тема. Столкнулся с этим на новом месте работы через сервис аспро agile, мало понимал зачем оно надо. Зато теперь благодаря автору понимаю, что штука действительно нужная. Думаю, что и не только в сфере айти.

[@quarkua]

Спасибо за видео! В целом все как себе и представлял. Причины по которым не можем работать по Scrum: 1.Выполнили спринт за 2 недели, внедрили. Спланировали, начали второй спринт прилетают баги по первому спринту с прода. Надо править ASAP собирать поставки внедрять возможно и не один раз. Задачи спринта стоят. Баги должна править поддержка не участвующая в Scrum? 2.Разная квалификация и чувство ответственности разработчиков, как следствие текучки кадров и пополнения команды на 95% за счет стажеров без какого либо опыта разработки до(особенность компании:)). Один добавляет поле на форму за 15 мин, другой будет делать это 4 часа. 3.Бизнес принимает пассивное участие в тестировании. В итоге зачатстую выясняется после релиза, что сделали "не совсем то что мы хотели". И опять ASAP переделать. Задачи спринта стоят. 4.Внезапные задачи от бизнеса которые нужно выполнить ASAP в середине спринта. 5.Отсутсвие нормального DevOps, поставки выполняет проеткная команда. Кто-то из разрабочиков в порядке очереди. 6.Задержка согласования документации и прохождения тесткейсов заказчиком от бизнеса. 7.Объемные задачи которые нельзя делить на несколько спринтов, нужно сдать заказчику в полном объеме до внедрения, если хотя бы одна подзадача незавершена внедрять всю "большую" задачу невозможно. Еще по Scrum не ясно: 1.2 недели спринт. Когда тестировать задачи завершенные вечером в пятницу последней недели? 2.В начале спринта тестирощик не загружен пока не готова ни одна задача? 3.Если сложить все митинги может получится -1 рабочий день.

[@itwithvitaly]

Привет, спасибо! Ситуации бывают разные в проектах и "серебрянные пули" всегда найти довольно сложно. Скрам подходит под категорию так называемых "гибких" методологий, и гибкость как раз от части и состоит в том, что этот подход можно адаптировать под нужды проекта :) Отвечу на вопросы: 1.2. По средине спринта должен быть code freeze, когда задачи которые идут в текущий релиз завершаются и еще неделя отводиться на баг фиксинг и тестирования. Не забывайте что здесь именно ключ в том что это про текущий релиз, а не про объем работы которые делает команда, потому что даже при code freeze недельный команда может брать задачи, которые пошли в текущий спринт но идут в следующую релиз версию. Т.е. у нас 2х недельный спринт, мы набираем задачи, у части задач будет релиз версия 1.0, у второй части 1.1. Таким образом мы сначала делаем задачи на 1.0 в первую неделю, потому замораживаем код и неделю отводим на тестинг и баг фикс версии 1.0. Пока этот процесс идет, то мы делаем задачи которые уже пойдут в следующую фикс версию 1.1. Таким образом мы как бы немного забегаем наперед. 2. Первый ответ частично отвечает на этот вопрос, тестировщики в начале спринта тестируют задачи которые вы сделали в прошлом спринте на версию 1.1, а также если тестировщики занимаются автоматизацией то они в это время могут писать regression тесты (автоматизация). 3. Так и есть, этот процесс опять же адаптивные, где-то некоторые митинги пропускаются, где-то просто идут на эти накладные расходы. В любом случае этот процесс придуман не глупыми людьми благодаря методу проб и ошибок, если бы это не работало - этим бы не пользовалось такое кол-во людей :)

[@quarkua]

@@itwithvitaly Спасибо, стало понятнее, как выстроен процесс)

[@ilyal5712]

@@itwithvitaly Эти советы было бы не плохо добавить в видео. Т.е. показывать не только плюсы, но и минусы, сравнение с Kanban, добавить практические примеры. А так видео хорошее, только моргайте :)

[@ilyal5712]

1) Code freez - заморозка спринта, пока не пофиксят срочные баги. Второй вариант: на каждом спринте по 20% времени посвящать bugfixing. Третий вариант - отменяем спринт, фиксим баги, стартуем спринт заново со стадии планирования. Менее эффективно. 2) Некоторые story points привязывают к определенному человеку. Тогда можно "предсказать", сколько в реальности у человека уйдет времени. Т.е. Васи Пупкину дается 60 story points на спринт, а Вове Иванову - 85. 3) Надо объяснять что нужен один decicated человек product owner, которого будут доставать каждый день на daily meetings. Иначе - никак. Можно хотя бы через день product owner приглашать. Если PO хочет поменьше митингов, задавайте вопросы по email. 4) Code freez. 7) Объясняем заказчику, что прогресса на sprint demo он не увидит, но процесс идет. В идеале - хоть какую-то видимость прогресса показать, хоть технически. 1) Переносить спринты на среду. Вообще плохая идея деплои в пятницу вечером - все хотят домой, и заказчик и программеры. 3) Да за это и критикуют Scrum. Говорят что "Scrum это все о митингах и планирование, а Kanban - это все о кодировании". Программеры по-среднему относятся к Scrum, ибо можно отдохнуть на митингах + печеньки :)

[@alexb.2616]

Полезнейшая инфа. Много раз слышал про SCRUM, теперь буду знать, что это такое! Спасибо.

[@itwithvitaly]

Спасибо!

[@ivanAccountent]

Спасибо, после просмотра разложилось все по полочкам именно в понимании "расзработка по скраму". Ранее работая даже не в ит в гос секторе (тоже работа командой над определенными задачами) , реально работая бы мы по скраму или чему то подобному продуктивность и "выхлопа" было бы гараздо больше! А не собрание планерка раз в неделю где пытались обсудить все и вся сразую

[@itwithvitaly]

Спасибо!

[@vovaka440]

Только начались лекции по методолгии, где рассказывали про Scrum, Agile, WaterFall. И тут нахожу это видео))

[@itwithvitaly]

Как удачно ! :)

[@serg1221]

Веталь, всё круто, продолжай в том же формате)

[@itwithvitaly]

Спасибо!:)

[@emanuelemazzeo4474]

Отличное объяснение. Я использую Restyaboard, бесплатный инструмент для управления проектами Agile, Scrum и Kanban.

[@olenaolena6075]

Спасибо за урок. Понятно, как раз для таких «гуманитариев» как я.

[@itwithvitaly]

Спасибо!

[@АндрейИгнатьев-с5н]

Все хорошо кратко и ясно

[@itwithvitaly]

Спасибо!

[@Medulla_oblongata01]

Отличный канал!

[@monochrome-]

Спасибо за видео!

[@itwithvitaly]

Спасибо!

[@jemilsuleimanov209]

Виталий спасибо, я хоть узнал что работаю по scrum :) И еще вопрос такой возник. У нас недельный спринт, а в таксках есть предпологаемые трудозатраты в часах, но так как я только только начал работать, то я трачу в несколько раз больше часов. Например по задаче предпологается что задача должна занять час, а я трачу на нее 5 часов, а может и больше, потому что библиотеку совсем не знаю используемую) Потом я проставляю сколько часов потратил на задачи к концу спринта. Как лучше записывать трудозатраты, в реальных потраченных часах(немного стыдно что так много времени трачу на простые задачи, и есть страх что я в таком случае не проработаю долго) или писать заниженные цифры(что сейчас и делаю) ?

[@stas9066]

Хороший вопрос !!! Ответьте, пожалуйста, Виталий!

[@АндрейТюников-н7в]

мне кажется всем джунам будет интересно мнение по этому поводу

[@МихаилАлександров-ж4м]

Скрам не предполагает, что в каждой задаче мы попадаем оценками "в десятку". любые оценки в скраме имеют какой-то смысл только в масштабе работы всей команды. Иными словами, если Вы,, как новый человек, тратите больше времени, чем запланировано, то это может означать две возможные ситуации: кто-то другой тратит меньше времени на свои задачи, тем самым выводя среднюю скорость команды в ожидаемый диапазон, или, второй вариант, команда не корректно оценила задачи.

[@itwithvitaly]

Привет, спасибо! Вообще это плохо что вы испытываете страх перед тем чтобы давать реальные цифры, если такую атмосферу создает ваш менеджмент - то это плохой менеджмент. Вообще честные оценки всегда лучше как для вас так и для команды, они позволяют видеть реальную картину того, сколько команда с учетом вас успевает за принт. Тут фишка не в том чтобы отчитать время в таск, а потом в конце собрать всех и потыкать пальцем, чтобы посмотреть кто делает медленно, а кто быстро. Тут как раз таки задача в том, чтобы команда могла делать прогнозирование на след спринт и могла понимать сколько реально вы успеете. К тому же если в команде здоровая атмосфера и например ваш менеджер будет видеть что вы много времени тратите на какую-то задачу, то его задача в первую очередь организовать процесс таким образом чтобы с каждым разом вы такие задачи делали быстрее, например сделать какую-то передачу знаний от более опытных спецов. В любом случае честные оценки всегда лучше!

[@VasilyVasilyVasily]

Спасибо! А как выглядят задачи конкретно для каждого программиста внутри спринта, кто их пишет, и насколько подробно, в команде же программисты разного уровня? Нужно ли писать все задачи вплоть до задач для джунов, или нужно заложить задачу на создание задач для подчиненных? Каждый сам оценивает сторипойнт своей задачи, или за джуна оценивает мидл или сеньор?

[@pyramidhead9692]

Тоже интересуют ответы на эти вопросы.

[@Xokyopo]

Ничего не понял, но очень интересно :)

[@itwithvitaly]

Cпасибо :)

[@dastansmailov4923]

Чаще моргай, а то жутко становится) с меня лайк

[@itwithvitaly]

Спасибо! Я стараюсь :)

[@vlaih0]

Теперь новички будут такие дверь ногой выбивать на собеседование со словами: "А я знаю Скрам, задачи джуна. У меня пять пет-проджектов и сейчас я вам расскажу багаж знаний для джуна" Интересно будет узнать, что через год-два в связи с этим придумает бизнес как повышение требований к джунам.

[@faruhjmishenkopetrovich4011]

Слишком слабый , будет эффект от этих видеороликов на бизнес )

[@itwithvitaly]

Хаха, ну, для такого эффекта на этот канал должны быть подписаны хотя бы миллион, минимум :)

[@f1amezof]

Эх, идеальный мир... А расскажи пожалуйста как разработчик может повлиять на PO или SM, не выполняющих свои обязанности и неверно пользующихся Scrum'ом?

[@frozeninside5004]

Сложенно рассказываешь! продолжай в том же духе )

[@itwithvitaly]

Спасибо!

[@МихаилНещерет-ъ8в]

Добрый день. Посоветуйте, что проще выучить и после работу найти? Java или Front end? Может курсы подскажите в Киеве? Спасибо

[@itwithvitaly]

Здравствуйте, на самом деле и Front End и Java по времени изучения +/- одинаково выйдет, поэтому я бы лучше рекомендовал отталкиваться от ваших личных интересов, к чему душа больше лежит. Курсы к сожалению не подскажу, т.к. не могу ручаться за качество. Возможно в скором времени сделаю свои, тогда смогу отвечать за рекомендацию и качество :)

[@МихаилНещерет-ъ8в]

Благодарен за ответ

[@vs8418]

Не кажется ли вам избыточным присутствие такой, если можно так выразиться, должности как Scrum-master на рынке? Если нет, то почему? Ах да, чуть не забыл - спасибо за видео! То что нужно, чтобы разбавить утреннюю рутину.

[@jewgenijmoldawski3306]

Если хороший скрам мастер, то неизбыточен. Однако проблема в том, что он сам убивает свою должнось: чем лучше он работает, тем менее заметен для участников проекта. Со всеми вытекающими.

[@itwithvitaly]

Спасибо! Часто скрам-мастер это не какой-то выделенный человек, а просто часть этих обязанностей берет на себя кто-то из команды, чаще всего PM/DM/BA или QA Lead

[@oleksandrstasiuk4780]

А это нормально что сейчас на junior java developer вакансий почти нет, или так было раньше, еще до ковида?

[@itwithvitaly]

Привет, я честно сказать не слежу за вакансиями Junior, но судя вообще по кол-ву - то рынок почти всех направлений (языков) вернулся к кол-ву которое было до ковида. Я думаю все восстановится!

[@ilyal5712]

Должно восстановиться. Комании уже набирают программеров, которых уволили в период начала эпидемии. Соответственно, не все идут обратно, некоторых перекупили другие компании.

[@emptyinside1753]

Годно. Лайк

[@itwithvitaly]

Спасибо!

[@emptyinside1753]

@@itwithvitaly тебе спасибо

[@АлександрВоробец-у5к]

🔥🔥🔥

[@itwithvitaly]

Спасибо!

[@ruslankhissamiyev817]

Норм объяснил:)

[@itwithvitaly]

Благодарю :)

[@a.o.yaroslavov]

Скрам - это методология организованного распиздяйства. В принципе, помогает не сгореть на работе, если ты мидл в большой команде других мидлов.

[@itwithvitaly]

Нуу, это уже слишком грубо говоря, на самом деле если классно налажен процесс это очень удобно. Сам прочувствовал на себе

[@a.o.yaroslavov]

@@itwithvitaly Классно налажен - это как? Когда всем в кайф?

[@kengerfil]

Видео начинается с 4:14

[@Lucio11a]

скрам, эт, конечно, здорово... но слишком дофига слов, которые все запутывают. Если это не фреймворк, какого черта его называют фреймворк? По сути это банальная модель организации трудового процесса. Плюс десятки слов-паразитов, имхо конечно, исковерканных, английских слов в тексте видео, с криво поставленным ударением. Хотя это тоже понятно... вы работаете в своей среде, где называете все по своему. Не как оно на самом деле, а как кто-то первый начал называть, прижилось и пошло поехало. Но я просто придираюсь... меня часто бесит произношение и коверкание слов. Не именно к вам, но к многим ютуберам тоже :) мой внутренний перфекционист негодует. Хочется, чтобы в интересном мне канале все было идеально. А этот канал мне интересен. В любом случае, благодарю за видео. Скрам сейчас почти везде пропагандируют. Есть даж интернет курсы по программированию, где скрам "преподают" параллельно СиШарпу, допустим.

[@vyacheslavkozlov2207]

Пишется - кОверкание слов, дажЕ, хоЧется, да и правила употребления многоточий освоить вам стОит.

[@Lucio11a]

@@vyacheslavkozlov2207 Ага, благодарю. Когда быстро пишу, пропускаю ошибки :) Однако, я не ютубер. И этот текст, я не читаю на огромную аудиторию. С меня никто спрашивать за ошибки не будет. То, что комментарий заметили Вы, это, на самом деле, удивительно.

[@itwithvitaly]

Привет, спасибо! Ошибки есть, безусловно, но надеюсь я смог донести суть, как мне кажется это важнее :)

[@ilyal5712]

Раньше Scrum называли методологией. Мне кажется framework используется для хайпа или обновления старого, как iBank, Web 3.0 etc. Scrum не на все 100%, но многие практики из него сейчас в большинстве компаний используют.

[@Mashashu]

@@Lucio11a Вам бесплатно выдают такой супер контент, не придирайтесь 😉

[@skiller4000]

В целом, очень грамотная речь, но иногда перебор с англицизмами. митинг = встреча, совещание? бэнефиты = выгода? деливерить = доставлять продукт? скоуп = объем задач? Как та тетка из видео - "это очень important для economy"? На (в) Украине сейчас так модно :) ? Работаю по скраму уже больше года, совещаний надо бы поменьше, все-таки разработка > бюрократия.

[@itwithvitaly]

Не, не модно, просто настолько часто взаимодействуешь в английским что уже перестаешь замечать как он интегрируется в твою речь :) Кстати это у многих так, можно сказать профессиональный отпечаток :)

[@aleksandrbeloushkin7971]

Нет там никакой эффективности, целыми днями митинги, а код пишется по вечерам