Простое руководство по методологии совместной работы Scrum

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

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

Давайте приступим к делу!

Введение в метод совместной работы Scrum

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

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

Обычно в Scrum участвует сплоченная команда, состоящая из пяти-семи человек. В команде Scrum есть три роли: владелец продукта, мастер Scrum и общие члены команды. Члены команды будут заниматься разработкой продукта.

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

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

Преимущества Scrum по сравнению с традиционными методами разработки

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

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

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

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

Как реализовать метод совместной работы Scrum (7 ключевых шагов)

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

Шаг 1. Создайте бэклог продукта, чтобы описать основные функции

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

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

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

Шаг 2. Проведите «собрание по планированию спринта», чтобы определить свои цели

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

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

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

Шаг 3. Добавьте элементы в журнал спринта, чтобы не отвлекаться от задачи

После того, как вы определили цели для своего первого спринта, ваша команда может создать «Бэклог спринта» - еще один документ, предназначенный для того, чтобы помочь вашей команде сосредоточиться на задаче. Многие команды создают бэклоги спринта, используя доску и стикеры, организованные в три столбца: «текущие дела», «в процессе» и «готово».

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

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

Шаг 4. Включите ежедневные встречи, чтобы поддерживать общение

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

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

Шаг 5. Представьте результаты спринта владельцу продукта для обратной связи

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

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

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

Шаг 6. Проведите ретроспективное собрание спринта, чтобы обсудить, что ваша команда может улучшить

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

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

Шаг 7. Повторите предыдущие шаги, чтобы создать законченный конечный продукт.

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

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

Заключение

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

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

У вас есть вопросы о методе совместной работы Scrum? Задайте их в разделе комментариев ниже!

Миниатюра изображения статьи: Андрей Рыбалко / shutterstock