Ретроспектива в канбан-команде

2021.09.06 (ред. 2021.10.26)

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

Более того, если в организации работает профессиональный agile-коуч, то организация может стать agile через канбан-метод. Просто не резким революционным, а более плавным эволюционным путем. Некоторые организации по-другому не смогут. Но даже настоящая agile-команда в какой-то момент может временно приостановить эксперименты (спринты), и просто начать работать на потоке обратной связи с операционки и рынка. И тогда она также временно станет обычной delivery командой.

Таким delivery командам также нужны ретроспективы. Но проводить их нужно явно не совсем так, как для agile (scrum) команд. В этой статье я поделюсь своим опытом настройки цикла инспекции и адаптации в виде ретроспективы для delivery-команды.

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

Организуйте людей вокруг работы

Мы разделили два типа карточек, которые появлялись на наших досках:

  1. Функционал, имеющий ценность для бизнеса. Например, фичи, user story, баги, техдолг. Для простоты, далее по тексту я буду называть все такие карточки фичами.
  2. Та часть работ по реализации фичи, которая может быть сделана отдельно взятой командой или даже одним человеком. Часть не представляет никакой ценности для организации без реализации других частей. Это могут быть архитектурные или функциональные компоненты, либо функциональные работы, которые нуждаются в интеграции между собой в рамках реализации фичи. Далее по тексту - задачи.

Небольшое отступление на тему, какими бывают команды, которые не могут без других команд сделать фичу:

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

Итак, какой у нас была доска для фич? Во-первых, эта доска была единой для всех команд, которые делают один продукт. Во-вторых, фичи на ней (особенно вначале!) ехали только по трём спартанским колонкам - todo, in progress, done. In progress - кто-то уже начал работать над фичей. Done - поставлено в прод. Мы не расшивали in progress на пункты definition of done (далее по тексту - DoD). Product owner вместе с операционной иерархией не различает их между собой.

У каждой команды по-началу была своя доска для задач. Думаю, что команда может хотеть свою доску потому, что (о ужас!):

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

Задачи на доске команд едут по колонкам definition of done (DoD) и нуждаются в интеграции между собой в рамках реализации фичи. Позже, когда команды осознали, что большинство коммитов подшивается не в задачи, а в фичи, они вообще отказались от использования "своих" досок. Они пристегнули DoD в виде шаблонного чек-листа ко всем фичам, которые заезжают за точку принятия обязательств (из бэклога продукта на доску с фичами).

Сбор информации

Принципы проведения ретроспективы для delivery команды не особо отличается от принципов проведения ретроспективы спринта:

  1. ломаем лёд и создаем атмосферу
  2. собираем информацию
  3. анализируем собранное
  4. генерируем гипотезы улучшений
  5. принимаем решения
  6. закрываем ретроспективу

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

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

Сразу оговорюсь, я использовал в работе kaiten. Не уверен в том, что вы легко сможете это всё сделать в другом таск-трэкере. В процессе сбора информации мы изучали пять метрик:

  1. CFD
  2. Lead Time
  3. Throughput
  4. Spectral Chart (можно заменить на Control Chart)
  5. Cycle Time

CFD

На этой диаграмме хорошо видны изменения потока при настройке WiP-лимитов. Но мы этот график вскоре забросили, потому что команда уже была достаточно зрелой, чтобы не брать задач больше, чем они могут сделать - WiP выставили в 3 на in progress на доске фич и практически никогда в него не упирались.

Lead time

Общеупотребимое сокращение - LT. Открываем просто для того, чтобы оценить текущее состояние и динамику развития команды. Открыли, обрадовались/огорчились, закрыли. Но во время изучения графика у кого-то в команде может появиться идея, вопрос или инсайт. Поэтому тратим минуту времени на изучение. У меня lead time показывал два графика - один для standard класса обслуживания (фичи, техдолги), другой для expedit (острые проблемы, срочные задачи, хотфиксы).

Throughput

Сокращенно - TP. Смотрим чтобы понять, какой объем функционала был сделан за период. Лучше если у нас нормализованный поток фич, каждая из которых по степени неопределенности примерно равна остальным. Но этого состояния очень трудно достичь. Поэтому мы смотрели TP по количеству "попугаев" за период.

Сравниваем с предыдущими периодами. Здесь тоже открыли, обрадовались/огорчились, закрыли. Однако толку с этого графика в плане улучшения эффективности команды никакого нет. Потому что этот график никак не помогает понять, насколько хорошо команда научилась 10-му принципу Agile - простота, искусство минимизации лишней работы. Но график представляет ценность для владельца продукта.

Он знает, сколько денег команда ест за период. Если разделить эти расходы на количество попугаев (или фич), то получаем стоимость одного попугая (или фич). Стоимость, конечно, пляшет - меняется от периода к периоду. Однако, владелец продукта может взять среднее, или последнее, и использовать для оценки: сколько стоит запилить эту фичу? Если у нас типы фич разделены, например, на story, bug и tech, то график покажет сколько денег за период на что ушло.

Также владелец продукта может наглядно увидеть фокус-фактор команды и прикинуть, какое количество попугаев (фич) команда скорее всего сможет поставить в прод в течение следующего периода.

Spectral chart / Control chart

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

Контрольный график сразу показывает нормаль (SLA) и фичи, которые за него выбиваются по LT. График также наглядно показывает насколько сильно они выбиваются - чем выше точка (кластер) на графике, тем дольше фича поставлялась.

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

Cycle time

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

Вопрос не в том, какую часть конвейера поставки хотят фиксить разработчики. Вопрос в том, какая часть конвейера создает больше всего времени LT. С этим и помогает cycle time. Он показывает среднее время, в течение которого, задачи висят в определенной колонке. Смотрим и обсуждаем с командой, какую колонку стоит вообще ковырять. И потом, на этапе анализа ковыряем эту колонку и ищем проблемы, из-за которых задачи так долго делаются на этом этапе DoD.

Баги с прода

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

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

Очень нелегко было привить немедленный RCA (в виде "5 почему") по багам с прода. Однако, достаточно легко было привить zero bug policy. RCA приходилось делать на ретроспективе при разборе багов за период. Мы открывали список багов, которые были выявлены и исправлены за период и совместно искали системные причины их появления.

Эмпирический контроль решений

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

В этом очень помогало то, что решения фиксировались в виде карточек на основе родительской карточки с формулировкой проблемы. Это очень помогает, когда никто не может вспомнить - нафига мы приняли такое решение? Открываем родительскую, и сразу всё вспоминается.

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