Scrum: современное и гибкое гибкое управление проектами

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

Скрам появился еще в 80-х годах прошлого века, но в своем нынешнем виде он существует с 1995 года. Именно тогда Кен Швабер и Джефф Сазерленд объединили усилия и опубликовали документ «Руководство по Scrum». Они хотели сделать работу более продуктивной и в то же время ввести как можно меньше правил, чтобы не ограничивать творчество.

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

Что касается работы в Scrum, есть два ключевых слова, которые играют очень важную роль:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Элементы, играющие важную роль в Scrum, называются артефактами. К ним относятся бэклоги продуктов, бэклоги спринтов и завершенные инкременты.

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

Работа над бэклогом продукта ведется постоянно. Список управляется динамично — в него постоянно включаются новые идеи, записи сильно разграничиваются, добавляются новые задачи, а сортировка адаптируется. На начальном этапе владельцу продукта обычно помогает Scrum-мастер. Мастер по опыту знает, как сформулировать документ, чтобы он был максимально прозрачным и эффективным. Записи, как правило, должны быть ориентированы на клиента. Помимо описания требуемой функции, документ также содержит заметку об объеме работы и запись об уровне приоритета.

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

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

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

• Коммуникация: Хорошее управление проектом может функционировать только тогда, когда все участники команды находятся на одном уровне. Scrum уделяет большое внимание общению в команде. Поэтому существует относительно большое количество мероприятий. Ежедневное собрание в начале рабочего дня позволяет убедиться, что ни один разработчик не работает мимо других. Любые проблемы в команде решаются на заключительной ретроспективе.
• Гибкость: Scrum используется для относительно коротких спринтов. Поскольку между двумя встречами по планированию проходит не более одного месяца, проект может быть изменен в кратчайшие сроки и адаптирован к любым новым требованиям.
• Прозрачность: Постоянное общение всех членов команды и система артефактов Scrum обеспечивают высокую прозрачность. Бэклоги формулируются таким образом, чтобы каждый мог легко ориентироваться в них и находить любую необходимую информацию.
• Контроль качества: Итеративный принцип Scrum обеспечивает непрерывный контроль продукта. Исправления ошибок являются такой же частью бэклога продукта, как и дальнейшие разработки. В ходе обзора спринта команда разработчиков также представляет готовый инкремент. Владелец продукта и заинтересованные стороны имеют возможность убедиться в его качестве. Это позволяет гораздо быстрее реагировать на ошибки разработки, чем обнаруживать неисправную функцию в самом конце проекта.
• Творчество: Scrum основан на самоорганизации команды. Вместо того чтобы диктовать рабочие процессы сверху вниз, разработчики в первую очередь начинают работать со своими собственными идеями. Поскольку структура Scrum сравнительно открыта и имеет мало правил, у отдельных членов команды появляется больше стимулов для выдвижения идей.
• Эффективность: По сравнению с классическим управлением проектами, Scrum требует гораздо меньше документации. Основное внимание должно быть сосредоточено на функционирующем продукте, а не на полной документации, которая отнимает время и ресурсы. Вместо этого команда может полностью сосредоточиться на работе по разработке в течение спринта и выполнять ее по своему усмотрению.

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

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

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