Зачем нужен Scrum и откуда он берется?

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

Подход прижился и теперь, в среднем, в каждой второй вакансии Product’a и Project Manager’a фигурирует понимание и опыт работы в Agile-среде. У разработчика об этом тоже спросят на телефонном собеседовании или при личной встрече, но в описании не указывают.

Если вы в поисках первой работы или раньше вам приходилось иметь дело с поступенчатым созданием проекта (также известен как waterfall подход), будет полезно разобраться с матчастью. Начинать стоит с Agile манифеста. Благо, он читается на одном дыхании.

Методологии гибкой разработки

Почему разработка - гибкая? Потому что система “Детальное техническое задание -> конкретный результат через N лет” конфликтует с некоторыми бизнес-моделями. Порой важно быстро запустить на рынок что-то небольшое, проверить - есть ли деньги, и только после этого продолжать. Концепция может меняться каждый месяц, так что с незыблемым ТЗ пришлось попрощаться. На смену пришел Agile, что в дословном переводе и значит - “гибкий”.

Ниже мы рассмотрим детали, но в первом знакомстве поможет таблица по сравнению трех основных способов вести разработку, которые прижились в отечественном IT.

Kanban и его доски

И, хотя сейчас есть очень много трекеров задач с интерактивным перемещением объектов, обычно с доской и колонками ассоциируется Kanban. Хотя, вообще, он - лекарство от разрывания специалистов между десятками “хотелок”.

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

Под “выполнено” мы понимаем definition of done (DoD), то есть то состояние, которое команда решила считать финалом. Например, в продакшн-среде. Или интегрирована у заказчика.

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

Теоретические выкладки и истории применения можно почерпнуть в книге “Канбан. Альтернативный путь в Agile” Дэвида Андерсона.

Scrum это...

Отцом методологии стал Джефф Сазерленд (Jeff Sutherland). Scrum в оригинальной формулировке представляет собой систему максимальной адаптации к внешним и внутренним факторам.

У Сазерленда Скрам это система работы, которая оптимально подходит для команд в семь человек (плюс-минус двое). Поэтому разработчикам-одиночкам бывает сложно подстроиться под порядок вещей на новой работе: мало того, что нужно привыкать работать с коллегами, так еще и весомая часть времени уделяется организационным моментам. Из положительного - в команде есть скрам-мастер, который помогает преодолевать трудности.

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

Еще одна роль в скрам-команде - владелец продукта или product owner (PO). Он является ответственным за согласование проекта (что делаем), ведение документации (как делаем) и приоретизацию задач (когда делаем). Это снимает с разработчика необходимость быть мишенью для заказчиков и отвлекаться на многочисленные обсуждения и переписывания технического задания. Кроме того, лучшие практики предписывают детально проработать задачу и подготовить дизайн до того, как команда станет планировать. Это существенно сокращает время на споры и застревания в процессе исполнения.

Если у вас есть время и вы любите читать истории успеха, уделите пару дней прочтению книги “Scrum” Сазерленда или его совместной работы с Кеном Швабером.

Scrumban и другие гибридные подходы

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

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

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

Как внедряют Agile в разработке

Этот подраздел можно назвать по-другому: “Что вас ждет, если процессы начнут налаживать уже после того, как вы устроились на работу?”.

Обычно из всех артефактов быстрее всего в практику входят ежедневные летучки, они же “стендапы” или daily synchs. Иногда их вводят постепенно, начиная с 1-2 раз в неделю, а потом учащают по мере привыкания и/или роста команды.

Коуч по внедрению

Тут всё понятно: приходит человек со стороны и проводит тренинг. А потом в течение нескольких недель помогает “вживить” новый фреймворк.

Плюсы: члены команды все еще разговаривают друг с другом

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

DIY

Проджект-менеджер может оказаться в ситуации, когда внедрение методологии всецело поручат ему. Предварительно полученная сертификация обычно помогает в таких ситуациях. Если ее нет, то на помощь приходят запросы типа “scrum habrahabr” и чтение того, как другие внедряли что-то подобное.

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

Минусы: нервозная атмосфера (“вот только вчера был свой парень”), отторжение (“ну давай по-старому”), разочарование (чужой опыт не всегда бывает положительным).

Особенности: менеджер - тоже человек, и практические знания пропускает через себя. Поэтому в реализации будет чувствоваться знакомая рука.

Волею начальства

В этой реализации обычно выпадает тот момент Agile-манифеста, где говорится, что “Люди и взаимодействие превыше процессов и инструментов”.

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

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

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