Отправляет ли Владелец Продукта в Контроль изменений перед повторной подготовкой Бэклога Продукта?

Управление изменениями не является гибким инструментом определения масштаба

Если он/она хочет изменить область действия путем добавления/исключения/перестановки приоритетов в Журнале невыполненных работ, PO должен подать Формальный запрос на изменение/IOCA, прежде чем принять утвержденное Изменение Скрам-мастеру для рассмотрения на предмет планирования.

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

Анализ и рекомендации

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

Заинтересованные стороны через Владельца Продукта могут добавлять или удалять элементы из Бэклога Продукта в любое время . Единственное, чего они не могут сделать, — это изменить истории в рамках текущего Спринта , если только Владелец Продукта не потребует досрочного завершения и возврата к Планированию Спринта.

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

Тем не менее, такая тяжеловесная поддержка является значительным «запахом проекта», который обычно указывает на то, что организация не приняла итеративную модель разработки и, вероятно, не понимает, как эффективно использовать встроенные средства управления процессами фреймворка. Обучение организации фреймворку Scrum — это работа Scrum Master, а эффективное управление заинтересованными сторонами — это работа Product Owner.

Пересмотрите выбор фреймворка

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

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

Я никогда этого не делал, и это было бы серьезным анти-шаблоном, потому что:

1. Вы препятствуете переменам
2. Вы исключаете ПО из команды, хотя бы косвенно

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

Наконец, нередко команды работают традиционным способом (BDUF, Waterfall и т. д.), используя при этом особые agile-методы, такие как роль, ежедневные схватки и спринты. Это не Scrum, но все же лучше, чем отсутствие интервалов для «проверки и адаптации». Я подозреваю, что это может относиться к вам, поэтому может потребоваться установление барьеров для изменений, чтобы проект продвигался вперед и оставался в рамках.