Как измерить time to market
Agile-метрики команд. Часть 2. Хорошие метрики
В прошлой статье мы говорили о том, какие метрики лучше не использовать в командах. Собственно с ней можно ознакомиться тут:
Agile-метрики команд. Часть 1. Сомнительные метрики
Оранжевые организация — большие любители все “мерять”. Лично мое мнение такое: мерять можно что угодно, однако в…
В этой статье мы рассмотрим какие метрики можно использовать со своими Agile командами.
Burn-up Chart
Что это: показывает как вы съедаете скоуп (объем) к дате или же наоборот, к какой даде будет сделан этот объем скоупа.
Что нам это дает? Мы можем прогнозировать. Например, когда будет сделан весь вот этот объем задач?
Или, что будет сделано к Рождеству?
В Agile мире, мы отдаем преимущество прогнозированию “к дате”, ибо объем задач, обычно, растет, потому при планировании “от объема” вы можете попасть в ситуацию, когда “давайте еще доделаем эту задачу, потому что без нее никак”.
End-to-end time to market (Lead time)
Что это: это метрика показывает, сколько времени проходит с момента появления идеи до момента ее фактической реализации и появления на стороне пользователя.
Часто в разработке команды измеряют, как быстро они делаю саму Feature, то есть сколько времени проходит с момента начала работы до продакшина.
Однако, на много интереснее, сколько времени прошло в целом от идеи до реализации. И вот почему:
Вы узнаете, сколько реально времени бизнес в среднем ждет одну фичу
А еще вы узнаете, сколько времени болтаются задачи в беклоге абсолютно без дела. Но это уже другая метрика 🙂
Эффективность потока (Flow Efficiency)
Любая работа это совокупность активный стадий, когда работа выполняется, и стадий ожидания, когда задача ожидает выполнения или следующей стадии.
Например, возьмем упрощенный процесс разработки с точки зрения задачи:
Проработка деталей — Разработка — Тестирование — Выпуск
В такой цепи “задача”, будет находиться в активном состоянии, когда над ней будет проводиться работа, например, программист пишет код. Как только он закончил, с точки зрения задачи, активная фаза закончилась, она перешла в стадию “ожидания тестирования”. Тестировщик приступит к работе тогда, когда освободиться от других задач.
Если вы считаете время, которое тратится на “работу” над задачей, то есть активное время, а так же время, которое задача проводит в ожидании, вы можете посчитать Эффективность потока — соотношение ожидания и активной работы.
Если работали над задачей 1 день (затрекали время), а фактически между активной работой она провела 2 дня (время ожидания), то эффективность такого потока = 1/(1+2) * 100 = 30%
Это значит, что 70% времени работа не ведется, то есть задача “простаивает”.
Количество элементов в беклоге
Что меряет: меряет количество элементов в бэклоге 🙂
Зачем мерять? Что бы понимать, сколько мусора на вашем “складе”. С точки зрения Lean бэклог — это склад. Излишние складские запасы — один из видов потерь.
Как за любым складом, за бэклогом нужно ухаживать, пересматривать, оценивать, чистить и инвентаризировать.
Чем больше ваш бэклог, тем меньше вы понимаете, что в нем храниться, и тем меньше его фактическая актуальность
Более того, чем больше всем элементов, тем больше времени тратиться на уход за ним, а так же, тем меньше прозрачность работы в нем.
Нет цифры, которая бы идентифицировала предел 🙂 это все очень специфично для команды/продукта/компании. Просто помните, что вряд ли стоит хранить задачи, которым несколько лет, что бы “не забыть” 🙂
Срок жизни элемента беклога
Предыдущая метрика тесно связана с этой метрикой — чем старее задачи в беклоге, тем менее смысла они имеют.
Старость беклога обычно гворит о следующих проблемах:
Чем меньше срок жизнь, тем понятнее контент беклога, проще с ним работать и повышается его актуальность.
Эволюция Definition of Done
Как померять работу Scrum Master? Очень просто — на сколько растет Definition of Done его команды. Этим же можно померять “взросление команды”.
Именно увеличение критериев готовности отлично отображает, на сколько растет техническая осознанность команды, на сколько быстро вы можете делать изменения, на сколько быстра обратная связь, на сколько вы близки к клиенту.
Если команда год сидит с критериями “код написан и протестирован”, то за прошлые 12 месяцев вы не стали более Agile в вашей компании. Вы остались на прошлом уровне. Не развились технически, управленчески и продуктово.
Метрики в Scrum и Kanban
По разным причинам Scrum получил очень широкое распространение среди IT компаний. Многие компании и отдельные команды начали внедрять Scrum в своих проектах. У одних это получается, у других не очень. Грамотный и опытный специалист перед внедрением чего-то нового всегда задумывается о метриках. Как убедиться, что внедрение Scrum идет по плану? Улучшается ли производительность команды? Нет ли каких-то проблем? Если вы тоже задавались этими вопросами, добро пожаловать под кат.
И тут в Scrum очень мало ответов. Кроме сугубо бизнес-метрик, которые можно применять практически в любом процессе (ROI, Earned Business Value, Running Tested Features и т.д.), в Scrum предлагается метрика Velocity. Но уже писано переписано, что использовать Velocity в качестве метрики не стоит. Это может привести к неожиданным неприятным последствиям.
Получается, что хороших метрик на первый взгляд нет. В конце статьи я упомяну некоторые неявные метрики в Scrum, но пока давайте поговорим о причине проблем. Самая главная причина – это время. Бизнес практически все измеряет временем (даже деньги – это время). А в Scrum это самое время фиксируется (быстренько все вспоминаем «железный треугольник») и разработка ведется итерациями. Но внутри итерации происходит много всего интересного: мы делаем задачи, пользовательские истории, тестрируем, собираем продукт, устанавливаем и т.д. И вся эта информация теряется на фоне итерации. Происходит так называемое «сглаживание шумов». Если мы затянули с одной активностью, то можем нагнать в другой. Ведь итерация целиком принадлежит команде и команда может «придумывать» внутри итерации что угодно, лишь бы в конце все было готово. Этот подход очень хорош для планирования, но отвратителен для метрик.
Во-первых, мы очень редко можем снимать показатели метрик – в конце итерации. А это в лучшем случае раз в неделю. В основном, все таки раз в две недели. Во-вторых, мы уже упоминали «сглаживание» и оно тоже вносит свои коррективы. Всю итерацию ситуация была из рук вон плохая, а в конце все сделали нечеловеческое усилие и вуаля – все готово и метрики в порядке. Хорошо это или нет? Нет! Мы теряем полезную информацию и не учимся на своих ошибках.
Совсем по-другому дела обстоят в Kanban. Тут внимание уделяется каждой задаче. Метрики снимаются со всего потока задач, который проходит через команду разработки. Вот краткий список метрик:
Этот простой список метрик позволяет полностью понимать и контролировать процесс разработки, постоянно анализируя и улучшая его. В идеале данные метрики считаются в разрезе категорий задач (по размеру, по типу, по срочности), чтобы еще улучшить понимание происходящего и позволить точнее прогнозировать результаты работы команды.
Я обещал упомянуть о неявных метриках в Scrum. Эти метрики можно собирать, используя Burndown Chart. Вы можете анализировать его с целью определения шаблонов работы команды, рассматривая ежедневный прогресс и гладкость графика. Вы можете усилить анализ. Для этого нужно ввести категоризацию задач и строить Burndown Chart по каждой категории. Некоторые команды ведут отслеживание метрик задач внутри итерации, но на мой взгляд это несколько противоречит принципам Scrum – внутри итерации команда может работать над задачами в произвольном порядке.
Подведу итог. В Kanban метрики гораздо сильнее, чем в Scrum, но это не делает Kanban более простым в реализации подходом. Наоборот, Kanban требует от команды гораздо больше ответственности, контроля и анализа с постоянным усовершенствованием. Зато с точки зрения бизнеса Kanban гораздо более прозрачный и контролируемый.
А какие метрики применяете вы? Какие метрики хорошо работали для вас в Scrum?
Time to market: не теряйте время, это слишком дорого
В современном бизнесе есть понятие time to market — это время, которое компания тратит на реализацию и выпуск бизнес-идеи своим клиентам. Чем ниже time to market, то есть чем быстрее фича отправляется в продакшн, тем быстрее зарабатываются деньги для бизнеса. Подробнее — в статье руководителя отдела производства продукта для магазинов Леонида Савченкова.
В Яндекс.Маркете мы внедрили несколько изменений, которые помогли нам сократить время разработки новой фичи с 64 до 46 дней. Их можно применить в любой команде, которая разрабатывает софт.
После того, как разработчик написал код и убедился, что всё работает как ожидается, обычно требуется ещё несколько шагов до выкладки в прод. Сначала нужно провести код-ревью и тестирование. Затем код нужно упаковать, обновить конфиг, подготовить изменения в базе данных. В общем случае это выглядит так:
Теперь давайте посмотрим, как можно ускорить каждый из этапов.
Если код-ревью для вас — обязательный этап, максимально оптимизируйте его. Отдайте линтеру все стилистические требования, чтобы живой человек на них не отвлекался. Договоритесь в команде о правиле, что на код-ревью отводится 24 часа. Внедрите инструмент, который автоматически раздаёт задачи на код-ревью — с учётом справедливости, опыта членов команды и календаря отсутствия.
Вот так у нас получилось ускорить этот этап (на графике изображён 80-й персентиль времени, за которое коммит проходит код-ревью):
Ручная проверка готового релиза QA-инженерами может занимать много времени. Как правило, она проходит в два этапа: тестирование новой функциональности, ради которой и затевался релиз, и регрессионное тестирование, чтобы убедиться, что мы ничего не сломали. Ускорить процесс поможет уменьшение размера релизов и автоматизация тестирования.
Если релизы будут небольшими и простыми в развёртывании (см. следующий пункт про CI и CD), их легко будет тестировать. Стоит целиться в один релиз в день.
Далее избавляйтесь от ручного регрессионного тестирования — пишите интеграционные тесты на весь регрессионный пак. Для бэкенда это достаточно легко. Тесты должны писаться против контрактов API и покрывать все возможные ситуации. Интеграционные тесты при этом прогоняются против настоящего тестового окружения или с использованием моков наиболее сложных сервисов, состояние которых непросто воспроизвести. Тесты пусть пишут сами разработчики. Для фронтенда тесты пишутся против интерфейса и, как правило, ближе к концу реализации фичи. Фронтенд-тесты часто играют роль интеграционных.
После такого подхода к автоматизации профессия тестировщика бэкенда в Яндекс.Маркете исчезла как класс. Существующие QA-инженеры остались для фронтенда.
Вручную они теперь проверяют только новый функционал, а для регрессионного тестирования пишут автотесты.
Вот так мы избавились от ручного регресса для личного кабинета партнёров Маркета в 2019 году:
Time-to-Market как козырь для внедрения DevOps
Представьте себе фантастическую ситуацию — директор компании решает внедрить DevOps. Сам, без давления со стороны технарей. Без убедительного примера конкурентов. Руководство само признало, что повысить качество продукта, предсказуемость, прозрачность и повторимость бизнес-процессов при разработке и внедрении ПО невозможно без средств DevOps.
Представили? Получилось? Вы успешно прошли тест на самое богатое воображение!
На самом деле, конечно же, всё не так. Чаще всего руководству не до наших ИТ-шных штучек. Поэтому приходится убеждать. Но как?
Когда в качестве аргумента приводится повышение культуры общения между программистами и системными администраторами, то легко можно нарваться на контраргумент: а сейчас вы некультурные, что ли? Или даже могут напомнить о затратах, которые уже понесла компания год-два назад, когда вы дружно переходили на Agile. Неужели в ИТ каждый год появляется фича, способная продвинуть процессы революционным способом?
Насчёт повышения качества продукта тоже можно заикнуться. Но осторожно. Поскольку задачу программировать без ошибок ещё никто не отменял. Да, без багов никак, но именно поэтому в компании есть «целый отдел тестировщиков», не так ли?
Предсказуемость процессов — это вообще такой субъективный фактор, обосновать который и избежать шуток про Вангу и Нострадамуса довольно сложно.
При этом, если мы говорим о типичном энтерпрайзе, то в такой компании, скорее всего, есть уже сложившаяся ИТ-команда. И эта команда в старом (если не считать Agile) привычном ритме трудится вместе немало лет и вряд ли горит желанием (опять) что-то менять. Всех всё устраивает, кроме, естественно, руководства. Которое видит, что в их ПО постоянно сыплются какие-то ошибки, смещаются сроки выпуска новых версий.
Конечно, можно предположить ещё один вариант, когда в компанию приходит человек с опытом в DevOps, ясно представляющий, в чём проблема и как её нужно решать. И который способен донести своё мнение до руководства. Однако давайте не будем надеяться на чудо-дядю.
И на этом многие ломаются. Начинают говорить, что никто их не поддерживает, что в этом болотце ничего внедрить невозможно и затем просто уходят в другую компанию, где цикл повторяется.
Получается замкнутый круг? Нет, просто постепенно мы приходим к выводу, что с бизнесом нужно говорить только на понятном ему языке — на языке денег. Для этого мы достаём из широких штанин рукава главный козырь — сокращение Time-to-Market. Нужно показать, что благодаря DevOps новые версии продукта будут выпускаться, как горячие пирожки. А все остальные вышеперечисленные выгоды от внедрения DevOps давайте оставим для итоговой презентации, которую мы создадим для директора, когда все получится. Многие скажут, что это слишком очевидно. Нет!
Нам нужно что-то, что займет у нас минимум времени и ресурсов (ведь никто не разрешит списывать человеко-месяцы на внедрение некоего DevOps и не закупят для нас срочно новых серверов), но при этом даст очень ощутимый результат (реально сократит Time-to-Market).
Для начала нужно найти бутылочное горлышко, а оно всегда одно (первый шаг в теории ограничений Голдратта). После успешного внедрения Agile (а все это имеет смысл только после внедрения Agile), в плане разработки софта всё равно им остается ручное тестирование. Даже при наличии пула свободных рук, регрессионное тестирование может занять две-три недели. А уж от том, как тестировщики «любят» проводить регрессионное тестирование, знаю все.
Итак, мы определили, что бутылочным горлышком является тестирование. Тогда начать нужно с его автоматизации. Многие заметят: легче сказать, чем сделать. Уже написаны миллионы строк кода, и хорошо, если программисты хоть что-то покрыли модульными тестами. На самом деле все не так страшно, как кажется. Как показывает опыт, 80 % успешного результата в виде серьезного снижения Time-to-Market достигается за счёт 20 % усилий. Именно во столько примерно обходится автоматизация тестирования в нашем случае.
Совсем по закону Парето, ага.
И самое главное, запустить автоматизацию тестирования можно ещё до того, как руководство согласится выделить ресурсы на внедрение остальных частей DevOps. Небольшой такой пилотный проект, который можно сделать собственными силами за одну-две недели.
Но при этом такая ситуация нам даёт шанс одержать эффектную и, самое главное, быструю победу. После которой, имея позитивный настрой и благословение руководства, уже можно просить и деньги, и ресурсы.
Начнём с того, что, наверняка, ваши программисты уже используют какое-либо серверное ПО для ежедневной сборки. Это может быть TeamCity, либо Bamboo, либо Jenkins, — не принципиально. Главное, часть автоматизации уже есть и это нужно использовать, а если нет, то за день его легко развернуть.
Сначала надо автоматизировать «дымовые» тесты. А как понять, что автоматизировать? Да просто посмотрите, что у вас регулярно ломалось при выкладке изменений за последние полгода.
Дальше нужно создать несколько тестов проверки работы основных бизнес-процессов. Как их определить? Задать вопрос вашим аналитикам/директорам/представителям бизнеса, при какой поломке в кабинет к программистам вбегает разъяренный директор и ставит задачи повышенным голосом.
Неделя, ну максимум две на создание таких тестов. В результате — очень быстрый фидбек на предмет глобальных ошибок.
И пока проект в режиме proof of concept, не надо заниматься подготовкой того же автоматического развертывания сервера для тестирования и прочими бантиками, а всё сделать вручную. Эту красоту потом можно с удовольствием сделать вместе с админами.
К чему это приведёт, догадаться не сложно. Разработчики сразу будут видеть (и исправлять) свои ошибки. Тестировщики будут избавлены от рутины в виде проведения долгих и нудных тестов на регресс. Им останется пара-тройка дней для того, чтобы протестировать только те места кода, которые были подвержены правке. Да-да, именно так. А если нет, то вернитесь в начало и еще раз поговорите с аналитиками/директорами/представителями бизнеса на тему критичных для бизнеса процессов.
Бутылочное горлышко, из-за которого возникали основные тормоза, ликвидировано. Теперь остаётся только выпустить несколько новых релизов в продуктивную среду, снять статистику «было/стало» и идти с этими цифрами к руководству. Профит!
После такой убедительной победы уже можно разговаривать про автоматизацию развертывания стендов (как минимум для тестирования). Далее выпрашивать средства на мониторинг и прочие прелести DevOps. При этом нужно помнить, что остальные компоненты системы уже не будут иметь вау-эффекта для бизнеса.
Пример в студию
В завершение поста, думаю, уместно будет привести пример успешно завершенного проекта по внедрению DevOps, который реализовала наша компания.
У одного крупного ритейлера около 20 % бизнеса приходится на интернет-магазин. При этом реагировать на рыночную ситуацию и вносить необходимые изменения в ПО нужно очень быстро. И часто. И качественно. Любой косяк на сайте может повлиять на конверсию, риски выражаются в реальных деньгах.
Для сокращения времени обновления и повышения качества была создана специализированная платформа автотестов, на которой были автоматизированы рутинные задачи по тестированию изменений и регресса сайта. Кроме того, был выстроен процесс взаимодействия группы автоматизированного тестирования с командами разработки. Это позволило разработчикам сразу выявлять и исправлять дефекты в обновляемой системе, не дожидаясь финального приемочного тестирования.
Представители ритейлера сочли опыт успешным и решили применить его к остальным софтверным продуктам.
И ещё небольшой пример, но уже из практики одной крупной страховой компании. До внедрения автоматизации тестирования релизы выходили раз в полгода. Не потому, что так требовал бизнес, — просто чаще не получалось. А заказчик как раз хотел. Так вот, через два месяца после начала внедрения средств автотестирования, ИТ-команда перешла на двухнедельные итерации выпуска релизов.
Достаточно показательно, чтобы начать этим заниматься, не так ли?
Сергей Страмнов, пресейл-архитектор Центра программных решений «Инфосистемы Джет»
Agile-метрики команд. Часть 2. Хорошие метрики
Burn-up Chart
Что это: показывает как вы съедаете скоуп (объем) к дате или же, наоборот, к какой дате будет сделан этот объем скоупа.
Картинка с https://spin.atomicobject.com/2016/03/31/burn-up-charts/
Что нам это дает? Мы можем прогнозировать. Например, когда будет сделан весь вот этот объем задач?
Или что будет сделано к Рождеству?
В Agile мире мы отдаем преимущество прогнозированию “к дате”, ибо объем задач, обычно, растет. Поэтому при планировании “от объема” вы можете попасть в ситуацию, когда “давайте еще доделаем эту задачу, потому что без нее никак”.
End-to-end time to market (Lead time)
Что это: эта метрика показывает, сколько времени проходит с момента появления идеи до момента ее фактической реализации и появления на стороне пользователя.
Часто в разработке команды измеряют то, как быстро они делают саму Feature, то есть сколько времени проходит с момента начала работы до продакшина.
Однако намного интереснее то, сколько времени прошло в целом от идеи до реализации. И вот почему:
Вы узнаете, сколько реально времени бизнес в среднем ждет одну фичу
А еще вы узнаете, сколько времени болтаются задачи в беклоге абсолютно без дела. Но это уже другая метрика 🙂
Эффективность потока (Flow Efficiency)
Любая работа – это совокупность активных стадий, когда работа выполняется, и стадий ожидания, когда задача ожидает выполнения или следующей стадии.
Source https://leankanban.com/flow-efficiency-a-great-metric-you-probably-arent-using/
Например, возьмем упрощенный процесс разработки с точки зрения задачи:
Проработка деталей — Разработка — Тестирование — Выпуск
В такой цепи “задача” будет находиться в активном состоянии тогда, когда над ней будет проводиться работа. Например, когда программист пишет код. Как только он закончил, то с точки зрения задачи активная фаза закончилась, то есть перешла в стадию “ожидание тестирования”. Тестировщик приступит к работе тогда, когда освободится от других задач.
Если вы считаете время, которое тратится на “работу” над задачей, то: есть активное время, а так же время, которое задача проводит в ожидании. И вы можете посчитать Эффективность потока — соотношение ожидания и активной работы.
Если работали над задачей 1 день (затрекали время), а фактически между активной работой она провела 2 дня (время ожидания), то эффективность такого потока = 1/(1+2) * 100 = 30%
Это значит, что 70% времени работа не ведется, то есть задача “простаивает”.
Количество элементов в беклоге
Что меряет: меряет количество элементов в бэклоге 🙂
Зачем мерять? Чтобы понимать, сколько мусора на вашем “складе”. С точки зрения Lean бэклог — это склад. Излишние складские запасы — один из видов потерь.
Как за любым складом за бэклогом нужно ухаживать, пересматривать, оценивать, чистить и инвентаризировать.
Чем больше ваш бэклог – тем меньше вы понимаете, что в нем хранится и тем меньше его фактическая актуальность
Более того, чем больше всех элементов, тем больше времени тратится на уход за ним, а также меньше прозрачность работы в нем.
Нет цифры, которая бы идентифицировала предел 🙂 Это все очень специфично для команды/продукта/компании. Просто помните, что вряд ли стоит хранить задачи, которым несколько лет, что бы “не забыть” 🙂
Срок жизни элемента беклога
Предыдущая метрика тесно связана с этой метрикой : чем старее задачи в беклоге, тем меньше смысла они имеют.
Старость беклога обычно гворит о следующих проблемах:
Чем меньше срок жизни – тем понятнее контент беклога, проще с ним работать и повышается его актуальность.
Эволюция Definition of Done
Именно увеличение критериев готовности отлично отображает, насколько растет техническая осознанность команды, насколько быстро вы можете делать изменения, насколько быстра обратная связь и насколько вы близки к клиенту.
Если команда год сидит с критериями “код написан и протестирован”, то за прошлые 12 месяцев вы не стали больше Agile в вашей компании. Вы остались на прошлом уровне. Не развились технически, управленчески и продуктово.