Кен Швабер

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

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

скрам-команды являются кросс-функциональными.

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

Эта кросс-командная координация очень похожа на то, что позже стало называться скрам скрамов (Scrum of Scrums) — встреча и подход, при котором работа нескольких команд разработки координируется участниками от каждой команды. Такой способ самоорганизации работы команд заметно помог издательству Tree, и первые четыре журнала начали появляться в сети в течение трех месяцев, а пятый и следующие не заставили себя долго ждать.

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

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

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

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