Scrum — это рамочная модель управления проектами, которая делает акцент на командной работе, ответственности и постепенном продвижении к четко определенным целям. Она начинается с простой идеи: начинать с того, что можно увидеть или знать. Затем отслеживать прогресс и вносить корректировки по мере необходимости.
Три кита Scrum
Scrum основан на эмпиризме, который утверждает, что знания приходят из опыта, а решения должны основываться на том, что известно. Эти три кита объединяют Scrum.
Почему Scrum?
Scrum обеспечивает постепенную доставку функциональности, в то время как Waterfall предоставляет результаты только на этапах. Традиционная разработка по модели Waterfall — это последовательный, этапный процесс, при котором ценность не появляется до завершения проекта. Scrum трансформирует эту модель, обеспечивая поставку новых функций каждым спринтом — как правило, каждые 2–4 недели — вместо того, чтобы сосредоточиться на крупном будущем релизе.
Scrum разбивает сложную работу на управляемые части, делит крупные организации на небольшие команды и превращает значимые проекты в серию коротких, ограниченных по времениспринтов.
Благодаря итеративной и постепенной разработке компании могут быстрее и эффективнее предоставлять продукты и услуги, которые действительно нужны клиентам. С Scrum вы можете получать и интегрировать обратную связь клиентов в конце каждого спринта, что означает, что ваши результаты формируются на основе реального использования, а не предположений. Это делает легче вовлечение клиентов и ключевых заинтересованных сторон.
Гибкость против Scrum
Гибкость — это практика, которая позволяет непрерывно итерировать разработку и тестирование на протяжении всего жизненного цикла разработки программного обеспечения. Гибкость разбивает продукты на более мелкие, управляемые компоненты.Scrum — всего лишь один из многих итеративных и постепенных процессов разработки программного обеспечения по методологии гибкости которые позволяют нам сосредоточиться на предоставлении бизнес-ценности в кратчайшие сроки.
Scrum обычно работает с требованиями, которые могут меняться или неизвестны на начальном этапе проекта. Scrum характеризуется:
- Легковесность
- Простота понимания
- Сложно освоить
Преимущества Scrum
Вот преимущества, которые Scrum приносит организациям, командам, продуктам и отдельным лицам:
- Более высокое качество: Существует рамочная модель для достижения видения или целей. Scrum обеспечивает непрерывную обратную связь и прозрачность, чтобы качество было максимально высоким. Scrum помогает обеспечить качество за счет практик, таких как:
- Сокращение времени выхода на рынок: Scrum доказал, что обеспечивает ценность конечным пользователям на 30%–40% быстрее, чем традиционные методы.
- Более высокая отдача от инвестиций (ROI): Более короткое время выхода на рынок — ключевая причина, по которой проекты Scrum достигают более высокой отдачи от инвестиций. Раннее накопление доходов и выгод означает более высокую общую отдачу. Это основано на фундаментальном принципе расчета чистой приведенной стоимости (NPV).
- Более высокий моральный дух команды: Работа с счастливыми, вовлеченными людьми — это удовлетворительно и продуктивно. Самоуправление передает решения, обычно принимаемые менеджерами или организациями, в рукиКоманда скрам члены.
- Более сильное взаимодействие команды: Когда команды скрам владеют проектом и продуктом, они могут добиться отличных результатов. Команды скрам взаимодействуют и повышают качество и эффективность проекта за счёт усиления вовлечённости и коммуникации.
Фреймворк скрам
Скрам прост. Это не набор жёстких, взаимосвязанных требований. Скрам — это не методология. Скрам воплощает научный метод эмпиризма. Он заменяет процедурные алгоритмические подходы эвристическими методами, уважая людей и саморегуляцию для решения непредсказуемости и сложных задач. Диаграмма ниже показывает скрам в действии, как описано Кеном Швабером и Джеффом Сандерсоном в их книге «Скрам: Искусство делать вдвое больше работы за половину времени», иллюстрируя путь от планирования до доставки программного обеспечения.
Компоненты процесса скрам
Сам фреймворк скрам прост. Он определяет лишь несколько общих руководящих принципов, с небольшим количеством правил,роли, артефакты, исобытия. Однако каждый из этих компонентов имеет решающее значение для конкретных целей и необходим для успешного использования фреймворка.
Основные компоненты фреймворка скрам:
- Роли скрам: Мастер скрам, Владелец продукта, и команда скрам
- Артефакты: Бэклог спринта, Бэклог продукта, График сгорания, журналы и т.д.
- События скрам: Планирование спринта, Обзор спринта, Ежедневный стендап, Ретроспектива спринта, и т.д.
- Спринты
На приведенной ниже диаграмме показаны ключевые элементы фреймворка Scrum. Процесс был визуализирован с использованием Канвас процесса Scrum из инструментов Agile-разработки Visual Paradigm.
Роли Scrum
Когда организация внедряет Scrum, первое, что нужно понять, — как роли Scrum отличаются от традиционных ролей управления проектами. Хотя в Scrum всего три основные роли, они не всегда соответствуют привычным должностным названиям. Давайте начнем с кратких определений каждой из них:
Продуктовый владельцы
Продуктовый владелец — это роль Scrum, отвечающая за представление интересов бизнеса или пользовательского сообщества. Он тесно сотрудничает с пользователями для определения функций в бэклоге продукта. Ключевые обязанности включают:
- Определение видения и стратегии продукта, включая краткосрочные и долгосрочные цели;
- Предоставление или сбор знаний о продукте или услуге;
- Понимание и передача потребностей клиентов команде разработки;
- Сбор, приоритизация и управление требованиями к продукту или услуге;
- Ответственность за бюджетирование продукта или услуги, включая рентабельность;
- Определение дат выпуска продукта или услуги;
- Ежедневное ответы на вопросы и принятие решений совместно с командой разработки;
- Принятие или отклонение завершенной работы из спринта;
- Представление основных результатов команды в конце каждого спринта;
- Управление бэклогом продукта.
Мастер Scrum
Мастер Scrum — это координатор команды Agile-разработки. Scrum позволяет командам самостоятельно организовываться и быстро адаптироваться на основе принципов Agile. Мастер Scrum управляет потоком информации. Ключевые обязанности:
- Выступать в роли наставника, помогая команде придерживаться ценностей и практик Scrum;
- Помогать устранять препятствия и защищать команду от внешних отвлекающих факторов;
- Содействие эффективному взаимодействию между командой и заинтересованными сторонами;
- Содействие здравому смыслу и прозрачности внутри команды;
- Защита команды от организационных сбоев.
Команда Scrum
Команда Scrum (также известная как команда разработки) состоит из 3–9 членов, которые совместно должны обладать всеми техническими навыками, необходимыми для предоставления продукта или услуги. Они напрямую руководятся Scrum-мастером, но не управляются в традиционном смысле. Они должны быть самодостаточными, межфункциональными и нести ответственность за выполнение всех необходимых задач.
Команда разработки несет ответственность за предоставление потенциально достойного поставки продукта на завершении каждого спринта — охватывая анализ, проектирование, разработку, тестирование и техническое письмо. Важные характеристики команды Scrum включают:
- Самодостаточность: Все члены команды управляют своей работой для выполнения назначенных задач. В Agile Scrum отсутствует лидер команды или руководитель по линии. Каждый должен вкладываться достаточно, чтобы управлять своими действиями и вносить вклад в успех команды. Если один не справляется, страдает вся команда.
- Межфункциональность: Все члены команды должны обладать всеми необходимыми знаниями и навыками для предоставления высококачественного, достойного поставки продукта. Эксперты могут быть привлечены для консультаций, но только для передачи знаний команде с целью устранения пробелов в навыках.
- Продуктовый владелец должен обладать бизнес-видением: Продуктовый владелец представляет голос клиента и должен переводить их потребности в конкретные действия для Scrum-мастера и команды разработки. Обычно это должность на полной ставке.
- Scrum-мастер не является линейным менеджером: Они помогают коучить команду разработки и устраняют препятствия, мешающие прогрессу.
Артефакты Scrum
Артефакты Scrum помогают определить работу, поступающую в команду, и текущую работу. Хотя существует больше артефактов — таких как пользовательские истории, релизные бэклоги, графики сгорания — здесь мы сосредоточимся на трёх основных:
Продуктовый бэклог
Продуктовый бэклог — это приоритизированный список пользовательских историй, представляющих функции, которые команда продукта нуждается или ожидает. Обычно этот список поддерживает продуктовый владелец.
бэклог спринта
Бэклог спринта содержит набор выбранных элементов, которые должны быть завершены в текущем спринте. Два важных момента, на которые следует обратить внимание, касающиеся взаимосвязи между бэклогом спринта и продуктовым бэклогом:
1. Команда решает, что добавить в спринт. Следовательно, команда несёт ответственность за выполнение этих элементов.
2. Перед перемещением элемента из продуктового бэклога в бэклог спринта команда должна убедиться, что у неё есть вся необходимая информация. Команда обычно определяет чек-лист критериев, которые должны быть выполнены перед добавлением элемента.
Продуктовый бэклог против бэклога спринта
Такой бэклог спринта — это список задач, к которым команда Scrum обязуется завершить в течение спринта. На встрече планирования спринта команда обычно выбирает несколько элементов продуктового бэклога в виде пользовательских историй и определяет задачи, необходимые для завершения каждого из них, как показано ниже:
График сгорания
График сгорания — это графическое представление оставшейся работы во времени. Оставшаяся работа (или работа в бэклоге) отображается по вертикальной оси, а время — по горизонтальной. Это непрерывный график оставшейся работы. Он может использоваться для прогнозирования момента завершения всей работы. Он широко используется в методах Agile-разработки программного обеспечения, таких как Scrum, но может применяться к любому проекту с измеримым прогрессом во времени. Оставшаяся работа может измеряться по времени или в очках истории.
События Scrum
Коммуникация — это ключ! Скрум опирается на прозрачность во всех аспектах (столп Скрума №1). Учитывая этот основополагающий принцип, фреймворк построен вокруг ряда ключевых событий, чтобы обеспечить два других столпа — Проверка и Адаптация — как показано в таблице ниже:
| Событие | Проверка | Адаптация |
|---|---|---|
| Планирование спринта |
|
|
| Ежедневный стендап |
|
|
| Обзор спринта |
|
|
| Ретроспектива спринта |
|
|
Примечание: Во время каждого спринта в Скруме проводится пять ключевых встреч, как показано ниже:
Планирование спринта
Каждый спринт начинается с планирования. Команда должна определить и обязаться доставить то, что будет частью спринта. Возможные элементы всегда извлекаются из бэклога спринта, как показано ниже:
Вот где Scrum-мастер может проявить себя. Продуктовый владельцы определяет, что необходимо с бизнес- или клиентской точки зрения, команда Scrum определяет, что, по её мнению, может быть доставлено, а Scrum-мастер обеспечивает наилучшее соответствие интересам обеих сторон.
Ежедневный стендап
Как только команда обязуется доставить то, что будет частью спринта, она проводит ежедневный стендап. Основная цель — обеспечить, чтобы каждый член команды (и, возможно, наблюдатели) полностью понимали статус и ход работы:
- Что я сделал вчера?
- Что я сделаю сегодня?
- Что мешает мне?
Ежедневное обновление предоставляет мгновенную обратную связь команде. Встречи короткие — не более 3 минут на человека.
Примечание:Наблюдатели присутствуют, чтобы наблюдать. Scrum-мастер должен минимизировать внешние и внутренние отвлекающие факторы.
Встреча по итогам спринта
Встреча по итогам спринта или демонстрация проводится в конце спринта для проверки инкремента. Команда демонстрирует инкремент на основе определения готовности, делая акцент на цели спринта. Продуктовый владелец проверяет и принимает доставленный инкремент.
Ретроспектива спринта
Ретроспектива спринта обычно является последним мероприятием в спринте. Многие команды проводят её сразу после встречи по итогам спринта. Встреча должна участвовать вся команда — включая Scrum-мастера и продуктового владельца. Обычно достаточно одного часа. На этой встрече команда может обдумать:
- Что мы должны начать делать?
- Что мы должны прекратить делать?
- Что мы должны продолжать делать?
Цель — непрерывно повышать эффективность команды.
Оптимизация бэклога
Представьте себе бэклог продукта как карту проекта. По мере совместной работы команда создает и обновляет список всех элементов, необходимых для завершения проекта, обеспечивая выполнение всех необходимых требований.
Спринты
В рамках Scrum все действия, необходимые для реализации элемента из бэклога продукта, выполняются в рамках спринта (также называемого «итерациями»). Спринты всегда короткие — обычно от 2 до 4 недель. Каждый спринт следует определённому процессу, как показано ниже:
Как отмечено, элементы в бэклоге продукта приоритизируются и выбираются для бэклога спринта. Спринт содержит только несколько крупных элементов — любая недооценка объёма работы по одному элементу может значительно повлиять на спринт. Поскольку крупные элементы часто сложнее оценить и понять, риск неудачи спринта возрастает. Опытные команды Scrum тратят время и усилия на разбиение сложных или крупных элементов (например, функций пользователей или эпиков) на более мелкие пользовательские истории (или далее — на задачи или подзадачи).
Эпик
Эпик охватывает большой объём работы. По сути, это «большая пользовательская история», которую можно разбить на множество более мелких историй. Завершение эпика может занять несколько спринтов. Поэтому при использовании эпиков в разработке их необходимо разбивать на более мелкие пользовательские истории.
Эпики вводятся на ранних этапах жизненного цикла проекта. Они являются высокого уровня, почти ориентированными на маркетинг функциональными элементами.
Мы называем крупные истории «эпиками», чтобы передать их масштаб. Подумайте об этом, как о фильме. Если я скажу вам, что фильм — это «приключения с элементами экшн», вы поймёте, чего ожидать — возможно, гонки на машинах, стрельба и т.д. Аналогично, обозначение истории как «эпик» иногда может передать дополнительный контекст.
Пользовательская история
Пользовательская история — это краткое описание требования к продукту или бизнес-кейса. Обычно она пишется простым языком, чтобы помочь читателям понять, что должно делать программное обеспечение. Продуктовый владелец создаёт историю. Затем члены команды Scrum разбивают историю на одну или несколько задач Scrum.
Истории пользователей обычно представляют собой функции, видимые конечному пользователю. Они следуют формату: «Я хочу [что-то сделать], чтобы [я мог достичь цели]». Они приносят ценность клиенту/пользователю. Это требование клиента к продукту.
Пример: «Как клиент, я хочу создать учетную запись, чтобы иметь возможность просмотреть свои покупки прошлого года и помочь мне спланировать свой бюджет на следующий год».
Задача
В противоположность этому, задача является более технической. Задачи часто включают код, проектирование, создание тестовых данных, автоматизацию и т.д. Обычно это индивидуальные обязанности. Задачи не формулируются в формате истории пользователя. Они более технические.
Пример: «Оценить угол интерфейса с использованием Material Design» или «Подать приложение в App Store».
English
Arabic
Chinese (Simplified)
Dutch
French
German
Italian
Japanese
Korean
Portuguese
Russian
Spanish