Comments 7
Классное саммари по методам, спасибо!
Но всегда встает проблема замера этих метрик, особенно DevEx.
Как мерить Flow state чтобы говорить уверенно о его эффективность - вопрос. Кол-во часов разраба без коммуникаций?)
Я бы сказал, что проблема несколько глубже: а каким образом удовлетворённость или состояние потока относятся к инженерным метрикам? В статье немного смешались метрики, подходы и сферические кони в вакууме. Читатель может потеряться.
Строго говоря, состояние потока - это вообще не метрика. Это "перспектива", с которой нужно смотреть на компанию и её процессы. Одна из осей координат, если угодно. Потому что DevEx сам по себе не методология (когда тебе дают чёткие инструменты), а фреймворк (когда акцент делается на практиках и образе мысли). В статье, кстати, DevEx как раз фреймворком и именуется.
Как это работает? Сначала вы выравниваетесь по тому, что для вашей компании или команды является состоянием потока и каким вы его хотите видеть. Потом выделяете факторы, которые влияют на него в лучшую и в худшую сторону. Затем уже эти факторы некоторым образор оцениваете. И это не обязательно числовые значения, это может быть и "хорошо"-"нормально"-"плохо" и т.п.
Далее, оценив своё текущее положение, вы стараетесь внедрить улучшения в тех областях, которые тянут состояние потока вниз.
Такие дела.
Цель инженерных метрик
Цели использования инженерных метрик могут быть разнообразными.
Directed by Robert B. Weide
Scrum, вероятно, самый известный Agile-фреймворк, включил Velocity как метрику для измерения объема работы
Вот тут ещё попрошу пруфы. В каком из изданий Scrum Guide упоминается Velocity как часть фреймворка? В скрам входит только то, что написано в гайде. Всё остальное, даже то, что создатели могу рассказывать на публичных выступлениях или писать в блогах, не является частями скрама.
Инженерные метрики: что мерить, как и зачем?