Может ли мастер схватки распределять задачи?

Мы следим за схватками в нашем проекте. Я вижу, что большую часть времени мастер схватки распределяет задачи для нас. Тем не менее, я прочитал во многих книгах о Scrum, что Scrum работает наоборот (подход «тянуть»), и члены команды выбирают задачи или функции. Является ли Scrum Master, назначающий задачи, правильным подходом или это противоречит гибкой идеологии?

Согласно статье Википедии о Scrum , задачи Sprint не назначаются ScrumMaster:

Задачи в спринте никогда не назначаются; скорее, задачи записываются членами команды по мере необходимости, в соответствии с установленным приоритетом и навыками члена команды. Это способствует самоорганизации команды и участию разработчиков.

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

ScrumMaster Лицо, ответственное за процесс Scrum, следящее за тем, чтобы оно использовалось правильно, и с максимальной пользой.

ScrumMaster не назначает задачи, простые и понятные. Команда самоорганизуется и принимает решения о том, кто работает над тем, что решает команда.

Это настоящий Скрам. Однако, многие организации могут использовать варианты этого.

Это способ, которым он должен работать, но, как со всеми вещами, которые прекрасно работают в теории ... это не всегда на самом деле работает.

Есть зависимости, желания клиентов и драйверы извне. Некоторые вещи нужно просто сделать, прежде чем вы сможете работать над этим модным виджетом, над которым все хотят работать.

Изнутри есть базовые способности разработчика. Некоторые вещи просто тяжелые, а некоторые просто лучше. Конечно, работая в течение бесконечного времени, я могу просто дать вам понять; но когда что-то должно быть сделано, тогда назначение человеку, который лучше всего справляется, чтобы сделать это быстрее и лучше, это тот, кто получает работу.

И еще есть проблемы с личностью, такие как чрезмерный контроль над Scrum Master и / или разработчиками, которые не могут связать свою обувь без ведома. Моя команда, например, имеет оба. В таких случаях лучше работает всем, чтобы игнорировать этот маленький факт о Scrum.

Другими словами, не просто делайте это, потому что процесс говорит об этом. Делай то, что работает. Винт остальное.

Конечно, есть и другой базовый факт человеческого существования ... может быть, вы даже не знаете, кто такой Мастер Скрама. Может быть, это не тот человек с таким названием. Может быть, у вас даже нет такого.

Никогда.

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

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

Другой подход может позволить команде завершить спринт, возложить на них ответственность за отсутствие результатов и затем обсудить это в ретроспективе спринта.

Как и любая идеология, бывают случаи, когда книгу правил нужно выбрасывать или тщательно игнорировать.

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

Существует большая разница между распределением задач по диктату (вы ДОЛЖНЫ делать X) и распределением по обсуждению и соглашению. Иногда соглашение может быть теплым.

С другой стороны, возможно, команде нужно руководить ... это трудно понять.

Тем не менее, я был бы обеспокоен любым процессом, который настаивает на том, чтобы вы следовали процессу до письма, без возможности шевелиться или судить. Такой процесс заменяет мышление.

По моему мнению, scummaster не должен этого делать, члены команды должны сами решать задачи. Если scrummaster выполняет только администрирование, как в случае с нашей командой, не вижу проблем. Наш мастер схватки обеспечивает синхронизацию макулатуры с файлом Excel. Роль мастера схватки должна быть способствующей, мы уверены, что вы можете делать свою работу беспрепятственно. Так мы работаем. Знаете ли вы, почему ваш scrummaster делает это? Он менеджер проекта боится устареть? Он боится, что команда не будет поднимать задачи самостоятельно? Это может быть хорошей идеей, чтобы обсудить это во время ретроспективы.

Я был мастером схватки в обоих типах окружения (где я передавал задания отдельным лицам, а где люди выполняли задания).

О, команда Push, ресурсы разработки не были взаимозаменяемыми. Работа с Windows Client должна была перейти к разработчику Windows, а работа в Интернете - к веб-разработчику. Таким образом, я смог выдвинуть задачи на ресурсы во время планирования сессий. Я также мог планировать индивидуальные возможности, чтобы знать, когда прекратить работу.

Метод извлечения хорошо работал в команде, где любая задача могла быть подхвачена любыми ресурсами. Но я не мог планировать индивидуальную мощность во время сеанса планирования, вместо этого мне приходилось зависеть от средней скорости, чтобы знать, когда этого достаточно. (Потребовалось ~ 3-4 спринта, прежде чем мы получили хорошее представление о скорости).

Я наткнулся на интересную статью, в которой изложены плюсы и минусы Push vs. Pull.