Scrum master activities - best practices
Принципы
Практики
Работа с product backlog
Список требований, историй, функциональности, которые упорядочены по степени важности. При этом все требования описаны на понятном для заказчика языке.
Описание каждой истории включает в себя:
• ID – уникальный идентификатор – просто порядковый номер (для идентификации
историй в случае их переименования.)
• Название – краткое описание истории, должно быть однозначным, чтобы все понимали о чем идет речь, и отличить одну историю от другой.
• Важность (Importance) – степень важности данной задачи, по мнению product owner'а.
Например, 10 или 150. Чем больше значение, тем выше важность.
• Предварительная оценка (initial estimate) – начальная оценка объема работ, необходимого для
реализации истории по сравнению с другими историями. Измеряется в story point’ах.
Приблизительно соответствует числу “идеальных человеко-дней”.
• Как продемонстрировать (how to demo) – краткое пояснение того, как завершённая задача будет
продемонстрирована в конце спринта.
Вроде простого тестового сценария типа “Сделайте это, сделайте то – должно получиться то-то”.
• Примечания – любая другая информация, представлена в форме кратких тезисов.
Пример
☀ Хранение product backlog в Excel таблице с возможностью совместного доступа (несколько пользователей могут редактировать файл одновременно).
Дополнительные поля для истории:
• Категория (нужно для объединения блока историй);
• Компоненты – указывает, какие компоненты будут затронуты при реализации истории. Поле состоит из группы checkbox’ов, которые отмечаются, если соответствующие компоненты требуют изменений. Поле “компоненты”
окажется особенно полезным, если у вас несколько Scrum команд, например, одна, которая
работает над панелью управления и другая, которая отвечает за клиентскую часть. В данном
случае это поле существенно упростит для каждой из команд процедуру выбора истории, за
которую она могла бы взяться.
• Инициатор запроса (requestor). Product owner может захотеть хранить информацию о всех
заказчиках, заинтересованных в данной задаче. Это нужно для того, чтобы держать их в курсе дела
о ходе выполнения работ.
• ID в системе учёта дефектов (bug tracking ID) – если вы используете отдельную систему для учёта
дефектов (например. Jira), тогда в описании истории полезно хранить ссылки на все дефекты,
которые к ней относятся.
☀
☀
☀