Коли чисельність команди налічує понад 10, ви все ще можете разом планувати випуск?

Вирішуючи, над чим працювати над наступним випуском, та оцінюючи терміни для кожної історії користувача (та підзадачі для даної історії), ви, хлопці, робите це в групі чи просто менеджери?

Для команди, чисельність 10, це практично?

Скільки часу це займає?

Визначення пріоритетів повинен здійснювати один власник продукту за участю різних зацікавлених сторін, включаючи старшого розробника, який є учасником коду та який відповідає за нефункціональні вимоги, оскільки бізнес-зацікавлений сторон відповідає функціональним вимогам.

Оцінка повинна бути абсолютно зроблена людьми, які будуть виконувати роботу, а не менеджером, який чинить тиск, але ваш інстинкт правильний, що більше півтисячі людей витратять години, сперечаючись над цим. В ідеальному світі ви дійсно повинні розбити команду таким чином, щоб в одній команді було не менше 4 і не більше 7 - 5 ідеально, ІМХО.

Якщо це абсолютно неможливо з якихось причин - і вам потрібно застосувати до цієї причини 5 балів , перш ніж визнати, що це неможливо - тоді команда повинна обрати групу з 4-5 осіб, яка б зробила оцінки від свого імені.

На мою думку, НЕ слід займатися плануванням випуску як команда з 10 осіб. Швидше за все, ви закінчите гігантську зустріч, де в будь-якій дискусії 6-8 людей почуватимуться повністю відключеними і нудно. Додайте до цього виснаження за 3-4 години, зачинені в кімнаті разом. І врахуйте, що якщо 10 людей розмовляють, у вас занадто багато розмови. Якщо вони не розмовляють, можливо, ви не отримаєте цінний внесок.

Ми зробили щось дуже схоже на компанію Йосифа. У попередньому випуску у нас було 8 інженерів, а планування випуску зайняло 2 суцільних тижні. І це було абсолютно жорстоко. Кілька годин кожного дня, я думаю, що всі ми починаємо намагатися говорити якомога менше, щоб зустріч закінчилася швидше.

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

Потім кожен ведучий повертався до своєї команди і перебирав частину релізу, за яку відповідала лише ця команда. За цей час ми заповнили деякі деталі та призначили значення точок історії.

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

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

Якщо можливо, я б рекомендував розділити 10 розробників на 3 групи. Якщо ви не можете розділити загальний реліз на 3 області, що переважно не перетинаються, то навіть 2 групи будуть кращими за одну велику команду.

Я насправді є частиною декількох проектів (і декількох команд) як ведуча, і є кілька, які є 10+. Майже на всіх проектах, над якими я працюю, планування випуску виконується ведучими та бізнес-аналітиками. Однак у нашій ситуації керівники управління не є менеджерами, тому менеджери насправді не беруть участь у плануванні випуску.

Оцінка проводиться командою з впровадження, і хоча обидві частини є окремими, вони дуже пов'язані.

Оцінка - це скільки часу займає завдання, щоб виконати завдання, тоді як планування випуску - це коли заплановано працювати над цими завданнями.

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

Це завдання ефективніше виконує менеджер. У невеликих командах ролі, як правило, змішуються. Усі беруть участь у всьому. Але в міру зростання вашої команди це стає некерованим, і ролі потрібно чітко визначати.

Стільки, як у мене виникає бажання брати участь у всьому, це просто не продуктивно.