Согласно недавним исследованиям, около 90% зарубежных ИТ-компаний предпочитают Scrum для управления своими проектами. Среди них Microsoft, Yahoo, Google, IBM, Amazon, BBC, а также Philips, Siemens, Nokia и многие другие. О том, что из себя представляет данная методология и в чем причина ее успеха, рассказывает старший инженер по тестированию компании «Аплана» — Ксения Квакова.
Agile и Scrum в проектном управлении
Чтобы лучше понимать, что такое Scrum, как методология управления проектами, нужно начать с Agile.
Agile (с англ. «гибкий», «подвижный», «быстрый») — это система ценностей. «Внедрить» Agile нельзя, ведь ценности можно лишь предложить людям, максимум — привить их. Придерживаясь каких-то убеждений, разделяя некие принципы, можно проецировать их на любые свои действия (и на любой вид коллективной деятельности). На основе Agile развивается целый комплекс подходов, но самая распространенная практика в управлении проектами — Scrum (Скрам).
Четыре ценности и 12 принципов Agile подробно описаны в Agile-манифесте, а узнать больше об Agile можно из предыдущей статьи в блоге «Апланы» — «Agile и управление проектами».
Scrum — это фреймворк или «каркас», один из Agile-процессов, практическое воплощение его ценностей, предназначенное для разработки, поставки и поддержки сложных продуктов.
Чтобы объяснить суть подхода, создатели Scrum (и одни из создателей Agile) Кен Швабер и Джефф Сазерленд разработали «Исчерпывающее руководство по Скраму», в котором описали основные «правила игры», а затем дополняли его на протяжении более двадцати лет. Конечно, Scrum не стоит на месте, а продолжает развиваться. Но в чем же его суть? В чем причина его успеха?!
Scrum: теория и ценности
В современном мире, особенно в высококонкурентной сфере IT, скорость выпуска продукта стоит в приоритете. При этом качество не должно страдать. Scrum позволяет выпускать функциональный продукт снова и снова, через определенные временные отрезки (от двух недель до месяца), называемые спринтами. Спринт — это ядро Scrum, его главная составляющая, проект в миниатюре. Новый спринт начинается сразу после окончания предыдущего. По результатам каждого из них принимается решение: выпускать этот реально работающий программный продукт как есть, либо продолжить улучшение на следующем этапе.
Scrum использует итеративный (регулярный повтор полного цикла работы над продуктом с непрерывным анализом результатов предыдущего этапа, корректировкой требований и процесса) и инкрементальный подходы (приращение результатов предыдущего этапа), чтобы управлять рисками и улучшать прогнозируемость.
Благодаря итерационной разработке, продукт можно выпускать быстро, с высокой периодичностью, а его качество можно постоянно улучшать, внося определенные доработки и корректировки. Таким образом, работоспособная и потенциально полезная версия продукта доступна в любой момент.
Scrum компактный, простой для понимания, но трудный для совершенного овладения. Он основан на теории эмпирического управления, согласно которой источником знаний является не что иное, как опыт, а источником решений — реальные данные. Процесс эмпирического управления основан на «трех китах»: прозрачности, инспекции и адаптации.
Команда в Scrum опирается на несколько ценностей: преданность, смелость, сфокусированность, открытость и уважение.
Суть Scrum — в маленькой команде людей
Разделяя ценности, каждый участник Scrum-команды должен уважать других, быть открытым с коллегами, смел, сфокусирован на результате и предан делу. Все должны знать, что происходит в проекте, с тем чтобы помочь команде добиваться нужных результатов. В любой момент каждый может высказать свое мнение по открытым вопросам или вызваться помочь отстающему коллеге.
Scrum-команды самоорганизующиеся и кросс-функциональные. В традиционной компании программисты сидят с программистами, бухгалтеры — с бухгалтерами. В Scrum наоборот — в одной команде находятся специалисты из разных областей: разработчики, тестировщики, дизайнеры, представители бизнеса и т. д. Все несут одинаковую ответственность за продукт.
По словам создателей фреймворка, суть Scrum — в маленькой команде людей. Они поясняют это так: «Каждая отдельная команда чрезвычайно гибка и адаптивна. Эти преимущества проявляются, распространяясь на любое количество команд в организации: одну, несколько или целые сети команд, которые разрабатывают, выпускают, осуществляют эксплуатацию и поддержку продуктов, таким образом объединяя труд тысяч людей».
Обычно Scrum-команда состоит из пяти-девяти человек (не считая скрам-мастера и владельца продукта и при условии, что они не участвуют в разработке). Важно, чтобы команда оставалась гибкой и ей хватало навыков для выполнения значимой работы.
Джефф Безос — основатель компаний Amazon и Blue Origin, владелец The Washington Post и богатейший человек в мире (Forbes, 2018) — приверженец Scrum. Он сформулировал простое и очень наглядное правило: команда должна быть достаточно маленькой, чтобы ее можно было накормить двумя пиццами. «Правило двух пицц», внедренное в Amazon, идеально соотносится с философией Scrum — именно таким количеством можно накормить от четырех до восьми человек.
В Scrum сотрудники не руководят друг другом, а работают сообща. Роли и состав команды на протяжении спринта не меняются.
Роли в Скраме
В традиционном варианте Scrum можно выделить три роли: владелец продукта, скрам-мастер и команда разработки. Однако, многие идут дальше. Так появляются дополнительные роли: заказчик, бизнес-аналитик и другие.
Согласно руководству, «скрам-мастер» — это лидер-помощник для команды, который вовлекает остальных участников в процесс работы, не имея при этом формальной власти. Он также помогает понять теорию и практики Scrum, его правила и ценности. В зоне его ответственности находится наблюдение за работой, предложения по повышению продуктивности, предоставление обратной связи, устранение препятствий и пр.
Владелец продукта — это человек-промежуточное звено между заказчиком и командой разработки (может быть на той и на другой стороне). Он несет ответственность за достижение максимальной ценности продукта.
События Скрама
Scrum предполагает четыре вида формальных событий, направленных на инспекцию и адаптацию: стендап (ежедневное собрание во время спринта), планирование спринта, обзор спринта и его ретроспектива. О прозрачности и открытости тоже никто не забывает. Например, стендапы Microsoft, на которых разработчики за чашкой чая обсуждают планы на ближайшие сутки, легко найти в сети.
Scrum-мероприятия со стороны могут выглядеть как «легализация бардака», потому как команды сами определяют формат встречи. Самое главное — достигнуть поставленных целей. На стендапе участники, как правило, стоя планируют работу на ближайший день, обговаривая что было выполнено накануне, и с какими трудностями столкнулся каждый член команды. Такая встреча длится не дольше 15 минут, поэтому, чтобы не терять время, участники могут здесь же пить кофе и перекусывать.
Создатели данного метода считают, что благодаря такому подходу, такой свободе, можно быстро решать проблемы различной сложности и креативно подходить к созданию программного или любого другого продукта.