Скрам: Правила игры. Карманное руководство

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

3.2. ВОПРОСЫ ЕЖЕДНЕВНОГО СКРАМА

На ежедневной встрече каждый игрок должен отвечать на три вопроса, относящихся к продвижению команды к цели спринта: сделал? запланировал? проблемы?

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

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

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

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

Вы знали, что ежедневный скрам – необязательно ежедневное короткое собрание команды?

Ежедневное короткое собрание команды – это практика, описанная в экстремальном программировании[28], которая служит той же цели, что и ежедневный скрам. Но экстремальное программирование советует последователям проводить это мероприятие стоя.

В скраме не обязательно стоять. Однако это хорошая тактика, особенно если вы хотите уложиться в 15 минут.

3.3. УТОЧНЕНИЕ БЭКЛОГА ПРОДУКТА

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

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

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

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

3.4. ПОЛЬЗОВАТЕЛЬСКИЕ ИСТОРИИ

В экстремальном программировании требования фиксируются в виде пользовательских историй. Эти истории пишутся на карточках и описывают функциональные ожидания с точки зрения пользователя. Билл Уэйк, ранний энтузиаст экстремального программирования, предложил акроним INVEST[29] как простой способ запоминания, а также оценки того, хорошо или плохо сформулирована пользовательская история: независимая, обсуждаемая, ценная, оцениваемая, небольшая, тестируемая.