всем привет.

добро пожаловать на наш курс и тема сегодняшнего видео

это SCRUM.
наверняка вы не раз слышали это слово возможно вы уже
работаете с этим фреймворком возможно читали о нем, но
не до конца разобрались, а может вы совсем не знаете и не
понимаете что это такое, но хотите постигнуть идею в
любом случае.
в этом видео мы с вами разберемся в данной теме и
расставим все точки над i, так как с данным фреймворком
вам с очень большой вероятностью придется столкнуться и
если вы планируете работать в it компании.

итак поехали для того чтобы вы понимали процесс

разработки в команде, это не какое-то хаотическое
движение где каждый делает только то что умеет и когда
захочет.

весь процесс работы над проектом — это строго

регламентированная деятельность - задачами и ролями
где каждый знает и понимает, что делает лично он, и за что
несёт персональную ответственность, а также видит, чем
занимается команда в данный момент времени, и где скоуп
задач каждого участника, хотя ради справедливости стоит
отметить, что в случае какого-то фейла, виновата обычно
вся команда, но и не один человек, да уж такая особенность.
все эти активности и роли определяется в разных
методологий в таких как waterfall, xp и так далее.
самые популярная методология на данный момент это
agile. свою популярность она получила благодаря гибкости
и быстрой адаптируемости к различным новым
требованиям.
рынок, для которого разрабатываются коммерческие
проекты имеет склонность постоянным изменением, это то,
что сегодня стильно, модно и молодежно,
завтра уже может устареть, и чтобы при разработке
продукта адаптироваться к таким изменениям, должна быть
возможность вносить правки, корректировки,
приоритизировать задачи и так далее.
короче основная идея это быстрая и безболезненная
перестройка работы команды.

методология Agile предоставило все необходимые

инструменты для достижения этой цели.

первое что нужно запомнить, это то что Scrum является

фреймворком, a Agile то есть он предоставляет все базовые
модули которые можно затягивать на проект и использовать
для организации процесса эффективной работы команды,
чтобы все активности были максимально продуктивны и
новые фичи имели максимальную бизнес ценность.

сам по себе Scrum основывается на так называемом

правилами 353 (три пять три) или он имеет три роли, 5
церемоний или событий и 3 артефакта.
 давайте для пройдемся по этим правилам, а затем
разберемся с небольшими нюансами данного фреймворка.
Итак начнем с Scrum как было сказано их три это продукт
оунер- скрам мастер- и собственно команда
разработчиков.

каждый из ролей выполняет свои обязанности и имеет свой

круг ответственности.

product owner - фактически это голос клиента, у него есть

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

следующая роль - это скрам мастер по сути это мост

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

заключительная роль — это команда разработчиков. по

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

если просто, то команда - это кросс функциональная и

самоорганизующаяся группа людей которая во время и с
высокой стабильностью доставляет новый функционал.
самоорганизующиеся команды самостоятельно решает
как выполнять свою работу и они следуют внешним
указанием.

кросс функциональная команды обладает всеми

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

в скрам команду входит и продукт оунер и скрам мастер и

команда разработчиков, то есть это такой тип команды,
которую включает себя все роли.

разобрались - переходим к церемонии или событиям.

более понятным языком это разные типы собраний для
обсуждения или решение определенных задач.

далее собрание или встречи я буду называть митингами

так как мне так привычнее.

спринт это длящийся от одной недели до 1 месяца отрезок

времени в течение, которого должен быть выполнен
определенный скоуп задач. его длительность
фиксирована и определяется на старте проекта.

сам по себе он является контейнером для всех остальных

типов митингов.

спринт planning это митинг на котором как раз-таки и

определяется скоуп задач, которая называется product
backlog, это формируется список который обязательно
должен быть выполнен текущем спринте -это sprint
backlog.

для того чтобы понять сколько команда может выполнить:

идет анализ предыдущих спринтов и того объема задач
который в них был закрыт и на основании этих цифр
набирается user story или просто задачи.

дейли стендапы (daily standups) - на этом митинге все

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

backlog груминг ранее мы говорили о том что sprint

backlog формируется на основании определенных метрик
или цифр, есть две основные оценки это capacity и velocity
или длительность выполнения задачи и ее сложность.

capacity определяется внутри системы мониторинга.

обычно эта программа наподобие jira на основании
выставляем их задача тегов, то есть готова к работе, в
разработке, в review, в тестировании - легко отследить
сколько по времени выполнялось та или иная задача.

velocity или скорость выставляется командой на груминге

техники выставления.
пока важно понять что на основании описание задачи
выставляется так называемые абстрактные величины -
оценки сложности или стори поинт и двигаемся дальше в
sprint preview (demo).

это показ результата спринта фактически эта

демонстрация клиенту результатов работы команды за
спринт, то есть презентация новых фич с описанием их
работы ну или есть результат работы.
например в этом спринте мы dar academy реализовали такой
то модуль в результате чего его стабильность и скорость
работы повысилась и страница стала работать быстрее.

последний тип — это ретроспектива. на данном митинге

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

скрам мастер получает информацию о процессах на

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

переходим заключительной части артефакты.

как вы помните их тоже 3. причем два из них уже были

озвучены: это product backlog - большой список задач
всего продукта за
которым постоянно нужно следить и приоритизировать
дополнять и расширять этой работой, как вы понимаете
занимается
продукт оунер.

sprint backlog это список задач для выполнения в текущем

спринте.
он небольшой но концу спринта он должен быть выполнен.

данный список может формироваться например проджект-

менеджером или лидом проекта и продукт инкремент или
burndown chart -график сгорания.

данный график показывает как выполняется работа то есть

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

я покажу вам насколько слажен и организован процесс

работы в течение спринта и так наш текущий спринт
только, что закрылся.
project manager отправляет письмо заказчику о том что
планируется выполнить течение следующего спринта.

предположим его длительность будет две недели.

данный список как уже было сказано сформирован на

основании того количества стори поинтов которые были
закрыты в предыдущих спринтах.
предположим это 50 стори поинтов что составляет
например 15 задач и эти задачи уже назначены на
определенных людей, то есть вся команда еще до начала

спринта знает свои задачи.

отлично теперь спринт стартанул.

каждый день мы собираемся командой и обсуждаем что

сделано и что каждый из нас будет делать сегодня, если мы
видим, что мы не успеваем выполнить все заявленные
задачи, значит как можно быстрее мы связываемся
заказчиком и объясняем ему возникшие блокеры, если кто-
то не справляется.

ему оперативно в помощь можно выделить человека в

общем и целом все проблемы мы стараемся обсуждать и
решать максимально быстро во время спринта.

мы также встречаемся для того чтобы оценить задачи из

бэклога.

это нужно для того чтобы заказчик представлял сколько

времени займет имплементация той или иной фичи и в
зависимости от текущей ситуацией и мог
приоритизировать backlog во время выполнения задач.
мы используем jira, если мы берем задачу то переводим ее
status in development.

если заканчиваем переводим на комплитед.

в день окончания спринта мы составляем письмо о том что

сделано в текущем спринте, после чего назначается
DEMOdAY.

где каждый разработчик показывает функционал который

он сделал плюс объясняется причина того почему
некоторые задачи не могли быть выполнены.

в конце мы проводим ретроспективу чтобы определить что

мы сделали хорошо где что-то не доработали, и что нужно
улучшить таким образом у нас

есть вся статистика и необходимая информация для

следующих спринтов.

мы закрываем текущие и начинаем новый и так по кругу.

вот почему такая модель разработки называется

итеративной.

я надеюсь теперь все роли и процессы стали более

прозрачны и понятны.
смотрите я рассказалА основной скелет построения и
организации процессов скрам.

конечно на каждом проекте они могут быть свои,но

основной каркас скажем так один и тот же, есть нюансы,
что некоторых ролей может не быть.

некоторые задачи могут быть делегированы на других

участников.

по 100 процентно скрам работает очень редко но как было

сказано, он очень гибкий и адаптируемый поэтому проблем
не возникает.

теперь рассмотрим пару нюансов которые есть в скрам.

в начале видео я говорила что скрам это фреймворк agile, а

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

эти принципы и подразумевает готовность постоянно

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

сам же процесс базируется на трех китах:

это прозрачность то есть все участники понимают что они
делают.
инспекция - постоянный контроль за артефактами и
различными отклонениями и
адаптация, внесение исследования изменениям, в случае
необходимости также команде разработчиков
предъявляется одно важное требование эта численность.

оптимальное количество людей от 3 до 9 человек, не

включая продукт оунера и скрам мастер, а именно поэтому
слишком большая команда может делиться на
отдельные стримы, которые работают со своими
направлениями, хоть скрам и не признает под команд в
команде разработки но все-таки такое деление происходит
довольно часто, и в целом это все что я планировала
рассказать вам о скрам.