Команда разрабатывает продукт для какого-то рынка. Еще нет ни одного конкретного заказчика, product owner – внутренний product manager. И в какой-то момент понимаешь, что разработан большой объем функциональности, но с точки зрения пользователя это не работает – баг здесь, баг там, небольшая, но очень важная функциональность не реализована, так как команда вполне довольна, добавляя данные напрямую через базу данных. Product owner периодически выражает свою озабоченность, но это как-то не помогает. Разработка первой версии продукта весьма тяжелая задача, команда теряет энтузиазм, так как не видит реального заказчика. Качество падает. Что делать?
В Scrum есть такое понятие, как sprint demo – новая версия показывается заказчику (product owner’у). Обычно проводится более-менее закрыто – команда, product owner и, возможно, кто-то из stakeholder’ов. «Открытое» sprint demo имеет некоторые плюсы:
- Знание о том, что demo будет открытым, и что там будут присутствовать коллеги, создает более сильный commitment
- Заставляет команду подумать о том, как продукт используется с точки зрения пользователя – нужно будет показывать это
- Продукт становится более стабильным – редко кто хочет показывать нестабильный продукт коллегам
- Это позволяет другим командам иметь какое-то представление о том, что происходит в компании
- Команда имеет возможность похвастаться своими достижениями
- Улучшает презентационные навыки команды
- Иногда можно получить ценные замечания от присутствующих
- Успешное публичное sprint demo дает команде сильное ощущение того, что они чего-то добились
Иногда невозможно (или бессмысленно) проводить публичное sprint demo. Например, когда:
- Контракт запрещает демонстрацию продукта даже другим сотрудникам компании
- Возможности продукта тяжело продемонстрировать, например, framework
Хотя в случае framework’a можно построить демо-приложение (что будет полезно и пользователям framework’а)
Не все так просто
Если бы «открытое» sprint demo было легко проводить, его организовывали бы чаще. Есть много сложностей, одними из основных являются:
- Команда боится публичной демонстрации
- Не привыкли работать с широкой аудиторией
- Боятся критики – помощь со стороны менеджера проекта/Scrum master/кого-то из stakeholder’ов будет весьма кстати
- Много ошибок в продукте – следующий раз продукт будет более стабильным
- Компания настолько разрозненна, что никто не интересуется работой других – это может быть серьезной проблемой и результаты публичной демонстрации являются хорошим индикатором
- После неудачного спринта – в этом случае особенно полезно делать sprint demo открытым. Это заставит команду проанализировать допущенные ошибки. Но нужно помочь команде понять, что иногда это случается, жизнь на этом не заканчивается – лучше подумать о том, как избежать таких проблем в будущем. Команда становится более стрессоустойчивой.
Когда команда проводит первую открытую демонстрацию, может прийти удивительно большое количество коллег. Поэтому стоит планировать демонстрацию в какой-нибудь конференц-комнате с проектором. Команда должна заранее создать демонстрационные сценарии и данные для них.
Результаты
История в начале статьи взята из реальной жизни. Помогла ли открытая демонстрация? Да.
В начале было сильное неприятие самой идеи. Но, после некоторого нажима со стороны менеджера проекта, команда согласилась провести открытое sprint demo. Одним из основных опасений команды было то, что никто не придет. Сюрприз – пришло так много людей, что пришлось перенести демонстрацию в большее помещение.
В итоге продукт стал более удобным и стабильным. Настроение в команде поднялось – проведение демонстрации и возможность похвастаться перед коллегами привнесло оживление.
Можно ли сказать, что эта практика должна быть обязательно применена каждой командой? Нет. Но в определенных ситуациях она принесет пользу. Пробуйте.
