скрам фреймворк что это
Гибкая методология разработки “Scrum”
Я продолжаю работу над диссертацией по проектному менеджменту. Сегодня мы кратко рассмотрим Scrum, рассмотрим типичные ошибки, приводящие к проблемам. Данный пост не претендует на полноту, он является обзорным и адресуется тем, кто еще не знаком со Scrum, или знаком лишь частично (к примеру, работает в модифицированном Scrum).
В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].
Это говорит о том, что в Scrum невозможно найти ответы на все вопросы и указания к действию во всех ситуациях (к примеру, в официальном описании Scrum лишь указана необходимость оценки времени, необходимой на выполнение работы, но не уточняется вид оценки. Т.е. это может быть и planning poker и другой способ оценки). Таким образом, само наименование топика не верно 🙂
Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии 🙂
Авторами Scrum заявлены следующие особенности:
-Легкий (англ. Lightweight)
-Понятный, доступный
-Сложный в освоении
(практически взаимоисключающие параграфы)
В классическом Scrum существует 3 базовых роли:
—Product owner
—Scrum master
—Команда разработки (Development team)
Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO — максимальное увеличение ценности разрабатываемого продукта и работы команды.
Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).
Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master — помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO
Команда разработки (Development team, DT) состоит из специалистов, производящих непосредственную работу над производимым продуктом. Согласно The Scrum Guide (документу, являющимся официальным описанием Scrum от его авторов), DT должны обладать следующими качествами и характеристиками:
-Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде, как им преобразовать Product Backlog в работающий продукт
-Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта
-За выполняемую работу отвечает вся команда, а не индивидуальные члены команды
Рекомендуемый размер команды — 7 (плюс-минус 2) человека. Согласно идеологам Scrum, команды большего размера требуют слишком больших ресурсов на коммуникации, в то время как команды меньшего размера повышают риски (за счет возможного отсутствия требуемых навыков) и уменьшают размер работы, который команда может выполнить в единицу времени. [1]
Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении всей жизни продукта.
Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog.
Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint’а.
По окончанию Sprint’а производятся Sprint Review и Sprint Retrospective, задача которых оценить эффективность (производительность) команды в прошедшем Sprint’е, спрогнозировать ожидаемую эффективность (производительность) в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ по продукту и другое.
Схематическое изображение процесса приведено на следующем рисунке: 
Важные, часто забываемые особенности
Часто можно услышать, что Scrum не работает, или работает хуже, чем ожидалось. Необходимо заметить, что чаще всего так происходит по одной из следующих причин:
1. Scrum применяется неверно или неполностью.
Согласно авторам Scrum, эмпирический опыт является главным источником достоверной информации. Необходимость полного и точного выполнения Scrum указана в The Scrum Guide и обусловлена нетипичной организацией процесса, отсутствием формального лидера и руководителя.
2. Недооценена важность работы по обеспечению мотивации команды.
Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения [2].
Таким образом, лишь небольшая часть сотрудников способно эффективно работать в Scrum без существенных изменений в ролях Scrum master и Product Owner, что противоречит идеологии Scrum, и потенциально приводит к неверному или неполному использованию Scrum.
3. Scrum применяется для продукта, требования к которому противоречат идеологии Scrum.
Scrum относится к семейству Agile, так Scrum приветствует изменения в требованиях в любой момент (Product backlog может быть изменен в любой момент). Это затрудняет использование Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла заранее планировать весь проект, ограничившись только just-in-timе планированием, т. е. Планировать только ту работу, которая должна быть выполнена в текущем Sprint. [3] Существуют и иные ограничения.
Достоинства и недостатки
Scrum обладает достаточно привлекательными достоинствами. Scrum ориентирован на клиента, адаптивен. Scrum дает клиенту возможность делать изменения в требованиях в любой момент времени (но не гарантирует того, что эти изменения будут выполнены). Возможность изменения требований привлекательна для многих заказчиков ПО.
Scrum достаточно прост в изучении, позволяет экономить время, за счет исключения не критичных активностей. Scrum позволяет получить потенциально рабочий продукт в конце каждого Sprint’а.
Scrum делает упор на самоорганизующуюся, многофункциональную команду, способную решить необходимые задачи с минимальной координацией. Это особенно привлекательно для малых компаний и стартапов, так как избавляет от необходимости от найма или обучения специализированного персонала руководителей.
Конечно, у Scrum есть и важные недостатки. Ввиду простоты и минималистичности, Scrum задает небольшое количество довольно жестких правил. Однако это вступает в конфликт с идеей клиентоориентированности в принципе, т. к. клиенту не важны внутренние правила команды разработки, особено если они ограничивают клиента. К примеру, в случае необходимости, по решению клиента Sprint backlog может быть изменен, не смотря на явное противоречие с правилами Scrum.
Проблема является большей, чем кажется. Т.к. Scrum относится к семейству Agile, в Scrum не принято, к примеру, создание плана коммуникаций и реагирования на риски. [3] Таким образом, делая сложным или невозможным формальное (юридическое или административное) противодействие нарушениям правил Scrum.
Другой слабой особенностью Scrum является упор на самоорганизующуюся, многофункциональную команду. При кажущемся снижении затрат на координацию команды, это приводит к повышению затрат на отбор персонала, его мотивацию, обучение. При определенных условиях рынка труда, формирование полноценной, эффективной Scrum команды может быть невозможным.
Помимо Scrum, я рекомендую обратить внимание на Канбан. В этом видео я сделал небольшой обзор метода Канбан:
Список использованных источников
[1] The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
[2] Психология управления, учебное пособие. (А. А. Трусь)
[3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)
Заранее благодарю за указанные ошибки и неточности!
Что такое scrum, как его реализуют и для чего применяют
Создайте рассылку в конструкторе за 15 минут. Отправляйте до 1500 писем в месяц бесплатно.
Отправить рассылку
Scrum — это набор принципов и инструментов, которые чаще всего применяют в IT-разработке. С их помощью разработчик может сделать работоспособный продукт в ограниченные по длительности итерации, именуемые спринтами. Возможности продукта определяют при планировании спринта. Краткосрочность итераций обеспечивает предсказуемость разработки и одновременно гибкость процесса.
Scrum как часть agile
Scrum (скрам) относят к agile-подходам. Такие подходы часто называют фреймворками. Их суть состоит в использовании набора инструментов для ускоренной разработки. Проще говоря, фреймворк — это каркас, состоящий из множества типовых шаблонов (библиотек), которые можно дорабатывать. При создании продукта по принципам scrum разработчик не тратит время на создание элементарных вещей и может сосредоточиться на уникальных задачах.
Представьте, что бригаде рабочих нужно построить дом. Для строительства нужно много разнообразных материалов: кирпич, арматура, балки, кровля и прочее. Если вести все работы с нуля, то рабочим придётся самостоятельно делать кирпичи, отливать арматуру и создавать другие стройматериалы. Это долго и сложно.
Вместо этого строители используют готовые материалы и строят каркас: фундамент, стены, крышу. Получился почти готовый дом. На этапе чистовой отделки рабочие уже могут экспериментировать, чтобы создать готовый уникальный продукт.
Согласно айджал-философии, при реализации проекта не стоит руководствоваться исключительно утверждёнными планами. Необходимо ориентироваться на изменяющиеся условия окружающей среды, учитывать обратную связь от заинтересованных лиц. Такие принципы мотивируют разработчиков к поиску уникальных решений, не ограниченных жёсткими стандартами.
Вместе с тем scrum и agile — не синонимы. Под agile подразумевают образ мышления, когда вся команда меняет своё отношение к созданию итоговой ценности. Достичь подобных изменений в короткие сроки не получится. Однако можно внедрить scrum, использующий основополагающие аджайл-принципы.
В основе scrum-структуры — непрекращающееся обучение и готовность приспосабливаться к изменяющимся факторам: в самом начале команда ничего не знает, но в процессе она развивается и применяет полученный опыт.
Важно понимать, scrum — это не пошаговый метод. Он не описывает, как именно нужно работать и какие решения принимать. Какие-то пошаговые инструкции в скрам отсутствуют. Взамен этого метод дает комплекс базовых рекомендаций по организации процесса.
Scrum — это фреймворк. Он определяет порядок организации процессов, однако предполагает уникальное содержание для всякого отдельного проекта. То есть изначально команда не знает, что будет делать, но знает, как это сделать.
Как работает scrum
Как методология управления проектами, scrum предполагает, что самоорганизованная команда представляет законченный продукт в фиксированный временной отрезок (спринт). Для успешного применения scrum, необходимо разобраться в его структуре. Она включает правила, роли, события и артефакты.
Главное правило: scrum строится по принципу «3-5-3»: 3 роли, 5 событий, 3 артефакта. Если хоть один из этих элементов отсутствует, то технологию нельзя назвать scrum.
Роли scrum
Scrum-команду образуют владелец продукта, команда разработчиков и scrum-мастер. При этом разработчиками выступают маркетологи, программисты, верстальщики и иные специалисты, что зависит от потребностей разработки.
Владелец продукта
Он ответственен за общий список задач (бэклог продукта). Владелец продукта scrum (scrum Product Owner) обязан определить приоритетность задач.
Остальные члены команды высказывают своё мнение. Но именно владелец продукта устанавливает ценность конкретной задачи и принимает решение, которое способны реализовать разработчики.
Владелец обеспечивает согласованность команды. Он постоянно на связи с разработчиками. Он отслеживает процесс, советует и контролирует соответствие решению.
Владелец продукта взаимодействует с заказчиками и заинтересованными лицами, собирает информацию, определяет требования. Он должен обеспечить команде условия, при которых она сможет создать максимальную ценность. Владелец в scrum бывает лишь один, поскольку разносторонние указания вносят хаос в работу.
Команда разработчиков
Команда scrum отвечает за исполнение работ из бэклога спринта. Без согласия скрам-команды никто абсолютно не вправе заносить поправки в бэклог.
Правильная команда в scrum самостоятельно определяет, как именно работать, какие конкретные работы проводить в пределах спринта, как повысить ценность. Любой из участников располагает собственными навыками, при этом все друг друга обучают и делятся рабочими нюансами. Это позволяет не нарушить процесс из-за чьей-то ошибки или несостоятельности.
Scrum-команда общается с владельцем продукта для совместного достижения поставленных целей. Но команда сама разрабатывает план каждой итерации и прогнозирует объём работ, учитывая прошлые спринты.
Scrum-мастер
Scrum-мастер — это наставник, тренер, организатор и дипломат. Он умеет быстро устранять возникающие препятствия, составляет список всех необходимых ресурсов, старается обеспечить максимальную продуктивность команды.
Вернёмся к примеру со строительной бригадой. В роли владельца продукта выступает подрядчик. Он напрямую взаимодействует с заказчиком, формулирует и ставит задачи. Команда — это строители, работающие над проектом. Scrum-мастером будет прораб, который руководит бригадой, обсуждает работы с владельцем продукта и направляет команду в нужном направлении.
События scrum
Основой scrum выступают спринты — чёткий ритм работы команды. Продолжительность спринта варьируется — как правило, от одной до четырёх недель. Любые scrum-события связаны со спринтом.
Организация бэклога
За данное событие в скрам отвечает владелец продукта. Он следит, чтобы продукт соответствовал требованиям, отслеживает рыночную ситуацию, уточняет потребности заказчика.
Владелец ведёт учёт задач, определяет приоритеты, обеспечивает актуальность собранной информации. Это позволяет команде в любое время начать реализацию уточнённых задач.
В процессе организации бэклога владелец фиксирует все сведения, собранные о продукте и требованиях к нему. Затем на основе анализа собранной информации составляют техническое задание. Оно состоит из списка задач, выстроенных по уровню приоритетности.
Совместно с командой и scrum-мастером раз в спринт проходит груминг бэклога. Это встреча, на которой бэклог актуализируют, дополняют новыми вопросами и задачами.
Планирование спринта
Команда разработчиков совместно со scrum-мастером планирует на общем собрании объём работ для предстоящего спринта и устанавливает цели.
Команда решает, какие задачи можно сделать в рамках спринта. По окончанию собрания участники понимают, что можно сделать за одну итерацию и как это реализовать.
Ежедневное совещание (стендап)
Краткосрочное совещание, максимум до 15 минут, проводят ежедневно. Обычно в начале рабочего дня команда подводит итоги выполненных работ, обменивается мнениями, уточняет неясные моменты. Каждый участник получает свой рабочий план на период до очередного стендапа.
Обычно участники стендапа рассказывают:
На ежедневных коротких скрам-совещаниях участники рассказывают, что им мешает в успешном достижении поставленной цели.
Обзор итогов спринта
По окончании спринта вся команда совместно просматривает и изучает результат (инкремент). Разработчики демонстрируют продукт заинтересованным лицам. Владелец продукта определяет, возможно ли запускать созданный продукт.
На основе обзора владелец дорабатывает бэклог продукта и это может стать началом планирования последующего спринта. Без проведения обзоров работа над продуктом будет вестись «вслепую» — без учёта мнения заказчиков.
Ретроспектива спринта
Это scrum-мероприятие предназначено для обзора завершённых этапов. Команда записывает результаты, обсуждает нюансы спринта и сопутствующих процессов.
Задача ретроспективы в scrum — привлечь внимание команды к тому, что получилось и что можно попытаться улучшить в следующий раз. При этом событие не имеет цели акцентировать ошибки.
Все перечисленные события происходят в течение одного спринта. После определения длительности итерации менять сроки разработки нельзя. Такой подход помогает команде использовать ценный опыт из прошлого спринта и учитывать сделанные выводы в будущем.
Посмотрим, как будут выглядеть мероприятия у нашей бригады строителей, которая работает по scrum:
Организация бэклога — подрядчик составляет перечень работ, которые нужно сделать и определяет их приоритетность. Например, в такой очерёдности — строительство фундамента, кладка стен, устройство крыши и прочее.
Планирование спринта — строители вместе с прорабом определяют, за какой срок можно закончить конкретную работу, что должно получится в итоге и как будут вестись работы.
Стендап — ежедневно по утрам строители обсуждают, что уже сделано и что нужно сделать. Прораб выдаёт разнарядку на день каждому рабочему.
Обзор итогов спринта — бригада демонстрирует результат завершённого этапа. К примеру, показывает подрядчику готовый фундамент. Одновременно можно обсудить вопрос о нюансах строительства стен (планирование очередного спринта).
Ретроспектива спринта — строители обсуждают оконченный этап работы: что получилось хорошо, а что плохо, какие ошибки возникали и как их можно было избежать.
Далее бригада переходит к осуществлению следующего этапа работ (последующий спринт) и порядок мероприятий повторяется. И так до полного завершения строительства и передачи готового дома заказчику.
Артефакты scrum
Артефакты scrum — это работы, которые надлежит сделать для завершения спринта. Они обеспечивают прозрачность проекта для всех участников.
Бэклог продукта
Это основной перечень всех запланированных работ. Его ведёт владелец. Список постоянно видоизменяют — меняют требования, добавляют улучшения. Руководствуясь списком, можно определить конкретные задачи.
Владелец продукта всё время работает над бэклогом, пересматривает приоритеты и перепроверяет актуальность. Если этого не делать, то из-за рыночных изменений либо новой информации некоторые задачи могут стать неактуальными.
Бэклог спринта
В состав этого скрам-артефакта включены рабочие задачи, реализуемые в рамках спринта.
Бэклог спринта не обязательно фиксировать, он может меняться в процессе. Но никакие препятствия или изменения не должны помешать достижению поставленной цели — результату, который команда хочет получить в итоге.
Инкремент
Это цель спринта. Часто под инкрементом подразумевают критерии готовности. Причём это может относиться к определённой контрольной точке, цели отдельного спринта либо полноценной версии продукта, готовой к использованию.
Ну и снова наша scrum-бригада строителей. Разберём, как будут выглядеть артефакты в данном случае:
Бэклог продукта — перечень всех работ, которые нужно выполнить для строительства дома.
Бэклог спринта — отдельный этап работ, разбитый на стадии. К примеру, чтобы завершить этап подготовки фундамента нужно выкопать траншею, выложить подушку, установить арматуру, залить бетон. Бригада примерно знает, сколько это займёт времени. Но в случае непредвиденных обстоятельств сроки можно изменить. Главное — достичь цели — сделать фундамент.
Инкремент — цель определённого этапа. Например, на этапе кладки стен инкрементом будут готовые стены. При этом критериями готовности могут служить такие параметры, как соответствие заданным размерам, отсутствие кривизны, наличие необходимых проёмов.
Как применять scrum удалённым командам
Если продукт разрабатывает удалённая команда, то ведение проекта по scrum можно организовать в специальных сервисах. Например, Scrum-доска Jira от Atlassian позволяет объединить все данные по проекту.
Такая доска отображает прогресс во время цикла разработки. Любой участник команды может в любое время получить доступ к доске. Для организации спринта нужно заполнить бэклог проекта.
Например, так может выглядеть скрам-доска в Atlassian — список задач с указанием исполнителя и срока исполнения и несколько столбцов со статусом задач:
Область применения scrum
Изначально scrum был разработан для сферы разработки программного обеспечения. Но постепенно фреймворк распространился и на другие области. Например, скрам используют в исследованиях, бизнесе, образовании, маркетинге. С начала 90-х гг. scrum активно применяют для таких целей, как:
Например, scrum можно применять для создания email-рассылки. Команда разработчиков будет включать маркетолога, копирайтера, редактора, дизайнера, верстальщика. Владельцем продукта может выступить email-маркетолог. При наличии необходимых знаний редактор может представлять scrum-мастера. Процесс создания рассылки можно поделить на несколько этапов (спринтов). Например:
Создание и запуск рассылки.
Доработка писем с учётом реакции аудитории.
Улучшение конверсии рассылки.
В конце каждого спринта будет готов полноценный продукт — рассылка, готовая к запуску. Но при этом письма дорабатывают: улучшают оформление текста, совершенствуют верстку email-письма, меняют содержание, добавляют или убирают различные элементы. И так до достижения конечной цели scrum-проекта — создания эффективной рассылки с высокими показателями конверсии.
Scrum применим в сферах, которые связаны со сложными продуктами, неопределённостью, стабильной изменчивостью.
Преимущественно scrum-фреймворки практикуют в разработке программного обеспечения. Однако принципы использования технологии удобно применять к командной работе любого направления. Это и обуславливает популярность scrum.