Чи може майстер scrum виділити завдання?

Ми слідуємо за течією нашого проекту. Я бачу більшість випадків, коли майстер скраму виділяє завдання для нас. Однак я читаю з багатьох книг про те, що scrum працює навпаки (підхід «тягнути») і члени команди підбирають завдання чи функції. Чи майстер scrum призначає завдання правильним підходом чи це суперечить спритній ідеології?

Відповідно до статті Вікіпедії про Scrum , завдання Sprint не призначаються ScrumMaster:

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

Крім того, визначення ScrumMaster полягає в тому, що він / вона є особою, відповідальною за те, щоб люди дотримувались правил процесу Scrum.

ScrumMaster Людина, відповідальна за процес Scrum, переконайтесь, що він правильно використовується та максимізуючи його переваги.

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

Це справжній Scrum. Звичайно, багато організацій можуть використовувати варіанти цього.

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

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

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

І тоді виникають такі питання особистості, як надмірний контроль Scrum Master та / або розробників, які не можуть зв’язати власне взуття, не кажучи про це. Наприклад, у моєї команди є і те, і інше. Просто працює краще, щоб кожен ігнорував цей маленький факт про Scrum у таких випадках.

Іншими словами, не робіть цього лише тому, що процес говорить. Робіть те, що працює. Закрутіть решту.

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

Ніколи.

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

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

Іншим підходом може бути надання можливості Команді завершити Спринт, притягнути їх до відповідальності за відсутність результатів, а потім дати можливість обговорити це в ретроспективі спринту.

Як і будь-яка ідеологія, бувають випадки, коли книгу правил потрібно викинути або ретельно проігнорувати.

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

Існує велика різниця між розподілом завдань за диктатом (ви РОБИТИ X) та розподілом за обговоренням та згодою. Іноді угода може бути теплою.

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

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

На мою думку, негідник цього не повинен робити, члени команди повинні самі підбирати завдання. Якщо реферат займається лише адміністрацією, як це буває в нашій команді, не бачимо жодних проблем. Наш майстер scrum гарантує, що дошка scrum board зберігає синхронізацію з файлом excel. Роль майстра скраму повинна сприяти тому, що ми / він гарантує, що ви можете безперешкодно виконувати свою роботу. Це те, як ми працюємо. Чи знаєте ви, чому ваш скрутмайстер робить це? Чи боїться він керівника проекту застаріти? Він боїться, що команда не підбере завдання самостійно? Це може бути гарною ідеєю обговорити це під час ретроспективи.

Я був майстром scrum в обох типах середовищ (де я підштовхував завдання до людей і де люди тягнуть завдання).

Про команду Push ресурси розвитку не були взаємозамінними. Робота клієнта Windows повинна була перейти до розробника Windows, а робота в Інтернеті - до веб-розробника. Тому я зміг підштовхнути завдання до ресурсів під час сеансів планування. Я також зміг зробити індивідуальне планування потенціалу, щоб знати, коли перестати натискати.

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

Я натрапив на цікаву статтю, в якій викладаються плюси та мінуси Push vs. Pull.