Измерения метрик в разработке (перепост)

Взято отсюда : Кому же нужны метрики ?

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

Уважаемые слушатели прошедших тренингов, если вы это читаете, то примите глубокое уважение и благодарность с моей стороны. Без вас я бы не смог совершенствовать материалы, да и эта статья не появилась бы.

Попробую категоризировать  реакции слушателей и собственно проанализировать, почему они именно такие. Причем в определенную категорию попадали как отдельные слушатели из какой-то группы, так и почти целиком вся группа.

    Безразличие, или мне(нам) это не надо, и вообще о чем это.Встречается там, где и так все нормально, т.е. заказчик и руководство довольны (или думают что все хорошо  , и поэтому довольны), существенных проблем нет, или к ним относятся очень снисходительно. Хорошо настроенных рабочих процессов тоже нет, но т.к. компания молодая, или небольшая, то все на виду и все вопросы можно преспокойно решать ручным управлением. Или же все настолько благоденствуют (я без сарказма, такое тоже бывает), что напрягаться по поводу метрик и не надо. И действительно, зачем (опять же без сарказма  )? Но это обычно долго не длиться, рано или поздно возникают вопросы типа: Почему вы так медленно работаете? Почему у вас столько дефектов? Да у вас же на устранение дефектов уходит больше времени, чем на разработку! Почему вы никогда не можете более-менее точно спрогнозировать, когда же вы закончите? И тому подобное. А возразить-то особо нечего, т.к. непонятно как это все объяснить.
    Мягкий отпор, или мы тут работу работаем, нам не до метрик. Это следующая ступень после первой. Итак, посыпались вопросы, проблемы. Их надо решать, а то заказчик платить перестанет. К сожалению, обычно мы боремся с последствиями, а не с причинами, и в таком состоянии зависаем. И боремся экстенсивными методами, такими как внеурочная работа, выкидывание «ненужных» видов работ (тестирование, ревью кода, специфицирование и т.п.). Просто педалим. Тут действительно не до метрик. Но вот здесь уже 100% нужно задумываться если не о метриках как таковых, то о базовых шагах по решению проблем. Рецепт прост как тот факт, что солнце каждый день всходит и заходит (исключая полярные дни и ночи J). И по счастливой случайности он совпадает с основными условиями внедрения метрик. А именно, для наведения порядка нужны 3 вещи:
        Процессы. Они вообще-то должны быть, формализованные в удобном для использования виде. Повторяемые, независимо от того, кто делает.Взаимосвязанные друг с другом, например, на выходе кодирования должен быть чистый работающий код, который расположен в оговоренном месте, снабженный релизной запиской, и обо всем этом должны узнать тестировщики. Соответственно, у тестировщиков должно быть понимание как этот код запустить, по отношению к какой версии требований тестировать и т.п. Видите, сразу идет связка таких инженерных практик и специальностей как бизнес анализ, кодирование, ревью кода, юнит тесты, тестирование, создание тестовой документации, и т.п.
        Инструментарий. Тут все просто, это поддерживающие вашу работу таск-тайм-баг трекеры и прочий автоматизирующий инструментарий. При правильной настройке полей и workflow данные собираются и отображаются без особых усилий.
        Люди. Должны быть достаточно профессиональны, чтобы в правильном порядке и виде использовать инженерные и управленческие практики, подточить их под нужды проекта. А также выбрать и настроить инструментарий, или хотя бы грамотно использовать существующий. При определенной инициативе можно переходить к метрикам, т.е. к следующему уровню.
    Осторожная заинтересованность, или вот ведь как еще можно делать.Тут, и в следующих уровнях работать со слушателями одно удовольствие, т.к. мы настраиваемся на одну волну, и в процессе тренинга приходим к решению конкретных задач слушателей. Пусть и не сразу речь заходит о метриках, но вырисовываются причины проблем. Чаще всего ими бывают или ненастроенные процессы, или инструментарий, или просто не хватает подготовки у людей в области процессов, измерений и улучшений.
    Одобрение и продуктивное обсуждение. Вот тут уже хорошо чувствуется профессиональная зрелость слушателей. Или же явно видно, что есть какие-то проблемы, для решения которых недостаточно просто капать на руководство, заказчика или кого-то еще. А требуются именно цифры и факты, на основании которых могут приниматься качественные управленческие решения. Т.е. тренинг является именно тем катализатором, который побуждает к внедрению измерений и, как следствие количественному управлению. Так, в одном из случаев, элементарный сбор статистики о причинах возникновения дефектов (defect origin), побудил к совершенствованию работы именно проблемного подразделения (наконец-то), и отставил претензии к подразделению-пользователю этих проблем.
    Полная поддержка и обмен опытом по внедрению измерений. В этом случае слушатели или уже внедрили и пользуются метриками или тут же на тренинге обсуждаем, как именно улучшить уже работающую систему измерений. В этом случае идет продуктивный обмен опытом использования метрик. Люди убеждаются на опыте коллег и материала, что идут в правильном направлении. И мне тоже практически всегда есть чему поучиться у слушателей такого уровня.

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

Ах да, зачем же нам вообще нужны метрики? А чтобы принимать качественные управленческие решения и разговаривать с заказчиками и руководством на языке цифр и фактов, а не на языке ощущений своего живота или другой части тела.