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

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

Ответ: При одновременном достижении двух условий:

1. Команда, как черный ящик, устроена внутри корректно: умеет работать с потоком обрабатываемых объектов (намеренно не указываю каких), пропускная способность отдельных этапов обработки сбалансирована. Достижение такого состояния – предмет отдельной целенаправленной работы, детализировать далее не будем, предполагаем далее, что оно достигнуто.
2. Команда может управлять входом поступающих объектов:

• • объекты должны быть замкнутыми (в математическом смысле :): иметь строгие границы) так, чтобы команда могла их осознать и работать с ними, определять Definition of Done (DoD);
  • объекты должны обладать определенной общностью в “размерах”, т.к. сложно обещать стабильность поставки, если трудоемкость объектов варьируется от 10 минут до нескольких недель;
  • команда управляет work in progress лимитом на число объектов обрабатываемых на первом этапе конвейера (bingo!: меньше впустим – быстрее пролетит).

Для того, чтобы подсчитать всех дьяволов, кучно роящихся в деталях, предлагаю более пристально взглянуть на то, как формируется этот “вход”.

Что слева?

Для иллюстрации воспользуемся классификацией компании Atlassian:

• Темы
• Инициативы
• Эпики
• Истории
• Задачи/подзадачи

Если вы взглянете на эту иерархию, то увидите, что в ней смешиваются объекты двух назначений:

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

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

Темы можно смело считать статичными аналитическими управленческими группировками.

Где здесь Бэклог?

Из чего состоит бэклог команды? Из каких объектов он состоит? Какая работа предшествует его пополнению?

Беклог команды состоит из понятных команде конечных элементов, обрабатываемых командой за один или несколько (не более чем некоторое N) условных “тактов”.

Такими объектами в иерархии Atlassian являются истории и подзадачи. Все ли с этом хорошо и понятно? Нет.

Истории изначально сформулированы так, чтобы обеспечивать сохранение/подтверждение некоторой ценности на нижнем уровне инкремента.

Задачи – не имеют такого свойства. Откуда же они появляются?

Реальные приложения устроены так, что отдельные пользовательские истории могут выливаться в чрезвычайные объемы работ. Из недавнего: “Кредитный менеджер должен иметь возможность выдать коммерческой компании кредит государственной поддержки бизнеса во исполнения ПП РФ №… от вчерашнего числа”, волосы причастных по сей день шевелятся.

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

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

Итак, бэклог команды состоит из набора взаимосвязанных историй и задач, которые по отдельности могут не иметь доказанной/воспринимаемой ценности. Тем не менее – именно с этим команда может работать быстро.

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

Как пополняется бэклог?

Владелец продукта отвечает за развитие продукта, а значит и пополнение бэклога. Как это происходит?

В какой-то момент у владельца продукта возникает Идея, эта идея могла быть обретена разными способами:

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

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

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

Владелец продукта формирует поток обработки Идей (воронку), конечным результатом которого является:

• подтверждение/отклонение ценности Идеи;
• декомпозиция Идеи до структуры Инициатива-Эпики-Истории, где Инициатива и Эпики могут быть новыми или уже существующими, а Истории – только добавляться.

Если ценность Идеи подтверждена, то истории из ее декомпозиции включаются в бэклог команды. Для идеи проходит точка принятия решения. Заказчик (если он явно присутствует) начинает ждать ее реализации (акцент к конечной ценности отдельных историй: заказчик, по умолчанию, ждет не реализации отдельных историй, сформулированных командой, а его Идеи целиком).

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

Вопросы на которые потребуется ответить команде при организации этой работы:

1. Как выделять/отрывать от основного потока ресурсы команды (которых в каждый конечный момент времени не хватает 🙂 ) на проработку идей в воронке.
2. Позволять ли воронке наполнять бэклог “впрок”?
   1. Если да, то как поступать при синхронном росте бэклога и недовольства скоростью
   2. Если нет, то как обосновывать тезис “мы пока не можем принять ваши ценные идеи”, т.к. именно в воронке и формируется восприятие и осознание их ценности?
3. Смириться (???) с тем, что бэклог может пополняться за счет детализации историй задачами, не имеющими самостоятельной ценности, если истории при ближайшем их рассмотрении потребовали разбиения.