Разбираемся в Scrum: Руководство с картинками и примерами
Scrum, один из наиболее популярных фреймворков для управления проектами, часто вызывает множество вопросов и разногласий по поводу своего применения. В процессе своей работы я неоднократно сталкивался с тем, что разные люди по-разному понимают и интерпретируют Scrum. Это побудило меня создать статью, которая поможет быстрее разобраться в его основах и особенностях.
В данной статье я постарался изложить основные принципы Scrum, опираясь на Scrum Guide, и дополнить их своими личными наблюдениями и опытом. Я включил множество иллюстраций и примеров из практики, чтобы сделать материал более понятным и полезным. Надеюсь, что эта статья станет ценным ресурсом для тех, кто хочет глубже понять и эффективно использовать Scrum в своей работе.
Определение Scrum
Scrum — это гибкий фреймворк, который помогает людям, командам и организациям достигать успеха в решении сложных задач за счет адаптивного способа решения за.
В формате «цитат» я буду во время статьи делить своим мнением.
Важно выделить, что Scrum — это не свод правил, по которому вы должны работать, это только фреймворк, который описывает принципы, как может работать команда в случаях, когда ей нужно всегда проверять, делает она то, что нужно, или нет.
»Фреймворк описывает начальную заготовку и свод инструкций, которые упрощают достижение конечной цели: каркас корабля и фундамент дома достроить проще, чем собирать с нуля.» (данное описание взято с сайта Яндекс Практикума)
Также важно отметить, что при внедрении Scrum в компанию не рекомендуется менять названия мероприятий и инструментов. Дело в том, что это может сбить с толку ваших коллег и затруднить процесс их адаптации. Преимущества Scrum заключаются в том, что существует Scrum Guide, который позволяет быстро и эффективно погрузить сотрудников в процессы. Благодаря этому вам не придётся тратить время на создание собственной документации.
Ниже вы увидите изображение, которое часто встречается при работе со Scrum:
На них описаны все основные мероприятия, которые позволяет создать гибкую среду, в которой:
Product Owner упорядочивает работу по решению комплексной проблемы в Product Backlog.
Scrum Team в ходе Sprint превращает выбранную работу в Increment, несущий ценность.
Scrum Team и заинтересованные лица инспектируют результаты и вносят правки для следующего Sprint.
Повторяет.
Ценности Scrum
Ценности Scrum лучше всего иллюстрирует изображение, представленное ниже:
Scrum команда
Основная единица Scrum — небольшая команда людей (до 10 человек).
Scrum команда состоит из:
одного Scrum Master,
одного Product Owner,
Developers.
Внутри Scrum Team нет подкоманд и иерархий. Это сплоченное объединение профессионалов, в любой момент времени сфокусированных на одной цели.
Scrum команды являются кросс-функциональными, то есть их участники обладают всеми навыками, необходимыми для создания ценности в каждом Sprint. Также они самоуправляемы, то есть сами решают, кто, что, когда и как делает.
Scrum Team достаточно маленькая, чтобы оставаться проворной, и достаточно большая, чтобы выполнять значительную работу в течение Sprint — состоит не более чем из 10 человек.
Если Scrum Teams становятся слишком большими, участникам следует рассмотреть возможность реорганизации в несколько сплоченных Scrum Teams, каждая из которых сфокусирована на одном и том же продукте. Следовательно, у них должна быть та же Product Goal, тот же Product Backlog, тот же Product Owner.
Вся Scrum команда несет ответственность за создание ценного, полезного Increment в каждом Sprint.
Важно помнить, что Increment — не значит релиз. Scrum не обязует каждый спринт выпускать новый релиз.
Developers
Developers — это люди в Scrum команде, которые привержены созданию любого аспекта готового к использованию Increment в каждом Sprint.
Product Owner
Product Owner несет ответственность за максимизацию ценности продукта, получаемого в результате работы Scrum Team.
Scrum Master
Scrum Master несет ответственность за применение Scrum в соответствии с Руководством по Scrum. Они делают это, помогая всем понять теорию и практики Scrum, как внутри Scrum Team, так и в организации.
Важно понимать, что scrum-мастер — это не просто менеджер, который указывает, как нужно работать. Это человек, который обучает команду и помогает ей работать по методологии scrum, устраняя все препятствия на пути. На самом деле, он даже не должен участвовать в мероприятиях. Например, он не обязан ходить на Daily. Его задача только научить команду укладываться в 15 минут, а затем команда может работать самостоятельно.
Ответственности ролей
Для удобства можно свести обязанности всех ролей в одну таблицу:
Developers | Product Owner | Scrum Master для команды | Scrum Master для Product Owner | Scrum Master для организаци |
|---|---|---|---|---|
создание плана на Sprint — Sprint Backlog; | разрабатывает и точно коммуницирует Product Goal; | коучит участников команды в части самоуправления и кросс-функциональности; | помогает находить техники эффективного определения Product Goal и управления Product | |
Backlog; | направляет, обучает и коучит организацию в применении Scrum; | |||
стремление к качеству посредством соблюдения DoD (definition of done); | создает и четко объясняет элементы Product Backlog; | помогает Scrum Team фокусироваться на создании Increments с высокой ценностью, | ||
соответствующих DoD; | помогает Scrum Team осознать необходимость четких и лаконичных элементов Product | |||
Backlog; | планирует переход на Scrum и консультирует по вопросам применения Scrum в рамках | |||
организации; | ||||
ежедневную адаптацию своего плана для достижения Sprint Goal (Daily); | упорядочивает элементы Product Backlog; | способствует устранению препятствий, мешающих прогрессу Scrum Team; | помогает применять эмпирическое планирование продукта в комплексной среде; | помогает сотрудникам и заинтересованным лицам понять и применять эмпирический |
подход к комплексной работе;, а также, | ||||
взаимную подотчетность друг перед другом как профессионалами. | обеспечивает прозрачность, доступность и понимание Product Backlog. | убеждается в том, что все события Scrum происходят, позитивны, продуктивны и не | ||
выходят за рамки ограничений по времени. | фасилитирует взаимодействие с заинтересованными лицами по запросу или при | |||
необходимости. | устраняет барьеры между заинтересованными лицами и Scrum Teams. |
Кратко данную таблицу можно представить с помощью такого рисунка:
События Scrum
Sprint — это контейнер для всех остальных событий.
Каждое событие в Scrum специально спроектированы для обеспечения необходимой прозрачности.
Неспособность проводить какое либо из событий Scrum в соответствии с описанием приводит к потере возможностей для инспекции и адаптации.
Sprint
Sprints — это пульс Scrum, где идеи превращаются в ценность.
Цель: | Вся работа, необходимая для достижения Product Goal, включая события Sprint Planning, Daily Scrum, Sprint Review и Sprint Retrospective, выполняется в рамках Sprints. |
|---|---|
Участники: | Developers, Product Owner, Scrum Master |
Timebox | |
(время проведения) | до 1 месяца |
В ходе мероприятия: | • не вносятся изменения, которые могут поставить под угрозу Sprint Goal; |
• не снижается качество; | |
• Product Backlog уточняется по мере необходимости;, а также, | |
• по мере появления новых знаний содержание работы может быть уточнено и | |
пересмотрено с Product Owner. | |
Ограничения: | Sprint может быть отменен, если Sprint Goal потеряла актуальность. Только Product Owner имеет право отменить Sprint |
Результат: | Готовый инкремент (не обязательно релиз) |
Sprint Planning
Sprint Planning инициирует Sprint, планируя работу, которую необходимо выполнить в этом Sprint.
Цель: | Постановка Spring Goal и планирование Spring Backlog, который команда должна будет сделать для реализации инкремента |
|---|---|
Участники: | Developers, Product Owner |
Timebox (время проведения) | до 8 часов (при спринте 1 месяц) |
В ходе мероприятия: | Участники должны ответить на основные вопросы: |
• почему этот Sprint ценен? | |
• что может быть готово в этом Sprint? | |
• как будет выполняться выбранная работа? | |
Результат: | Spring Goal |
Spring Backlog |
Мне кажется, что это одно из самых обсуждаемых мероприятий в Scrum, потому что многие разработчики не понимаю зачем оно нужно и считают, что порой нельзя оценить задачу, ведь в ней могут быть много не известных.
Мне на практике для планирования помогло несколько вещей:
1. Лучше оценивать задачи относительно других задач. Я в своей практике выбираю выполненные задачи, у которых известно время выполнения, и предлагаю сравнивать относительно них. Это позволяет чуть точнее оценить задачу. (Важное замечание: это работает при условии, если задача полностью понятна)
2. Внедрите DoR и не берите задачи в разработку, которые не проработаны до конца
3. Если все таки нужно брать задачу, в которой много неизвестных, то создайте задачу для исследования. Сделайте прототип. Покажите его Product Owner и стэйкхолдерам и затем если все понятно переходите на полноценную разработку функционала. (Это также сочетается со вторым пунктом, так как прототипы можно считать DoR для разработки)
Пример из практики
Однажды нам потребовалось создать функционал, который позволил бы пользователям фильтровать результаты запросов по определённым правилам. Первое, что пришло нам в голову, — это создать текстовый запрос, похожий на SQL или JQL. Для этого нам нужно было бы подключить Antler, чтобы работать со сложными вложенностями в запросе (скобочки и т.п.) Однако мы никогда раньше не работали с этим инструментом, и он выглядел довольно сложно. Поэтому мы решили создать небольшой прототип с базовыми функциями без сложных структур. Мы показали его Product Owner.
Он посмотрел и сказал: «Но пользователи же не будут всё это писать вручную. Давайте сделаем визуальный конструктор запросов». За следующий спринт мы создали несколько макетов и продемонстрировали их. Product Owner внёс небольшие комментарии, но в целом его всё устроило. Затем мы реализовали прототип за спринт, показали его, и Product Owner окончательно одобрил функционал.
После выпуска версии заказчику он тоже оценил, что такой вариант удобен. В итоге мы не потратили много времени на внедрение Antler и, благодаря итерациям, смогли понять, что именно нужно заказчику. Можно сказать, что Product Owner не прописал задачу правильно, но нужно понимать, что он тоже человек и не всегда может предугадать все варианты реализации.
Daily Scrum
Daily Scrum — это 15-минутное событие, которое позволяет команде каждый день проверять прогресс выполнения Sping Backlog.
Цель: | Инспекция прогресса в достижении Sprint Goal, адаптация Sprint Backlog по мере необходимости, корректировка запланированной предстоящей работы. |
|---|---|
Участники: | Developers |
Timebox (время проведения) | до 15 минут |
В ходе мероприятия: | Developers определяют прогресс выполнения Sping Backlog |
Результат: | Spring GoalSpring Backlog |
Небольшое замечание: стоит обратить внимание, что в этом событии не обязательно должен участвовать Scrum Master. На данном мероприятии его задача — научить команду проводить самостоятельно и укладываться в отведенное время.
Многие разработчики считаю, что данное мероприятие не нужно и просто отнимает время. Но не забывайте, что в во время Sprint вся команда отвечает за Increment, а не один человек. Поэтому Daily и должны позволять команде понять статусы по задачам и определить нужна ли кому-то помощь в реализации.
Sprint Review
Цель: | Инспекция результата Sprint и выявление возможностей для адаптации.Scrum Team представляет результаты своей работы ключевым заинтересованным лицам, иобсуждает прогресс в достижении Product Goal. |
|---|---|
Участники: | Developers, Product Owner, заинтересованные люди (stakeholders) |
Timebox (время проведения) | до 4 часов (при спринте 1 месяц) |
В ходе мероприятия: | Во время события Scrum Team и заинтересованные лица анализируют, что было достигнуто в ходеSprint, и что изменилось в их окружении. |
Результат: | На основе проанализированной информации участники совместно решают, что делать дальше. Product Backlog также может быть скорректирован с учетом новых возможностей. |
В Scrum Guid отдельно отмечено, что Sprint Review — это не просто демонстрация инкремента. Это в первую очередь обсуждения чего добилась команда и куда нужно идти дальше.
Sprint Retrospective
Цель: | Запланировать повышение качества и эффективности |
|---|---|
Участники: | Developers, Product Owner, Scrum Master |
Timebox (время проведения) | до 3 часов (при спринте 1 месяц) |
В ходе мероприятия: | Участники Scrum Team обсуждают, что прошло хорошо во время Sprint, с какими проблемами они |
столкнулись, и как эти проблемы были (или не были) решены. | |
Результат: | Предположения, которые сбили Scrum Team с пути, и исследуется их происхождение. |
Ретроспектива является последним мероприятием в спринте и обозначает его завершение.
Интересно, что ретро — это то, что не делают чаще всего в компаниях.
Возможно, это и хорошо, так как не тратится время разработчиков. Но. ретро — в первую очередь инструмент обучения, который позволяет команде понять, что пошло не так во время спринта и что можно улучшить в следующем.
Для того, чтобы команда полюбила использовать данный инструмент важно, чтобы было видно что изменилось после него.
На своей практике мы за 4 месяца устранили больше 20 проблем и уменьшили LeadTime на 30% за счет проведения ретро внутри команды.
Артефакты Scrum
Артефакты Scrum иллюстрируют работу или ценность. Они созданы так, чтобы максимально чётко отражать важную информацию. Это позволяет всем, кто с ними знакомится, иметь общее представление о ситуации и действовать на его основе.
Для каждого артефакта есть определенная цель, для которой он реализуется. Это позволяет понять в какую сторону идет разработка и достигнута ли ее цел.
Связи артефактов и целей представлены в таблице:
Артефакт | Цель |
|---|---|
Product Backlog | Product Goal |
Spring Backlog | Spring Goal |
Increment | DoD (определение готовности) |
Product Backlog
Product Backlog — это список задач, которые необходимо выполнить для улучшения продукта. Он упорядочен и постоянно обновляется. Этот список — единственный источник работы для Scrum Team.
Также должен постоянно проводится процесс Gruming Backlog (актуализации бэклога), когда задачи в бэклоге продукта должны описывать подробнее, декомпозироваться до уровня спринта, а лишние задачи удаляться.
Ответственность за Product Backlog лежит на Product Owner. Он отвечает за наполнение и приоритезацию задач.
Product Goal
Product Goal — это долгосрочный ожидаемый результат Scrum Team. Они должны достичь одной цели (или отказаться от нее), прежде чем приступить к следующей.
Product Goal входит в состав Product Backlog. Остальная часть бэклога продукта появляется, чтобы определить, «что» будет способствовать достижению Product Goal.
Sprint Backlog
Sprint Backlog — это план, который команда разработчиков создаёт для себя. Он представляет собой понятное и актуальное описание работы, которую команда планирует выполнить в течение спринта для достижения цели спринта. Поэтому в течение спринта Sprint Backlog обновляется по мере получения новой информации. В нём должно быть достаточно подробностей, чтобы команда могла отслеживать свой прогресс во время ежедневных собраний (Daily Scrum).
Sprint Backlog состоит из:
Sprint Goal — почему нужен данный инкремент,
набора выбранных на Sprint элементов Product Backlog — что нужно сделать для реализации инкремента
осуществимого плана действий по поставке Increment — как реализовать инкремент.
Sprint Goal
Sprint Goal — это единственная цель на спринт. Хотя разработчики и стремятся достичь этой цели, она также даёт им гибкость в выборе конкретных задач, необходимых для её выполнения. Sprint Goal помогает сохранять связность и фокусировку, побуждая команду Scrum работать вместе, а не над отдельными инициативами.
Sprint Goal создаётся во время планирования спринта и затем добавляется в список задач на спринт (Sprint Backlog). Разработчики помнят о Sprint Goal, работая над задачами спринта.
Отдельно отмечу абзац из манифеста:» Если работа не соответствует ожиданиям, они (developers) взаимодействуют с Product Owner, чтобы пересмотреть содержание Sprint Backlog в рамках Sprint, не изменяя Sprint Goal.»
Increment
Increment — это конкретная ступенька к достижению Product Goal.
Каждый инкремент дополняет все предыдущие. Они проходят тщательную проверку, чтобы гарантировать, что все инкременты будут работать вместе. Чтобы быть ценным, инкремент должен быть полезным и пригодным для использования.
В течение одного спринта можно создать несколько инкрементов.
Итоговые инкременты демонстрируются на Sprint Review, что способствует развитию эмпирического подхода.
Отдельно выделю абзац, который мне показался интересным: «Однако инкремент может быть предоставлен заинтересованным сторонам ещё до завершения спринта. Важно понимать, что Sprint Review не является единственным моментом для предоставления ценности.»
DoD (Определение готовности)
DoD (Определение готовности) — это формальное описание состояния Increment, при котором он соответствует требованиям качества, предъявляемым продукту.
Определение готовности обеспечивает прозрачность, предоставляя всем единое общее понимание того, какая работа была выполнена в рамках Increment.
Если элемент Product Backlog не соответствует определению готовности, его нельзя выпускать или даже показывать на Sprint Review. Вместо этого он возвращается в Product Backlog для дальнейшего рассмотрения.
Если определение готовности для Increment является частью единых стандартов организации, все Scrum Teams должны использовать его в качестве необходимого минимума. Если оно не определено стандартами организации, то Scrum Team должна создать определение готовности, подходящее поставляемому продукту.
Разработчики должны строго придерживаться определения готовности. Если несколько команд Scrum работают над общим продуктом, они должны совместно создать и соблюдать одно и то же определение готовности.
Заключение
Изучение и внедрение Scrum может показаться сложным на первых порах из-за множества нюансов и разнообразных интерпретаций. Однако, опираясь на фундаментальные принципы Scrum Guide и постоянно обучаясь можно значительно улучшить этот процесс.
В данной статье я постарался объединить теоретические аспекты с практическими иллюстрациями, чтобы сделать понимание Scrum более доступным.
Надеюсь, что предоставленная информация поможет вам глубже разобраться в сути этого фреймворка и успешно применить его в своих проектах. Помните, что ключ к эффективному использованию Scrum — это не только знание теории, но и постоянное стремление к улучшению и адаптации под конкретные условия вашей команды и проекта.
