Отзыв на книгу
«Канбан: Альтернативный путь в Agile»
Цель прочтения книги
Найти способы решения задач:
- оптимизировать распределение нагрузки по ресурсам
- использовать ресурсам наиболее эффективно
- снизить прямые потери времени
- сократить времени работы на задачами
- избавиться от "загадывания" несбыточных сроков
- увидеть "как на ладони", весь процесс работы над проектами
Отзыв
На мой взгляд — в книге очень много полезных мыслей, но они выходят за рамки самого рассказа про канбан. Можно было разделить книгу на две.
Интернет-проекты снова отмечены глифом простоты: “для релиза сайта нужно все лишь скопировать измененные файлы на удаленный компьютер”. В то время как для релиза настоящего ПО существует целый ряд задач и проблем связанный с этим процессом.
Автор отдельно отмечает, что канбан это не методология управления проектами, а управление изменениями в ходе работы над проектом.
В книге поднимается очень важный вопрос поддержания оптимального баланса между работой и жизнью. Работа должна иметь размеренный темп. Прежде всего жизнь, а потом уже работа. Работа не должна мешать отдыхать или заниматься хобби и тд. Должно быть свободное от работы время, не только на выходных. Именно этот вопрос подвигнул автора к созданию канбана.
Для того, чтобы совершенствоваться, изучать что-то новое, да и просто делать свою работу качественно — на это должно быть время. Поэтому система должна ограничивать поток поступающих в работу задач.
Постоянная загрузка на 150% приводит к выгоранию сотрудников. В буквальном смысле приходится "молотить по кливиатуре" без оглядки.
Я думаю, что именно поэтому опытные разработчики не хотят работать в студии и заниматься заказной разработкой, а предпочитают работать “инхаус”, занимаясь разработкой одного проекта-продукта.
Коротко о главном
Канбан - это вытягивающая система бережливого производства. Задачи не пропихиваются в систему, как это обычно бывает, а наоборот система сообщает, что готова взять следующую задачу в работу.
Ключевой регулятор стабильности и равномерности — это ограничение на количество невыполненных задач, называемое WIP-лимитом. То есть одновременно в работе может находиться строго ограниченное кол-во задач. Лимит напрямую зависит от количества ресурсов и производительности команды.
Оптимальным лимитом на одного специалиста считается 3 задачи . Из расчета, чтобы пока 1-2 задачи заблокированы ресурсы не простаивали без дела.
Таким образом, вычислить свой WIP-лимит в каждой колонке можно исходя из количества доступных ресурсов для решения задач данного этапа.
Именно это стимулирует завершение текущих задач, чтобы приступить к следующим. Если что-то мешает решению задачи — задача считается заблокированной и тормозит весь процесс. Поэтому все помехи при таком подходе устраняются максимально оперативно.
Многозадачность ведет к потерям. Одновременная работа над большим количеством задач обязательно приводит к тому, что какие-то задачи блокируются и остаются “висеть”. Проходит время, все забывают про задачу и ее нюансы. Поэтому доработка таких задач происходит дольше.
Большое количество незавершенных задач увеличивает общее время выполнения всех задач. И это является прямыми потерями времени.
Прозрачность процесса — следующая важная мысль. Все заинтересованные участники проекта должны наглядно видеть какие есть задачи, кто и над чем сейчас работает, какие проблемы тормозят процесс.
Сигнальная доска — визитная карточка канбана. Доска содержит колонки в порядке следования жизненного цикла задачи, от появления идеи до полного завершения работы над задачей. Во время работы задачи перемещаются слева направо, проходя по очереди все статусы. Каждая колонка имеет свой, оптимальный WIP-лимит.
Бутылочное горлышко — обеспечивает спокойный ритм работы над задачами на всех следующих этапах. То есть это колонка с наименьшим лимитом, за которой следуют колонки в которых лимит больше. Горлышком может быть первая колонка, или та в которой доступно меньше всего ресурсов.
Эскалация — процесс донесения проблемы до руководителей и уполномоченных лиц. Если проблема оглашена, она будет решена наиболее быстро. Способы и правила эскалации должны быть четко прописаны. Долгое решение проблемы из-за того, что про нее кто-то не знал тоже является прямой потерей времени.
Важно, при внедрении канбана, кардинально не менять существующий процесс. А лишь немного его оптимизировать, чтобы сохранить существующие бизнес-процессы, ценности и компетенции. Старые сотрудники не любят такие изменения, все должно остаться по прежнему, при этом обрести размеренный темп.
Классы обслуживания - нужны чтобы обеспечить наиболее оптимальное распределение ресурсов по задачам и клиентам. Классов должно быть буквально несколько, чтобы их можно было легко запомнить и отличать на доске своим цветом. В большей степени они определяют приоритеты задач, которые будет взяты в работу когда система освободится. А также, сколько максимум дней потребуется на выполнение задачи.
Из этого следует, что обратный отсчет времени до сдачи задачи начнется только в момент реальной работы над задачей, в момент, когда система будет готова. А опубликована задача будет вместе со следующим релизом.
Это же прекрасный способ решения проблемы нарушения крайних сроков, выставленных задолго до того, как реально освободятся ресурсы для работы над задачей!
Вот и ненужно никакого долгосрочного планирования. Нужен только пул задач, отсортированных по классам. При освобождения ресурсов, достаточно взять первую попавшуюся задачу из самого приоритетного класса.
Ускоренный класс обслуживания - обладает наивысшим приоритетом и меньшим сроком выполнения. Это то, что постоянно происходит со всеми подряд проектами. А должно быть строгое ограничение на количество ускоренных проектов.
Идеальный лимит - это один ускоренный проект. И это должно происходить только при реальной необходимости, когда владельцу продукта что-то “вдруг стало жизненно необходимым” и имеет объективную аргументацию.
Другие полезные тезисы из книги:
- каждому отделу своя доска, со своими особенностями процессов
- первоисточник состояния задая — КСУП
- отдельный человек занимается синхронизацией КСУП и сигнальной доски
- работа над новой задачей начинается, только когда в системе освободились ресурсы для нее
- избавиться от тщательной пред. оценки задач - это тоже потеря времени
- небольшие частые релизы (от 1 недели)
- отсутствие привязанности релизов к конкретным датам (желательно)
- ежедневные или еженедельные скрам собрания