Scrum

Первые результаты

Команда была готова к работе с методологией только после того, как мы обеспечили условия для работы:

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

У команды появились ценности. Вот какие ценности мы определили:

1. Мы решаем задачи, а не пишем код.
2. Если правило мешает нам быть эффективными – мы от него отказываемся.
3. Идеальная задача выглядит как потребность, а не как требование. Мы сами решим, что и как делать, чтобы решить задачу.
4. Мы честны друг перед другом – и поэтому доверяем.
5. Каждый делает все, что от него зависит, настолько хорошо, насколько может, и с тем, что имеет в сложившейся ситуации.
6. Мы не ищем виноватых, мы ищем наилучшие пути решения проблемы.
7. Мы стараемся не повторять ошибки, мы не стесняемся их. Ошибки – это наш путь к улучшению себя и нашего продукта.
8. Нам как профессионалам доверяют задачи, а мы выбираем пути решения –­ и поэтому несем ответственность за результат, принимаясь за работу.
9. Мы не говорим «кажется/по идее/теоретически, это работает так», мы говорим – «это работает так».
10. Если нужно решить проблему, мы встаем и решаем, мы идем и спрашиваем, мы говорим о проблемах открыто – потому что не хотим впоследствии искать виноватых.

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

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

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

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

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

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

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

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

Планирование Спринта

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

Планирования Спринта члены Команды ищут ответы на следующие вопросы соответственно:

• Что будет разработано в Инкременте, являющимся результатом работы следующего Спринта?
• Как максимально эффективно выполнить работу по созданию Инкремента?

Часть первая: Что будет сделано в этом Спринте?

В этой части Команда Разработчиков пытается спланировать функциональность, которая будет разработана во время Спринта. Владелец Продукта представляет Команде Разработчиков упорядоченный Журнал Продукта и вся Скрам Команда старается достичь единого понимания работы, которую предстоит проделать на протяжении Спринта.
Входными для этой встречи являются Журнал Продукта, последний разработанный Инкремент продукта, возможности Команды Разработчиков, а также последний показатель ее продуктивности. Количество элементов из Журнала Продукта, которые Команда способна выполнить до окончания Спринта определяется самой Командой. Только Команда Разработчиков может реально оценить объем работы, который она в состоянии завершить до окончания Спринта.
После того, как Команда Разработчиков спрогнозирует элементы Журнала Продукта, которые она выполнит в данном Спринте, Скрам Команда приступает к формированию Цели Спринта. Цель Спринта – это цель, которая будет достигнута в результате Спринта благодаря реализации Журнала Продукта и которая указывает Команде Разработчиков, почему она работает именно над этим Инкрементом функциональности.

Часть вторая: Как выбранная работа будет проделана?

После того, как объем работы Спринта определен, Команда Разработчиков решает каким образом на протяжении Спринта воплотить отдельную функциональность в “готовый” Инкремент продукта. Требования Журнала Продукта, выбранные для выполнения во время ближайшего Спринта вместе с планом их разработки, называют Журналом Задач Спринта (Sprint Backlog).

Как правило, Команда Разработчиков начинает планировать систему и работу, благодаря которой Журнал Продукта можно превратить в работающий Инкремент продукта. Работа может быть разной степени трудоемкости и сложности. Однако обычно во время Планирования Спринта Команда Разработчиков планирует такой объем работы, который она в состоянии выполнить за Спринт. До окончания этой встречи работа, запланированная Командой Разработчиков на первые дни Спринта, разбивается на требования, которые можно выполнить за день или менее. Команда Разработчиков сама организовывает свою работу, планируя поэтапность выполнения требований из Журнала

Спринта как во время встречи по Планированию Спринта, так и, при необходимости, на протяжении всего Спринта.
Владелец Продукта может присутствовать на второй части Планирования Спринта, чтобы иметь возможность объяснить задания из Журнала Продукта и, при необходимости, помочь найти альтернативы. Если же Команда Разработчиков решает, что у нее слишком много, либо слишком мало работы, она может повторно обсудить требования Журнала Спринта с Владельцем Продукта. Команда может пригласить людей со стороны, чтобы они посоветовали что-то с технической или же экспертной точки зрения.
До окончания встречи по Планированию Спринта Команда Разработчиков должна быть в состоянии объяснить Владельцу Продукта и Скрам Мастеру, каким образом она собирается работать в качестве самоуправляемой команды, чтобы достичь Цели Спринта и создать ожидаемый Инкремент продукта.

Цель Спринта

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

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

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

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

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

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

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

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

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

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

Артефакты и ценности Scrum

Артефакты Scrum – это документы и материалы, созданные в ходе командной работы над проектом. Они включают в себя: 

• бэклог продукта;
• пользовательские истории, или user stories; 
• требования к качеству; 
• планы спринтов;
• и т.д. 

Артефакты помогают команде: 

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

`pc`

{{/pc}}

`mobile`

{{/mobile}}

Бэклог продукта в Scrum

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

Бэклог помогает команде определять приоритеты и планировать работу, а также отслеживать прогресс проекта.

Спринт в Scrum

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

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

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

Бэклог спринта в Scrum

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

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

Инкремент в Scrum

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

Инкременты продукта помогают Scrum команде видеть прогресс в создании продукта и оценить результаты работы.

При работе с системой Scrum важно помнить о ее основных ценностях, которые включают в себя:

Ключевые понятия в Scrum

В методологии Scrum используются следующие ключевые понятия:

• роли — основные участники разработки и управления проектом, и те, кто занимается реализацией готового продукта;

• практики — способы и техники, применяемые создателями продукта при работе над ним;

• артефакты (документы) — детализированные описания продуктов и графики достижения целей, составленные командой;

• итерации — временные отрезки, составляющие рабочий процесс;

• спринт — период от 1 до 4 недель. За эти сроки создается фрагмент продукта, ценного для пользователя. Перед запуском проектной командой планируются этапы создания релиза и формулируются требования к нему.

Роли в Scrum-методологии представлены:

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

• скрам-мастером (Scrum Master) — координатором, организующим всю деятельность разработчиков. Scrum Master  проводит совещания, ликвидирует конфликты и затруднения в рабочих процессах, контролирует выполнение всех практик, сохранность и использование Scrum-инвентаря;

• командой разработки (Development Team) — рабочей группой из 5-9 человек — программистами, тестировщиками, аналитиками, архитекторами и другими специалистами. Команда разработки проводит оценку функциональности продукта, отслеживает все процессы вместе со скрам-мастером, предоставляет готовые результаты заказчику.

Также в разработке продукта опосредованно участвуют Stakeholders (акционеры) — инициаторы работ, которым скрам-проект принесет прибыль, и Users — пользователи продукта, на которых он рассчитан.

Недостатки

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

Другие термины на «S»

SSRSQLSEOSSHSSLSaaSSDLCSassSparkSlackScalaSciPySwiftSpringSQLiteSeabornSwaggerSOAP APISeleniumSequelizeStreamlitScreencastScikit-learnSublime TextSWOT-анализSelenium WebDriverSingle Page ApplicationSqrt-декомпозицияSmoke-тестирование
Все термины

Кому стоит использовать скрам-доски?

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

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

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

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

Scrum vs Kanban: общее и отличия

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

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

1. Визуализация рабочих процессов

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

2. Ограничение работы

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

3. Управление потоком

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

4. Постоянное совершенствование

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

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

Нужно ли моей команде использовать Scrum?

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

Преимущества Scrum

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

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

Ограничения Scrum

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

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

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

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

Отслеживание стендапов в ходе проекта помогает сосредоточиться только на самом важном

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

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

Принципы Scrum и роли в команде

`pc`

{{/pc}}

`mobile`

{{/mobile}}

Методология Scrum базируется на cледующих основных принципах и ролях:

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

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

В течение спринта команда работает по Scrum над одной функцией или задачей, и каждый ее член концентрируется на достижении общей цели.
Владелец продукта, или продакт-оунер (англ. product owner). Он отвечает за определение приоритетов и постановку целей для команды. Он должен постоянно быть на связи со стейкхолдерами (представителями заказчика) и адаптировать все требования к будущему готовому продукту в соответствии с их изменениями.

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

`pc`

{{/pc}}

`mobile`

{{/mobile}}

Состав Scrum-команды включает в себя следующие роли:

Скрам-мастер (Scrum Master) 

Скрам-мастер – это один человек, который отвечает за: 

• организацию рабочего процесса;
• управление командой;
• разрешение конфликтов. 

Он должен помочь команде в:

• планировании спринтов;
• определении работы; 
• отслеживании прогресса. 

Скрам-мастер в Agile также должен обеспечивать прозрачность процесса разработки продукта и коммуникацию между всеми участниками команды и заинтересованными сторонами.

Владелец продукта (Product Owner) 

В Scrum должен быть один владелец продукта. Это человек, который отвечает за: 

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

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

• работать с бэклогом продукта;
• расставлять приоритеты задач;
• управлять рисками.

Разработчики (Developers) 

Команда разработчиков в Scrum занимается реализацией функциональности продукта в рамках спринта. Члены команды должны: 

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

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

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

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

Он должен: 

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

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

Менеджер проекта (Project Manager) 

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

• работа с бюджетом;
• определение цели и задачи проекта;
• контроль качества продукта. 

Agile и Scrum: связь и различия

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

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

Философия Agile базируется на двенадцати принципах:

• Удовлетворение потребностей заказчика в приоритете. Главное, чтобы клиент был доволен. Поэтому команда регулярно предоставляет ему промежуточные результаты работы, не дожидаясь финала проекта.
• Изменение требований допускается на всех стадиях разработки.
• Работающий продукт должен выходить как можно чаще.
• Постоянная совместная работа исполнителей и заказчиков.
• Привлечение команды профессионалов для работы над проектом.
• Живое общение внутри команды.
• Цель рабочего процесса – полностью рабочий продукт.
• Устойчивый темп работы.
• Совершенствование проекта на всех его этапах.
• Минимум лишней работы.
• Самоорганизующиеся команды.
• Стремление постоянно улучшать свои результаты.

Получается, разница в том, что фреймворк Скрам – это один из подходов семейства Agile, использующийся для реализации её принципов в практических условиях.

***

Какие компании применяют Scrum

В первом десятилетии XXI века Scrum стал самым популярным среди гибких подходов к разработке новых программных продуктов. Однако сейчас фреймворк успешно используется во многих других индустриях: в материальном производстве (например, Северсталь, SOKOLOV), в маркетинговых агентствах и дизайнерских студиях, в телеком-компаниях (Tele2, МТТ), в фармакологии (BIOCAD), в розничных сетях (X5 Retail Group, МВидео) и др.

Наиболее известные в мире кейсы внедрения Agile и Scrum — Google, Amazon, Zappos.

Например, в 2016 году у компании Северсталь появилось желание ускорить выпуск на рынок новых марок стали. Изначально этот процесс занимал в среднем 2-2,5 года и иногда к моменту появления их на рынке, они часто не находили спроса, или оказывалось что конкуренты (в частности, Китай) уже закрыли потребность рынка в этой марке стали. Компания запустила первые пилотные команды для разработки продуктов по Scrum. Они оказались успешными — срок разработки новой продукции сократился с 2,5 лет до 4 месяцев.

Другие кейсы применения Agile и Scrum в российских компаниях вы можете почитать в разделе Истории клиентов.

Артефакты и практики в Scrum

При разработке продукта по методологии Scrum для определения результата используются следующие термины:

• user story — описание продукта, основанное на пожеланиях пользователей;

• task (задание) —  задача, выполняемая для реализации проекта;

• эпик  (epic) — та или иная функция продукта, которая может быть описана в user story или task;

• story points — оценка сложности выполнения задач (применяется при разбивке проекта на три и более спринтов);

• velocity — скорость работы команды, определяемая метриками и графиками;

• definition of done — критерий готовности проекта на том или ином этапе разработки;

• sprint goal — конкретные цели, которые необходимо достичь в ходе спринта.

В любом Scrum-проекте выделяют следующие артефакты:

• журналы проекта (Product Backlog) — отсортированные по приоритетам перечни технических и функциональных требований к продукту. Составляется до начала работ владельцем продукта и дополняется командой разработчиков (по критериям выполняемости);

• журнал спринта (Sprint Backlog) — разбивка функций, выбранных для создания продукта, на отдельные задачи по фазам (итерациям). На выполнение каждой из них отводится, как правило, 1-2 дня. По каждому спринту устанавливается определенный объем работ;

• графики спринта (Burndown Chart и Burnup Chart) — диаграммы отслеживания выполнения («сгорания») задач, по оси Y которых отмечаются story points, а по оси X — количество дней спринта. При этом максимальное число story points в графиках Burndown Chart соответствует первому дню спринта, а в Burnup Chart — последнему.

В Scrum-управлении проектами используются следующие основные практики:

• ежедневные скрам-встречи (Daily Scrum Meeting) — короткие совещания команды разработки и скрам-мастера, в ходе которых выясняется, какие задачи были выполнены, и распределяется работа над новыми заданиями спринта;

• встречи по обзору спринта (Sprint Review Meeting) — открытая встреча, на которой с владельцем продукта обсуждаются плюсы и минусы наработок и демонстрируются готовые части проекта;

• аварийные остановки спринта (Sprint Abnormal Termination) — данную практику применяет владелец продукта, когда необходимость в проведении того или иного спринта отпадает. В ходе совещаний Sprint Abnormal Termination обсуждаются причины приостановки работы, возможности и порядок запуска нового спринта.

Более подробно ознакомиться с методологией Scrum и научиться ее применять на практике можно, записавшись на курсы обучения, которые проводит ЦРК БИ (ЦЕНТР РАЗВИТИЯ КОМПЕТЕНЦИЙ В БИЗНЕС-ИНФОРМАТИКЕ) НИУ ВШЭ. Запись проводится на нашем сайте.