Скрам, что это и как пользоваться?

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

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

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

На официальной странице The Scrum Guide можно почитать очень подробно, кто, как и зачем придумал Скрам, а главное, что создатели вкладывают в это понятие. Даже на украинском (!)

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

Итак, 4 особенности Скрам как методологии:

• работа над проектом разбивается на небольшие подзадачи;
• команда из 5-7 человек выполняет каждую из них в фиксированный срок (1-4 недели);
• в течение работы над одной подзадачей проводится 5 типов совещаний;
• полученный результат работы над каждой подзадачей обладает ценностью для заказчика.

Теперь подробнее про каждую из особенностей:

Sprint

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

В общем, спринт — это про конкретные задачи. Не хватало какой-то функции? Добавили. Что-то не работало? Починили. Благодаря ему удобно организовывать работу и еще удобнее следить за прогрессом проекта в целом.

Артефакты

Красивым словом «Артефакты» в Scrum называют создаваемые в процессе разработки вещи:

1. Бэклог продукта. Product Backlog — зона ответственности владельца продукта. Это список задач или, как его называет Википедия, «журнал пожеланий к проекту». Бэклог — это не что-то, что утвердили раз и навсегда, а гибкий перечень функций, улучшений, исправлений и так далее. В нем указываются актуальные задачи для команды и отмечаются те, что уже выполнены.
2. Бэклог спринта. Еще один бэклог, но поменьше и более конкретный. Это список задач на конкретный спринт, который формируется на митинге по его планированию. Он тоже может меняться, если команда столкнулась с затруднениями, и нужно сделать что-то еще, кроме того, что запланировали. Но его цель, она же цель спринта, остается неизменной.
3. Инкремент. Это как раз тот, полученный результат работы над каждой подзадачей, что обладает ценностью для заказчика. Инкрементом он называется потому, что его уже можно так или иначе добавить к остальному проекту и посмотреть, как он работает. Это не обязательно должна быть целая новая функция, вполне может быть и усовершенствование той, что уже есть, или вообще исправление ошибки. Но обязательно то, что команда должна была сделать в течение спринта. В общем, это ожидаемый (чаще всего) результат, который показывают владельцу продукта, чтобы он видел, как идет работа над его проектом.

Совещания

Scrum — штука цикличная, и цикл этот состоит из повторения разных совещаний, они же митинги:

1. Project/Product backlog. Владелец продукта приходит на первое такое совещание с самым главным артефактом проекта — подготовленным списком задач, которые нужно решить для запуска. Бэклог — это современная версия технического задания, в которой можно и нужно менять что угодно, если что-то изменилось на рынке или в предпочтениях пользователей. В нем собраны и отсортированы по приоритету все рабочие задачи (Story, Bug, Task и прочее) и в него же вносится информация о ходе выполнения работ: сделали задачу — поставили галочку. На этом митинге все просто ознакамливаются с тем, над чем им предстоит работать в целом, а вот на следующем начинают обсуждать.
2. Sprint Planning. Планирование самого спринта — обсуждение самой приоритетной задачи командой и скрам-мастером. На этом этапе выбираются истории из бэклога, которые нужно сделать для выполнения цели спринта. В конце этого совещания все участники команды должны четко понимать, что им предстоит делать.
3. Daily Standup Meeting. Каждый день все участники команды собираются в одно и то же выбранное время, чтобы рассказать, как у них дела. С задачами по проекту. Каждый в двух предложениях описывает, что он сделал вчера и что будет делать сегодня, а если столкнулся с трудностями, то еще и о них — как решил или как собирается решать. Название стендап буквально означает, что, если дело происходит в офисе, то разработчикам рекомендуется общаться стоя. Чтобы никому не хотелось болтать дольше, чем нужно. В условиях удаленной работы ежедневные митинги тоже не затягиваются — подробные обсуждения возникших проблем или появившихся идей выносятся на отдельные созвоны между заинтересованными участниками, а остальные отчитались и пошли заниматься своими делами. Потому что Скрам — это про эффективность!
4. Sprint Review. В конце спринта, когда все готово, инкремент показывают владельцу продукта, а заодно всем, кому это интересно, если опыт может быть полезен коллегам. Если все хорошо, то инкремент выпускают на прод, а в бэклог вносятся соответствующие изменения. Очень часто этот этап плавно перетекает в первый из следующего спринта.
5. Sprint Retrospective. Встреча команды для обсуждения рабочих и сопутствующих моментов. Скрам-мастер проводит аналитику спринта, все делятся мнением о том, как он прошел, а заодно об участниках команды — кто молодец, а кто не очень, а потом обсуждают, как работать лучше.

Действующие лица

В классическом Scrum существует 3 базовых роли:

1. Product owner (PO). Это вы как владелец продукта, а чаще кто-то из ваших сотрудников, кого вы сделаете ответственным за общение с командой разработки. Тот человек, который будет создавать бэклог проекта и дополнять его, слушать в конце спринта, что же там эта самая команда разработки сделала, а что нет, и что будет делать дальше. PO не обязательно должен разбираться в технологиях разработки, но обязан быть специалистом в своей отрасли. Его работа — точно знать, что должен делать готовый проект и каждая его часть, а заодно вникать в то, как идет разработка.
2. Scrum master (SM). Скрам-мастер — проджект-менеджер на максималках. Его работа, с одной стороны, помогать продукт оунеру разобраться в нюансах работы со Скрам, а с другой — организовывать работу команды. Он отвечает и за поиск кадров для команды, и за то, чтобы у них были материально-технические ресурсы, и в целом за то, чтобы все дружили и эффективно работали. Планирование и проведение всех митингов в спринте — тоже работа SM.
3. Development team (DT). Команда разработчиков — +/- 5 специалистов, которые будут заниматься работой над проектом. The Scrum Guide требует от них не только навыков для выполнения задач, но еще и быть в состоянии самим организовывать рабочие процессы, а также нести коллективную ответственность за достижение цели спринта. Команд этих может быть любое нужное вашему проекту количество, но они должны состоять из специалистов в определенных технологиях и быть небольшими, чтобы избежать проблем с коммуникацией. А коммуницировать нужно будет много, иначе как научиться самоорганизовываться, работать вместе, брать ответственность, анализировать успехи и неудачи и делать другие вещи, постулируемые методологией Скрам? В общем, для работы в командах Scrum мало быть хорошим техническим специалистом, нужны еще и soft skills выше среднего.

1. Гибкость. Scrum — просто идеальная система управления проектами, которые растут и масштабируются, а это буквально любое мобильное или веб-приложение, и даже сайты. Сегодня вы добавили новую функцию, посмотрели, как она работает, и уже в следующем спринте можете начать ее совершенствовать, менять или убрать! И это актуально не только для MVP, для которых каждая функция новая, но и для проектов, которым уже несколько лет, и они постоянно тестируют гипотезы, чтобы стать лучше.
2. Видимые результаты. Итог каждого спринта — что-то «реальное». Новая функция или исправление ошибки, не так важно, как возможность видеть, что работа идет, и идет успешно. Именно за это, кроме возможности менять бэклог, когда им хочется, и любят Scrum владельцы продуктов. Участникам команды это тоже очень важно, так как условно «закрывает гештальт», дает возможность почувствовать удовлетворение от проделанной работы.
3. Мотивация. Хотеть следовать принципам Agile и делать это на самом деле — две большие разницы. Знаете, сколько людей способны на самоорганизацию? 15%, в лучшем случае! А сколько готовы согласиться на коллективную ответственность? А скольким нравятся «бесполезные» совещания? Работа со всем этим и есть та самая «сложность в освоении». Только от скрам-мастера зависит, будет ли Scrum работать для команды. Сделать так, чтобы взрослые и умные дяди и тети если не дружили, то уважали друг друга, и понимали важность совместной работы, может быть очень сложно. И хотя, с одной стороны, вас как заказчика не должно волновать, как там ваш подрядчик свои дела решает. С другой, рекомендую все-таки обратить на это внимание, если вам не хочется в один не прекрасный день остаться без самой важной для проекта команды. А, ну и будьте готовы, что и вам придется готовиться к этим совещаниям раз в две недели.
4. Несоответствие цели и инструмента. Scrum безусловно хорош для многих задач, даже не связанных с разработкой. Но, при этом, все методологии семейства Agile объединяет не просто терпимость, а прямо-таки любовь к изменениям. Если вашему проекту заявленная гибкость ни к чему, и вы уверены, что точно знаете, как должен выглядеть проект от начала и до конца, лучше выбрать классическое проектное управление, что будет значительно эффективнее.
    

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

Главные принципы Scrum — ясность коммуникации, прозрачность и стремление к постоянному совершенствованию.