Какой agile-процесс способствует тому, чтобы команда назначала задачи отдельным разработчикам, а не отдельные люди назначали задачи себе?

Ты спрашиваешь:

1. Существует ли процесс, который продвигает группу для назначения задач отдельным разработчикам. Задачи должны быть назначены как часть группового решения и как часть того, что будет дальше.

Что вам нужно сделать, так это объяснить команде (те, кто занимается сбором), к чему вы стремитесь. Это может затем побудить их разделить задачу, как вы ожидаете.

Как только они осознают пользу вашего улучшения , большинство из них согласится с ним.

Затем вы спрашиваете:

2. Как я могу справиться со случаями, когда на самом деле люди ходят и получают задания от внешних ресурсов таким образом взламывая групповое решение о том, кто что делает. Мне как-то интересно, то что я описал - бред? Какой agile-процесс мешает разработчикам выбирать задачи самостоятельно?

В то время как Agile способствует эффективности, вы ожидаете, что краткосрочная неэффективность будет способствовать долгосрочной эффективности.

Как только вы (по-новому) определите «эффективность», она должна соответствовать вашей реализации Agile.

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

Имейте в виду, что случайное «нарушение правил» — это не конец света ; иногда лучше игнорировать мелкие нарушения, чем делать из этого большое дело и отвлекать всех.

Хорошей идеей может быть ведение журнала, когда ваша реализация «спасла положение». Например: поскольку x и y знали код, когда x ушел в длительный отпуск, нам не потребовалась долгая передача.

Напоминание людям о том, насколько великолепна ваша система, с доказательствами помогает им понять ее и побуждает следовать ей.

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

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

Для команды, безусловно, было бы законным попробовать случайный или псевдослучайный процесс распределения задач. Возможно, они могли бы провести его в качестве эксперимента: решить, как они будут измерять успех, опробовать подход в течение ограниченного периода времени (например, 4 недели), а затем оценить, как подход прошел в конце.

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

Как я могу справиться со случаями, когда на самом деле люди ходят и получают задания от внешних ресурсов таким образом взламывая групповое решение о том, кто что делает. Мне почему-то интересно, то, что я описал, — это ерунда? Какой agile-процесс отбивает у разработчиков охоту выбирать задачи для себя?

Если команда решит, какой подход они будут использовать, то вряд ли они попытаются обойти его. В этом ценность самоорганизующихся команд: команды поддерживают выбранный подход и, следовательно, с большей вероятностью хорошо его реализуют.

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

Если команда решила, что это хорошая идея — поощрять всех браться за задачи, с которыми они не знакомы, то это одно. Если вам нужна практика, которая отбивает у них охоту браться за знакомые им задачи, то это другое дело. Первый подход Agile, второй... Сомневаюсь .

Я не думаю, что существует какой-либо процесс Agile, который делает то, о чем вы просите, и это потому, что это не имеет смысла, если ваш контекст не является конкретным. Под этим я подразумеваю, что работа более или менее относится к одной и той же области знаний, у членов вашей команды есть роли в этой области знаний, но они не просто имеют одинаковый опыт. Кто-то более квалифицированный, кто-то менее. То, что вы предлагаете, может сработать в этой ситуации, но не во всех ситуациях. А причина в том, что у вас неизбежно будет специализация внутри команды.

То, как вы сформулировали вопрос, заставляет меня думать, что вы считаете специализацию проблемой. Если в команде есть все роли для выполнения своей работы, то это не проблема . Команды создают программное обеспечение в Agile, а не отдельные лица.

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

Хорошо делиться знаниями, хорошо проводить сеансы парного программирования, хорошо, когда люди получают общую картину и несут совместную ответственность за результаты, но давать им задачи, с которыми они не знакомы, — не обязательно способ сделать это. Это выталкивает их из их зоны комфорта, и это способ чему-то научиться, но заходите слишком далеко, и вы получите беспорядок в своих руках, в конечном итоге вызовете много разочарований и даже текучесть кадров. Как я уже сказал, это работает в определенных контекстах, не во всех. Я призываю вас подумать о последнем проекте, в котором вы пробовали это, и рассмотреть навыки людей и характер работы, и я уверен, что вы обнаружите, что не было слишком много вариаций, просто разные уровни опыта и взглядов. большой картины.

В качестве другого примера предположим, что в вашей команде есть дизайнер и бэкэнд-разработчик Java. Вы бы возложили задачу на бэкенд-разработчика только потому, что хотите избежать специализации? Или хуже? Дали бы вы дизайнеру фоновую задачу? Это не имеет никакого смысла.

Есть действительно одна проблема: при работе над приоритетными задачами. Допустим, дизайнер занят, а бэкенд-разработчик только что закончил какую-то работу и может выбрать следующую задачу из списка приоритетов. Следующей задачей по приоритетности является задача проектирования. UPS! Теперь разработчик должен осмотреться, чтобы увидеть, какие еще есть внутренние работы. Вторая задача — это внутренняя работа, поэтому они берут на себя эту задачу. Но это был второй приоритет, а не первый. Это проблема, верно? Но вы не решите эту проблему, запихивая задачу проектирования в горло бэкенд-разработчику.

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

Вообще говоря, вас должно интересовать то, что команда обязуется делать дальше, а не то, кто именно из членов команды этим занимается.