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

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

Триаж бэклога нужно проводить сравнительно нечасто. (Заметим, что в некоторых методах гибкой разработки ПО он называется «грумингом».) Разные команды предпочитают различную периодичность – ежемесячно, ежеквартально, дважды в год. При триаже бэклога обычно присутствуют те же владельцы продукта и представители бизнеса, которые ходят на собрания по пополнению очереди, а также менеджер проекта. Технических сотрудников немного – нередко они представлены одним менеджером среднего звена.

Цель триажа бэклога – проанализировать все эти элементы и решить, оставить их или удалить. При этом не назначаются никакие ранги и не расставляются приоритеты: выбор стоит единственный – оставить или удалить.

Некоторые команды смогли отказаться от триажа благодаря автоматизации и внутренним правилам. Так, команда Microsoft XIT из кейса в главе 4ежемесячно удаляла из бэклога все элементы старше шести месяцев. Считалось, что если элемент за полгода так и не перевели во входящую очередь, то он вряд ли обладает существенной ценностью и, возможно, его вообще никогда не выберут. Но при изменении ситуации его всегда можно затребовать обратно, так что удаление из бэклога ничего не испортит.

Цель проведения триажа бэклога – сокращение его размеров. Преимущество меньшего размера бэклога – в облегчении процедуры обсуждения приоритетов. Выбирать из 200 элементов гораздо проще, чем из 2000.

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

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

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

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

В анализе журнала проблем должны принимать участие менеджер проекта и члены команды, которые отметили элементы как блокированные. При этом следует ответить на вопросы «Кто отвечает за проблему и работает над ней?» и «Когда ожидается ее разрешение?». Проблемы, в решении которых нет прогресса и работа над которыми блокирована, должны быть переданы высшему руководству.

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

Обычно работа с проблемами и передача их наверх – узкое место даже в организациях, принявших agile-методы разработки. Быстрое решение проблем, особенно тех, которые не зависят от команды разработки – доступность среды, не вполне понятные требования, недостаток оборудования для тестирования, – ускоряет рабочий поток и значительно увеличивает как производительность команды, так и создаваемую ценность. Устранение проблем и передача их наверх – очень важные элементы работы, которые окупаются сторицей. Улучшения в них должны стать приоритетом даже для незрелых команд. Подробнее об этом – в главе 20.

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

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

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

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

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