Дэн Олсен – MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям (страница 54)
Основное внимание в Канбане уделяется рабочему потоку. Здесь нет ограниченных по времени итераций, как это принято в 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, за тем исключением, что бэклог текущего спринта не фиксирован, а определяется динамически. По умолчанию истории пользователей сортируются на основе количества присвоенных им баллов и автоматически включаются в текущую итерацию и выходят из нее. При этом ведется учет расчетной скорости отработки и времени, оставшегося до завершения спринта. Если вас не устраивает такая настройка, вы можете воспользоваться режимом «ручного планирования» (называемым также режимом «фиксации»), который позволяет зафиксировать порядок расположения историй в бэклоге спринта. В том случае, если вы не воспользуетесь перечисленными опциями, работа приложения будет в большей степени соответствовать методологии Канбана.
Выбор правильного метода Agile-разработки
Теперь, когда у вас есть общее представление о Scrum и Канбане, осталось решить, какой из методов больше подходит для использования в вашем конкретном случае. Несмотря на то что приверженцы каждой из этих методологий видят в них серьезные различия, на самом деле оба подхода построены на общих принципах Agile. Я обнаружил, что Agile-фреймворки подобны обуви: чтобы понять, насколько хорошо вам подходят те или иные туфли, их нужно просто примерить. Разумный выбор подходящей методологии состоит в том, чтобы поочередно опробовать их в течение нескольких месяцев. Многие команды начинают с того, что пробуют применять либо Scrum, либо Канбан. Если методология работает хорошо, они продолжают ее придерживаться. Если нет, переходят к следующей. Примерив обе «пары обуви», команда получит все необходимое, чтобы решить, какая из них подходит ей лучше.
Тем не менее, вот несколько советов, которые увеличат шансы начать «выбор обуви» с наиболее подходящего варианта: Канбан, как правило, подходит для небольших команд разработчиков. Меньшие накладные расходы и отсутствие заранее определенной продолжительности итерации могут обеспечить более быстрый выпуск продукта. Но, по мере того как компания разрастается до нескольких команд разработчиков, применение Канбана может становиться все более сложным. Отсутствие строго определенного графика выполнения работы может усугубить ситуацию, поскольку многочисленным группам разработчиков требуется больше времени на коммуникации, чтобы оставаться на одной волне. Команды, которые имеют хороший опыт совместной работы, способны масштабировать Канбан до больших размеров без негативных последствий. Но, если в вашей компании есть несколько команд, которым необходимо координировать свою работу, то Scrum с его предсказуемым темпом разработки может оказаться более полезным.
Идея жестких плановых сроков запуска новых продуктов плохо соотносится с любыми методами гибкой разработки. Большинство компаний, применяющих «водопадный» подход, привыкли к тому, что у них есть нисходящая дорожная карта, которая диктует, какие функции они должны запускать каждый месяц или квартал, хотя эти сроки часто оказываются фикцией из-за регулярных задержек. При переходе на Agile многие из них по-прежнему придерживаются «водопадного» подхода в отношении бэклогов своих продуктов. Мне нравится использовать термин «Agilefall»[24] для описания компаний, переживающих трудности перехода с «водопадного» подхода на Agile и пытающихся поначалу усидеть сразу на двух стульях. Если вашей команде будет трудно отказаться от «подушки безопасности» в виде жестких сроков запуска, то вам, скорее, подойдет Scrum, нежели Канбан. По крайней мере, используя Scrum, вы знаете, что определенный объем работ будет выполнен к концу каждой итерации, и можете примерно оценить, сколько спринтов потребуется для запуска той или иной функции. Большинство команд, работающих по Канбану, не тратят время на оценку трудоемкости или планирование сроков завершения работ. Тщательно отслеживая продолжительность цикла и используя простые статистические методы, даже в случае с применением Канбана можно делать относительно достоверные прогнозы в отношении срока запуска продукта, однако лишь немногие команды разработчиков могут похвастаться настолько высоким уровнем точности отслеживания своих рабочих процессов.