Использование канбан в разработке программного обеспечения: от Agile к Lean. Окончание

Источник

Окончание. Начало здесь

Автор: Кенжи Хиранабе (Kenji Hiranabe), основатель и генеральный директор Change Vision, Inc., Япония

Перевод: В. Федорущенко

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

Теперь давайте рассмотрим непосредственно нашу сферу деятельности – разработку ПО. В среде Agile уже давно принято отображать статус проекта визуально, помещая карточки на стене рабочей комнаты.

Такие карточки часто называются «канбаном задач» или «программными канбаном».

На рисунке 5 изображен пример канбана задач, используемого разработчиками компании Change Vision Inc.

Рис. 5. Agile канбан

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

Является ли такая система вытягивающей? На производстве детали передаются с предыдущего процесса последующему. В Agile, как показано на рис. 5, не видно этапов «передачи». Каждая карточка канбан считается одной задачей, на ней записана информация о номере задачи, названии, примерном времени выполнения и имени человека, задавшего данную задачу. Задачи имеют статус «сделать», «в процессе», «готово» и видны всей команде. Agile особенно ценит командную работу и старается избегать «передачи» задач внутри команды. Я называю это «Agile канбан» или «гибкий канбан».

На рисунке 6 показан еще один пример доски канбан, используемой в копании Ямаха (Yamaha Motor Solutions Co., LTD).

Рис. 6. Поддерживающий канбан

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

В данном случае используется понятие «рабочего процесса» вместо понятия «итерации», используемого в Agile. Такой метод больше похож на канбан в производстве, чем в Agile, и этот процесс может представлять собой «вытягивающую систему», если разрешить только последующему процессу передвигать карточки канбан. Я называю это «поддерживающий канбан» и нахожу его схожим с KSSE Дэвида Андерсона, который я опишу ниже в этой статье.

И еще один пример на рисунке 7 – воображаемый эксперимент, демонстрирующий использование канбан в потоке создания ценности всего процесса разработки продукта.

Рис. 7. Lean + Agile канбан

Представим, что в едином потоке разработки продукта существует команда заказчика, владелец продукта, команда разработчиков и команда качества. Все они работают вместе, передавая задачи и используя очереди так, что каждая команда работает асинхронно, но поддерживая скорость работы, зависящую друг от друга. Каждое поле «готово» по сути является очередью, выполняющую роль, похожую на склад производственного предприятия, и по сути выглядит почти так же, как канбан в TPS. Это больше похоже на использование Agile канбана асинхронно внутри каждого процесса и использование поддерживающего канбана синхронно вдоль всего потока процесса. Я полагаю, что систему канбан можно расширить до масштабов всего процесса, в таком случае канбан будет наглядным изображением потока создания ценности.

В данном примере объемы незавершенных работ могут быть ограничены заданными размерами каждой из областей. Чтобы превратить эту систему в вытягивающую, необходим какой-то механизм, который будет давать сигнал на работу предыдущему процессу. В качестве одного из решений можно ввести правило, что только последующий процесс может передвигать карточки «готово» в качестве сигнала для предыдущего процесса. Второе решение — проводить периодические совещания по итерации, на которых будет синхронизироваться работа команд и транспортировка (передача) информации между ними. Эти два способа коммуникации похожи на два сигнала «изъятия», о которых говорилось ранее: визуальный сигнал о количестве изъятых канбанов и о периодическом интервале времени. Здесь набор отзывов пользователей для одной итерации соответствует детали, изъятой с поддона, а число деталей (канбан) соответствует проектной «скорости» итерации. Я называю этот метод «Lean + Agile канбан», и он может быть объединен с «Agile канбан», как показано на следующем рисунке.

На рисунке 8 изображен небольшой переносной канбан, который я обнаружил на проекте в компании Сentral Computer Services. На данном проекте команда работает в нескольких небольших подгруппах (обычно по двое). У всей команды существует рабочий процесс, концептуально похожий на рис. 7, а также небольшие доски – Agile канбан, как показано на рисунке 8 (сделать/в процессе/готово). Когда подгруппа получает один отзыв от пользователя, она разбивает его на задачи и записывает их на доске канбан. В данном случае, систем канбан – двухуровневая: первый уровень проекта, где карточки канбан являются сообщениями пользователей, и второй уровень группы или подгруппы, где карточки означают задачи. Данной компании очень понравилось использование небольшой переносной системы канбан, и они назвали ее «нано-канбан».

Рис. 8. Переносной Agile канбан (нано-канбан)

Как вы видите, есть несколько способов применить понятие канбана в программном обеспечении. «Agile канбан» работает внутри команды, чтобы обмениваться информацией и сделать работу более самонаправленной, но он не поддерживает рабочий поток. «Поддерживающий канбан» — другой метод, позволяющий работе по техническому обслуживанию, разбитую на мелкие части, протекать между фазами проекта (enabling small-batch maintenance work to flow between several states). Комбинация «Lean + Agile канбан» использует «поддерживающий канбан» вдоль всего потока работ, а «Agile канбан» – внутри подпроцессов.

Важно заметить, что “Agile канбан” на рис. 5, который в настоящее время часто встречается в Agile проектах, видит только подгруппу (subteam) в потоке создания ценности. Если вы рассматриваете поток создания ценности целиком от клиента до клиента, в этом случае обычно существует команда внутри того же потока, которая выдает вам заявки или другая команда, которая доставляет ваши результаты клиенту. Одна из целей данной статьи – предложить идеи по расширению применение канбан от простого Agile канбан до канбан на всем потоке создания ценности.

Производство и разработка

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

	Agile канбан	Поддерживающий канбан	ТPS канбан
А) Физический	Да	Да	Да
В) Ограничивающий WIP	Возможно	Фокусировка	Да
C) Непрерывный поток	Возможно	Фокусировка	Да
D) Вытягивающий	Возможно	Фокусировка	Да
E) Самонаправляющийся	Фокусировка	Да	Да
F) Визуальный	Фокусировка	Да	Да
G) Посылающий сигнал	Да	Да	Да
H) Побуждающий к Кайзен	Фокусировка	Да	Да
I) Прикрепленный	Нет	Да	Да

«Ограничивающий WIP», «Непрерывный поток» и «Вытягивающий» – свойства сами по себе не присущи Agile канбан, показанному на рис. 5. Agile канбан больше делает акцент на выполнение задач, «визуализацию» и «самонаправление», чтобы помочь команде быть более автономной и улучшить внутренние процессы. Для того, чтобы сделать поток непрерывным, а также ограничить незавершенное производство, необходимы «совещания по итерации» для передачи информации.

«Поддерживающий канбан» на рис. 6 без «совещаний по итерации» может ограничить WIP, а также контролировать поток как единое целое по принципу «вытягивания». В данном подходе акцент стоит на «ограничении WIP», «непрерывности потока» и «вытягивании», в то же время позволяя команде (или менеджеру) использовать данный метод для улучшения процессов.

Возвращаясь к рис. 3, я разбил свойства и результаты канбан на две основные категории (на рис. 9), так, чтобы два вышеупомянутых канбана программного обеспечения соответствовали этим категориям. А на рис. 10 проиллюстрирован спектр применения канбан в производстве и разработке. Производство – это процесс с высоким процентом успеха (больше 99%), а разработка имеет более низкий шанс на успех. Agile разработка – это процесс, в котором шанс успеха примерно 50%, в то время как каскад оптимален, когда шанс успеха больше 90% (согласно теории Шеннона, проект с 50% шансом успеха является самым ценным). Обычно, когда разработка переходит в состояние технической поддержки, шансы на исправление ошибок и добавление новых функций возрастают.

Фокус канбан-систем на «контроль над процессами» подходит работе с «более 90%» шансом на успех, тогда как фокус канбан-систем на «улучшение процессов» подходит работе в областях, где шансы на успех равны и 50%, и 90%.

Заметьте, что подход Agile также хорошо работает на поддерживающей стадии разработки продукта, так же как и свойства канбан, направленные на «улучшение процессов».

Рис. 9. Свойства и результаты канбан

Рис 10. Спектры подхода с использованием канбан

KSSЕ

Здесь я расскажу о недавно появившемся применении Лин в разработке программного обеспечения. Однажды на конференции по Agile я послушал сессию Дэвида Андерсона про программный канбан. Он управлял «поддерживающим типом» систем канбан в Corbis.com и опубликовал на эту тему работу «KSSE». Его подход заключался в том, что среди свойств канбана, в первую очередь, нужно делать акцент на «ограничении незавершенного производства», как и указано в абстрактной диаграмме на рис. 4, а также на «самонаправляющей» характеристике, которая делает команду самоорганизиванной, требуя меньше управления «сверху». Затем, проведя визуализацию потока с помощью канбан, он нашел места, «задерживающие» весь поток, и скорректировал человеко-ресуры, например, передвинул людей между процессами. Это значит, что его подход учитывает свойства канбана от «ограничения WIP» и «самонаправления» до «кайзен», как показано на рис. 3.

После конференции Андерсон начал рассылку, в которой ведется обсуждение и собирается информация о применении канбана в Agile. Аарон Сандерс тоже участвует в сборе знаний про канбан, он начал создавать «словарь KSSE».

KSSE работает хорошо, если существуют множественные серийные процессы, передающие задачи через очереди между процессами. Заметьте, KSSE не обязательно применяет концепцию «итераций». Я вижу возможность применять Agile несколько в другом масштабе, чем «скрам скрамов» («scrum of scrums»), используя KSSE.

Обеспечить поток ценности

Когда Agle сравнивается с Lean в использовании канбан, что должны представлять собой карточки канбан?

В Agile канбан, одна карточка — это «задача», выявленная из «отзыва клиента». В команде разработчиков она представляет собой единицу работы, потому что каждый в команде знает, что это значит. Однако если системы канбан работают с несколькими процессами (командами) в потоке создания ценности, что движется по потоку, создавая ценность для клиента? В этом случае карточки канбан – это не «работа», а «характеристики», и это не фрагмент структуры декомпозиции работ (WBS – work breakdown structure), а фрагмент структуры декомпозиции характеристик (FBS – failure breakdown structure), чтобы все, даже клиент, смогли понимать значение и ценность того, что движется в потоке. Джим Хигсмит в своей книге «Agile Project Management» тоже отдает преимущество FBS над WBS.

«Отзывы клиентов», «резервы» (backlog items), «случаи использования» абстрактно называются минимальными рыночными характеристиками (MMF – minimum marketable features), чтобы точно указать, что движущееся в потоке несет ценность клиенту. А бережливая разработка тогда может быть расшифрована как «заставить минимальные рыночные характеристики двигаться быстрее через весь поток ценности».

Пример «Agile канбан» на рис. 5 – это разбивка (декомпозиция) работ, которая хорошо действует внутри команды. Пример «поддерживающего канбана» на рис. 6 – это декомпозиция характеристик и каждая карточка представляет собой минимальные рыночные характеристики. Пример «Lean + Agile канбан» на рис. 7, используемого на рис.8, показывает комбинацию декомпозиции характеристик на высоком уровне и декомпозицию задач на низком уровне.

Как только рабочий поток определен, пять принципов гибкого мышления (Вомак, 1996) могут быть применены непосредственно ко всему процессу. Управление бережливым процессом просто следует нижеуказанным принципам:

1. Определить ценность для клиента — определить и отранжировать минимальные рыночные характеристики.
2. Определить поток создания ценности и устранить потери – найти задачи, задерживающие поток.
3. Дать клиенту возможность задавать темп движения потока создания ценности – дать канбану управлять потоком.
4. Вовлечь и дать полномочия рабочим — уполномочить команду в гембе.
5. Непрерывно проводить улучшения в стремлении к совершенству — рефлексия и кайзен.

TPS – Общая Картина

Дальше следует приложение, в котором я делюсь тем, что узнал из TPS (Toyota Production System) и считаю применимым и к программным разработкам. Мэри и Том Поппендик считают, что в эффективной разработке программного обеспечения много общего с TPS и Бережливым производством на уровне принципов, а не практики. Так что давайте сделаем шаг назад, и посмотрим на канбан в TPS c высока.

Легко вообразить, что канбан – это центр TPS, но это не так. На рис. 11 показана концептуальная структура производственной системы Тойота (TPS), которую иногда называют «Дом TPS». Существует несколько ее вариантов, и здесь показана версия Тошико Нарусава и Джона Шука. В TPS канбан – это лишь инструмент вытягивающей системы для реализации принципа «точно в срок». «Точно в срок» можно по-другому перефразировать как «делать и поставлять то, что нужно именно тогда, когда нужно и именно в нужном объеме». Этот принцип стремится обеспечить потребность клиента в приобретении «продукта наилучшего качества за наименьшую возможную цену в кратчайшие сроки». Заметьте, что «точно в срок» – это лишь одна из двух основ TPS, второй является дзидока (Jidoka). Дзидока или автоматизация в производстве – это то же самое, что разработка через тестирование (test-driven development) в программном обеспечении. Мэри и Том Поппендик интерпретируют дзидоку как «Культуру остановки линии». Работники заводов Тойота действительно останавливают производственную линию, вместо того, чтобы отправлять дефекты на следующий этап – это не просто правило, а культура Тойоты, которая датируется еще временем Сакичи Тойода.

Рис. 11. Структура концепции TPS

Точно в срок состоит из трех элементов: «время такта», «непрерывный поток» и «вытягивающая система».

1. Время такта задает темпы производства продуктов, основываясь на уровне продаж.
2. Непрерывный поток производит продукты в процессе без задержек, согласно времени такта.
3. Вытягивающая система передвигает элементы (детали) и управляет производством между процессами, ограничивая объемы запасов.

Также заметьте, что эти две основы TPS полагаются на кайзен и людей. Тойота производит около 10 миллионов автомобилей в год, и в то же время они улучшают свои процессы почти на 1 миллион кайзен-предложений в гембе (рабочем месте). Визуализация того, что делает команда, всегда первый этап кайзена.

Заключение

Я проанализировал работу канбан в производстве и выделил его свойства. Системы канбан используются, чтобы достичь:

1. Лучшего контроля над процессами – они обеспечивают непрерывный поток, в то же время ограничивая незавершенное производство.
2. Улучшения процессов – они делают поток видимым и побуждают к Кайзен.

То, что я называю «Agile канбан», делает акцент на пункте 2, в то время как «поддерживающий канбан» направлен на первый. Я предложил комбинацию обоих, чтобы расширить визуализацию и «вытягивающую систему» на весь поток создания ценности и сделать весь процесс бережливым.

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!

Получить подарок

---

Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Подписаться

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.