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

Зачем использовать канбан-систему

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

Простое ограничение незавершенных задач посредством канбана приводит к повышению качества работы и ее производительности. Сочетание оптимизации потока работ и повышения качества помогает сократить время выполнения работ и повышает предсказуемость и вероятность выполнения задачи в срок. Установив регулярные каденции релиза и постоянное следование расписанию, Канбан помогает создать доверительные отношения с клиентами и другими участниками цепочки создания ценности – другими отделами, с поставщиками и зависящими от вас партнерами.

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

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

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

Канбан как комплексная адаптивная система для бережливого производства

Канбан-метод предлагает комплексную адаптивную систему, которая направлена на катализацию перехода организации к бережливому производству. Комплексные адаптивные системы обладают начальными условиями и простыми правилами, которые требуются для перехода к комплексному адаптивному интеграционному поведению. Чтобы создать навыки бережливого производства в организации, Канбан использует пять ключевых свойств. Эти свойства присутствуют во всех успешных вариантах внедрения Канбана, в том числе и в том, который использовался в Microsoft и будет описан в главе 4. Вот эти пять свойств.

1. Визуализация рабочего потока.

2. Ограничение количества незавершенных задач.

3. Измерения и управление потоком.

4. Формальные политики процессов.

5. Использование моделей[5] для оценки возможностей совершенствования.

Ситуационное поведение и канбан

В реализациях Канбана мы ожидаем увидеть появление новых привычек и осознания некоторых правил, список которых постоянно растет. Некоторые из них (или даже все) есть в большинстве последних реализаций. Так, все они присутствовали в Corbis за 2007 год. Мы полагаем, что этот список будет расти, когда мы больше узнаем о влиянии Канбана на организации.

• Процессы уникальны для каждого проекта или потока создания ценности.

• Разделенные каденции (или разработка, не привязанная к единому итерационному циклу).

• Рабочее расписание определяется стоимостью задержки.

• Оптимизация поставки ценности с помощью классов обслуживания.

• Управление рисками основывается на емкости производственной системы.

• Терпимость к экспериментам в процессе.

• Управление на основании количественных показателей

• Вирусное распространение (Канбана) по организации.

• Слияние небольших команд для создания единых трудовых центров.

Канбан как разрешение действовать

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

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

В ранние годы гибкой разработки ПО лидеры сообщества нередко не понимали, почему их методы работали. Мы говорили об «экосистемах»{10} и советовали новичкам внедрять все практики – иначе решение не сработает. Некоторые компании опубликовали модели agile-зрелости, где делались попытки оценки усвоения практик. В Scrum-сообществе существует опробованный на практике тест, который часто называют «тестом Nokia»{11}.

Эти основанные на практике оценки направлены на унификацию и отрицают необходимость в адаптации в соответствии с контекстом. Канбан дает рынку разрешение игнорировать эти практические схемы. Он активно поощряет разнообразие.

В 2007 году несколько человек побывали в моем офисе в Corbis, чтобы посмотреть на Канбан в действии. Обычно все посетители, связанные с agile-сообществом разработки ПО, спрашивали об одном и том же: «Дэвид, мы увидели в офисе семь канбан-досок. Они все разные! Каждая команда работает по своему процессу! Как можно справиться с таким разнообразием?» На этот вопрос я обычно отвечал так: «Конечно! Все ситуации разные. Они развивают свой процесс в соответствии с контекстом». Но я знал, что все процессы ведут начало от одних и тех же принципов и что члены команд, осознавая эти базовые принципы, могут адаптировать их под собственные нужды.

Когда с Канбаном познакомилось больше людей, они поняли, что эта система помогает решать проблемы управления изменениями, с которыми они столкнулись в своих организациях. Канбан придает гибкости команде, проекту или компании. Мы пришли к выводу, что Канбан разрешает создать на рынке собственный процесс, оптимизированный для конкретного контекста. Канбан дает разрешение людям думать самостоятельно. Он позволяет быть разными: отличаться от команды, расположившейся в соседнем кабинете, на другом этаже, в другом здании или в конкурирующей фирме. Он дает разрешение отклониться от учебника. Более того, Канбан дает инструменты, которые позволяют объяснить (и оправдать), почему разнообразие – это хорошо и выбрать его – значит поступить правильно.

Чтобы подчеркнуть этот выбор, я разработал дизайн футболки для Общества ограничения незавершенных задач. Я вдохновился постером Шепарда Фэйри для предвыборной кампании Обамы, на который поместил портрет Тайити Оно, создателя канбан-системы в Toyota. Слоган «Да, мы за канбан» призван подчеркнуть, что у вас есть возможность. Вам разрешается попробовать Канбан, модифицировать свои процессы, быть другими. Ваша ситуация уникальна, и вы можете разработать собственное решение для своего процесса, оптимизированное для вашей сферы деятельности и потока создания ценности, рисков, с которыми вы сталкиваетесь, навыков вашей команды и требований ваших клиентов.

Выводы

• Канбан-системы могут быть использованы в любой ситуации через ограничение наличия элементов работы внутри системы.

• Сады Императорского дворца в Токио используют канбан-систему, чтобы контролировать число посетителей в парке.

• Количество сигнальных карточек «канбан», находящихся в обращении, ограничивает объем незавершенных задач.

• Новая работа втягивается в процесс после возвращения в оборот сигнальной карточки, когда предыдущее задание выполнено.

• В IT-сфере мы, как правило, используем виртуальную канбан-систему, поскольку для ограничения количества незавершенных задач не передаются какие-либо физически существующие карточки.

• Доски со стикерами, часто встречающиеся в гибкой разработке ПО, не являются канбан-системами.

• Канбан-системы создают на рабочем месте положительную напряженность, которая вызывает обсуждение проблем.

• Канбан-метод (или Канбан с большой буквы) использует канбан-систему как катализатор изменений.

• Канбан требует формальных политик процессов.

• Канбан использует инструменты разных областей знаний для анализа проблем и поиска решений.

• Канбан предполагает пошаговое улучшение процессов благодаря постоянному выявлению проблем, влияющих на производительность.

• Современное определение Канбан-метода можно найти в сети на сайте Общества ограничения незавершенных задач (Limited WIP Society, http://limitedwipsociety.ning.com/).

• Канбан дает разрешение на отклонения в разработке ПО, поощряет поиск специфических решений в зависимости от контекста вместо догматического следования определению процесса жизненного цикла разработки ПО или шаблону.

Часть II

Преимущества канбана

Глава 3

Рецепт успеха

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

Как у менеджера у меня никогда не было возможности в крупных организациях нанять собственную команду. Меня просили приспособить существующий коллектив, причем с минимальными кадровыми изменениями, для проведения революции в производительности организации. Я думаю, что такая ситуация встречается гораздо чаще, чем возможность набрать новую команду.

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

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

Вот эти этапы:

• концентрация на качестве;

• снижение количества незавершенных задач;

• частые релизы;

• баланс требований и пропускной способности;

• приоритизация;

• борьба с источниками вариативности для улучшения предсказуемости.

Внедрение рецепта

Этот рецепт применяется в форме его выполнения техническим или функциональным менеджером. На первом месте – концентрация на качестве, и она находится под контролем менеджера по разработке или тестированию либо его непосредственного руководителя – например, технического директора. Двигаясь вниз по списку, мы видим, что постепенно требования контроля ослабевают и начинают уступать место сотрудничеству с сопредельными группами – вплоть до этапа «приоритизация». Приоритизация – это работа бизнес-отдела, а не технологической организации, поэтому менеджер технического отдела не должен этим заниматься. К сожалению, руководители бизнес-подразделений нередко уклоняются от ответственности и поручают провести расстановку приоритетов именно техническому менеджеру. А затем распекают его за неправильный выбор. Борьба с источниками вариативности для улучшения предсказуемости идет в списке последней, потому что для искоренения некоторых типов вариативности требуются изменения в поведении. А просить людей об этом – сложная задача! Поэтому борьбу с вариативностью лучше отложить до того момента, когда благодаря успехам, достигнутым на более ранних стадиях, в организации произойдет смена климата. Как мы увидим в главе 4, иногда важно бороться с источниками вариативности на ранних стадиях, чтобы стала возможной реализация первых этапов. Здесь главное – выбирать такие источники вариативности, которые не требуют серьезных изменений в поведении, чтобы сотрудники с готовностью приняли ваши предложения.

Концентрация на качестве – самый простой этап, потому что это техническая дисциплина, которой может руководить функциональный менеджер. Остальные этапы сложнее, поскольку во многом зависят от согласия и сотрудничества с другими командами. Они требуют навыков постановки целей, переговоров, знания психологии, социологии и эмоционального интеллекта. Создание консенсуса на этапе баланса требований и пропускной способности жизненно важно. Чтобы сгладить дисбаланс между ролями и обязанностями членов команды, требуются серьезные дипломатические способности и навыки переговорщика. Таким образом, имеет смысл сосредоточиться на тех вещах, которые находятся под вашим контролем и способны положительно сказаться на производительности вашей команды и бизнеса в целом.

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

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

Концентрация на качестве

В «Манифесте гибкой разработки ПО» ничего не говорится о качестве, хотя в «Принципах манифеста»{12} ведется речь о мастерстве, что подразумевает концентрацию на качестве. Но если качество не фигурирует в «Манифесте», почему оно стоит на первом месте в моем рецепте успеха? Суть в том, что большое количество ошибок приводит к основным потерям времени в разработке ПО. Эти цифры просто невероятны, а их амплитуда может колебаться на несколько порядков.

Кейперс Джонс{13} сообщает, что в 2000 году во время пузыря доткомов он оценивал качество программ для североамериканских команд, и оно колебалось от шести ошибок на одну функциональную точку до менее чем трех ошибок на 100 функциональных точек – 200 к одному. Серединой будет примерно одна ошибка на 0,6–1,0 функциональной точки. Таким образом, для команд вполне типично тратить более 90 % своих усилий на устранение ошибок. Есть и прямое тому свидетельство: в конце 2007 года Аарон Сандерс, один из первых последователей Канбана, написал на листе рассылки Kanbandev, что команда, с которой он работал, тратила 90 % доступной производительности на исправление ошибок.

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

Улучшение качества программ – это всем хорошо понятная проблема.

И гибкая разработка, и традиционные подходы к качеству имеют свои достоинства. Их нужно сочетать. Тестированием должны заниматься профессиональные тестировщики. Они находят дефекты и предотвращают их попадание в готовый продукт. Если вы будете просить разработчиков писать модульные тесты и автоматизировать их для автоматизированного регрессионного тестирования, то это возымеет серьезный эффект. Казалось бы, если просить разработчиков сначала писать тесты, то это дает психологическое преимущество. Так называемая разработка через тестирование (Test Driven Development, TDD) действительно, судя по всему, помогает: тестовое покрытие выглядит более полным. Стоит сказать, что дисциплинированные команды, которые я возглавлял, писали тесты уже после функционального кодирования и демонстрировали качество на уровне лучших показателей индустрии. Однако очевидно, что у средней команды качество повысится, если тесты будут написаны до функционального кода.

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

Совместный анализ и проектирование улучшают качество. Когда команды просят работать вместе над анализом проблем и проектированием решений, качество обычно выше. Я предлагаю командам проводить сессии совместного командного анализа и проектирования. Проектирование должно проводиться ежедневно малыми порциями. Скотт Амблер называет это agile-моделированием{14}.

Использование шаблонов проектирования повышает качество. Шаблоны проектирования заключают в себе известные решения известных проблем. Благодаря им на ранних этапах жизненного цикла становится доступно больше информации, а ошибки проектирования устраняются.

Использование современных инструментов разработки повышает качество. Многие современные инструменты содержат функции проведения статического и динамического анализа кода. Их нужно включать и настраивать для каждого проекта. Эти средства анализа могут помочь программистам избежать элементарных ошибок – например, внесения таких широко известных проблем, как пробелы в защите.

Более экзотические современные инструменты разработки, такие как производственные линии программных продуктов (или фабрики программного обеспечения) и предметно-ориентированные языки, устраняют ошибки. Фабрики программного обеспечения можно использовать для инкапсуляции шаблонов проектирования как фрагментов кода. Тем самым сокращается вероятность внесения ошибок в код. Можно использовать этот инструмент и для автоматического переиспользования функционала в коде, что также сокращает вероятность внесения ошибок. Использование программного обеспечения также сокращает необходимость проверок кода, поскольку фабричный код не нужно проверять заново. Его качество доказано.

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

Сокращение объема незаконченного проектирования существенно повышает качество программ.

Снижайте количество незавершенных задач и делайте частые релизы

В 2004 году я работал с двумя командами в Motorola. Обе они разрабатывали сетевую часть бэкэнд-приложения для мобильных телефонов. Одна команда работала над сервером для «скачивания по воздуху» (over-the-air, OTA) рингтонов, игр и других приложений и данных. Вторая разрабатывала сервер для управления устройствами «по воздуху» (OTA DM). Обе команды руководствовались методологией Feature Driven Development (FDD). Обе были примерно одного размера – человек восемь разработчиков, один архитектор, до пяти тестировщиков и менеджер проекта. Работая совместно с маркетологами, команды сами проводили анализ и проектирование. Обеим командам помогали отдельные команды проектирования пользовательского взаимодействия (UX) и разработки пользовательской документации (технические писатели).

Незавершенные задания (WIP), время выполнения и ошибки

На рис. 3.1 демонстрируется кумулятивная диаграмма потока для команды, занимавшейся закачкой ОТА. Кумулятивная диаграмма потока – это зонированный график, который отражает объем работы в определенном состоянии. Состояния, показанные на диаграмме, – это бэклог, то есть объем работы, который заведен в учетную систему, но очередь до него еще не дошла. «Начатое» – это когда требования к функционалу обсуждались с разработчиками; «спроектированное» – то есть для функции разработана ML-диаграмма последовательности; «разработанное» – то есть функционал разработан в соответствии с диаграммой последовательности; «завершенное» – то есть все модульные тестирования пройдены, код прошел рецензирование и был принят ведущими разработчиками и передан на тестирование.

.

Рис. 3.1. Кумулятивная диаграмма потока (КДП) команды закачек OTA (осень 2003 – зима 2004 гг.)

Первая линия на диаграмме показывает количество функций в масштабе проекта. Этот объем был разделен владельцами бизнеса на две части. Вторая линия показывает количество начатых функций. Третья линия – число спроектированных, четвертая – разработанных, а пятая – количество завершенных и готовых к тестированию функций.

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

Команде сервера закачек ОТА не хватало либо дисциплины, либо мотивации для использования метода FDD. Они не работали совместно, как требует FDD, а выдавали большие порции функций на откуп индивидуальным разработчикам. Обычно на одного разработчика у них в любое время приходилось до десяти функций. А команда по разработке OTA DM следовала методам, изложенным в учебнике. Они хорошо работали в сотрудничестве и разрабатывали модульные тесты для 100 % своих функций. И самое важное – они трудились над небольшим количеством функций одновременно, обычно это было 5–10 функций в работе для всей команды в любой момент.

Целевым ориентиром для функции в FDD является 1,6–2,0 функционального очка кода.

У команды по разработке сервера закачек OTA, находившейся в Сиэтле, среднее время выполнения составляло примерно три месяца на функцию от начала работы до сдачи ее для интеграционного теста команде из Шампейна (рис. 3.1).

У команды по разработке OTA DM среднее время выполнения колебалось от 5 до 10 дней, что показано на рис. 3.2. Разница в исходном качестве, измеряемом в количестве ошибок в системном или интеграционном тесте, превысила 30 раз. Команда по разработке OTA DM продемонстрировала изначальное качество на уровне лидеров индустрии – две или три ошибки на 100 функций, а команда по разработке сервера закачек OTA продемонстрировала средний по индустрии результат – около двух ошибок на функцию.

Рис. 3.2. Кумулятивная диаграмма потока (КДП) команды управления устройствами OTA (зима 2004 года)

Из этих диаграмм можно сделать вывод, что количество незавершенных задач непосредственно связано с временем выполнения. Рис. 3.2 явно демонстрирует, что с сокращением числа незавершенных задач уменьшается и время выполнения. На пике среднее время выполнения составляет 12 дней. Позднее в проекте, когда незавершенных задач становится меньше, среднее время выполнения сокращается до четырех дней.

Существует причинно-следственная связь между количеством незавершенных задач и средним временем выполнения, и эта зависимость линейна. В производстве эти отношения известны как закон Литтла. Пример двух команд из Motorola предполагает наличие корреляции между увеличением времени выполнения и снижением качества. Похоже, что увеличение времени выполнения оборачивается существенно худшим качеством. В нашем случае увеличение среднего времени выполнения в 6,5 раза повлекло за собой более чем тридцатикратное увеличение первичных ошибок. Более долгое время выполнения связано с увеличением количества незавершенных задач. После выявления этого примера я стал использовать незавершенные задания как средство контроля качества и убедился в наличии взаимосвязи между их количеством и исходным качеством кода. Однако на момент написания этой книги не существует научных подтверждений этого эмпирически полученного результата.