Scrum не является методологией или процессом управления

Методология – это совокупность методов, правил и постулатов, применяемых в дисциплине; конкретная процедура или набор процедур . Методология не работает в сложной и непредсказуемой области. В сложных (комплексных) областях команды должны использовать эмпирический подход. Они должны быть в состоянии определить свои собственные процессы и методы и адаптировать их.

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

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

Scrum – это не процесс управления, но он может помочь контролировать риски. Скрам может сделать “пустые” расходы (лишние траты) более прозрачными для повышения эффективности процессов. Scrum может помочь обеспечить согласованность с бизнес-целями. Постоянно фокусируясь на создании «готового» инкремента, команда одновременно управляет риском по поставке.

Scrum – это не «серебряная пуля» или способ заставить разработчиков работать быстрее

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

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

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

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

Основная цель владельца продукта – не документирование требований

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

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

Бэклог продукта не является agile версией традиционного документа с требованиями

С помощью Scrum организация фокусируется на поставке частей ценной функциональности.

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

Кроме того, бэклог продукта не следует рассматривать как контракт, который препятствует совместным переговорам и открытости к изменениям.

Бэклог продукта – это не список всех запросов

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

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