Обзоры Спринта

Ранние Обзоры Спринта проводились без участия конечных пользователей. Владелец Продукта приглашал на них только внутренних клиентов. Команды хотели попрактиковаться в проведении подобных мероприятий до того, как пригласить на них пользователей. Вот почему первыми посетителями Обзоров Спринта стали сотрудники других отделов: технической поддержки, маркетинга, продаж, управления персоналом и контроля. Я опишу ход обычного Обзора Спринта:

• Владелец Продукта открыл встречу и громко зачитал Цели Спринта, над которыми работала продуктовая группа. Затем Владелец Продукта перечислил элементы, которые уже были выполнены.
• Команды по очереди кратко рассказали о сложностях, с которыми им пришлось столкнуться во время Спринта, и о том, как им удалось (или не удалось) их преодолеть.
• Гостей пригласили посетить станции. Событие было организовано в формате «базара» или ее более структурированном варианте «выставка». На каждой станции у нас было по меньшей мере два разработчика. Один из них демонстрировал Инкремент и просил дать отзывы о нем, а другой просто все записывал.
• После демонстрации мы вернулись к формату открытого обсуждения. Владелец Продукта рассказал о новостях рынка, изменил приоритеты элементов Бэклога Продукта и ответил на все вопросы.
• Затем гости покинули помещение, а команды и Владелец Продукта собрали обратную связь по всем станциям и, когда это требовалось, обновили некоторые из артефактов — карту влияния (impact map), канвас ценностного предложения (value-proposition canvas), карту историй (story mapping) и, конечно, Бэклог Продукта.

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

Конечные пользователи присоединялись к команде разработки один раз в два Спринта. Мы использовали две инновационные игры, которые прекрасно дополняли друг друга: «Быстрая лодка» (Speed Boat) и «Обрезание дерева» (Prune The Tree). «Быстрая лодка» хороша для исследования боли клиентов и выявления задач, которые надо выполнить (jobs-to-be-done). «Обрезание дерева» — для нахождения наилучших решений (фич) для Бэклога Продукта.

Для меня Ретроспектива в Скраме всегда была особым событием. Переход от компонентной к функциональной структуре команды — важнейший шаг для участников. Вот почему я ожидал, что на ранних Ретроспективах проявится огромное количество проблем и вопросов. И я был прав. Первый Спринт стал стрессом для всех команд, и мы объединили общую Ретроспективу (Overall Retrospective) и командные Ретроспективы (Team Retrospective) в одно большое мероприятие, потому что у всех были одни и те же проблемы, и было важно вовлечь в решение проблем всю продуктовую группу. Всеобщее участие и выполнимые улучшения по SMART имели огромное значение. Стресс постепенно снизился, а в последующих Спринтах каждая команда провела свою отдельную командную Ретроспективу в дополнение к общей Ретроспективе.

Системные и командные препятствия. Так как системные препятствия обсуждаются во время общей Ретроспективы, я просил команды отделять их от командных. Я часто использую методику «Круги влияния». Рисую на флипчарте два круга, вложенных друг в друга. Внутренний круг содержит проблемы, с которыми команда может разобраться самостоятельно, а внешний круг — общие проблемы.

Конец Спринта пришелся на конец недели (пятницу), поэтому мы решили проводить общую Ретроспективу во вторник после обеда, в самом начале следующего Спринта. Ее постоянными участниками стали Владелец Продукта, Скрам-мастера и представители команд.

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

Ниже я перечислю несколько вопросов, которые мы обсуждали во время таких Ретроспектив:

• Выполнение определения готовности (DoD) всеми командами.
• Усиление определения готовности.
• Распределение по Спринту багов, попавших в продакшн.
• Взаимодействие команд с группой технической поддержки.
• Изменение цикла релиза.