Книга: Scrum и XP: заметки с передовой
Уточнение описаний историй
Уточнение описаний историй
Нет ничего ужасней, чем ситуация, когда команда с пафосом демонстрирует новую функциональность продукта, а product owner тяжко вздыхает и говорит: «ну да — всё это красиво, вот только не то, что я просил!»
Как убедиться, что product owner и команда понимают историю одинаково? Или что все члены команды понимают все истории одинаково? Да никак. Есть простые способы выявить разницу в понимании. Наиболее простая практика — всегда заполнять все поля для каждой истории (точнее, для всех историй, которые могут попасть в текущий спринт).
Пример № 1:
Команда и product owner вполне довольны планом на спринт и уже готовы закончить планирование, но тут ScrumMaster говорит: «Минуточку! У нас нет оценки для истории „добавить пользователя“. Давайте-ка оценим!». После пары сдач в planning poker, команда сходится на оценке в 20 story point’а, на что product owner вскакивает с криком: «ЧЕГООО?!?». Пара минут ожесточённых споров и вдруг выясняется, что команда имела в виду «удобный web-интерфейс для функций добавить, редактировать, удалить и искать пользователей», а product owner имел в виду только «добавлять пользователей напрямую в базу данных с помощью SQL-клиента». Команда оценивает историю заново и останавливается на 5-ти story point'ах.
Пример № 2:
Команда и product owner вполне довольны планом на спринт и уже готовы закончить планирование, но тут Scrum master говорит: «Минуточку! Вот тут у нас есть история „добавить пользователя“… Как она может быть продемонстрирована?». Народ пошепчется и через минуту кто-то встанет и начнёт: «ну, для начала надо залогиниться на сайт, потом…», a product owner тут же перебьёт: «залогиниться на сайт?! Не-не-не-не… эта функция вообще к сайту не должна иметь никакого отношения — это будет просто маленький SQL-скрипт, только для администраторов».
Поле «как продемонстрировать» может (и должно) быть очень кратким! Иначе вы не успеете вовремя закончить планирование спринта. По сути, это лаконичное описание на обычном русском языке, как вручную выполнить наиболее общий тестовый пример: «Сделать это, потом это, потом проверить, что получилось так-то».
И я понял, что такое простое описание часто позволяют обнаружить разное понимание объёма работ для историй. Хорошо ведь узнать об этом заранее, не так ли?
- Как мы планируем спринт
- Почему без product owner’а не обойтись
- Почему качество не обсуждается
- Планирование спринта, которое никак не заканчивается
- Распорядок встречи по планированию спринта
- Определяем длину спринта
- Определение цели спринта
- Выбор историй, которые войдут в спринт
- Как product owner может влиять на то, какие истории попадут в спринт?
- Как команда принимает решение о том, какие истории включать в спринт?
- Почему мы используем учетные карточки
- Критерий готовности
- Оценка трудозатрат с помощью игры в planning poker
- Уточнение описаний историй
- Разбиение историй на более мелкие истории
- Разбиение историй на задачи
- Выбор времени и места для ежедневного Scum’а
- Когда пора остановиться
- Технические истории
- Как мы используем систему учёта дефектов для ведения product backlog’а
- Свершилось! Планирование спринта закончено!
- Разбиение историй на более мелкие истории
- 5.4. РЕКОМЕНДАЦИИ НАЧИНАЮЩИМ ПО СОСТАВЛЕНИЮ ОПИСАНИЙ АЛГОРИТМОВ И ЭВРОРИТМОВ
- Глава 6. Реальные примеры применения историй
- Глава 5 ПРОЕКТНАЯ ПРОЦЕДУРА РАЗРАБОТКИ ФУНКЦИОНАЛЬНЫХ ОПИСАНИЙ
- Группу историй организует тема
- 53. Уточнение по публикации потенциального клиента
- 8.8.3. Шаг 2. Уточнение классов с определением набора операций (методов) для каждого
- 8.8.4. Шаг 3. Уточнение классов с точным определением их зависимостей от других классов
- 8.9.4. Уточнение классов с точным определением их зависимостей от других классов. Продолжение учебного примера
- VII. Технологии драматизации адвокатских историй.
- Элемент B4 Рассказывание историй: подготовка простой истории
- 2.2.2. Уточнение вида проектируемого турпродукта и его целей