Scrum: Що робити, якщо власник продукту має завдання?

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

Чи доцільно, щоб завдання власника продукту (які переважно стосуються досліджень) змішувались із завданнями команди (деякі з них - це дослідження, а деякі - розробку).

Експерти Scrum дуже твердо заявляють, що власник продукту та Scrum Master повинні бути двома різними людьми. Однак не існує такого правила, яке виключає жодну команду з розвитку. Примітка у посібнику з Scrum :

Розмір команди розміру

Оптимальний розмір команди розробки досить малий, щоб залишатися спритним і досить великим, щоб виконати значну роботу. Менше трьох членів групи з розвитку зменшує взаємодію та призводить до менших підвищення продуктивності. Менші команди розвитку можуть зіткнутися з обмеженнями у навичках під час спринту, через що команда розвитку не зможе доставити потенційно звільнений приріст. Мати більше дев'яти членів вимагає занадто великої координації. Великі команди розвитку розробляють надто багато складності для емпіричного процесу управління. Ролі Власника продукту та Scrum Master не включаються до цього підрахунку, якщо вони також не виконують роботу Блоку спринту.

Наслідком цього останнього рядка буде те, що якщо Власник продукту виконує роботу Блоку спринту, він або вона зараховується до складу Команди розвитку.

Це означає, що робіть будь-які роботи, щоб ваша робота була добре виконана.

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

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

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

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

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