Кен Швабер

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

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

я объяснил команде разработки концепцию трассирующей пули, представленную Эндрю Хантом и Дэвидом Томасом в книге «Программист-прагматик. Путь от подмастерья к мастеру

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

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

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

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

Почему содержание будущих спринтов было изменено?
■ Почему дата или содержание релиза были изменены?
■ Почему во время спринта команда реализовала меньше требований, чем ожидалось?
■ Куда помещена невыполненная в спринте работа?
■ Почему команда разработки была менее или более эффективной, чем ожидалось?

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

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