Как быть с большими неразделяемыми историями в SCRUM?

Question

[V Sh.]

Добрый день!
Пытаюсь понять и по возможности внедрить "SCRUM для одного" для своих проектов, не всегда информационных. И возник вопрос: как можно написать историю в Product backlog, если результаты достигаются за время, превышающие длительность спринта и достигающиеся посредством регулярности выполнения, а не суммарного времени, затраченного на решение? Например, обучение игре на гитаре, достижение каких-то успехов в спорте (похудеть, привести себя в оптимальную форму). Выделяя по часу в день-два все это достигается, предположим, за три-четыре месяца. Но как это отразить по методологии SCRUM?
Если переводить это в информационную плоскость, то будет что-то типа "получить историю запросов пользователей на протяжении четырех месяцев работы приложения". И как с такой историей работать? Как правильно для нее рассчитать объем работ в стори поинтах?

Comments

[Владислав Лысков]

"SCRUM для одного"

такого не бывает и быть не может

[V Sh.]

Владислав Лысков, можете аргументировать? Лично я не нашел ничего, что бы могло этому противоречить. Бэклоги, задачи, оценка объема работ - нигде не фигурирует количество человек в команде.

Answer 1

[dollar]

Необходимо так или иначе разделить на подзадачи, которые укладываются в итерацию. Если вы не знаете, как именно это сделать, значит вам нужно глубже погрузиться в предметную область и разобраться, как она устроена в деталях, либо отказаться от SCRUM.

"Обучение игре на гитаре" - 1) тренируем пальцы 2) учим основные аккорды 3) учим конкретную мелодию. Ну или совсем банально: урок 1, урок 2, урок 3 (если есть учебник, то там это уже сделано за вас).

"Похудеть" - аналогично. 1) Сбросить 1.5кг 2) Сбросить 1.5кг 3) Сбросить 1.5кг. Если есть этапы в методике похудения, то использовать их.

Как сказал выше, можно отказаться от SCRUM. Надеюсь вы понимаете, что его нельзя пихать везде без разбору. Есть кейсы, где SCRUM очень плохо работает, а другой метод заходит на ура. Те же примеры с обучением и голоданием не требуют никакого скарама.

получить историю запросов пользователей на протяжении четырех месяцев работы приложения

Наладить сохранение истории запросов пользователей в базу. (1 день)
Или
Скачать и проанализировать историю запросов пользователей за последние 4 месяца. (1 день)

Comments

[V Sh.]

Да, с историей запросов не совсем верная аналогия. Скорее что-то типа еженедельного тестирования/рефакторинга: обязательного на протяжении какого-то периода и никак не автоматизируемого. Знаю, что некоторые закладывают это не в бэклог, а куда-то еще, и просто уменьшают фокус-фактор. Скорее всего на SCRUM доске не получится отобразить растянутую во времени историю. Либо делить, либо не отображать...

Answer 2

[Robur]

Вы путаете задачи с процессами и результатами.

"получить историю запросов пользователей на протяжении четырех месяцев работы приложения".

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

Назовите мне любую из них которая будет длится все четыре месяца?

Всегда ставьте вопрос "что для этого надо сделать?" и у вас появятся более мелкие вещи.

Даже если вы не можете придумать - они есть.
Например "подергать одну и ту же струну два часа" сегодня. Завтра будет такая же задача, но другая.
Все разбивается вплоть до уровня "нажать А" затем "нажать Б" и это далеко не предел.