Враховуючи послідовну зміну, наскільки короткий термін планування занадто короткий?

Зміни не рідкість, зміна вимог, зміна специфікацій, зміна робочого процесу. Я прийняв, що зміни відбудуться, але мені цікаво: знаючи, що зміни відбудуться, наскільки короткий термін планування занадто короткий? (Виправдання заохочуються)

• Ітерація (2-4 тижні)?
• Тиждень?
• Період 2-3 днів?
• День?
• 1/2 на день?

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

"[цього ранку / сьогодні / цього тижня / тощо.] ви будете працювати над цим, і [сьогодні вдень / завтра / наступного тижня / тощо] ви будете працювати над цим .

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

Я практикувач Scrum, тому я запропоную вам використовувати його.

1. Визначте тривалість ітерації. Мені подобаються два тижні ітерації в стартапах і один місяць у великих корпоративних проектах
2. На початку ітерації виберіть із функцій, які ви розробляєте, із запущених продуктів. Ніхто не має права змінювати план ітерацій, навіть менеджер продукту.
3. Зміни відбуваються у відставанні виробу, а не в ітераційному плані. Тому вас ніколи не зачіпають у вашій роботі.

Детальніше про Scrum

Планування часто має тенденцію до того, щоб у всіх деталях губилася велика картина, і ви в кінцевому підсумку крутитеся колесами. Це величезний ризик.

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

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

Я розбиваю речі так:

1. Будь-яка значна розробка проекту / заявки - 1 тиждень.
2. Прості разові вдосконалення кидаються у список із пріоритетністю, і кожне з них звертається за періоди від пів до повного дня.
3. Виправлення помилок зазвичай мають пріоритет і проходять подібний процес, як №2, але іноді їх можна виправити набагато швидше.

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

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