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

Дэвид Андерсон

Канбан. Альтернативный путь в Agile

David J. Anderson

KANBAN

Successful Evolutionary Change for Your Technology Business

Издано с разрешения Lean Kanban Inc.

Благодарим за помощь в подготовке издания сообщество Lean Kanban Community Russia в лице Пименова Алексея, Вячеслава Цырульника, Антона Манина, Сергея Баранова и Игоря Филипьева

Все права защищены.

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

© David J. Anderson, 2010

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2017

Посвящается Николе и Натали

Предисловие

Я всегда обращаю внимание на работы Дэвида Андерсона. Познакомился я с ним в октябре 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-планирование и единый класс обслуживания. Пожалуйста, обратите внимание на эти различия.

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

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

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

Часть I

Основы

Глава 1

Решение дилеммы agile-менеджера

В 2002 году я был менеджером по разработке в удаленном офисе подразделения мобильных телефонов Motorola в Сиэтле (оно называлось PCS) и оказался в сложной ситуации. Мой отдел был частью стартапа, который Motorola приобрела годом ранее. Мы разрабатывали сетевое ПО для беспроводной передачи данных, например беспроводного скачивания и управления приборами. Эти серверные приложения входили в интегрированные системы, которые были тесно связаны с клиентским кодом мобильных телефонов, а также с другими элементами в телекоммуникационных сетях и операционной инфраструктуре, например с биллингом. Дедлайны назначались менеджерами, которые не обращали внимания на инженерную сложность проекта, его риски или масштаб. Основа кода развивалась из стартапа, при этом разработка многих первоначально запланированных возможностей была отложен на потом. Один старший разработчик настаивал на том, чтобы наши продукты назывались «прототипами». Нам было отчаянно необходимо повысить производительность и качество продукции, чтобы соответствовать требованиям бизнеса.

В своей повседневной деятельности в 2002 году и в процессе работы над предыдущей книгой{1} я был обеспокоен в основном двумя проблемами. Во-первых, как защитить команду от постоянно растущих требований бизнеса и достичь того, что сейчас в agile-сообществе принято называть «оптимальным темпом». И во-вторых, как я могу успешно внедрить agile-подход в масштабах всей организации, преодолев неизбежное сопротивление переменам?

В поисках оптимального темпа

В 2002 году agile-сообщество воспринимало оптимальный темп просто как «40-часовую рабочую неделю»{2}. Принципы Agile-манифеста{3} гласили, что «agile-процессы способствуют оптимальному развитию. Спонсоры, разработчики и пользователи должны быть готовы поддерживать постоянный темп в течение бесконечного времени». За два года до этого моя команда в Sprint PCS постоянно слышала от меня, что «масштабная разработка ПО – это марафон, а не спринт». Если членам команды предстояло поддерживать неизменный темп в процессе работы над полуторагодичным проектом, то нельзя было позволить им сгореть за месяц-другой. Проект нужно было распланировать, вставить в бюджет, расписать по времени и подвергнуть оценке, чтобы члены команды ежедневно тратили на работу разумное количество времени и не слишком уставали. Передо мной как менеджером стояла задача достичь этой цели и удовлетворить все требования бизнеса.

Когда я работал на первой менеджерской должности (это было в 1991 году, в стартапе, который делал платы захвата видео для персональных и более мелких компьютеров), CEO[3] сообщил, что у руководства сложилось обо мне «крайне отрицательное мнение». Я всегда отвечал «нет», когда наши возможности как разработчиков уже были исчерпаны, а от нас требовали все больше продуктов или функций. К 2002 году это вошло у меня в привычку: я провел еще десять лет, отказываясь выполнять капризы владельцев бизнеса.