Дмитрий Блинов

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

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

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

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

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

Когда это возможно, скрам-мастер старается ускорить необходимые изменения. Результатом часто является повышение производительности и больший возврат от инвестиций. Однако иногда эти изменения культурно неприемлемы, скрам-мастер должен вовремя это почувствовать и уступить. Помните, что «скрам – это искусство возможностей». Мертвая пастушья собака – бесполезная собака.

Какие препятствия могут помешать мне и команде достичь цели спринта?

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

Скрам-мастеру часто приходится бороться с 20-летней историей конфронтаций внутри компании, где каждая сторона видит в другой источник чего-то ценного, но почти недоступного.

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