Препятствия – скрытые и все остальные
In Allan Kelly on 3 Июнь 2009 tagged Agile, Lean, SCRUM, канбан, перевод, совещания стоя with no comments
В комментарии к моей заметке «Три варианта проведения совещаний стоя» был задан вопрос: «Вы можете привести примеры ’скрытых’ препятствий?». Отвечаю, вот они родимые.
Первое: необходимо понимать разницу между блокировкой и затруднением. Блокировки останавливают всю работу. Они редко скрыты, поэтому люди не могут вернуться к тому чем они занимались. Препятствие — это что-то, что мешает работе, замедляет вас, разрушает вашу мораль.
К счастью, или, может, к несчастью, разработчики отличаются хорошим умением обходить блокировки. Они находят пути «заставить работать эту штуковину», даже если это не наилучший, не самый быстрый, или неправильный путь. Так блокировки иногда становятся препятствиями. Если мы не будем бороться с препятствиями, наши команды не достигнут своего максимума.
Одна из неприятных форм препятствий формулируется как «я застопорился, поэтому я буду работать над чем-нибудь, чтобы выглядеть занятым». Работа которая сделана редко так же важна как работа, которая остановлена блокировкой, она даже бесполезнее.
Так или иначе, ниже я приведу примеры препятствий, делая акцент на скрытых:
Поставщик не отвечает: кто-то ждет от поставщика доставки чего-либо и она никак не произойдет; или вы ждете ответа от технической поддержки поставщика, или, возможно вам нужна информация от поставщика перед принятием решения о том использовать ли их продукт или стоит посмотреть что-то еще.
Проблемы со сборкой: она неудачная, или вам нужен кто-то еще для того чтобы поправить строчку, или вы ждете прав доступа, или похоже что в компиляторе есть баг, или… этот список можно продолжать.
Ожидание другой команды: детальные тесты, контроль версий, пользовательский интерфейс, техническая поддержка и т.д. В идеале мы хотим чтобы каждая команда была вертикальной. Т.е. была самодостаточной, обладала необходимыми навыками и достаточными полномочиями для выполнения работы без привлечения кого-либо со стороны. Этого не происходит, потому что вам уже нужна другая команда, для выполнения чего-либо. И в этом месте возникают проблемы, потому что у другой команды приоритеты отличаются от приоритетов вашей команды.
Обновление компилятора, ОС, сервера приложений и т.д.: небольшая часть ПО (или возможно оборудования) нуждается в обновлении. Так вместо того чтобы продолжать работать над задачей, кто-то отвлекается на обновление системы. И когда это происходит дольше чем ожидается, или возникают проблемы, тогда это становится препятствием, а зачастую блокировкой.
Баг — типичный баг в библиотеке: вы не можете продолжить свою работу потому что это не ваш баг. В идеале вы запросто можете влезть в код и исправить проблему, но… если баг в библиотеке стороннего производителя, то сделать это будет уже не так просто. Если загвоздка в компиляторе, или поставщике, то вы получаете одну из проблем описанных выше.
Изменения базы данных: команды, работающие с базой данных выглядят так как будто работают в другом временном измерении. Очень часто я встречал команды, которые не могли работать дальше, потому что были необходимы изменения в схеме БД, или мета-данные были проблемой, или… Действенное решение заключается в двух вещах: упрощенная архитектура, как следствие уменьшение требований к сложности базы данных, и гарантии того что у группы есть навыки для самостоятельной работы с БД.
Ожидание решения руководства: это слишком обычно, руководство не может решить — сделать как X или сделать как Y.
Когда члены команды не могут сообщить о выполнении задачи на Scrum-митинге они рапортуют о том «что они сделали», а это включает «почему они не выполнили поставленную задачу». Это как раз то место, где упоминаются вышеперечисленные препятствия.
Хороший Scrum-мастер/Руководитель митинга/Agile-тренер должен выявить эти проблемы и переместить их в препятствия.
Оригинал: Allan Kelly — Impediments – hidden or otherwise (20.04.2009).