Выявление блокировщиков — это то, как вы решаете проблемы в команде

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

Смысл этой встречи — дать возможность членам команды поделиться контекстом. Гибкие методологии хотят, чтобы разработчики жили в состоянии потока: максимальная производительность с минимальными отвлекающими факторами. Но как они могут это сделать и при этом оставаться частью команды?

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

Тем не менее, разработчики часто затрудняются сказать, что они заблокированы. Почему это?

Уменьшение влияния вашего эго

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

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

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

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

Распознавание блокировщиков в обычной деятельности

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

  • Зависимости. Когда вы ждете зависимости, вы заблокированы, даже если точно знаете, как решить пользовательскую историю. Вам нужна зависимость, чтобы приземлиться первым.
  • Расписания. Иногда менеджеры говорят: «Отложите это изменение кода до выпуска во вторник». Может быть, вы ждете встречи с партнером, или команда решает внести большую смену только после окончания праздника. Вы по-прежнему заблокированы, даже если код готов.
  • Утверждения. Некоторые проекты требуют одобрения членов внутренней команды, партнеров или внешних клиентов. Как только вы закончите работу, отметьте себя заблокированным, пока вы ждете полной очистки.
  • Решения. Иногда проект может остановиться, если вокруг какого-то решения слишком много споров. Должны ли мы решать это на уровне данных или на бизнес-уровне? Должны ли мы добавлять новый API или нет? Вы заблокированы, потому что команда должна прийти к соглашению.
  • Отсутствующие истории. Одна из неприятных проблем возникает, когда члену команды сказали работать над проектом, но его владелец продукта, скрам-мастер или менеджер еще не написали или не завершили работу над заявками. Ой! Вы должны поймать это раньше. Время разработчиков дорого стоит, и мы не хотим его тратить!

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

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

Алгоритмы планирования для людей и процессоров

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

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

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

Выпуск претензий к задачам, которые не активны

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

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

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

Но когда у разработчика от пяти до десяти пользовательских историй в статусе «Активно», может быть, он пытается сделать слишком много. Попросите их сосредоточиться на двух или трех задачах одновременно, и вы можете разблокировать работу для других членов команды.

Используйте небольшие коммиты и регулярные пулреквесты

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

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

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

Лучший способ справиться с этим — поблагодарить разработчика за проделанную работу и сказать: «Этот тикет явно слишком велик. Делим пополам. Мы закроем этот тикет и откроем два новых. Вы можете работать над заявкой А, а этот человек будет работать над заявкой Б».

Следите за своей реакцией на блокировщики

Если я могу закончить этот разговор одним важным советом, то вот он: Спасибо вашей команде за выявление блокировщиков. Когда кто-то поднимает руки и указывает на проблему, обязательно скажите: «О, хороший улов! Посмотрим, что мы можем сделать».

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

Тед Спенс преподает в Bellevue College и ведет инженерное дело в Lockstep. Если вы интересуетесь программной инженерией и бизнес-анализом, я буду рад услышать от вас в LinkedIn.