MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям - Дэн Олсен

Возьмем для примера ситуацию, представленную на Рисунке 12.4. Когда разработчик завершит работу над заданием D, он переместит его карточку из столбца «В процессе» в столбец, соответствующий стадии «Завершено». Однако при этом он не сможет перенести задание F из состояния «Подготовлено» в столбец «Разработка», поскольку лимит НЗП для этой стадии, равный трем карточкам, уже исчерпан. Аналогично, когда тестировщик завершит работу с заданием B, он переместит его карточку в столбец «Тестирование завершено», но не сможет взять в работу задание C, поскольку для стадии «Тестирование» исчерпан лимит НЗП, равной двум карточкам. Для продолжения работы необходимо «вытолкнуть» одну из карточек из столбца «Тестирование завершено». Как только это произойдет, задание C может быть переведено в состояние «В процессе тестирования», что, в свою очередь, освободит место в столбце «Разработка» для задания F.

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

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

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

Вы можете визуализировать ход работы в системе Канбан с помощью диаграммы кумулятивного потока (Рисунок 12.5), которая показывает, сколько карточек заданий находилось в каждом из рабочих состояний в конце каждого дня. Для простоты на Рисунке 12.5 отслеживаются только три вида рабочего состояния: «Бэклог», «В процессе» и «Завершено». Вы можете видеть, что продолжительность цикла измеряется горизонтальной толщиной слоя, относящегося к заданиям, находящимся «В процессе», а показатель времени выполнения равен суммарной горизонтальной толщине слоев, отражающих количество заданий в «Бэклоге» и «В процессе». Количество НЗП равно вертикальной толщине слоя, характеризующего количество заданий, находящихся «В процессе».

Рисунок 12.5. Диаграмма кумулятивного потока

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

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

При существенном различии масштабов выполняемых рабочих заданий можно наблюдать расширение диапазона значений продолжительности цикла, поскольку небольшие задания отрабатываются быстрее, чем более масштабные. Некоторые практикующие Канбан разработчики применяют оценку масштабности заданий, используя описанную выше систему, основанную на размерах футболок (S, M, L и так далее). Это позволяет обеспечить получение более адекватных значений показателя продолжительности цикла; разные значения данного показателя соотносятся с оценками сложности отрабатываемых заданий.

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

Инструменты Канбана

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

Однако существует множество цифровых инструментов для управления канбан-процессами. Одним из наиболее популярных приложений для визуализации канбан-доски в ходе разработки программного обеспечения является Trello. На самом деле, многие используют Trello для управления и другими рабочими процессами. Это приложение особенно популярно среди менеджеров по продуктам и дизайнеров. Они используют собственные рабочие панели, которые могут подключаться к канбан-доскам разработчиков. Многие канбан-команды используют такие приложения, как JIRA Agile, SwiftKanban и LeanKit.

Еще одним достойным внимания приложением является Pivotal Tracker, хотя оно и не относится к инструментам, специализированным для Канбана. Я использовал Tracker при создании нового продукта, когда получал полезный опыт работы с Pivotal Labs. Это приложение использует виртуальную доску со столбцами, отведенными для каждого из заранее определенных рабочих состояний. Данный инструмент поддерживает интересное сочетание Канбана и Scrum (существует даже Agile-методология под названием «Scrumban», которую будет полезно изучить, если эта идея выглядит для вас привлекательной).

Приложение Pivotal Tracker позволяет оценивать пользовательские истории в баллах и вычислять скорость выполнения работы. Такой подход в большей степени соответствует методологии Scrum, за тем исключением, что бэклог текущего спринта не фиксирован, а определяется динамически. По умолчанию истории пользователей сортируются на основе количества присвоенных им баллов и автоматически включаются в текущую итерацию и выходят из нее. При этом ведется учет расчетной скорости отработки и времени, оставшегося до завершения спринта. Если вас не устраивает такая настройка, вы можете воспользоваться режимом «ручного планирования» (называемым также режимом «фиксации»), который позволяет зафиксировать порядок расположения историй в бэклоге