Определение Scrum

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

История термина Scrum

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

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

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

Три основных принципа, лежащих в основе Scrum:

• Общее (визуальное) рабочее пространство;
• Самоорганизация;
• Эмпиризм.

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

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

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

Три столпа Scrum:

• Прозрачность
• Инспекция 
• Адаптация

Подходит ли гибкая методология Скрам для вас?

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

Давайте рассмотрим пример людей, работающих на стройке. Посмотрите на количество инструментов, которое они носят на своих поясах и в карманах. У них всегда есть основные инструменты: рулетка, карандаш, каска, листок бумаги и защитные очки. И наличие всех остальных инструментов зависит от работы, которую они планируют выполнить сегодня. Если рабочий выполняет работу по электрике, он берет с собой инструменты, необходимые для электрики. Когда он занимается финишной отделкой или укладкой плитки, он использует другой набор. Весь набор инструментов всегда находится либо в машине, либо на складе. Как это относится к Scrum?

Я рассматриваю Scrum как инструмент на поясе у рабочего. Руководитель должен использовать Scrum, когда это уместно, что может быть не в 100% случаев. Так же, как вы не используете отвертку для забивания гвоздя, вы не должны использовать Scrum в проекте, который не подходит для этого. Итак, когда вам следует использовать гибкую методологию Скрам?

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

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

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