Scrum — метод управления проектами широко применяется для проектов работающих с нематериальными ресурсами (разработка, дизайн, проектирование) и контроля, который преодолевает многие сложности, чтобы сосредоточиться на создании программного обеспечения/сервиса/документации, которые отвечает потребностям бизнеса. Руководитель и команда могут получить в свои руки понятные исходные и конечные требования и технологию работы, которая позволяет постоянно взаимодействовать с клиентом и другими участниками, а также сдавать результаты работ постепенно и эмпирически.
Scrum — это простая основа для эффективной совместной работы над сложными программными проектами. Кен Швабер и Джефф Сазерленд написали Руководство по Scrum и объяснили скрам четко и лаконично.
Скрам-процесс управления и контроля, который проходит через сложности, чтобы сосредоточиться на создании программного обеспечения, которое отвечает потребностям бизнеса. Управление и команды могут получить в свои руки вокруг требований и технологий, никогда не отпускать, и сдать работы программного обеспечения, постепенно и эмпирически. В целом scrum — это довольно простая основа для эффективной совместной работы над сложными программными проектами. Кен Швабер и Джефф Сазерленд написали Руководство по scrum и объяснили scrum четко и лаконично.
Скрам Глоссарий
Скрам Глоссарий предназначен для представления и обзора терминов методологии scrum. Некоторые из указанных терминов не являются обязательными в скрам, но были добавлены, потому что они обычно используются в скраме. Чтобы узнать больше о методологии scrum, для определения того, какие из этих условий являются обязательными элементами scrum и понимания, как эти элементы связаны, мы настоятельно рекомендуем Вам изучить справочное руководство по scrum.
История scrum
Хиротака Такеучи и Нонака Икуджиро ввели слово «скрам» как термин в контексте разработки продукта в 1986 году в своей статье о новой игре при разработке нового продукта. Позже Такеучи и Нонака утверждали в «Создание базы знаний компании», что это форма «создания организационного знания,… особенно хорошо используется при инновациях, постепенно и спирально».
Авторами описан новый подход к разработке коммерческого продукта, который позволит повысить скорость и гибкость, на основе примеров из промышленных предприятий в автомобильной, копировальной промышленности. Они называют это целостный или регби подход, так как весь процесс осуществляется одной командой которая обладает взаимозаменяющимся функционалом в несколько перекрывающихся этапах, где группа участников «старается двигаться как целостный организм, передавая мяч назад и вперед». (Регбийное определение скрама — это метод спортивной организации который относится к плотно-упакованным формированиям игроков с опущенными головами, пытающихся завладеть мячом.)
Кен Швабер использовал принципы скрам как «Передовые методов разработки» еще в начале 1990-х в его компании, в то время как Джефф Сазерленд, Джон Шумниоталес и Джефф Маккенн разработали подобный подход в Easel Corporation, обозначая его с помощью одного слова Скрам. В 1995 году Сазерленд и Швабер совместно представили документ с описанием методологии scrum на семинаре по разработке и реализации бизнес ориентированных продуктов, проведенного в рамках конференции «Объектно-ориентированное программирование, системы, языки и приложения ’95» (конференции OOPSLA ’95) в Остине, штат Техас. В течение следующих лет Швабер и Сазерленд сотрудничали, чтобы объединить этот материал со своим опытом и наработать хорошую практику в результате развития этот подход приобрел популярность и известность под названием scrum-метод.
Швабер работал с Майком Бекедале над описанием данного метода в книге «Agile Software Development with Scrum» в 2001 году . Scrum-подход к планированию и управлению развитием продукта предполагает приведение полномочий по принятию решений на уровень эксплуатационных свойств и определенности. Хотя слово «Scrum» — это не аббревиатура, это иногда видно как используется написание «SCRUM». Это может быть связано с одним из ранних документов Кен Швабера, в котором использовано scrum в названии.
В 2002 году Швабер с другими основал Скрам Альянс и запустил сертифицированную магистерскую программу по scrum и смежных областей. Однако Швабер оставил Скрам Альянса в конце 2009 года.
Scrum метод
Обязательство
Члены команды самостоятельно выполняют работу для достижения собственных и командных целей, каждый спринт.
Смелость
Члены команды знают, что они имеют достаточно смелости, чтобы совместно решать конфликты и проблемы, таким образом они могут поступать правильным образом.
Фокус
Членам команды сосредотачиваются исключительно на своих и командных целей и спринта; не должно быть никакой работы, кроме той которая прописана в беклоге.
Открытость
Члены команды и их заинтересованные стороны соглашаются обеспечить прозрачность своей работы и проблем, с которыми они сталкиваются.
Уважение
Члены команды уважают друг друга, чтобы быть технически грамотным и работать с добрыми намерениями.
Все работы в рамках скрам производятся в атмосфере открытости, для того чтобы быть прозрачными и понятными: процесс → рабочий процесс → прогресс и т. д. Scrum-команде нужно часто инспектировать разработку продукта и качество работы команда для того, чтобы сделать эти вещи видимыми. Применяя практику частых обзоров, скрам-команда может определить, когда их работа отклоняется от допустимых пределов и адаптировать свой процесс или продукт на стадии разработки.
Роли в скрам
Владелец продукта
Владелец продукта является ролью представляющей заинтересованную в конечном результате проекта сторону и голос клиента, несет ответственность за обеспечение того, чтобы scrum-команда предоставляла оговоренную ценность для бизнеса клиента. Владелец продукта создает клиентоориентированные запросы, характеристики и функционал (как правило, пользовательские истории), расставляет их в соответствии с их важностью и приоритетностью, после этого добавляет их в список невыполненных работ по продукту (Бэклог продукта). Scrum-команды должны иметь только одного владельца продукта. Эта роль несовместима с ролью scrum-мастера. Владелец продукта должен сосредоточиться на деловых вопросах развития продукта, зачастую он проводит большую часть своей работы на поддержание связей с заинтересованными сторонами и не указывает (не выполняет управленческих функций), каким образом команда достигнет технического решения. Эта роль, эквивалентна роли представителя заказчика в некоторых других гибких методологиях, таких как экстремальное программирование (XP).
Общение — одно из основных обязанностей владельца продукта. Умение донести приоритеты, взаимодействовать с членами команды и заинтересованными сторонами имеет решающее значение, чтобы направить развитие продукта в нужном направлении. Владельцы продуктов заполняют коммуникационный пробел между командой и заинтересованными сторонами. Они служат в качестве посредника для участников команды, представителя команды и целого сообщества заинтересованных сторон.
Как лицо группы заинтересованных сторон, ниже приведены некоторые коммуникационные задачи владельца продукта:
- демонстрирует решения ключевых заинтересованных сторон, которые не присутствовали на обзоре спринта;
- определяет и объявляет релизы;
- сообщает статус решения команде;
- организует ключевые события обзоров;
- воспитывает заинтересованные стороны в процесс развития;
- согласовывает приоритеты, сферы деятельности, финансирование и расписание;
- гарантирует, что Бэклог определен, прозрачен и понятен.
Эмпатия — ключевой атрибут для владельца продукта, чтобы иметь возможность поставить себя на место других. Владелец продукта беседует с различными заинтересованными сторонами, которые имеют разные мнения, должностные обязанности и цели. Владелец продукта должен быть в состоянии видеть конечный результат проекта с разных точек зрения. Команда разработчиков нуждается в тщательном описании и технических характеристиках, поэтому они могут создать продукт, который соответствует ожиданиям, в то время как главному заказчику может быть просто необходим отчет по прогрессу. Предоставление больше информации, чем необходимо, может привести к потере интереса со стороны заинтересованных лиц и в конечном счете приведет лишь к потере времени. Опытные владельцы продукта предпочитают прямые средства коммуникации.
Способность владельца продукта, эффективно общаться также усиливается, если он обладает методами выявления потребностей заинтересованных сторон, согласования приоритетов между разными интересами стейкхолдеров и оперативного взаимодействия с разработчиками для обеспечения эффективного описания требований.
Команда разработки
Команда разработчиков отвечает за предоставления потенциально готового приращения (PSIs) продукта в конце каждого спринта (которое является целю спринта). Состав команды не должен превышать девяти человек, а минимальное количество сотрудников- трое, данные сотрудники делают реальную работу (анализируют, разрабатывают, проектируют, тестируют, взаимодействуют, документируют и тд.). Данные специализированные команды имеют все необходимые навыки для создания продукта и в большинстве своем многофункциональны. Самоорганизующиеся функции — это одно их особенностей команды разработки в scrum, хотя там может быть какое-то взаимодействие с офисом управления проектами (ОУП).
Скрам-Мастер
Scrum — предполагает наличия scrum-мастера, который отвечает за устранение препятствий в способности команды к достижению целей, продуктов и результатов. Скрам мастер — это не традиционный тимлид или менеджер проекта, и действует в качестве буферной зоны между командой и какими-либо отвлекающими внешними влияниями. Скрам мастер помогает обеспечить направленность команды в согласованных процессы в рамках Скрам, часто облегчает ключевые сессий, и предлагает улучшения. Роль также упоминается как фасилитатор или лидер-услуг и объединяет эти два термина.
Основные обязанности Скрам мастера включают (но не ограничиваются):
- Помогает владельцу продукта поддерживать Бэклог продукта таким образом, обеспечивая необходимую связь, поэтому команда способна постоянно продвигаться вперед;
- Оказывает помощь скрам-команде в определении параметров функционала продукта, с участием ключевых заинтересованных сторон;
- С целью повышения эффективности взаимодействия внутри команды, проводит обучение принципам скрам;
- Содействует развитию самоорганизации внутри скрам-команды;
- Оказывает помощь команде в устранении препятствий, мешающих прогрессу, будь то внутренние или внешние влияния;
- Организация мероприятий по обеспечению регулярного прогресса;
- Информирование основных заинтересованных сторон продукта по scrum принципам
- Коучинг команды в кросс-функциональности
Отличие скрам мастера от менеджера проекта (руководителя проекта) состоит в том, что менеджер проекта обладает функциональными обязанностями в управлении командой проекта, а скрам мастер нет. Скрам-команды используют принципы самоорганизации. Скрам официально не признает роль менеджера проекта, как и традиционные административно-командные тенденции управления проектами.
Рабочий процесс scrum
При управлении временем тайм-бокс назначает фиксированный период времени, называемый временным окном, для каждого запланированного действия. Некоторые подходы к управлению проектами используют тайм-бокс. Он также используется для индивидуального использования при решении личных задач в меньших временных рамках. Часто это связано с наличием конечных результатов и сроков, и это повышает производительность пользователя.
Каждый спринт начинается с планирования мероприятий, которые задают направление спринта, определения задач в спринте, и, оценки, соответствия целям спринта. Каждый спринт заканчивается обзором ретроспективой спринта, которые рассматривают прогресс, чтобы предоставить информацию заинтересованным сторонам и выявления улучшений для следующего спринта.
Скрам акцентирует внимание на работу, которую сделали в конце спринта. В случае с программным обеспечением, это скорее всего означает, что программное обеспечение было полностью проверено, документировано и потенциально готово к поставке.
Планирование
В начале спринта Скрам команда проводит спринт планирование для:
- Общение по определению объема работ, которые предполагается сделать во время этого спринта;
- Выбор элементов Бэклога продукта, которые могут быть завершены в один спринт;
- Подготовка спринта, определение необходимых работ, чтобы закончить некоторые элементы Бэклога продукта;
- Определение тайм-боксов — четырех-часовых лимитов на двухнедельные спринты (пропорциональная продолжительность для остальных спринтов);
- В течение первой половины, вся скрам-команда (а это команда-разработчиков, scrum-мастер, а также product owner- владелец продукта) выбирают работы-задачи из Бэклога, которые могут быть достигнуты в этом спринте;
- Во второй половине команда разработчиков декомпозирует работы (задания), необходимые для предоставления этих элементов Бэклога продукта, в результате чего подтверждается спринт;
- Некоторые элементы Бэклога продукта могут быть разделены или переориентированы если выявленные работы, не достижимы в этом спринте.
После того, как команда разработчиков подготовит спринт, они определяют длительность работ (как правило, путем голосования) для выполнения задач в течение спринта.
Ежедневный скрам
Ежедневный scrum в начинается в одной и той же комнате. Это централизованное расположение помогает команде начать вовремя. Каждый день во время спринта команда проводит ежедневный скрам (обычно стоя) с конкретными руководящими принципами:
- Ежедневный скрам. Все члены команды разработчиков должны готовиться. Ежедневный Скрам…
…начинается точно по времени, даже если некоторых членов команды не хватает;
…должен начаться каждый день в одном и том же месте и в одно и то же время;
…ограничен (timeboxed) пятнадцатью минутами. - Могут присутствовать посторонние, хотя обычно только команда scrum обменивается мнениями о текущей ситуации;
- Особенностью ежедневного скрам-митинга является то, что каждый участник группы отвечает на 3 локоничных и простых вопроса:
- Мои вчерашние выполненные задачи? Каким образом я помог команде-разработчиков достигнуть цели-спринта?
- Какие я ставлю себе задачи на сегодня, чтобы нам совместно достичь цели-спринта?
- Наблюдаю ли я какие-либо ограничения, мешающие мне или команде разработчиков достигнуть цели-спринта?
Любое ограничение (например, камень преткновения, риск, проблема, задержка зависимостей, необоснованность предположения), выявленных на ежедневном scrum-митинге должно быть записано скрам мастером и перенесено на scrum доску. Детальное обсуждение во время ежедневного скрам-митинга не производится.
Обзоры и ретроспективы
Команда проводит два мероприятия в конце спринта: обзор и ретроспектива спринта.
Действия команды во время обзора спринта:
- Обзор работ, которые были выполнены и планирование работ, которые не были завершены;
- Представлена готовые работы для заинтересованных сторон (например демо)
Руководящие принципы для обзора спринта:
- Недоделанные работы не могут быть продемонстрированы;
- Рекомендуемая продолжительность — два часа для двухнедельного спринта (пропорционально для других длительностей спринтов)
В ретроспективе спринта, команда:
- Размышляет о прошлом спринте;
- Определяет и согласовывает процесс непрерывного совершенствования действий.
Руководящие принципы для ретроспектив спринта:
- В ретроспективе спринта лишь два главных вопроса: что было хорошего во время спринта? Что можно улучшить в следующем спринте?
- Рекомендуемая продолжительность — 1-1,5 часа на двухнедельный спринт(пропорционально для других длительностей спринтов)
- Это событие закреплено за скрам мастером
Дополнительно
Следующие мероприятия обычно выполняются на практике, хотя и не рассматриваются всеми как основная часть методологии scrum:
Уточнение Бэклога
Уточнение Бэклога (некоторые называют груминг Бэклога) — это непрерывный процесс пересмотра элементов Бэклога и проверка того, что в нем правильно расставлены приоритеты и он составлен таким образом, который позволяет говорить о том, что задачи достаточно четкие и исполняемые для команды.
Элементы Бэклога:
- могут быть разбиты на несколько более мелких;
- критерии приемки могут быть уточнены;
- зависимости, последователи и подготовительные работы могут быть определены и согласованы при техническом согласовании.
Хотя данная практика не входит в основной скрам, уточнение Бэклога было принято как способ управления качеством элементов Бэклога, с рекомендуемым объемом до 10% времени спринта.
Скрам скрамов
Скрам скрамов — это метод, позволяющий в масштабе работать по scrum для нескольких команд, работающих над этим программным продуктом, обеспечивает возможность обсудить прогресс и взаимозависимость, сосредоточившись на том, как координировать разработку программных приложений, особенно когда они соприкасаются в сфере интеграции. Ежедневный скрам митинг для каждой команды, в зависимости от продолжительности, заканчивается назначением одного участника команды в качестве представителя для принятия участия в скрам скрамах с представителями других команд. В зависимости от контекста, представители могут быть как техническими специалистами так и scrum-мастерами команд.
Это мероприятие направлено не просто на обновление и обобщение прогресса от различных скрам команд, оно позволяет сосредоточиться на том, как команды коллективно работают, принимают, смягчают или уклоняются от каких-либо рисков, обсуждают препятствия, зависимости или допущения (RIDAs), которые были выявлены. Скрам скрамов отслеживает эти RIDAs через наличие собственных скрам досок, что обычно приводит к более тесной координации и сотрудничеству между scrum-командами.
Работа построена по аналогии с ежедневным скрам-митингом, и каждый представитель готовит свои ответы на следующие четыре вопроса:
- Какие риски, ограничения, зависимости и предположения, ваша скрам-команда выдвинула с нашей последней встречи?
- Какие риски, ограничения, зависимости и предположения, ваша команда будет выдвигать, прежде чем мы встретимся снова?
- Есть ли любые новые риски, препятствия, зависимости и допущения, замедляющие вашу команду или которые становятся у вас пути?
- Собираетесь ли вы ввести новый риск, препятствие, зависимость и предположение, которое будет мешать другой команде?
Как Джефф Сазерленд прокомментировал,
С тех пор как я изначально дал определение скрам скрамов (Кен Швабер работал в IDX в то время со мной), я могу точно сказать, что скрам скрамов — это не «Мета Скрам». Скрам скрамов, каким я его использовал, несет ответственность за предоставление рабочих версий софта от всех команд в конце спринта, или за релизы во время спринта. Ответственность за это несет Мастер скрам скрамов . Так скрам скрамов — это механизм более оперативной поставки ПО.
