Agile метрики. Часть 3: Метрики Lean и Kanban

Продолжаем изучать agile метрики. В этом разделе мы рассмотрим показатели, относящиеся к системам работы Lean и Kanban.

Время выполнения истории (Story Lead Time)

Время выполнения – это концепция, которая часто используется в методологиях Lean и Kanban. Это общее время, прошедшее с момента когда пользовательская история вносится в систему (например записывается в бэклог или создается в инструменте управления проектами) до момента ее завершения, то есть переходит в статус “сделано”. Сюда относится и время проведенное в бэклоге. Таким образом время выполнения истории сообщает вам, сколько времени требуется чтобы запрос или улучшение полностью прошло через систему. Возможно вы захотите изменить критерии того, когда история “Готова”, чтобы обозначить, что она действительно выпущена для клиентов, а не готова к выпуску. При расчете скорости вы используете свое обычное определение “готово” (что соответствует вашему определению “Готовности к поставке”, а не фактической передачи клиенту), потому что вы пытаетесь выяснить как быстро ваша команда может закрыть полностью одну историю и перейти к следующей. Время выполнения – это измерение общего времени, которое необходимо для выполнения с момента первого создания и до момента реализации (когда оно начинает приносить прибыль). Время выполнения полезно для определения общей скорости вашей цепочки создания стоимости. Вы должны попытаться сократить время выполнения истории (во многих отношениях это гораздо более важный показатель чем скорость

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

Время цикла истории (Story Cycle Time)

Время цикла истории похоже на время выполнения, но с важным отличием. Это время которое требуется для того, чтобы история перестала быть “в разработке” (у вас наверняка есть этот или аналогичный статус в вашем инструменте отслеживания проекта) и перешла в статус “Готово”. Следовательно – это подмножество времени выполнения истории и поэтому оно всегда меньше его. Время выполнения минут время цикла – это время ожидания: время, которое история или требование проводит в очереди в ожидании выполнения действий. Как и в случае с временем выполнения истории, вы должны стараться сократить его. В идеале, ваше среднее время цикла должно составлять половину или меньше от времени спринта. Если ваше среднее время цикла больше, чем время одного спринта, у вас большая проблема, потому что вы не заканчиваете истории за один спринт. Как и в случае со временем выполнения, убедитесь, что вы используете общее время, прошедшее с момента, когда пользовательская история переходит в разработку, даже если она блокируется, застревает или долго не дорабатывается. Если история колеблется между состояниями (например между “В разработке” и “В тестировании”), не забудьте включить и это время. Часы никогда не перезапускаются; они начинают идти, когда история впервые переходит в разработку и перестает, когда она выполнена. Без исключений.

Время выполнения функции (Feature Lead Time)

Время выполнения функционала похоже на время выполнения истории, но только для функции, а не для истории. Поскольку пользовательские истории часто объединяются и выпускаются как функция, на самом деле это очень полезный показатель. Он описывает, сколько времени требуется от ценной работы, чтобы перейти от идеи в реализацию для клиентов. Как и в случае с пользовательскими историями, часы начинают отсчитывать время для функции с момент как только она попадает в бэклог. Если вы хотите измерить показатель “идеи в деньги” (concept to cash), т.е. сколько времени нужно, чтобы произошел релиз для пользователей, то часы перестают идти, когда функция передана пользователю. Если вы хотите измерить время необходимое для готовности функции к поставке, то часы останавливаются когда она будет готова к выпуску (при этом функция может быть фактически развернутой, но неактивной или отключенной).

Время цикла функции (Feature Cycle Time)

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

Пропускная способность истории (Story Throughput)

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

Как использовать пропускную способность

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

Время такта

Время такта – необычный показатель, который больше подходит для Бережливого Производства (Lean Manufacturing), чем для Бережливой Разработки Программного Обеспечения (Lean Software Development). Но некоторые люди обсуждают его применение, так как это важная часть методологии Lean, поэтому стоит объяснить что это такое. Время такта – среднее время между заказами клиента. Таким образом, если вы получаете 48 заказов клиентов в день, то ваше время такта составляет 30 минут (в сутках 24 часа, значит мы получаем 2 заказа в час). Время такта – мера потребительского спроса, поэтому является основной метрикой используемой для управления производительностью в системах бережливого производства (так как система основывается на вытягивании, а не на выталкивании). Заказы клиентов на самом деле не являются “выводом” в контексте программного обеспечения, поскольку программное обеспечение можно скопировать практически с нулевой стоимостью (или осуществить доставку в качестве Интернет-сервиса в качестве услуги за почти нулевую стоимостью), поэтому данная метрика не так полезна в контексте программного обеспечения.

Соотношение Созданного к Готовому

Эта метрика интересна тем, что показывает соотношение созданных историй к готовым. В каждом спринте берется количество историй, которые были созданы (вне зависимости от того, где или в каком состоянии вы их разместили) и делится на количество историй, которые были завершены (согласно вашему определению готовности). На ранних стадиях разработки продукта это число, скорее всего, будет больше единицы. Это связано с тем, что люди придумывают новые идеи и пишут истории, а разработчики медленно продвигают истории, выстраивая архитектуру, согласовывая проектирование моделей и т.д. (хотя безусловно в процессе этого они должны выпускать в какой-то мере работоспособный софт в течении каждого спринта). Однако со временем этот показатель должен начать снижение. Если вы действительно хотите поработать над бэклогом, то этот показатель очевидно, должен быть меньше единицы. Здесь будет уместно вспомнить хороший девиз: “Прекрати начинать, начни заканчивать”.

Как использовать данную метрику

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

Продолжение

В следующей части мы познакомимся с метриками из инструментов контроля версий.