Самая известная книга, посвящённая теме, в русском переводе известна под названием «Scrum. Революционный метод управления проектами», что содержит определение, которое нередко вызывает критику. В оригинале подзаголовок другой: «Искусство делать в два раза больше работы в два раза быстрее». Здесь Scrum не называется методом, и речь не идёт об управлении проектами. Однако и такой вариант трактовки в более широком контексте тоже оправдан. Особенно если рассматривается не узкая сфера разработки программного обеспечения (ПО), а подход, лежащий в основе фреймворка, который легко распространяется почти на любой вид коллективной деятельности.

Scrum: трудности перевода

Scrum (по-русски произносится «скрам») – термин, который в регби означает фигуру, создаваемую игроками в процессе игры, а в бизнесе придумывался авторами Джеффом Сазерлендом (Jeff Sutherland) и Кеном Швабером (Ken Schwaber) как каркас эффективного процесса разработки ПО. В официальном описании Scrum нет указаний к действию в любой ситуации, и некоторые вопросы остаются без ответов (например, здесь указывается необходимость оценки отводимого на процесс рабочего времени, но не определяется вид оценки). Поэтому говорить о Scrum как об исчерпывающей методологии в классическом понимании слова нужно с осторожностью.

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

Универсальная схема Scrum

Управление продуктом в Scrum складывается из нескольких универсальных для каждого контекста шагов.

1. Выбирается «Владелец продукта» – человек, который становится связующим звеном между рынком (заказчиком продукта или конечным потребителем) и командой исполнителей. Этот человек отвечает за увеличение ценности продукта и со старта видит общий замысел.
2. Собирается команда исполнителей, компетентность которой должна сочетаться с умением согласованно работать.
3. Определяется Scrum-мастер. Здесь мастер – это администратор, следящий за ходом работы в команде, но не командующий, а помогающий в обучении, обеспечивающий плановое проведение собраний и т. д.
4. Создаётся список требований к цели и продукту с расстановкой пунктов по приоритету. Этот список меняется по ходу развития проекта.
5. Участники команды оценивают каждый пункт списка, решая сколько временных и материальных ресурсов потребуется для реализации задачи.
6. Владелец продукта, мастер и участники команды проводят собрание, где в совместном обсуждении планируется спринт – короткий (не больше месяца в практике разработчиков ПО) этап, на который планируется решение определённой части задач. В некоторых контекстах такой этап называют итерацией. Предполагается, что в течение каждого спринта-итерации команда нарабатывает определённое количество баллов, которое в следующем спринте желательно увеличить, чтобы продемонстрировать рост производительности.
7. Для информирования всех участников процесса создаётся информационная доска, заполняемая стикерами, с разделением на то, что нужно сделать, что находится в работе, и что сделано. По мере выполнения задач, стикера перемещаются из одной колонки в другую.
8. Короткие общие собрания проводятся ежедневно. На них озвучиваются препятствия на пути, определяется уже сделанное для пользы проекта и запланированное.
9. Каждый спринт заканчивается детальным обзором результатов работы и, что не менее важно, обсуждением характеристик процесса в прошедшем спринте. Если можно что-то улучшить, то обговариваются направленные на оптимизацию нововведения, которые будут внедрены в следующем спринте.

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

• философии Scrum, которая со временем включила в себя ценности и принципы манифеста Agile (авторы методологии были в числе 17 авторов, подписавших знаменитый манифест),
• требований в заданном формате,
• определённого алгоритма действий с распределением ролей в команде,
• особого типа рабочих отношений,
• специфического понимания отдельного рабочего этапа,
• инструментария, подходящего для этой методологии.

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

Философская основа Scrum

Управление продуктом в Scrum на идеологическом уровне – это следование определённому образу жизни и образу деятельности. Автор книги о методе Scrum увлекался японскими боевыми искусствами и это увлечение отразилось на отношении к своей работе, которая перестала быть просто зарабатыванием денег. Работа в стиле Scrum (как и айкидо) – это способ постоянного совершенствования через практику стремящихся к единству тела и разума.

Идеологические основы Scrum позднее были более чётко выражены в манифесте Agile. В нём были перечислены 4 ценности и 12 принципов, которым призывали следовать авторы манифеста. На первое место в системе ценностей ставились:

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

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

Предполагалось, что если практика на каждом этапе вносит свои коррективы, и это делает продукт лучше и ценнее, а потребителей – счастливее, то эта практика лучше жёсткого планирования. Подход Agile объединил в одно семейство модели, в основе которых лежали сформулированные ценности. Частью такого семейства моделей был и остаётся Scrum.

Роли в Scrum

Scrum подход предполагает распределение трёх ролей между участниками проекта.

1. Product owner . Этого человека называют «владельцем продукта» поскольку он становится единственным, кто принимает окончательное решение (поэтому эта роль, как правило, не перепоручается группе лиц). Он же ведёт проект в целом и занимается увеличением ценности продукта для рынка (заказчика), которого представляет. Исполнитель этой роли должен поставить задачи команде на спринт, но не ставит задачи конкретному исполнителю. То есть, Product owner – руководит продуктом, а не командой.
2. Scrum Master . Роль мастера тоже не предполагает возможность постановки задач конкретному исполнителю, поскольку команда, следуя принципам подхода, должна проявлять себя как самоорганизующийся и самоуправляемый организм. Его роль в работе ближе к роли администратора:
3. Team . Scrum команда в такой модели кроссфункциональна и самоуправляема. Нет специального человека, который бы организовывал её работу. Применительно к сфере разработки ПО, команды, как правило, складываются из 5-9 человек (в среднем – семи) специалистов разного профиля (аналитиков, разработчиков, тестировщиков). Несмотря на разнообразие специалистов внутри команды, Team действует как единой целое, и результаты её деятельности тоже оцениваются как результат общей работы.

В других сферах бизнес-деятельности, перенявших модель Скрам, стараются сохранить этот количественных стандарт, поскольку большему коллективу сложно самоорганизоваться и функционировать эффективно. Недаром в знаменитой игре Что? Где? Когда? её автор, В. Ворошилов, придумывая правила, остановился на шестёрке знатоков, как на самой эффективной функциональной коллективной единице.

В случае масштабирования при решении очень трудоёмких многоплановых задач, число людей в команде Скрам всё равно стараются не увеличивать, а для работы организовывают систему из нескольких команд. Помимо прочего, это объясняется и «законом Брукса», согласно которому, если коллектив не успевает вовремя закончить проект, то добавление числа исполнителей задерживает проект ещё больше.

Характеристика этапов работы

Работа над проектом и распределение времени предполагает фазы планирования, спринтов и подведения итогов спринта.

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

Список скрам-артефактов включает 4 инструмента:

Все этапы, процессы (ритуалы) и технология применения инструментов важны для жизнеспособности модели. Управление проектами Scrum даёт максимальный эффект при комплексном и системном внедрении всех составляющих.

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

Что такое Scrum методология? Как ее применять в разработке и не только? Почему гибкость не всегда хороша?

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

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

Что такое Scrum

Scrum – гибкая методология разработки или гибкий управленческий фреймворк (т.е. структура) с акцентом на качество процессов.

Суть методологии сводится к тому, что создание продукта делится на определенные части. На выполнение таких частей отводится кусок времени или спринт (обычно 2 недели). В конце каждого такого спринта необходимо проводить демонстрацию завершенного куска. Рисунок выше, это просто общий принцип процессов. Давайте разберем более подробно.

Как работает Scrum

Как Scrum устроен на самом деле смотрите ниже.

Пока это выглядит как китайская грамота, поэтому предлагаю посмотреть на отдельные части и разобрать каждый элемент структуры. Очень рекомендую книгу Бориса Вольфсана “Гибкие методологии” именно она легла в основу данного материала (часть картинок оттуда).

Структура Scrum

Давайте посмотрим из каких элементов состоит Scrum.

Роли

• Владелец продукта (product owner/manager). Ставит задачу, определяет приоритеты по задачам, взаимодействует с заказчиком.
• Скрам-мастер – человек, который отвечает за процессы внутри команды, координирует работу, следит за внутренней атмосферой. Планирует спринт, организует скрам митинг, участвует в демонстрации результатов в конце каждого спринта.

Скрам митинг – ежедневная планерка, летучка, где разбирается ход работы спринта. Что сделали, есть ли проблемы, что планируется сделать. Не более 15 минут на собрание. Все участники команды должны высказаться. Скрам-мастер следит за таймингом и выступлением каждого.

• Команда – 7±2 человек, которые реализуют требования владельца продукта.

Артефакты

• Беклог продукта. Список требований с расставленными приоритетами и трудозатратами.
• Беклог спринта. Часть беклога спринта, то есть несколько задач, которые реально уместить в один спринт.
• Инкремент продукта. Готовая часть продукта для демонстрации. В digital проектах, это может быть функциональность. К примеру, рабочая форма регистрации на сайте, которую можно показать.

Процессы

• Планирование спринта. Команда со скрам-мастером планирует план работ на будущий спринт, то есть составляет беклог спринта (список) задач.
• Обзор спринта. Демонстрация инкремента продукта после каждого спринта. Команда показывает рабочую функциональность владельцу продукта (и заказчику по запросу), а тот, в свою очередь, вносит изменения в требования, если они необходимы.
• Ретроспектива. Обзор прошедшего спринта с целью улучшения процессов. Команда, скрам-мастер и владелец продукта обсуждают прошедший спринт, делают выводы, думают над тем, что можно было бы улучшить.
• Скрам митинг. (см.определение выше в блоке “Роли”)
• Спринт. Как правило двухнедельный этап времени, в течении которого команда успевает разработать готовый для демонстрации функционал.

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал . Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

Пример Scrum

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

Мы считаем, что сервис будет базироваться на сайте. Пользователь регистрируется, оставляет заявку и ему перезванивает оператор, который уточняет детали и договаривается об удобном для клиента времени. Для разработки сайта мы хотим применить Scrum.

Выбираем, для примера, важную задачу или историю пользователя (user story) в рамках создания сайта: “Регистрация клиента/пользователя”. И раскладываем ее на более мелкие части. Формируем беклог продукта.

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

На практике, историй пользователя (типа “Регистрация пользователя”) гораздо больше. Сервис/продукт может включать множество таких историй, поэтому приоритезация строится сверху вниз, слева направо. В верхней левой части располагаются самые важные user story (Активность) и самые важные задачи.

Для отображения беклога задач используются обычные стикеры, доска (иногда даже стена). Вот как это может выглядеть.

Понятно, что управлять такой “махиной” в реальном времени просто невозможно, поэтому для удобства работы, вся эта стена переезжает в специальный софт/программу (Jira, Trello, Redmine и прочие трекеры управления проектами). Там вы можете назначать ответственных за задачи и исполнителей, изменять статусы задач и прочее.

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

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

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

После 2-х недельного спринта скрам-мастер и команда проводит демонстрацию функционала. В нашем примере, мы успели сделать форму регистрации и показываем ее владельцу продукта. Он смотрит и вносит корректировки, если требуется. После принятия работы переходим к следующему спринту.

Ретроспектива: анализ спринта

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

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

Как расставлять приоритеты

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

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

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

Оценка историй пользователей внутри беклога

Мы сформировали беклог, но как оценить истории пользователя с точки зрения сложности? Для этого используется метод эталона. Это относительная оценка, которая позволяет понять потенциал команды и приблизительно оценить ресурсы.

Мы берем одну user story из беклога за образец и присваиваем ей ценность единицу (story point). Дальше оцениваем другие истории пользователя с точки зрения выбранной.

Например, в нашем сервисе есть история пользователя “Регистрация пользователя”. Мы берем ее за образец и даем ценность в один бал или один story point (так его называют в гибких методологиях). Каждый участник команды пишет свою оценку к остальным историям пользователя в списке с учетом задачи, которую взяли за образец и отдает ее скрам-мастеру.

В примере выше “Фото галерея с довольными клиентами” стоит 0,5 story point, то есть по сложности она в 2 раза меньше нашей эталонной истории “Регистрация пользователя”. Все оценки участники команды ставят анонимно, можно на стикерах писать и переворачивать.

Когда все проставили оценки, результаты открываются. Скрам-мастер организует обсуждение между участниками, которые поставили самые крайние оценки. На рисунке выше, это 2 и 8. Они договариваются между собой и запускается второй раунд голосования.

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

Далее с учетом приоритетов задачи набираются в спринты и начинается работа. По итогам завершенных спринтов становится понятно, сколько story point-ов приблизительно может выполнить команда. А в процессе разбора (ретроспективы) после могут найтись точки роста.

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

Можно ли применять Scrum не только в разработке

И да и нет. До того, как я начал понимать, что означают эти 5 букв (Scrum), часть принципов уже использовал в работе. Планирование, с помощью различных инструментов и выстраивание своего так называемого “спринта задач” уже было.

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

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

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

Когда применять Scrum

В основном в небольших проектах и старт-апах. Можно и в больших, типа Mail.ru, но там должна быть определенная свобода действий и отдельные функциональные команды со своим владельцем продукта. Не забывайте, что Scrum про гибкость и изменения. Команды не должны быть больше 7±2 человек, иначе невозможно будет эффективно организовать коммуникации.

Нюансы

Если вы решили внедрить Scrum у себя в проектах, то учитываете следующие нюансы:

• Нет ориентации на клиента. Не все заказчики будут готовы к определенным стандартам Scrum.
• Не учитывается система реагирования на риски. Команда может заложить какое-то доп.время на выполнение задач, но при сильных отклонениях от плана, система встанет.
• Команда и человеческие качества. Так как упор сделан на самоорганизующуюся команду, то все участники должны обладать высоким уровнем ответственности и соответствующей мотивацией. Создание такой команды, очень сложная задача.
• Скрам-мастер. Человек отвечающий за процессы и мотивацию команды, должен чувствовать всех участников и связи внутри группы. Это редкий специалист, которого также тяжело найти на рынке.

Завершим

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

Что такое Scrum. Суть методики

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

Методика Scrum, которую разработали Джефф Сазерленд и Кен Швабер, призвана решить все эти проблемы. Scrum — это противоположность классическому поэтапному подходу, применяемому к реализации проектов. Методику Scrum взяли на вооружение многие компании как из технологических отраслей, откуда она сама родом, так и из традиционных и даже некоммерческих. Подход, лежащий в основе методики Scrum, можно применять в разных видах деятельности, в которых требуется коллективная работа.

Важными характеристиками Scrum является ее гибкость и ориентированность на клиента, так как она предполагает его (клиента) непосредственное участие в процессе работы.

Scrum не требует внедрения каких-либо дорогостоящих инструментов. Схему методики Scrum вкратце можно описать следующим образом:

1. Для начала необходимо выбрать « Владельца продукта » — человека, обладающего видением того, что вы собираетесь создать или достигнуть.

2. Затем нужно собрать « Команду » , в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь.

3. Нужно выбрать «Скрам-мастера» — того, кто будет следить за ходом реализации проекта, обеспечивать проведение коротких собраний и помогать команде устранять препятствия на пути достижения цели.

4. Приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели. Пункты этого списка должны быть расставлены по приоритету. Список носит название « Бэклог продукта » . Он может развиваться и изменяться на протяжении всего срока реализации проекта.

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

6. Затем участники, скрам-мастер и владелец продукта должны провести первое скрам-собрание , на котором они запланируют спринт — определенное время для выполнения части заданий. Продолжительность спринта не должна превышать один месяц. За каждый спринт команда нарабатывает определенное количество баллов. Команда должна постоянно стремиться к тому, чтобы превзойти в новом спринте количество наработанных баллов за предыдущий спринт, то есть ее цель — постоянно превосходить свои собственные результаты — « наращивать динамику производительности » .

7. Чтобы все участники были в курсе состояния дел нужно завести скрам-доску с тремя колонками: « Нужно сделать, или бэклог » ; « В работе » ; « Сделано » . На доску участники клеят стикеры с заданиями, которые в процессе работы поочередно перемещаются из колонки « Бэклог » в колонку « в работе » , а затем в « сделано » .

8. Ежедневно проводится скрам-собрание . По выражению Джеффа Сазерленда « это пульс всего процесса Scrum » . Суть его проста — ежедневно, на ходу, пятнадцать минут на то, чтобы все дали ответы на три вопроса: « » , « » , « » .

9. По завершении спринта команда делает его обзор — проводит встречу, на которой участники рассказывают, что сделано за спринт.

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

Недостатки традиционного подхода к управлению проектами

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

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

Почему? Как отмечает Джефф Сазерленд, Генри Гант придумал такие диаграммы еще в 1910 году. Они получили широкое распространение в Первой мировой войне. Однако, « каждый, кто изучал историю этой войны, знает, что ни подготовка кадровых ресурсов, ни система организации никогда не были ее сильными сторонами. Мне не дано понять, почему концепт времен Первой мировой войны становится-де-факто аналитическим инструментом проектирования и применяется даже в XXI веке. Мы отказались от принципов позиционной войны, но каким-то образом ее „ окопные “ организационные идеи остаются популярными и по сей день » .

В современных условиях эта схема неуместна и похожа на модель Политбюро ЦК КПСС, которое « верило » отчетам, которые оно получало накануне крушения Советского Союза и которые имели мало общего с реальным положением дел.

Философия scrum

В методике Scrum нашло свое отражение увлечение автором книги японскими боевыми искусствами. По его словам, в Японии к « Scrum не относятся как к сиюминутной причуде. Японцы расценивают Scrum как подход к решению вопросов, как образ действий, как способ существования бытия — в общем, как образ жизни. Когда я обучаю людей этой методике, я часто рассказываю о своем многолетнем опыте занятий японским боевым искусством айкидо » .

Общее у айкидо и Scrum то, что ими можно овладеть лишь в процессе работы, когда « ваше тело, ваш разум и ваш дух соединяются в единое целое через постоянную практику и стремление к совершенству. Занимаясь айкидо, мы постигаем понятие сюхари (Shu Ha Ri) — это одновременно и концепция боевых искусств, и показатель уровня мастерства » .

Суть командной работы в Scrum

Scrum — это, прежде всего, командная работа. Автор выделяет три характеристики лучших коллективов:

непрекращающийся поиск совершенства;

• автономность — способность к самоорганизации;
• многофункциональность. Наличие разных специалистов и культура взаимодействия и взаимопомощи.

Какого размера должна быть команда? Джефф Сазерленд рекомендует малочисленные группы — около семи человек. Он приводит данные, что если группа состоит из более чем девяти человек, то скорость ее работы падает.

Кроме того автор напоминает о «законе Брукса»:

« Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше » .

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

Нет мультизадачности

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

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

Суть работы — поток

Scrum помогает попасть в « поток » — состояние наивысшей концентрации, когда вы делаете то, что нужно, не затрачивая на это усилий, не заставляя себя и не подгоняя. Автор считает, что главное для успешной работы — достичь и управлять этим состоянием. « В своей работе вам нужно достичь главного — управления потоком, не требующего никаких усилий. В боевых искусствах или медитативных практиках мы достигаем чувства единения в движении, которое не требует усилий, — это энергия, беспрепятственно текущая сквозь нас. Когда вы смотрите на великих танцоров или певцов, то чувствуете, как они покоряются этой энергии. К достижению такого состояния мы должны стремиться в нашей работе » .

Как его достичь? За состоянием потока стоит внутренняя дисциплина,

« Не должно быть ни одного движения впустую » .

Скрам и счастье

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

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

Элементы скрам

Спринты

Как уже отмечалось выше, в начале спринта и для обеспечения открытости и наглядности, нужно завести специальную доску и поделить ее на три колонки: « Бэклог » ; « В работе » ; « Сделано » . Перед каждым спринтом члены команды наклеивают в колонку « Бэклог » стикеры с задачами, которые, по их мнению, они могут выполнить за спринт. В течение спринта, любой член команды, взявшись за задачу, переклеивает стикер из раздела « Бэклог » в колонку « В работе » . После выполнения задачи — в колонку « Сделано » . Таким образом, каждый видит, над чем сейчас работают другие участники.

Однако есть важное замечание — « ничто не переносится в колонку „ Сделано “ до тех пор, пока эта часть проекта не будет опробована клиентом » .

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

Ежедневные собрания

Суть в том, чтобы они проводились стоя, каждый день, в одно и то же время, их длительность не превышала пятнадцать минут и на них участники задавали одни и те же три вопроса: « Что ты делал вчера, чтобы помочь команде завершить спринт? » , « Что ты будешь делать сегодня, чтобы помочь команде завершить спринт? » , « Какие препятствия встают на пути команды? » .

Делайте до конца

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

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

Планирование в Scrum

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

Что делать потом? Каждый пункт списка нужно оценить на предмет того, сколько на его выполнение уйдет сил, времени и других ресурсов. Каким образом производить оценку? Автор предлагает шкалу относительных оценок. Например, можно сравнивать задачи « в собаках » . Эта проблема — такса или ретривер? А может быть, дог?

Но в любом случае удобнее установить числовые значения. Например, « Такса — единица; дог — тринадцать; лабрадор стал пятеркой, а бульдог — тройкой » .

Автор также предлагает использовать интересную методику покер планирования. Ее суть — каждому участнику процесса планирования дается колода карт с числами Фибоначчи — 1, 2, 3, 5, 8, 13 и так далее. Каждый пункт списка, единица работы, которая должна быть оценена, выкладывается на стол.

Требования — это истории

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

« Представьте, что вы составляете „ пожелание пользователя Amazon.com “ . Пробный вариант выглядит так: „ Мне как потребителю нужен крупнейший в мире магазин книг, где я могу купить любую книгу в любое время “ .Это описание вполне отвечает характеру Amazon, но история получилась слишком расплывчатой, чтобы с ней можно было что-то сделать. Нужно фрагментировать нашу историю. Сделать ее действительно очень конкретной и функциональной. Приведу несколько образцов пользовательских историй, которые вы можете написать, имея в виду книжный интернет-магазин :Как потребителю мне удобно искать книги по жанрам, чтобы быстро найти те, которые я люблю читать.Как потребитель я, отбирая книги для покупки, хочу класть сразу каждую в корзину.Как управляющий по выпуску новой продукции я хочу иметь возможность отслеживать покупки наших клиентов, чтобы быть в курсе, какие книги им можно предлагать.Вот профессионально сделанные пожелания пользователя, характер которых группа должна принять во внимание » .

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

Как планировать спринт

В Scrum процесс планирования происходит в начале каждого нового спринта и так и называется — « планирование спринта » . « Все собираются вместе, просматривают список пользовательских историй, которые уже стоят в очереди на выполнение; выясняют, какое количество задач может взять на себя каждый участник группы; тщательно взвешивают, смогут ли они за этот спринт довести до полной готовности отобранные задания; смогут ли продемонстрировать заказчику сделанные единицы работ и показать ему готовые функции продукта; смогут ли сами себе в конце спринта сказать, что они со всем справились » .

После этого команда дружно произносит: « Вперед! » — и принимается за работу

Но что такое работа? Рутина, обязаловка? С точки зрения скрам, работа — это история. Что это значит? Это означает, что вам следует представить человека, которому нужно то, что вы делаете; потом то, что это такое, и, наконец, зачем людям это нужно.

Командам нужно хорошо узнать свою динамику — сколько работы она может выполнить за один спринт. Это поможет ей работать разумнее и устранять все помехи на своем пути.

« Динамика x время = результат. Узнав, насколько быстро вы продвигаетесь, вы сможете понять, когда окажетесь на финише » .

Открытость во всем

Скрам предполагает прозрачность всех действий и процессов.

Это выражается в доске с тремя колонками, к которой имеют доступ все участники команды.

« Секретность — яд. Ничто не может держаться в тайне. Все должны знать всё, включая финансовые данные. Запутывание следов нужно только тем, кто ищет собственной выгоды » .

Владелец продукта

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

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

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

Минимизация рисков в скраме

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

« Методология Scrum полезна бизнесу тем, что быстро отвечает на вопрос: сможем ли мы заработать деньги, если сделаем то или иное?»

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

Аннотация: Анализируется методология Scrum, рассматриваются рабочие элементы шаблона MicrosoftVisualStudioScrum 2.2, элементы задела работы продукта, элементы работы, спринты, организация команды в методологии Scrum, жизненный цикл проекта ПО, управление работами по продукту, рабочий процесс элемента невыполненной работы, связи между рабочими элементами.

Презентацию к данной лекции Вы можете скачать .

Цель лекции:

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

Введение

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

Рабочие элементы

Рабочие элементы используются для отслеживания, наблюдения за состоянием хода разработки ПО и создания отчетов. Рабочий элемент - это запись , которая создается в Visual Studio Team Foundation Server для задания определения, назначения, приоритета и состояния элемента работы. Для шаблона MicrosoftVisualStudioScrum 2.2.определяет следующие типы рабочих элементов :

• невыполненная работа по продукту;
• ошибка;
• задача;
• препятствие;
• тестовый случай.

В методологии Scrum пользовательские требования , которые определяют функциональность продукта, задаются элементами задела работы продукта (ProductBacklogItem - PBI). Элементы задела работы продукта, которые будем называть "элементы работы - ЭР ", представляют собой краткое описание функций продукта и оформляются в произвольной форме в виде кратких заметок. Вначале задаются наиболее важные и понятные всем пользовательские требования - ЭР. Элементы работы могут детализироваться в виде задач. В процессе создания программного продукта ЭР могут уточняться, добавляться или удаляться из списка требований.

Цикл выпуска продукта в Scrum состоит из ряда итераций, которые называются спринтами . Спринт имеет фиксированную длительность, как правило, 1-4 недели. Элементы работы, включенные в очередной спринт, не подлежат изменению до его окончания. Хотя спринт завершается подготовкой работоспособного программного продукта, его текущей функциональности может быть недостаточно для оформления выпуска, имеющего ценность для заказчика. Поэтому выпуск работоспособного программного продукта, который заказчик может использовать, включает, как правило, несколько спринтов.

Организация команды

Организация команды в методологии Scrum определяет три роли :

• владелец продукта (Product owner);
• руководитель (ScrumMaster);
• члены команды (Team members).

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

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

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

• проведение ежедневных Scrum-собраний;
• привлечение сотрудников вне команды:
• стимулирование эффективного общения членов команды;
• определение размера команды.

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

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

Инструментальная и методическая поддержка гибкого подхода к созданию программных продуктов Scrum, реализованная в VisualStudio 2012, позволяет управлять жизненным циклом проекта ПО ( рис. 16.1) .

Рис. 16.1.

В начале проектирования владелец продукта и заказчик формируют концепцию программного продукта, которая показывает, для кого предназначен продукт, какие преимущества получат пользователи и какие существуют конкуренты. Концепция продукта связывается с областью проекта и ограничениями. Область проекта определяет масштаб работ , а ограничения - условия, которыми будут руководствоваться для первых спринтов и выпусков. Далее владелец продукта создает список всех потенциальных функций продукта - "Невыполненная работа по продукту" (ProductBacklog). , которую в дальнейшем будем называть невыполненная работа - НВР , содержит список элементов работы - пользовательских описаний функциональности.

Управление невыполненной работой по проекту сводится к поддержанию элементов работ в актуальном состоянии. Отдельные элементы работ списка НВР могут добавляться или удаляться в процессе создания ПО . Это является результатом того, что команда получает дополнительную информацию о новых требованиях заказчика к проектируемому программному продукту, а заказчик выясняет, как реализуются его ожидания.

Для элементов работ владелец продукта совместно с командой проекта расставляет приоритеты. При планировании спринта в него включают наиболее значимые, с точки зрения владельца продукта, пользовательские требования - ЭР, которые характеризуются наибольшей потребительской ценностью. Выбранные элементы работ перемещают в список "Незаконченная работа " (SprintBacklog). Список Незаконченная работа (НЗР) отражает состав работ планируемого спринта. Список НЗР является результатом процесса планирования спринта.

Координацией работ в спринте занимается руководитель спринта (ScrumMaster). Он организовывает процесс приоритезации задач спринта, распределения задач между членами команды. Руководитель спринта проводит собрание по планирования работ , ежедневные собрания для краткого обсуждения результатов работы и проблем, обзорные собрания в конце спринта и выпуска.

Ежедневные Scrum-собрания имеют продолжительность 15 - 30 минут. Целью таких собраний является выявление проблем, которые тормозят процесс разработки, и определить действия по их нейтрализации. Для простых проблем принимается решение по их устранению, а сложные проблемы откладываются на последующие спринты. В ходе ежедневного Scrum-собрания руководитель задает темп спринта, акцентирует команду на наиболее важных элементах списка невыполненных работ . Каждый член команды сообщает, что было сделано вчера, что будет делать сегодня и какие имеются препятствия в работе. Если на ежедневном Scrum-собрании возникают вопросы, для решения которых необходимы специалисты, которых в команде нет, тогда руководитель берет на себя анализ и возможные пути разрешения данного вопроса.

Результатом спринта является работоспособное ПО , возможно обладающее только частью необходимых функций программного продукта. Выпуск спринта может быть развернут у заинтересованных лиц для предварительного анализа соответствия ожиданиям заказчика. Результатом отзыва является формирование "Отзыв" (FeedBack), что может привести к изменения содержания списка Элемент задела работы продукта. После выполнения всех работ по программному продукту, то есть обнуления списка требований в списке Элемент задела работы продукта подготавливается финальный выпуск программного продукта.

Управление невыполненной работой

Список Невыполненная работа по продукту является одним из ключевых артефактов в методологии Scrum. Успех Scrum-команды во многом определяется качественным содержанием данного списка. Список НВР обычно включает пользовательские описания функциональности - элементы работы, а также может включать нефункциональные требования. Для создания списка НВР в TFS могут применяться различные клиентские сервисы ( рис. 16.2):

• командный обозреватель Visual Studio;
• веб-доступ черезTeam Web Access;
• Microsoft Office Excel;
• Microsoft Office Project.

Рис. 16.2.

Владелец продукта на основе требований и пожеланий клиентов формирует список функций продукта в виде элементов задела работы продукта, которые помещает в список Невыполненная работа по продукту . При создании нового элемента невыполненной работы для него устанавливается состояние "Новый" ( рис. 16.3).

Рис. 16.3.

После установки элементу работы приоритета его состояние изменяют на "Утверждено". На собрании по планированию спринта команда просматривает наиболее приоритетные элементы работы и выбирает те, которые будут выполняться в текущем спринте. Для элементов невыполненной работы, которые попали в текущий спринт, устанавливается состояние "Зафиксировано". Это означает тот факт, что рабочие элементы спринта не подлежат изменению до конца спринта. При завершении работы по элементу его состояние устанавливается "Выполнено". Если для элемента работы, находящегося в состоянии "Выполнено" выявляется дополнительная работа, то этот элемент может быть переведен в состояние "Зафиксировано". Для элемента работы, находящегося в состоянии "Зафиксировано", при возникновении проблем, препятствующих его завершению в спринте, может быть работа приостановлена и установлено состояние "Утверждено". Элемент невыполненной работы может быть удален из списка Невыполненная работа по продукту по решению Владельца продукта. Это может произойти как из состояния "Новый", так и состояния "Утверждено", что соответствует установке для элемента работы состояния "Удалено". В результате пересмотра элемента работы, имеющего состояние "Удалено", для него вновь возможен перевод в состояние "Новый".

Список Невыполненная работа по продукту является главным документом для Scrum-команды. На основе данного списка команда создает другие рабочие элементы, составляющие спринты и выпуски. Для Элементов невыполненной работы команда создает задачи и тестовые случаи. Задачи детализируют элемент работы и определяют конкретную реализацию требований пользователя. Тестовые случай необходимы для проверки соответствия функциональности кода требованиям пользователя. Если тестовый случай не проходит, то создается рабочий элемент "Ошибка". При блокировании задачи из-за невозможности её выполнения в текущем спринте создают рабочий элемент "Препятствие". Scrum- команда может создавать вспомогательные рабочие элементы (ошибки и препятствия) в отношении элементов, на которые они влияют (задачи и тестовые случаи) и связывать эти элементы ( рис. 16.4).

Рис. 16.4.

Для отслеживания хода выполнения проекта, можно создавать отчеты, отражающие наиболее важные данные для текущего проекта. В процессе создания ПО можно пользоваться стандартными отчетами или создавать собственные отчеты. Отчеты можно создавать, настраивать и просматривать с помощью Excel , Project или служб Reporting ServicesSQL Server .

Методология Scrum имеет следующие положительные стороны:

• пользователи начинают видеть систему спустя всего несколько недель и могут выявлять проблемы на ранних стадиях разработки программного продукта;
• интеграция технических компонентов происходит в ходе каждого спринта и поэтому проблемы проекта (если они возникают) выявляются практически сразу;
• в каждом спринте команда фокусируется на контроле качества;
• гибкая работа с изменениями в проекте на уровне спринта.

Ключевые термины

Что представляет собой спринт в методологии Scrum.

Какие роли определены в организации команды в методологии Scrum.

Кто отвечает за качественный выпуск программного продукта в методологии Scrum.

Поясните содержание жизненного цикл проекта ПО в методологии Scrum.

Поясните содержание рабочего процесса элемента невыполненной работы.

Поясните возможные связи между рабочими элементами.

Упражнения

1. Проведите исследование (поиск по интернету) применимости методологии Scrumдля проектирования программных систем.
2. Проанализируйте причины распространения методологии Scrum для создания эффективных программных решений.
3. Проведите исследование (поиск по интернет) программного инструментария методологии Scrum для платформ отличных от Microsoft.Net.

Scrum, наверное, самая популярная методология разработки программного обеспечения. Что же представляет собой Scrum? Это своеобразный каркас, позволяющий успешно решать проблемы разработки ПО высокой сложности и значимости. Данная методология обладает замечательной гибкостью функционала, что позволяет проводить такие тонкие настройки, что дистрибутивы программы, установленные на компьютерах разных разработчиков, могут кардинально отличаться друг от друга. Также Scrum является доступной и понятной, но одновременно сложной в глубоком освоении. Методология Scrum в используется довольно успешно уже не один год. Рассмотрим основы данной методологии.

Роли в проекте

Стандартный Scrum включает в себя три базовые роли. О них и поговорим подробнее:

• Product owner (PO). Это своеобразное связующее звено, с помощью которого происходит «общение» команды разработчиков проекта с заказчиком. Главной целью РО является повышение ценности проекта и деятельности команды в глазах заказчика. Метод достижения данной цели – Product Backlog, содержащий отсортированные в порядке важности рабочие задачи проекта (Bug, Task, Story и некоторые другие).
• Scrum master (SM). Цель, которую преследует данная роль, – помощь команде проекта в повышении эффективности ее работы. Достигается она путем устранения препятствий и проблем, возникающих в то время, когда происходит разработка проекта, а также дополнительной мотивацией персонала.
• Development team (DT). Команда разработки, которая включает в себя квалифицированных сотрудников, работающих над непосредственной реализацией проекта. Scrum Guide (руководство по работе в данной программе) рекомендует набирать в команду не более 7-8 человек. Меньшая численность команды грозит недостаточной производительностью труда. Большая – высокими расходами на поддержание коммуникации между членами команды.

Для успешной работы над проектом требуется 7-8 человек: при меньшей численности производительность труда будет недостаточна, при большей – возникают проблемы с коммуникацией.

Процесс Sprint – основа методологии

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

Перед запуском очередного Sprint осуществляется Sprint Planning, целью которого является оценка состояния Product Backlog и создание Sprint Backlog, содержащего набор задач для текущего этапа Sprint. Главной особенностью любого Sprint является наличие четко обозначенной цели, которую необходимо достигнуть за отведенный срок.

Во время работы над проектом ежедневно проводится так называемый Daily Scrum («планерка»), на котором каждый участник проекта оценивает свою вчерашнюю деятельность, а также составляет план текущего рабочего дня. Основополагающей задачей Daily Scrum является оценка статуса проекта и прогресса текущего Sprint, а также ранний мониторинг проблем, с которыми может столкнуться команда разработчиков проекта. По завершении каждого Sprint осуществляются Sprint Review и Sprint Retrospective, которые определяют степень эффективности команды в прошедшем Sprint, а также прогнозируют производительность работы над проектом в следующем Sprint.

Некоторые особенности методологии

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

• Возникающие сбои в работе Scrum зачастую просто являются результатом неверного применения функционала программы. Эта методология очень чувствительна к максимально точной организации рабочего процесса, основные принципы которой описаны в документе под названием Scrum Guide.
• Scrum должен применяться для управления проектами, требования к которым не вступают в противоречия с идеологией данной программы. Крайне не рекомендуется использование Scrum в fixed-cost или fixed-time проектах. Так, суть данной методологии подразумевает возможность внесения изменений в проект на любом этапе его разработки.
• Методология Scrum ориентирована на потребности клиента, и ее можно адаптировать к различным типам работы.
• Важной особенностью и преимуществом является возможность выдавать потенциально рабочий и функциональный продукт по завершении каждого Sprint.
• Так как Scrum является членом программной «семьи» Agile, в ее функционале не предусмотрена возможность планирования коммуникаций и реакции на риски. Это сильно препятствует и даже делает невозможным какое-либо противодействие нарушениям правил.
• Продуктивная работа в Scrum должна проводиться профессиональной и многофункциональной командой проекта, создание которой сопряжено с немалыми затратами на отбор и обучение персонала.

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