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

Решить вопрос координации между разными местами можно при помощи электронной системы. Одной стены карточек недостаточно.

Помимо электронного ведения задач понадобится ежедневно синхронизировать физические стены карточек. Важно, чтобы за этим в каждом офисе следил специально назначенный человек. Одна команда, с которой мы работали в 2008 году, базировалась в Нью-Йорке и Лос-Анджелесе. У них были (почти) идентичные стены карточек в каждом офисе, и за их синхронизацию в обоих случаях отвечал определенный сотрудник.

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

• Лучше всего использовать и физическую стену карточек, и электронную систему управления задачами.

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

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

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

• Расстановка приоритетов и планирование релиза должны проводиться независимо друг от друга и иметь свой собственный ритм.

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

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

• Регулярный триаж бэклога в целях его сокращения положительно влияет на скорость и эффективность совещаний по расстановке приоритетов.

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

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

Раздел 3 (главы 6–15) описывает механизмы внедрения канбан-системы, заканчиваясь главой 15, где говорится о том, как выступить с инициативой перехода на Канбан. Инициация перехода требует договоренности с различными внешними заинтересованными лицами, а не только с клиентами, типичными для компаний по разработке и их партнеров. Например, эта новая договоренность предполагает обязательство по регулярной выдаче работающего продукта.

Термин «каденция поставки» предполагает установление паттерна выдачи релизов работающего продукта с регулярными интервалами. Например, если мы договорились выдавать продукт каждые две недели, то каденция поставки будет составлять раз в две недели, или 26 раз в год. Возможно, появится даже решение по конкретному дню поставки. Например, каждую вторую среду, как это было с корректировочными версиями IT-приложений в Corbis.

В кругах, близких к гибкой разработке ПО, устоялось мнение о важности регулярной каденции. В agile-методах разработки она достигается благодаря сгруппированным по времени итерациям длиной от одной до четырех недель. Необходимость таймбоксинга (ограничения по времени) основана на том, что для проекта очень важен устойчивый ритм, а для этого нужно применять строго ограниченные по времени итерации. В начале каждой итерации определяется объем работ (бэклог итерации) и обязательства по их выполнению. Все приходит в действие! Проводятся анализ, планирование тестов, проектирование, разработка, тестирование и рефакторинг. Если все идет по плану, то запланированная работа делается в полном объеме. Итерация заканчивается предоставлением работающего продукта и ретроспективным собранием, на котором обсуждаются возможности будущих усовершенствований и модификаций процесса. Затем цикл повторяется с четко заранее оговоренной частотой – еженедельно, раз в две недели, ежемесячно и т. д.

Канбан избавляется от ограниченных во времени итераций и вместо этого рассинхронизирует деятельность по расстановке приоритетов, разработке и поставке. Каденция для каждой из них устанавливается и корректируется естественным образом. Однако Канбан не отказывается от понятия «регулярная каденция». Канбан-команды по-прежнему с заданной частотой выдают версии продукта, предпочитая короткие интервалы. Метод тоже работает в соответствии с «Принципами манифеста гибкой разработки» {19}. Однако Канбан старается избегать любых крайностей, связанных с искусственной установкой временн ы х рамок для задач.

За последние десять лет команды, использующие agile-методы, пришли к выводу, что лучше меньше незавершенных задач, чем больше, и что поставка функционала небольшими порциями предпочтительнее всего. Поэтому в середине последнего десятилетия произошел переход на более короткие итерации. Так, типичные команды Scrum перешли с четырехнедельных циклов на двухнедельные, а команды, практикующие экстремальное программирование, – с двухнедельных на недельные. В результате возникла проблема с делением работы на малые порции – порой бывает трудно сделать их достаточно малыми, чтобы их выполнение укладывалось в доступное временн о е окно. Рынок ответил на это, создав более изощренные методы анализа и написания пользовательских историй. Цель – сократить размер историй, сделать их детализированнее и снизить вариативность размера, чтобы уложить их в более короткие итерации. Хотя такой подход кажется вполне здравым, достичь этого трудно. Он относится к шестому элементу рецепта успеха: атака на источники вариативности для улучшения предсказуемости. Как уже говорилось в главе 3, сокращение вариативности часто требует от людей изменить свое поведение и обрести новые навыки. А это очень непросто.

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