0: Здравствуйте, дорогие друзья. С вами Игорь Филиппов. Это школа канбана. И сегодня у нас 5 эпизод 2 сезона, который называется заблокированные задачи, скрытый убийца потока. Итак, сегодня я расскажу вам, как я работал с блокировками.

1: Напомню, что у нас был скрам с двухнедельными итерациями, был бэклок. Была довольно большая доска со спринтом, с кучей этапов и подэтапов. И вот в этом всем контексте нужно было

2: Выстроить какую-то системную работу с блокерами. Давайте, наверное, начнём с доски и вообще поговорим о том, как эти блокеры появлялись. Ну, 1 из источников это, конечно же, тестирование, то есть

3: Когда у нас происходит тестирование готового функционала, тестировщик может выявить какую-то работу, которая не доделана до конца, либо же не соответствует требованиям в этом случае он приостанавливает тестирование.

4: Ставит на задачи блокер. Вот, например, как здесь, да, то есть и пишет причину. Нужна доработка по бэку там или что-нибудь в этом Роде. Да, кстати, сегодня мне помогает кайтон и его прекрасная визуализация. Ну так вот, соответственно, тестировщик

5: Ставит блокер на задачу, заводит сабтаск, сабтаск попадает в колоночку, нужно сделать и дальше она переходит сразу на разработчика, если там какой-то небольшой баг или же переходит в очередь на анализ, если же требует

6: Какое-то до описания требований. Кстати, понятное дело, что баг, он не сразу попадает на разработчика, а сначала попадает в очередь на разработку сабак сабтаск. Вот, соответственно, разработчик.

7: Устраняет баг. Задача, которая висит на тестировщике, разблокируется и он может продолжить тестирование. Это 1 сценарий, он довольно стандартный и мне кажется, работает у всех. Но что если вдруг тестировщик

8: Заблокировал задачу и разработка требует несколько дней. В этом случае задача перемещается из колонки в тестирование, в колонку. Давайте попробуем вот так вот сделать в колонку. Заблокирована.

9: Тестировщик указывает причину блокировки, заводит задачу на внешнюю команду, если причина не в нас, либо же заводит задачу на нашу команду, если причина в нас и задача попадает опять же в очередь и дальше, когда разработчик

10: Освобождается, попадает к нему в работу. Таким образом, у нас начинает накапливаться задача в колонке заблокирована. И мы так жили. И, соответственно, я считал это правильным. И каждый день на weekly я инспектировал заблокированные за

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

12: При этом у нас начинает расти колонка заблокирована, в ней становится очень много задач, и это становится проблемой для потока. В чем, собственно, проблема для потока. Во первых, визуальная у тебя на доске как будто бы

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

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

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

16: И стал перемещать задачи с доски в этот спринт. То есть так, давай, все переместилось. То есть вообще не по феншую вообще не так, как про это говорят, как про это учат и вообще.

17: Кажется, что это какая-то антинаучная история. То есть, а как же так? Но я руководствовался следующими принципами. Я хотел очистить доску заблокированных задач, по которым все равно ничего не делается, не меняются статусы, поэтому я

18: Хотел сфокусировать работу команды на тех задачах, которые сейчас реально можно делать. Да, получается, мы немножечко заметали сор под ковёр. То есть у нас есть заблокированные задачи, я их убираю с доски, мы фокусируемся на том, что нужно на том, что

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

20: Профит того, что сделал вот этот вот spring в логе продукта, назвал его заблокированным. Почему? Потому что у меня в 1 месте стали видны все заблокированные задачи и я начал с ними системно работать. Во первых, по всем заблокированным задачам у меня была причина блокировки во вто

21: Во всех заблокированных задачах у меня были ссылки на задачи, которые эти блокеры должны снять. В третьих, я получил инструмент систематизации, кластеризации блокеров по причинам возникновения. То есть здесь мы зави,

22: В 3 задачах от команды, а здесь мы зависим в 2 командах от задачи б здесь у нас нужны доработки большие на нашей стороне. И поэтому, пока мы их не сделаем, блокер не будет снят, но то есть даже вот такой вот простейший анализ пока

23: Зал, нам 3 причины блокировки, 2 смежные команды, которых мы зависим. 1 причина внутри нас. И таким образом, я как продакт, получил некий инструмент воздействия на внешние команды. То есть в этот момент у нас появился

24: Порт, который я назвал, работа с зависимостями. Я поподробнее расскажу о нём в следующем эпизоде. В этом я сейчас скажу о том, что вот такая вот работа с блокерами помогла мне, во первых, увеличить скорость выполнения за

25: Задач на основной доске. Во вторых, увеличить фокус команды на тех задачах, которые можно делать, они не заблокированы и опять же, тем самым увеличить пропускную способность и увеличить скорость их реализации. И 3, это получить все блокеры в

26: В 1 месте начать с ними работать на системном уровне, кластеризовать, определить причины возникновения блокировок и на системном уровне начать их устранять. На этом у меня сегодня все