«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. Просто посчитайте сколько дистрибутивов (сборок) дошло до пром за оп��еделенное время и получите текущую производительность Вашего конвейера.
В принципе, эту же метрику можно использовать и в областях, связанных с деньгами.
Например, для интернет-магазина можно было бы аналогично посчитать количество заказов за определенное время. Весь вопрос в том, действительно ли магазинам это нужно?
Вывод
Как видите, Одна Единственная Универсальная Метрика всё-таки имеет право на жизнь, по крайней мере в области разработки ПО и в сервисных подразделениях (служба тех поддержки).
Она с проста для расчета, содержит в себе смысл, и может быть использована для сравнения с целевым значением.
Конечно, её нельзя применять бездумно. Перед тем как приступать к реализации подумайте, а действительно она Вам нужна.
А что Вы думаете по поводу универсальной метрики?
Какую метрику Вы используете в качестве универсальной?
