Учитывая последовательные изменения, насколько короткий период планирования слишком короткий?

Изменения не редкость, изменение требований, изменение спецификаций, изменение рабочего процесса. Я согласился, что будут перемены, но мне интересно: зная, что произойдут перемены, насколько короткий период планирования слишком короткий? (Обоснования приветствуются)

• Итерация (2-4 недели)?
• Неделя?
• 2-3 дня?
• День?
• 1/2 дня?

Предположим, что компания «планирует» 1 [временной интервал (сверху)] заранее от текущего, так что любой план звучит так:

«[этим утром / сегодня / на этой неделе / ​​и т. д.] ты будешь работать над этим, а [[сегодня / завтра / на следующей неделе / ​​и т. д.] ты будешь работать над этим» .

Также предположим, что изменения в фокусе / направлении будут последовательно происходить каждый второй-третий интервал времени.

Я практик Scrum, поэтому я предложу вам использовать его.

1. Определите продолжительность вашей итерации. Мне нравится двухнедельная итерация в стартапах и один месяц в крупных корпоративных проектах
2. В начале итерации выберите из функций, которые вы будете разрабатывать, из журнала ожидания продукта. Никто не имеет права менять план итерации, даже менеджер по продукту.
3. Изменения происходят в резерве продукта, а не в плане итераций. Таким образом, вы никогда не будете затронуты в вашей работе.

Подробнее о Scrum

Планирование часто приводит к потере большей картины во всех деталях, и в итоге вы просто крутите колеса. Это огромный риск.

Я предпочитаю использовать XP (или Scrum), который говорит, что вы должны планировать один раз в начале каждой итерации, что я считаю наиболее эффективным, когда они имеют продолжительность 1-2 недели.

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

Я разбиваю вещи так:

1. Любой значимый проект / разработка приложения - 1 неделя.
2. Простые одноразовые усовершенствования добавляются в список по приоритетам, и каждое из них рассматривается в периоды от половины до полного дня.
3. Исправления ошибок обычно имеют приоритет и проходят через процесс, аналогичный # 2, но иногда могут быть исправлены намного быстрее.

Ключевым фактором здесь является то, сколько планирования вы действительно можете сделать для конкретной задачи? Запуская новый веб-сайт, который делает yadda, yadda, yadda, есть больше планирования заранее, чем исправление ошибки. Кто планирует ошибки заранее? Менеджер отдела обнаруживает, что они что-то забыли и нуждаются в этом в конце отчетного квартала, вы должны отложить все в сторону и работать над этим.

Еженедельная итерация может длиться 10 часов или может составлять 50. Все зависит от того, сколько другого материала происходит немедленно. Я думаю, что руководству гораздо проще понять временные ограничения, когда вы спрашиваете, следует ли отложить проект, чтобы сделать небольшое дополнение? Я приятно удивлен, когда они считают это небольшое изменение ненужным, и я должен продолжать работать над сайтом yadda-yadda-yadda-website.