SCRUM

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

Краткий список терминов и определений

• Скрам – рассматриваемая методология управления проектами.
• Выпуск (release) – временной отрезок, в ходе которого над продуктом ведется работа. Фиксирован по времени. Имеет список задач, подлежащих решению в этот выпуск. Часто завершается выпуском новой версии продукта. Состоит из спринтов.
• Спринт (итерация) – временной отрезок, в ходе которого над продуктом ведется работа. Фиксирован по времени. Имеет список задач, подлежащих решению в этот спринт.
• Пожелание заказчика (user story) – функциональность, которую заказчик хочет реализовать в проекте.
• Резерв продукта (Product Backlog) – список пожеланий заказчика, которые необходимо реализовать в проекте, отсортирован по важности.
• Резерв выпуска(Release Backlog) – список пожеланий заказчика, которые необходимо реализовать в текущем выпуске.
• Резерв спринта(Sprint Backlog) – список пожеланий заказчика, которые необходимо реализовать в текущем спринте.
• Очки истории (Story Points) – абстрактные очки сложности пожеланий заказчика.
• График сгорания задач (Burndown chart) – график, показывающий оптимальный темп решения задач и реальный.
• Собрания – проводятся в разное время и с разной периодичностью. Целью собраний является либо обсуждение предстоящих задач на какой-то период, или подведение итогов прошедшего спринта.
• Владелец Продукта (Product Owner) - это человек, отвечающий за разработку продукта.
• Команда – люди, занимающиеся непосредственно реализацией функциональных требований.
• Скрам Мастер – человек из команды, представляющий интересы команды перед владельцем продукта и помогающий команде оставаться эффективной.

История возникновения

Подход впервые описали Хиротака Такэути и Икудзиро Нонака в статье The New Product Development Game (1986г). Авторы этой провели исследования среди японских компаний и выявили, что старый подход к разработке продуктов, в котором каждая фаза разработки следует только после предыдущей, малопродуктивен. Согласно старому подходу, процесс разработки продукта двигался как эстафета. Группы специалистов последовательно передавали друг другу эстафетную палочку. Разработка продукта шла последовательно, от фазы к фазе: разработка концепции, проверка осуществимости, дизайн продукта, процесс разработки, пилотный продукт и финальный продукт. Согласно этому методу функции были специализированы и сегментированы. Вместо данного подхода ряд компаний стали применять другой подход, основанный на том, что над одной задачей работают разно профильные специалисты. Такой подход аналогичен стратегии в игре Регби, когда команда вместе старается пройти всю дистанцию, передавая мяч друг другу. Авторы статьи применили термин из этой игры под названием Scrum для описания совместной работы нескольких специалистов из разных областей, который представляет собой ситуацию, когда несколько игроков оказываются в схватке над мячом.

Впервые метод Scrum был представлен на общее обозрение задокументированным, чётко сформированным и описанным совместно Швабером и Джефом Сазерлендом на OOPSLA’96 в Остине. С тех пор данная методология претерпевала незначительные изменения и доработки, однако кардинальных отличий не было. В 2001 году Швабер совместно с Майком Бидлом детально описал данный метод ведения проектов в книге «Agile Software Development with SCRUM». В настоящее время на рынке программных разработок данный подход очень востребован, существует множество учебников, статей и советов по поводу его использования и внедрения. Так же существует сайт scrum.org, который посвящен данной методологии.

Основные термины

Спринт — итерация в скрам, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 (в некоторых случая от 1) до 4 недель. В отдельных случаях, к примеру согласно Scrum стандарту Nokia, длительность спринта должна быть не более 6 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок. Для оценки объема работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка фиксируется в резерве проекта. На протяжении спринта никто не имеет права менять список требований к работе, внесенном в резерв проекта. Резерв проекта (Product backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются «пожеланиями пользователя» (user story) или элементами резерва (backlog items). Резерв проекта открыт для редактирования для всех участников скрам процесса. Резерв спринта (Sprint backlog) — содержит функциональность, выбранную владельцем проекта из резерва проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения спринта. Пожелание заказчика (User Story) — требуемая функциональность, которую добавляют в резерв часто называют историей. Зачастую история имеет следующую структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>». Такая структура удобна тем, что понятна как разработчикам так и заказчикам. Очки истории (Story Points) — абстрактная метрика оценки сложности истории, которая не учитывает затраты в человекочасах. Обычно используют одну из следующих шкал: ряд Фибоначчи (1,2,3,5,8,13,21,34,55); линейную шкалу (1,2,3,4 … n); степень двойки (1,2,4,8 … 2n); размеры одежды (XS, S, M, L, XL). График сгорания задач (Burndown chart) — Диаграмма, показывающая количество сделанной и оставшейся работы. Обновляется ежедневно с тем, чтобы в простой форме показать подвижки в работе над спринтом. График должен быть общедоступен. Существуют разные виды диаграммы:

• диаграмма сгорания работ для спринта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать в текущем спринте.
• диаграмма сгорания работ для выпуска проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на базе нескольких спринтов).

Собрания

Планирование спринта (Sprint Planning Meeting)

Происходит в начале новой итерации Спринта.

• Из резерва проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда;
• На основе выбранных задач создается резерв спринта. Каждая задача оценивается в идеальных человеко-часах;
• Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи;
• Обсуждается и определяется, каким образом будет реализован этот объём работ; Продолжительность совещания ограничена сверху 4-8 часами в зависимости от продолжительности итерации, опыта команды и т.п. (первая часть совещания) Участвует владелец проекта и скрам команда: выбирают задачи из резерва продукта; (вторая часть совещания) Участвует только команда: обсуждают технические детали реализации, наполняют резерв спринта.

Ежедневное совещание (Daily Scrum meeting)

• начинается точно вовремя;
• длится не более 15 минут;
• проводится в одном и том же месте в течение спринта.
• В течение совещания каждый член команды отвечает на 3 вопроса:
  • Что сделано с момента предыдущего ежедневного совещания?
  • Что будет сделано с момента текущего совещания до следующего?
  • Какие проблемы мешают достижению целей спринта? (Над решением этих проблем работает скрам мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц, непосредственно затронутых данным препятствием.)

Обзор итогов спринта (Sprint review meeting)

• Проводится после завершения спринта.
• Команда демонстрирует инкремент функциональности продукта всем заинтересованным лицам.
• Привлекается максимальное количество зрителей.
• Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).
• Нельзя демонстрировать незавершенную функциональность.
• Ограничена 4-мя часами в зависимости от продолжительности итерации и инкремента продукта.

Ретроспективное совещание (Retrospective meeting)

• Проводится после завершения спринта.
• Члены команды высказывают своё мнение о прошедшем спринте.
• Отвечают на два основных вопроса:
  • Что было сделано хорошо в прошедшем спринте?
  • Что надо улучшить в следующем?
• Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).
• Ограничено 2-мя часами.

Роли

В методологии Scrum всего три основных роли: Скрам Мастер, Владелец продукта, Команда. По методике Scrum в производственном процессе есть определенные роли, разбитые на 2 группы «свиней» и «цыплят». Свиньи создают продукт, тогда как куры заинтересованы, но не настолько — ведь им все равно, будет ли проект удачным или нет, на них это мало отразится. С 2011 года данные термины не используются. Скрам Мастер (Scrum Master) - самая важная роль в методологии. Скрам Мастер отвечает за успех Scrum в проекте. По сути, Скрам Мастер является интерфейсом между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта или тимлид. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды. В Agile команда является самоорганизующейся и самоуправляемой. Основные обязанности Скрам Мастера таковы:

• Создает атмосферу доверия,
• Участвует в митингах в качестве человека, обеспечивающего успешную групповую коммуникацию
• Устраняет препятствия
• Делает проблемы и открытые вопросы видимыми
• Отвечает за соблюдение практик и процесса в команде Скрам Мастер ведет ежедневное совещание и отслеживает прогресс команды при помощи резерва спринта, отмечая статус всех задач в спринте. Может также помогать владельцу продукта (Product Owner) создавать резерв для команды.

Владелец Продукта (Product Owner) - это человек, отвечающий за разработку продукта. Он представляет единую точку принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет. Обязанности владельца продукта таковы:

• Отвечает за формирование «видения продукта»
• Управляет ожиданиями заказчиков и всех заинтересованных лиц
• Координирует и приоритизирует резерв продукта
• Предоставляет понятные и тестируемые требования команде
• Взаимодействует с командой и заказчиком
• Отвечает за приемку кода в конце каждой итерации Владелец продукта ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта.

Команда (Team) – непосредственно исполнители задач. В методологии скрам команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед владельцем продукта. Работа команды оценивается как работа единой группы. В скрам вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды. Обязанности команды таковы:

• Отвечает за оценку элементов резерва продукта
• Принимает решение по дизайну
• Разрабатывает программное обеспечение и предоставляет его заказчику
• Отслеживает собственный прогресс (вместе со скрам мастером).
• Отвечает за результат перед владельцем продукта Размер команды ограничивается размером группы людей, способных эффективно взаимодействовать лицом к лицу. Типичные размер команды - 7 плюс минус 2. Команда в Скрам кроссфункциональна. В нее входят люди с различными навыками - разработчики, аналитики, тестировщики. Нет заранее определенных и поделенных ролей в команде, ограничивающих область действий членов команды. Команда состоит из инженеров, которые вносят свой вклад в общий успех проекта в соответствии со своими способностями и проектной необходимостью. Команда самоорганизуется для выполнения конкретных задач в проекте, что позволяет ей гибко реагировать на любые возможные задачи. Для облегчения коммуникаций команда должна находиться в одном месте (colocated). Предпочтительно размещать команду не в кубиках, а в одной общей комнате для того, чтобы уменьшить препятствия для свободного общения. Команде необходимо предоставить все необходимое для комфортной работы, обеспечить досками с листами, предоставить все необходимые инструменты и среду для работы.

Жизненный цикл проекта

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

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

• Команда выполнила все задачи из резерва спринта
• Команда точно не успевает выполнить поставленные задачи к концу спринта.

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

Scrum – это набор ценностей.

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

Минусы Scrum

• Успех проекта в большей степени зависит от владельца продукта – стоит ему допустить ошибку и команда пойдет по ложному пути.
• Скраму без разницы как делаются детали. Методология подразумевает, что команда способна само развиваться и находить лучшие решения для поставленных задач. Зачастую это не так.
• Скрам не прививает любовь к скорости разработки. Если команда не успевает в спринт выполнить все задачи, она собирается и обсуждает это, но это не означает, что её скорость вырастет в следующем спринте. Как раз наоборот – у команды появиться соблазн просто взять поменьше задач в следующий раз.
• Скрам не позволяет «быстро» исправлять ошибки, так как менять писок задач на спринт нельзя. Поэтому заказчик вынужден ждать исправления ошибки как минимум до конца следующего спринта.
• При внедрении скрама в работу происходит переразделение полномочий и обязанностей. Это приводит к тому, что некоторые отделы (например, тестирования) становятся не нужными, как таковые. В то же время команда должна теперь сама думать за все эти отделы. Такое перераспределение полномочий может сильно пошатнуть сложившийся «микроклимат» в коллективе компании.
• При неправильной подаче скрам может мотивировать команду к скорости работы, но не к качеству. Таким образом, первые несколько итераций будут феноменальными по скорости и продуктивности. Однако при увеличении количества написанного кода, продуктивность будет неизбежно падать и наконец, из-за небрежности в начале, проект превратиться в снежный ком, который будет катиться сам по себе в каком-то направлении.