«One Ring To Rule Them All»
J.R.R.Tolkien
«Управлять можно только тем, что можно измерить»
П.Друкер
Когда речь заходит о метриках, то на ум приходят десятки, а то и сотни различных вариантов.
Каких только измерений не придумали!
Но вот беда, когда смотришь на эти красивые картинки, часто бывает совершенно непонятно, что они обозначают.
Да и вообще совершенно неясно, правильно ли были выбраны эти метрики или стоило бы смотреть на совершенно другие?
Хочется какой-то одной метрики, такой, чтобы посмотрел, и всё сразу стало понятно.
Но существует ли она? Или волшебства нет?
Давайте разберемся и посмотрим на конкретном примере...
Часто, всё, что мы имеем – только некий набор входных данных с которым не очень непонятно, что делать.
Представьте, что в вашей компании используется таск-трекер Jira и все разработчики обязаны отмечать в нём события взятия задач в работу и их решения.
Можно получить выгрузку по задачам Jira, но что с ней делать дальше?
Хорошая идея в этой ситуации – подумать, чем именно Вы хотите управлять и какого результата хотите добиться.
Почитайте, например, статью «Прозрение по метрикам: как я понял, что такое метрики и в чём их главная прелесть»
А если добавить сюда еще и книги «Lean Analytics», «Running Lean» и Дао Toyota, то становится понятным, что в случае Jira правильнее всего управлять и измерять время поставки разработанного функционала в пром.
Итак, цель выбрана – мы хотим измерять время поставки ПО, но сделать это можно сотней разных способов. Например, можно измерить длину каждого из шагов разработки, а еще добавить к этому измерения потери времени на ожидания, исправления дефектов, переоткрытия и т.п. Даже на вскидку можно назвать около 50-70 различных метрик, относящихся в разработке ПО.
Как же быть? Существует ли та самая Одна Единственная Метрика, по которой одним взглядом можно всё понять?
Если Вы видели своими глазами те десятки метрик, которых идёт речь выше, то я заранее знаю Ваш ответ – Вы скажет: Нет! А так хочется…
Хочется такой метрики, по одному взгляду на которую можно было бы понять насколько успешно движется разработка и надо ли делать с ней что-то дополнительное.
Удивительно, но похоже, есть одна достойная метрика, которая может смело претендовать на звание Одной Единственной и Неповторимой.
Давайте взглянем на неё поближе.
Есть в Jira такой отчёт как «Диаграмма суммарного потока»…
«Стоп-стоп-стоп… Его же все знают, — скажите Вы, ничего нового я тут не найду»
В общем да, отчёт всем известный, но всё же давайте взглянем на него чуть более подробно. Уверяю, Вас ждёт несколько «приятных» сюрпризов.
Вот как обычно он выглядит:
Какие-то полосы. К чему они? Зачем? Что обозначают? А вот что…
Тёмно-красная полоса – количество реализованных задач нарастающим итогом. Синяя – количество задач в работе, а желтая – новые задачи, зарегистрированные в бэклоге.
Нарастающий итог это когда сделанные задачи всё время прибавляются количеству сделанных ранее.
Например, представьте, что позавчера Вы сделали 2 задачи. На графике в позавчерашней точке будет отмечено: 2.
Вчера Вы сделали еще 3 задачи. Следующая точка на графике будет равна 2(позавчерашние)+3(вчерашние)=5.
А сегодня Вы сделали еще одну задачу. Сегодняшняя точка на графике будет равна 2(позавчерашние)+3(вчерашние)+1(сегодняшние)=6
Т.е. график будет всё время увеличиваться.
И вот, если расположить на графике количество сделанных задач, количество задач в работе и новых задач, то можно извлечь ту самую нашу Одну Единственную и Неповторимую Метрику.
Рассмотрим реальный пример (выгрузка из Kibana и Elasticsearch):
Видите?
По сути, мы можем посчитать скорость (или производительность) разработки. 200 новых задач сделаны за 17 дней. Отсюда получаем, что текущая скорость скорость разработки – 11,76 задач/сутки, т.е. на одна задача выполняется 0,085 дня.
Судят по графику, количество задач в работе, голубая область, не изменяется (ширина полосы почти везде одинаковая), т.е. можно принять, что скорость разработки постоянна, в отличие от количество новых задач.
При текущей скорости разработки 800 новых задач, созданных 17.06.2018, будут выполнены только через 68,03 суток.
Нормально? По-моему, не очень.
Говоряще? Однозначно!
Вот еще один реальный пример (отчёт Jira). Это график исполнения тикетов службой технической поддержки:
Точно также вычисляем производительность службы поддержки – 2,7 задач/сутки.
Недостаточно знать текущую скорость. Нужно понимать еще и целевое значение, т.е. видеть, к чему стремиться.
Понимая скорость работы одного человека можно рассчитать, сколько человек потребуется службе поддержки, чтобы реализовать целевое количество задач или увеличить текущую производительность.
В службе поддержки работает 15 человек. Получается, что на человека приходится 0,18 задач/сутки.
Допустим, Вы захотели увеличить скорость исполнения и сделать так, чтобы служба смогла отрабатывать не 2,7 задач в сутки, а 10 (целевое значение).
Один человек делает 0,18 задач в сутки, значит 10 задач сделают 56 человек.
Ну, или как вариант, можно увеличить скорость работы одного человека.
При скорости работы 1 задача в сутки, на 10 задач Вам понадобиться уже не 56 человек, а всего 10.
Получается, что метрика позволяет Вам, по сути, повлиять на время поставки.
Сравнивая текущую производительность с целевым значением можно понять во сколько раз требуется ускорить процесс.
Варьируя параметры, составляющие производительность (количество людей и скорость их работы), можно управлять итоговым временем поставки.
На самом деле аналоги метрики можно увидеть во многих областях.
Возьмём, например, DevOps. DevOps используется для сокращения промежутка времени между созданием дистрибутива и его развёртывания на пром, т.е. здесь, также как и в примерах выше, нужно управлять временем поставки.
Очевидно, что метрика идеально подходит и для DevOps. Просто посчитайте сколько дистрибутивов (сборок) дошло до пром за определенное время и получите текущую производительность Вашего конвейера.
В принципе, эту же метрику можно использовать и в областях, связанных с деньгами.
Например, для интернет-магазина можно было бы аналогично посчитать количество заказов за определенное время. Весь вопрос в том, действительно ли магазинам это нужно?
Как видите, Одна Единственная Универсальная Метрика всё-таки имеет право на жизнь, по крайней мере в области разработки ПО и в сервисных подразделениях (служба тех поддержки).
Она с проста для расчета, содержит в себе смысл, и может быть использована для сравнения с целевым значением.
Конечно, её нельзя применять бездумно. Перед тем как приступать к реализации подумайте, а действительно она Вам нужна.
А что Вы думаете по поводу универсальной метрики?
Какую метрику Вы используете в качестве универсальной?
J.R.R.Tolkien
«Управлять можно только тем, что можно измерить»
П.Друкер
Когда речь заходит о метриках, то на ум приходят десятки, а то и сотни различных вариантов.
Каких только измерений не придумали!
Но вот беда, когда смотришь на эти красивые картинки, часто бывает совершенно непонятно, что они обозначают.
Да и вообще совершенно неясно, правильно ли были выбраны эти метрики или стоило бы смотреть на совершенно другие?
Хочется какой-то одной метрики, такой, чтобы посмотрел, и всё сразу стало понятно.
Но существует ли она? Или волшебства нет?
Давайте разберемся и посмотрим на конкретном примере...
Часто, всё, что мы имеем – только некий набор входных данных с которым не очень непонятно, что делать.
Jira и её задачи
Представьте, что в вашей компании используется таск-трекер Jira и все разработчики обязаны отмечать в нём события взятия задач в работу и их решения.
Можно получить выгрузку по задачам Jira, но что с ней делать дальше?
Хорошая идея в этой ситуации – подумать, чем именно Вы хотите управлять и какого результата хотите добиться.
Почитайте, например, статью «Прозрение по метрикам: как я понял, что такое метрики и в чём их главная прелесть»
А если добавить сюда еще и книги «Lean Analytics», «Running Lean» и Дао Toyota, то становится понятным, что в случае Jira правильнее всего управлять и измерять время поставки разработанного функционала в пром.
Итак, цель выбрана – мы хотим измерять время поставки ПО, но сделать это можно сотней разных способов. Например, можно измерить длину каждого из шагов разработки, а еще добавить к этому измерения потери времени на ожидания, исправления дефектов, переоткрытия и т.п. Даже на вскидку можно назвать около 50-70 различных метрик, относящихся в разработке ПО.
Как же быть? Существует ли та самая Одна Единственная Метрика, по которой одним взглядом можно всё понять?
Если Вы видели своими глазами те десятки метрик, которых идёт речь выше, то я заранее знаю Ваш ответ – Вы скажет: Нет! А так хочется…
Хочется такой метрики, по одному взгляду на которую можно было бы понять насколько успешно движется разработка и надо ли делать с ней что-то дополнительное.
Удивительно, но похоже, есть одна достойная метрика, которая может смело претендовать на звание Одной Единственной и Неповторимой.
Давайте взглянем на неё поближе.
Есть в Jira такой отчёт как «Диаграмма суммарного потока»…
«Стоп-стоп-стоп… Его же все знают, — скажите Вы, ничего нового я тут не найду»
В общем да, отчёт всем известный, но всё же давайте взглянем на него чуть более подробно. Уверяю, Вас ждёт несколько «приятных» сюрпризов.
Вот как обычно он выглядит:
Какие-то полосы. К чему они? Зачем? Что обозначают? А вот что…
Тёмно-красная полоса – количество реализованных задач нарастающим итогом. Синяя – количество задач в работе, а желтая – новые задачи, зарегистрированные в бэклоге.
Нарастающий итог это когда сделанные задачи всё время прибавляются количеству сделанных ранее.
Например, представьте, что позавчера Вы сделали 2 задачи. На графике в позавчерашней точке будет отмечено: 2.
Вчера Вы сделали еще 3 задачи. Следующая точка на графике будет равна 2(позавчерашние)+3(вчерашние)=5.
А сегодня Вы сделали еще одну задачу. Сегодняшняя точка на графике будет равна 2(позавчерашние)+3(вчерашние)+1(сегодняшние)=6
Т.е. график будет всё время увеличиваться.
И вот, если расположить на графике количество сделанных задач, количество задач в работе и новых задач, то можно извлечь ту самую нашу Одну Единственную и Неповторимую Метрику.
Рассмотрим реальный пример (выгрузка из Kibana и Elasticsearch):
Видите?
По сути, мы можем посчитать скорость (или производительность) разработки. 200 новых задач сделаны за 17 дней. Отсюда получаем, что текущая скорость скорость разработки – 11,76 задач/сутки, т.е. на одна задача выполняется 0,085 дня.
Судят по графику, количество задач в работе, голубая область, не изменяется (ширина полосы почти везде одинаковая), т.е. можно принять, что скорость разработки постоянна, в отличие от количество новых задач.
При текущей скорости разработки 800 новых задач, созданных 17.06.2018, будут выполнены только через 68,03 суток.
Нормально? По-моему, не очень.
Говоряще? Однозначно!
Вот еще один реальный пример (отчёт Jira). Это график исполнения тикетов службой технической поддержки:
Точно также вычисляем производительность службы поддержки – 2,7 задач/сутки.
Есть к чему стремиться
Недостаточно знать текущую скорость. Нужно понимать еще и целевое значение, т.е. видеть, к чему стремиться.
Понимая скорость работы одного человека можно рассчитать, сколько человек потребуется службе поддержки, чтобы реализовать целевое количество задач или увеличить текущую производительность.
В службе поддержки работает 15 человек. Получается, что на человека приходится 0,18 задач/сутки.
Допустим, Вы захотели увеличить скорость исполнения и сделать так, чтобы служба смогла отрабатывать не 2,7 задач в сутки, а 10 (целевое значение).
Один человек делает 0,18 задач в сутки, значит 10 задач сделают 56 человек.
Ну, или как вариант, можно увеличить скорость работы одного человека.
При скорости работы 1 задача в сутки, на 10 задач Вам понадобиться уже не 56 человек, а всего 10.
Управляем временем поставки
Получается, что метрика позволяет Вам, по сути, повлиять на время поставки.
Сравнивая текущую производительность с целевым значением можно понять во сколько раз требуется ускорить процесс.
Варьируя параметры, составляющие производительность (количество людей и скорость их работы), можно управлять итоговым временем поставки.
А где еще это применимо?
На самом деле аналоги метрики можно увидеть во многих областях.
Возьмём, например, DevOps. DevOps используется для сокращения промежутка времени между созданием дистрибутива и его развёртывания на пром, т.е. здесь, также как и в примерах выше, нужно управлять временем поставки.
Очевидно, что метрика идеально подходит и для DevOps. Просто посчитайте сколько дистрибутивов (сборок) дошло до пром за определенное время и получите текущую производительность Вашего конвейера.
В принципе, эту же метрику можно использовать и в областях, связанных с деньгами.
Например, для интернет-магазина можно было бы аналогично посчитать количество заказов за определенное время. Весь вопрос в том, действительно ли магазинам это нужно?
Вывод
Как видите, Одна Единственная Универсальная Метрика всё-таки имеет право на жизнь, по крайней мере в области разработки ПО и в сервисных подразделениях (служба тех поддержки).
Она с проста для расчета, содержит в себе смысл, и может быть использована для сравнения с целевым значением.
Конечно, её нельзя применять бездумно. Перед тем как приступать к реализации подумайте, а действительно она Вам нужна.
А что Вы думаете по поводу универсальной метрики?
Какую метрику Вы используете в качестве универсальной?
