Собрания по пополнению очереди

 

Собрания по пополнению очереди в Канбане призваны расставить приоритеты. Этот этап обычно откладывается на последний момент в связи с природой механизма пополнения очереди и каденции совещаний. Собрания по пополнению очереди проводятся с привлечением группы бизнес‑представителей или владельцев продукта (если использовать терминологию agile‑разработки). Рекомендуется проводить такие собрания с регулярными интервалами. Равномерный темп снижает координационные затраты и придает надежность отношениям между бизнесом и командой разработки ПО.

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

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

На собрании присутствуют и другие заинтересованные лица. Желательно, чтобы среди них были ответственный за выполнение (например, менеджер проекта), как минимум один менеджер, отвечающий за техническую функциональность (например, менеджер по разработке или тестированию либо более высокопоставленный менеджер из той же области), человек, способный оценить технические риски (например, технический архитектор системы или архитектор данных), профессионал в области эргономики, специалист по операциям и системам, бизнес‑аналитик. В 2007 году в моей команде на собраниях бывали менеджер по разработке и менеджер команды аналитиков, а иногда также корпоративный архитектор или архитектор данных. Менеджеры по разработке посещают собрания поочередно в соответствии с графиком.

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

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

 

Совещания по планированию поставок

 

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

Человек, ответственный за координацию выполнения (обычно это менеджер проекта), как правило, ведет и совещания по планированию поставки. Следует пригласить и все остальные заинтересованные стороны – специалистов по управлению конфигурацией системы, специалистов по эксплуатации системы и сети, разработчиков, тестировщиков, бизнес‑аналитиков и т. д., а также непосредственных руководителей перечисленных сотрудников, которые присутствуют благодаря своим техническим познаниям и умению оценивать риски. Менеджеры участвуют в совещании, чтобы можно было немедленно принять решения.

У зрелой компании обычно готова технологическая карта или структура релиза, что облегчает планирование. Вот некоторые вопросы, которые нужно принимать во внимание:

• Какие элементы системы готовы (или будут готовы) для релиза?

• Что требуется, чтобы действительно подготовить релиз всех элементов?

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

• С какими рисками это сопряжено?

• Как эти риски минимизировать?

• Какие планы экстренных мероприятий потребуются?

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

• Сколько времени займет релиз?

• Что еще для него необходимо?

 

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

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

 

Триаж

 

Триаж – это медицинский термин, который обозначает оценку и классификацию срочно поступивших больных по степени неотложности врачебной помощи. Сначала эта система применялась в военно‑полевых условиях, где пациентов делили на три категории: умирающие, кому оказать помощь уже нельзя; те, кто может выжить только при неотложной помощи; и те, кто, скорее всего, останется в живых и без срочной помощи. И сейчас в приемных покоях больниц существует подобная система классификации пациентов.

Триаж был усвоен разработчиками ПО для систематизации дефектов во время стабилизационной фазы традиционного программного проекта. Триаж использовался для отделения ошибок, которые должны быть устранены (и очередности их устранения), от тех, что останутся и могут пойти в производство при выходе продукта. Обычно триаж ошибок проводили ведущий тестировщик и ведущий разработчик, руководители группы тестирования и разработки, а также владелец продукта.

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

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

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

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

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

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

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