Читать книгу Канбан. Альтернативный путь в Agile - Дэвид Андерсон - Страница 3

Я всегда обращаю внимание на работы Дэвида Андерсона. Познакомился я с ним в октябре 2003 года, когда он прислал мне экземпляр своей книги Agile Management for Software Engineering: Applying Theory of Constraints for Business Results («Гибкое управление в разработке программ: применение теории ограничения систем для результатов в бизнесе»). Как можно предположить из названия, на книгу большое влияние оказала теория ограничений (ТОС) Элияху Голдратта[1]. Позднее, в марте 2005 года, я посетил Дэвида в Microsoft, к тому времени он плотно работал с кумулятивными диаграммами потока. Еще позже, в апреле 2007 года, мне довелось наблюдать, как действует прорывная канбан-система, внедренная им в Corbis.

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

Конечно, скорость хороша, если направлена в нужную сторону, и я уверен, что Дэвид двигается в верном направлении. Особенно меня восхищает последняя работа с канбан-системами. Я всегда считал, что принципы бережливого производства можно напрямую применить в разработке продукта, в отличие от идей ТОС. Более того, еще в октябре 2003 года я написал Дэвиду следующее: «Одна из главных слабостей ТОС – недооценка важности размера партии. Если ваш основной приоритет состоит в том, чтобы найти и устранить ограничение, то это часто значит, что вы просто решаете не ту проблему». Я до сих пор считаю это утверждение верным.

На нашей встрече в 2005 году я снова предлагал Дэвиду смотреть дальше, чем простая фокусировка на узких местах в ТОС. Я объяснял ему, что шумный успех производственной системы Toyota (ПСТ) не имеет ничего общего с поиском и устранением узких мест. Выигрыша в производительности Toyota достигает благодаря снижению объемов партии и уменьшению вариативности, благодаря чему сокращается количество необходимых производственных запасов. Именно сокращение таких запасов привело к достижению экономических преимуществ, и это стало возможным благодаря таким системам сокращения незавершенного производства, как канбан.

В 2007 году я посетил Corbis. Результат внедрения канбан-системы выглядел впечатляющим. Я указал Дэвиду, что он значительно улучшил канбан-подход, используемый в Toyota. Почему я так считал? Производственная система Toyota оптимизирована для работы с повторяющимися и предсказуемыми задачами с одинаковой длительностью и однородной стоимостью задержки. В этих условиях вполне корректно использовать такие подходы, как FIFO-приоритизация («первым пришел – первым ушел»). Также вполне корректно блокировать поступление работы, если достигнут предел незавершенных задач. Однако если мы имеем дело с неповторяющейся, непредсказуемой деятельностью с разной продолжительностью и различными стоимостями задержки, эти подходы нельзя признать оптимальными – а именно так и обстоят дела с разработкой ПО. Нам нужны более продвинутые системы, и это первая книга, которая описывает их с практическими подробностями.

Я хотел бы предупредить читателей о некоторых вещах. Во-первых, если вы думаете, что знаете, как работают канбан-системы, то вы, вероятно, имеете в виду те, что используются в бережливом производстве. Идеи, описанные в этой книге, намного прогрессивнее тех простых систем, в которых используются статические WIP-лимиты[2], FIFO-планирование и единый класс обслуживания. Пожалуйста, обратите внимание на эти различия.

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

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

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

Дон Рейнертсен,

автор книги The Principles of Product Development Flow