Записи с метками процесс

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

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

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

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

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

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

Оригинал статьи здесь.

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!