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

Стикерные представители

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

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

Стикерные представители помогают и при разработке, распределенной по нескольким географическим зонам. Особенно важно это было для Corbis, когда команда тестировщиков работала в Ченнаи (Индия), а некоторые специализированные разработчики финансовых систем находились в Южной Калифорнии.

Синхронизация по географическим зонам

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

На самом деле все наоборот. Первая команда в Microsoft (из главы 4) находилась в индийском Хайдарабаде, в то время как руководство и владельцы продукта размещались в американском Редмонде. У компании Corbis, описанной в главе 5, тоже были команды и в Индии, и в других местах за пределами Сиэтла – например, в Лос-Анджелесе и Нью-Йорке, и это не считая людей, периодически работавших дома.

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

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

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

Выводы

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

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

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

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

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

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

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

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

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

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

Глава 8

Формирование каденции поставки

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

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

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

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

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

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