Портал №1 по управлению цифровыми
и информационными технологиями

Бэклог! — Как много в этом слове ...

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

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

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

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

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

Что слева?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT