Ранние Обзоры Спринта проводились без участия конечных пользователей. Владелец Продукта приглашал на них только внутренних клиентов. Команды хотели попрактиковаться в проведении подобных мероприятий до того, как пригласить на них пользователей.
Обзоры Спринта
Ранние Обзоры Спринта проводились без участия конечных пользователей. Владелец Продукта приглашал на них только внутренних клиентов. Команды хотели попрактиковаться в проведении подобных мероприятий до того, как пригласить на них пользователей. Вот почему первыми посетителями Обзоров Спринта стали сотрудники других отделов: технической поддержки, маркетинга, продаж, управления персоналом и контроля. Я опишу ход обычного Обзора Спринта:
- Владелец Продукта открыл встречу и громко зачитал Цели Спринта, над которыми работала продуктовая группа. Затем Владелец Продукта перечислил элементы, которые уже были выполнены.
- Команды по очереди кратко рассказали о сложностях, с которыми им пришлось столкнуться во время Спринта, и о том, как им удалось (или не удалось) их преодолеть.
- Гостей пригласили посетить станции. Событие было организовано в формате «базара» или ее более структурированном варианте «выставка». На каждой станции у нас было по меньшей мере два разработчика. Один из них демонстрировал Инкремент и просил дать отзывы о нем, а другой просто все записывал.
- После демонстрации мы вернулись к формату открытого обсуждения. Владелец Продукта рассказал о новостях рынка, изменил приоритеты элементов Бэклога Продукта и ответил на все вопросы.
- Затем гости покинули помещение, а команды и Владелец Продукта собрали обратную связь по всем станциям и, когда это требовалось, обновили некоторые из артефактов — карту влияния (impact map), канвас ценностного предложения (value-proposition canvas), карту историй (story mapping) и, конечно, Бэклог Продукта.
Фокус на продукте целиком. Я заметил, что разработчики, которые не были активно вовлечены в работу на станциях, постоянно перемещались между станциями и давали обратную связь своим коллегам. Они становились по-настоящему заинтересованы в работе остальных. Иногда образовывались небольшие группы людей, которые обсуждали продукт.
Попробуйте инновационные игры.
Конечные пользователи присоединялись к команде разработки один раз в два Спринта. Мы использовали две инновационные игры, которые прекрасно дополняли друг друга: «Быстрая лодка» (Speed Boat) и «Обрезание дерева» (Prune The Tree). «Быстрая лодка» хороша для исследования боли клиентов и выявления задач, которые надо выполнить (jobs-to-be-done). «Обрезание дерева» — для нахождения наилучших решений (фич) для Бэклога Продукта.
Ретроспективы Команд
Для меня Ретроспектива в Скраме всегда была особым событием. Переход от компонентной к функциональной структуре команды — важнейший шаг для участников. Вот почему я ожидал, что на ранних Ретроспективах проявится огромное количество проблем и вопросов. И я был прав. Первый Спринт стал стрессом для всех команд, и мы объединили общую Ретроспективу (Overall Retrospective) и командные Ретроспективы (Team Retrospective) в одно большое мероприятие, потому что у всех были одни и те же проблемы, и было важно вовлечь в решение проблем всю продуктовую группу. Всеобщее участие и выполнимые улучшения по SMART имели огромное значение. Стресс постепенно снизился, а в последующих Спринтах каждая команда провела свою отдельную командную Ретроспективу в дополнение к общей Ретроспективе.
Системные и командные препятствия. Так как системные препятствия обсуждаются во время общей Ретроспективы, я просил команды отделять их от командных. Я часто использую методику «Круги влияния». Рисую на флипчарте два круга, вложенных друг в друга. Внутренний круг содержит проблемы, с которыми команда может разобраться самостоятельно, а внешний круг — общие проблемы.
Общие Ретроспективы
Конец Спринта пришелся на конец недели (пятницу), поэтому мы решили проводить общую Ретроспективу во вторник после обеда, в самом начале следующего Спринта. Ее постоянными участниками стали Владелец Продукта, Скрам-мастера и представители команд.
Видение совершенства и восемь тем для обсуждения. В начале разработки команды создавали видение совершенства. Это недостижимый на практике чек-лист, показывающий, как организация может выглядеть в идеале. Каждое решение, принятое во время общей Ретроспективы, изучалось на предмет того, насколько оно соответствует видению совершенства.
Ниже я перечислю несколько вопросов, которые мы обсуждали во время таких Ретроспектив:
- Выполнение определения готовности (DoD) всеми командами.
- Усиление определения готовности.
- Распределение по Спринту багов, попавших в продакшн.
- Взаимодействие команд с группой технической поддержки.
- Изменение цикла релиза.
