«Метрики не являются средством сдерживания сумасшедших», — Джеймс Фентон
резюмировать
В предыдущие недели мы рассматривали важность достижения прозрачности в гибкой трансформации. Мы видели, как доска Kanban, даже если она используется без поддержки гибких передовых методов, может немедленно добавить ценность в этом отношении. Затем мы воспользовались улучшенной видимостью для стабилизации вновь сформированных команд и устранения узких мест в их производительности.
Это важный первый шаг к улучшению процесса и ликвидации отходов. На данном этапе, и прежде чем мы пойдем дальше, мы должны убедиться, что мы можем собрать достоверные данные об эффективности внесенных изменений. В гибкой практике сбор таких данных известен как сбор метрик.
Основные показатели команды
Самым фундаментальным измерением, используемым в бедных системах, является измерение времени выполнения заказа . Это средняя продолжительность работы с момента получения запроса командой до тех пор, пока он не будет удовлетворен путем предоставления потребителю необходимой стоимости.
Представьте команду как трубу. Часы начинают тикать, как только команда приняла запрос (то есть он входит в один конец канала); в этот момент он становится предметом инвентаря, над которым они отвечают. Часы останавливаются только тогда, когда доставляется соответствующее значение (т. Е. Когда готовый элемент выходит из другого конца трубы). Время отставания должно быть включено, если команда эффективно владеет им и контролирует добавленную работу. По сути, все это будет учитываться как время, проведенное в канале команды вместе с тестированием, экспертной оценкой и любым временем, потраченным на задержки. С другой стороны, считается, что резервы, которые могут расти вне контроля команды, находятся за пределами канала. Если будет замечено, что предметы проводят в среднем 3 дня в трубе команды, то это будет время выполнения команды.Обратите внимание, что время выполнения запроса клиента будет больше, чем это, если он не попадает прямо в трубу команды или подвергается какой-то дополнительной обработке впоследствии.
Столь же простой показатель — это пропускная способность команды , то есть количество предметов, фактически доставленных за определенный период. Если бы вы подсчитывали в среднем 10 готовых изделий, выходящих из трубы каждый день, то пропускная способность составляла бы 10 в день. Умножьте пропускную способность на время выполнения заказа, и вы сможете определить, сколько элементов в среднем находится в конвейере … то есть «Выполняется работа». Для времени выполнения заказа в 3 дня и пропускной способности 10 изделий в день мы можем предположить, что среднее значение WIP должно составлять 30. Другими словами:
WIP = throughput * lead time
or
throughput = WIP / lead time
Очевидно, что если вы сможете найти способы вдвое сократить время выполнения при сохранении того же предела WIP, можно ожидать удвоения пропускной способности. И наоборот, если бы вы увеличили лимит WIP команды, вы бы обнаружили, что время выполнения заказа также пришлось бы увеличивать для каждого элемента, если бы они поддерживали одинаковую пропускную способность … это означает, что клиент, делающий запрос, должен будет ждать дольше это должно быть выполнено. Это жестокая арифметика, которая делает ограниченное WIP столь желательным. Короче говоря, это позволяет более быстро доставлять стоимость клиентам, чтобы ее можно было эффективно использовать, и сводит к минимуму амортизацию работ, которые были частично разработаны и выполняются.
Однако наиболее распространенный показатель, используемый в гибких проектах, — это скорость . По сути, это то же самое, что и пропускная способность, но вместо подсчета готовых изделий мы будем подсчитывать количество «баллов», которые были оценены для каждого предмета., В отличие от пропускной способности, скорость учитывает тот факт, что не все предметы имеют сопоставимый «размер» … некоторые могут занять заметно больше времени, чем другие, и поэтому должны нести больше очков. Эти различия могут быть очень значительными в проектах, где необходимо выполнять все виды новых работ, некоторые из которых могут быть довольно сложными, а некоторые — сравнительно тривиальными. Расхождения могут быть менее значительными в работе «как обычно», когда изменения в системе сводятся к небольшим и повторяемым изменениям, и в таких случаях «пропускная способность билета» все еще может быть наиболее подходящей мерой.
Чувствуя ожог
Работа, которую команда принимает в свое отставание, становится ее собственной ответственностью в этот момент. Некоторые гибкие методы, особенно Scrum, предписывают две отдельные резервные копии, только одна из которых принадлежит команде разработчиков. Это журнал ожидания Sprint , и он фактически представляет собой пакет работ, который команда прогнозирует для доставки в течение указанного временного интервала или «Sprint». В Scrum, спринт не может превышать месяц, и это помогает держать партию достаточно маленькой. Команда согласится взять подходящее Журнал Спринта из большого количества работ, принадлежащих представителю клиента или Владельцу продукта. Это известно как бэклог продукта .
Так как Журнал ожидания спринта представляет собой пакет, хотя и небольшой, было бы полезно знать во время спринта, находится ли команда в процессе доставки всего этого к концу спринта. Если партия имеет приблизительный размер … возможно, выраженный в виде общего количества баллов, или, возможно, времени, которое могут занять любые связанные задачи …, то ежедневное отслеживание объема работ можно отслеживать. Это показывает объем работы, оставшейся в Журнале Спринта, день за днем, и, таким образом, скорость прогресса может быть определена.
Накопительный поток
Время выполнения заказа, пропускная способность, скорость и выгрузка являются элементарными мерами, потому что они включают все отходы, которые несет команда, использующая процесс, которым она владеет и за который несет ответственность. Они тупые инструменты. Они не показывают, где именно в этом процессе чаще всего возникают блокировки и задержки. Никто не может информировать команду о том, где изменения должны быть реализованы.
Использование задачи или доски канбан может помочь, и мы видели, как добавить диагностические столбцы для этой цели в предыдущей статье . Можно наблюдать за доской на предмет блокировок и получать некую информацию, которую можно рассмотреть в ретроспективе . Правление не даст вам точных цифр, подтверждающих эти заявления.
Очевидно, что если мы добавим диагностические столбцы к плате, мы сможем сами выявить соответствующие метрики. Квалифицированный наблюдатель сможет записать, сколько времени они проводят «В разработке», «В тесте», «Внешне заблокированы» или в любом другом состоянии, в котором мы проявили интерес. Использование электронных плат делает процесс менее обременительным. чем отслеживание вещей вручную, и статистика обычно может быть получена одним нажатием кнопки. Диаграммы накопленного потока часто используются для иллюстрации этих измерений. Они тесно связаны с пространственно-временными диаграммами, используемыми для моделирования транспортных потоков, и эффект от ударных волн от заторов может стать очевидным.
Заключение и примечание о других показателях
Измерения, которые мы рассмотрели в этой короткой статье, были сфокусированы на технической доставке. Время выполнения, пропускная способность, скорость, расход и совокупный поток могут использоваться членами команды для проверки и адаптации своего процесса, а также для подтверждения или опровержения любых подозрений с использованием достоверных данных. Чего они не делают, так это предоставляют индикатор поставленной стоимости. Насколько нам известно, ни одна из работ, выполненных командой и доставленных заказчику, на самом деле не оказалась полезной.
Измерение «стоимости» является сложным вопросом и может быть весьма субъективным. Например, если мы заменили сайт электронной коммерции, как мы узнаем, стоила ли эта инициатива? Мы просто измеряем какие-либо изменения в доходах? Если так, как мы можем доказать, что изменение не было вызвано другими факторами … и в течение какого периода мы должны его измерять? Как насчет доли рынка, или удержания и оттока клиентов, или количества привлеченных новых клиентов? Не являются ли эти цифры потенциально еще более важными? Разве мы не должны измерять изменения в демографии клиентов? А как насчет улучшенных показателей на новом сайте? Мы можем провести это измерение достаточно легко, но как нам его вычислить?
По сути, нам нужно сделать следующее. Нам необходимо уметь отличать бизнес-метрики «тщеславия», которые просто выглядят хорошо, от «действенных» бизнес-метрик, которые могут быть использованы для формирования и проверки гипотезы максимально быстро и эффективно. Короче говоря, нам нужно думать о наших показателях, как будто мы были «Бережливым стартапом», и рассматривать продукт не просто как дойную корову для получения дохода, но как инструмент обучения для изучения новых и более широких возможностей.