Обзор

Что такое Scrum?

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

Хотя Scrum, о котором я говорю, чаще всего используется командами разработчиков программного обеспечения, его принципы и уроки могут быть применены ко всем видам командной работы. Это одна из причин популярности Scrum. Scrum, часто рассматриваемый как Agile подход управления проектами, описывает набор способов, инструментов и ролей, которые работают сообща, чтобы помочь командам структурировать и управлять своей работой.

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

Ролик

Структура (фрейморк)

Люди часто думают, что Scrum и Agile - это одно и то же, потому что Scrum сконцентрирован на постоянном улучшении, которое является основным принципом Agile . Тем не менее, Scrum является основой для выполнения работы, где гибкость является является необъемлемым качеством мышления. Вы не можете «идти в ногу с Agile », так как от всей команды требуется самоотдача, чтобы изменить то, как они думают о том, чтобы приносить пользу вашим клиентам. Но вы можете использовать такую среду, как Scrum, чтобы помочь вам начать думать таким образом и применять на практике Agile-принципы в повседневном общении и работе.

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

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

 

Scrum артефакты

Давайте начнем с определения трех артефактов в Scrum. Артефакты - это то, что мы делаем, как инструмент для решения проблемы. В Scrum эти три артефакта :

• список необходимых требований (backlog) по продукту
• список необходимых требований (backlog) по спринту
• приращение с вашим определением «выполнено».

Это три константы в команде разработчиков, которые мы продолжаем пересматривать снова и снова.

Видео

• Список необходимых требований (backlog продукта)- это основной список работ, которые необходимо выполнить, который ведется владельцем продукта или менеджером проекта. Это динамический список функций, требований, улучшений и исправлений, который служит входом для списка необходимых требований (backlog) спринта. По сути, это список команды «To Do» (Что сделать). Список необходимых требований (backlog) спринта продукта постоянно пересматривается, повторно расставляется по приоритетам и поддерживается владельцем продукта, потому что, по мере того, как мы узнаем больше или по мере изменения рынка, проблемы могут перестать быть актуальными или могут быть решены другими способами.
• Список необходимых требований спринта (backlog спринта) - это список элементов, пользовательских историй или исправлений ошибок (багов), выбранных командой разработчиков для реализации в текущем цикле спринта. Перед каждым спринтом на совещании по планированию спринта (о котором мы поговорим позже в этой статье) команда выбирает, над какими элементами он будет работать для спринта, из списка необходимых требований продукта. Список необходимых требований  спринта может быть гибким и может развиваться во время спринта. Тем не менее, основная цель спринта - то, чего команда хочет добиться от текущего спринта, - не должна быть подвергнута изменениям.
• Инкремент (или цель спринта) является итоговым продуктом спринта, пригодным к применению. В Atlassian мы обычно демонстрируем «приращение» во время демонстрации конца спринта, где команда показывает, что было завершено в спринте. Вы можете не слышать слово «прирост» в мире, так как оно часто упоминается как определение «готово», веха, цель спринта или даже полная версия или эпик.

 

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

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

Scrum-мероприятия или события

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

ВИДЕО

Ниже приведен список всех ключевых мероприятий, в которых может принять участие команда Scrum:

1. Организация списка необходимых требований (backlog): иногда это называется уходом за списком необходимых требований, ответственность за это событие несет владелец продукта. Основными задачами владельца продукта являются продвижение продукта к его видению продукта и постоянное измерение актуального состояния рынка и клиента. Поэтому владелец продукта должен поддерживать этот список в актуальном состоянии, используя отзывы пользователей и команды разработчиков, чтобы помочь расставить приоритеты и сохранить список готовым к использованию в любой момент времени. Вы можете прочитать больше о поддержании списка необходимых требований (backlog) здесь.
2. Планирование спринта: объем работ, которые необходимо выполнить во время текущего спринта, планируется на этом собрании всей командой разработчиков. Эта встреча проводится мастером Scrum и именно на этом совещании команда выбирает цель спринта. Затем в спринт на основе списка необходимых требований продукта добавляются конкретные истории использования. Эти истории всегда конкретизированы и также согласованы командой Scrum, чтобы их можно было реализовать во время спринта.

В конце собрания по планированию каждый участник Scrum должен иметь четкое представление о том, что может быть доставлено в спринте и как можно получить приращение.

3. Спринт: Спринт - это фактический период времени, когда команда Scrum работает вместе, чтобы завершить приращение. Две недели - это довольно типичная продолжительность для спринта, хотя некоторые команды считают, что неделю легче охватить, а месяц - более ценный прирост. Дейв Уэст из Scrum.org сообщает, что чем сложнее работа и чем больше неизвестных, тем короче должен быть спринт. Но это при условии что это действительно подходит вашей команде, и вы не должны бояться изменений, если эта модель не работает! В течение этого периода продолжительность спринта может быть пересмотрена между владельцем продукта и командой разработчиков при необходимости. Это формирует суть эмпирической природы Scrum.

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

4. Ежедневные Scrum или летучки (stand-up): это ежедневная супер-короткая встреча, которая происходит в одно и то же время (обычно по утрам). Многие команды пытаются завершить встречу за 15 минут. Эта встреча также называется «ежедневным занятием», подчеркивая, что она должна быть быстрой. Цель ежедневной схватки состоит в том, чтобы все члены команды были в резонансе, выровнены с целью спринта и прикинули план на предстоящий рабочий день.

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

Распространенным способом проведения совещаний является порядок, когда каждый член проектной команды отвечает на три вопроса в контексте достижения цели спринта:

• Что я делал вчера?
• Что я планирую сделать сегодня?
• Есть ли препятствия?

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

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

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

Три основные роли для успеха Scrum

Команде Scrum нужны три конкретные роли: владелец продукта, мастер Scrum и команда разработчиков. А поскольку команды разработчиков Scrum являются кросс-функциональными, в состав команды разработчиков входят как тестировщики, дизайнеры, специалисты по UX, так и инженеры по операциям в дополнение к разработчикам.

Владелец продукта Scrum

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

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

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

Мастер Scrum

Мастера Scrum- лидеры Scrum в пределах своих команд. Они тренируют команды, владельцев продуктов и бизнес в процессе Scrum и ищут способы повысить их эффективность.

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

Команда разработчиков Scrum

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

Члены команды имеют разные наборы навыков и взаимно обучают друг друга, поэтому никто не становится узким местом при выполнении работы. Сильные Scrum-команды самоорганизуются и подходят к своим проектам с четким отношением «мы». Все члены команды помогают друг другу обеспечить успешное завершение спринта.

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

Scrum, Kanban и Agile

Scrum - настолько популярный Agile-подход, что Scrum и Agile часто неправильно воспринимают за одно и то же. Но есть и другие Agile-подходы, такие как Kanban, который является популярной альтернативой. Некоторые компании предпочитают следовать гибридной модели Scrum и Kanban, которая получила название Scrumban или Kanplan.

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

Scrum фокусируется на меньших итерациях фиксированной длины. После того, как период времени для спринта завершен, определяются истории или записи списка необходимых требований (backlog) продукта, которые могут быть реализованы в течение этого цикла спринта. Однако в kanban число заданий или незавершенного производства (незавершенную работу) (work in progress лимит WIP), которые должны быть реализованы в текущем цикле, который сначала фиксируется. Время, необходимое для реализации этих функций, затем рассчитывается в обратном направлении.

Kanban не так структурирован, как Scrum. Помимо лимита WIP, он достаточно открыт для интерпретации. Scrum, однако, имеет несколько категориальных концепций, применяемых в рамках его реализации, таких как обзор спринта, ретроспектива, ежедневный scrum и т. д. Он также настаивает на кросс-функциональности, которая заключается в способности scrum-команды не зависеть от внешних членов для достижения своих целей. Собрать кросс-функциональную команду не так просто. В этом смысле kanban легче адаптировать, в то время как scrum может рассматриваться как фундаментальный сдвиг в мыслительном процессе и функционировании команды разработчиков.

Но почему scrum?

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

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

Однако освоение Scrum может занять некоторое время, особенно если команда разработчиков адаптируется к типичной модели водопада (waterfall model). Концепции меньших итераций, ежедневных встреч Scrum, обзоров спринтов и определения мастера scrum могут стать сложным культурным сдвигом для новой команды.

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

По материалам  Agile Coach "What is Scrum?"