Наша инженерная команда использует Agile Scrum, и мы, наконец, достаточно растем, чтобы иметь возможность делегировать больше ролей Scrum большему количеству участников, в том числе таким инженерам, как я.
Одна роль, которую мы представляем, на которую я вызвался, называется «вышибала».
Роль вышибалы в этом контексте заключается в следующем:
Очередь работы, отдельная от спринта, доступна для работы вышибал во время простоя. Эта очередь представляет собой небольшие задачи с низким приоритетом, которые не влияют на потребности бизнеса или цели спринта. Выполнение этих задач должно быть остановлено, чтобы вышибала мог выполнить свою роль.
Я ищу гораздо более формальное определение этой роли и любую информацию о ней, которую я могу получить. Есть такая информация? Есть ли у этой роли другие имена, которые дают лучшие результаты поиска?
Как уже говорили другие, в Scrum нет роли под названием «Вышибала». Руководство по Scrum определяет ровно три роли в Scrum Team :
Скрам-команда состоит из владельца продукта, команды разработчиков и скрам-мастера.
Поскольку Scrum-команда является кросс-функциональной, команда, безусловно, может выбрать выполнение любых действий, которые способствуют достижению целей спринта, и может делать это любым способом, который имеет смысл для команды. Однако определение дополнительных ролей (а не процессов) — это антишаблон Scrum, который обычно указывает на основную проблему процесса.
Ваша команда определяет роль «Вышибала» для сортировки и поддержки. Когда ты сказал:
Роль вышибалы в этом контексте заключается в следующем:
общайтесь и отслеживайте поддержку,
исследуйте входящие проблемы и
при необходимости эскалируйте
вы явно описываете повторяющуюся функцию поддержки, а не разработку продукта или ограниченную по времени работу, которые являются областями, для которых был разработан Scrum. Это не означает, что Scrum не допускает исправления ошибок или поддержки; это просто означает, что проектирование процесса поддержки за пределами фреймворка Scrum, а затем включение его обратно в Scrum, как правило, является неправильным решением.
В Scrum вся работа должна быть расставлена по приоритетам в Бэклоге Продукта, оценена во время Планирования Спринта и должна быть связана с текущей Целью Спринта. В правильно реализованной среде Scrum ошибки или дефекты, не относящиеся к текущему Спринту, помещаются в Бэклог Продукта, обсуждаются и расставляются по приоритетам во время Уточнения Бэклога, а затем планируются , если и когда они входят в область действия, во время Планирования Спринта.
Это имеет смысл, потому что Scrum — это, прежде всего, структура управления проектами, и его цель — управлять проектами с определенной областью действия и ограниченной продолжительностью. Текущая поддержка или повторяющиеся процессы не являются проектами, и ими может быть трудно управлять в рамках структуры, разработанной для временных рамок, а не для процедурных циклов.
На мой взгляд, ошибки или дефекты в продукте проекта определенно принадлежат Скрам-команде, но должны обрабатываться в рамках Скрам-фреймворка. Однако постоянная поддержка не должна быть частью Scrum, если только не было принято бизнес-решение о постоянном сокращении возможностей команды по выделению временных рамок для поддержки в каждом спринте.
Лучшей альтернативой является создание отдельного процесса поддержки , возможно, с использованием Канбана или другой гибкой методологии, основанной на циклах или очередях, которая затем могла бы обрабатывать проблемы напрямую или возвращать их обратно в Бэклог продукта Scrum, если это необходимо. Концептуально такой процесс поддержки находится вне фреймворка Scrum, но это не значит, что он должен быть изолирован!
Я использовал Scrum для административных, вспомогательных и бэк-офисных процессов, которые не основаны на проектах. Это можно сделать. Однако центральной особенностью Scrum являются временные рамки, а поддержка по своей сути не зависит от оценок или временных рамок.
Единственный способ, которым я смог заставить Scrum работать в таких непроектных начинаниях, это:
Если вы не согласны со всем вышеперечисленным, то Scrum не подходит для вашего процесса поддержки. Оцените Канбан как альтернативу работе с очередями или найдите другой процесс, более подходящий для вашего бизнеса и политических нужд.
Чтобы узнать больше о том, как справляться с текущими или повторяющимися задачами поддержки в рамках Scrum, или о том, почему Scrum часто является неправильным выбором для управления текущим процессом поддержки, см. следующие связанные ответы:
Похоже, вы описываете классическую роль поддержки вне Teams Sprint. Сортировка очереди поддержки, чтобы оставить команде схватки пространство для выполнения своей основной работы.
Слава вам.
Возможно, вам следует подумать о создании канбан -доски для поддержки вашей работы по сортировке?
Но, чтобы формально ответить на ваш вопрос, нет такой роли Agile Scrum, чтобы описать работу, которую вы делаете. Это связано с тем, что структура Scrum является легкой, что позволяет командам гибко реализовывать ее так, как им удобно.
С уважением
Scrum предписывает только три роли: Scrum Master, Product Owner и Delivery (или Dev) Team.
Тем не менее, ничто не мешает команде решить, как они хотят решать проблемы, с которыми они сталкиваются. Если кто-то берет на себя эти обязанности, это работает на вашу команду, круто. Однако формального определения вы не найдете.
Однако у меня есть один вопрос: почему, когда вы не проводите сортировку поддержки, вы не можете просто помогать другим членам команды в спринтерской работе. Похоже, вы искусственно отделяете себя от команды.
Scrum предусматривает только три роли: Scrum Master, Product Owner и Team Development. Никакие другие роли в Scrum не определены. Поскольку Scrum позволяет делегировать некоторые элементы каждой роли, вы можете дать имя роли, назначенной человеку, которому делегированы определенные задачи, и это имя будет зависеть от вашей организации.
Роль Владельца Продукта отвечает за управление Бэклогом Продукта, и похоже, что большинство этих задач прямо относятся к этой сфере. В частности, руководство по Scrum говорит следующее о владельце продукта :
Владелец Продукта является единственным лицом, ответственным за управление Бэклогом Продукта. Управление бэклогом продукта включает в себя:
- Четкое выражение элементов Бэклога Продукта;
- Упорядочивание элементов в Бэклоге Продукта для наилучшего достижения целей и задач;
- Оптимизация ценности работы, которую выполняет Команда Разработки;
- Обеспечение того, чтобы Бэклог Продукта был видимым, прозрачным и понятным для всех и показывал, над чем Скрам-команда будет работать дальше; и,
- Обеспечение понимания Командой Разработки элементов Бэклога Продукта на необходимом уровне.
Вышеуказанную работу может выполнять Владелец Продукта или поручить это Команде Разработки. Тем не менее, Владелец Продукта остается ответственным.
Если о проблемах сообщается из-за пределов Скрам-команды (которая состоит из трех ролей), то эти проблемы влияют на Бэклог Продукта. Такие вещи, как отчеты об ошибках, изменения в существующих функциях или запросы новых функций, будут новыми или измененными элементами Журнала Продукта.
Обратите внимание, что Владелец Продукта может делегировать некоторые из этих обязанностей Команде Разработки. Конечно, это уменьшит возможности команды. Однако более раннее привлечение технических специалистов может привести к тому, что элементы Бэклога Продукта будут более тщательно проработаны и включены в сеансы Планирования Спринта. Это компромисс, на который должна пойти команда (а иногда и организация).
Одна вещь, которую вы упомянули, «общаться и отслеживать поддержку», может также подпадать под роль Scrum Master . Скрам-мастер оказывает поддержку не только команде разработчиков, но и владельцу продукта и организации. Скрам-мастер должен помогать владельцу продукта находить способы обработки этих входящих запросов и методы надлежащего управления бэклогом продукта, включая написание хороших элементов бэклога продукта. Скрам-мастер также несет ответственность за устранение любых препятствий для Команды Разработки.
Помимо всего этого определения Scrum, вы можете определить другие задачи, которые необходимо выполнить в ходе спринта, и кто будет нести ответственность за их выполнение. И вам решать, как правильно определить эти роли и найти хорошие способы их делегирования на постоянной или ротационной основе.
Лично я считаю, что Владелец Продукта, возможно, при поддержке одного члена Команды Разработки (возможно, на ротационной основе) и Скрам-мастера, должен взять на себя инициативу по этим вопросам. Изучение входящих проблем и превращение их в элементы Бэклога Продукта, безусловно, является функцией Владельца Продукта, которую можно делегировать. Работа над устранением препятствий, безусловно, является функцией Скрам-мастера, которая может включать в себя соответствующую эскалацию. Отслеживание поддержки может быть общей ответственностью, но я считаю, что это задача, которую должен выполнять скрам-мастер, чтобы позволить команде разработчиков сосредоточиться на разработке, а не на отслеживании работы других людей.
Вики Лейдлер
Мэтт Уолтер
Алан Лаример