Во многих наученых горьким опытом командах разработки ПО принята практика "постмортемов" (postmortem) - анализ удач и провалов по завершении проекта или очередного этапа проекта. Существуют разные подходы к такому анализу. Где-то опрашивают всех участников процесса разработки, где-то только ключевых людей. Где-то больше склонны обсуждать успехи, а где-то провалы. Где-то спрашивают личное мнение, где-то основываются прежде всего на статистике.
В том числе - где-то анализируют статистику багов за рассматриваемый период, а где-то не придают ей большого значения. Полагаю, многие не принимают во внимание данные багтрекера оттого, что не очень представляют, что и как можно оттуда извлечь. А извлечь можно разное.
Нередко первое, что приходит в голову - посмотреть различные распределения багов по людям и выявить таким образом чемпионов и античемпионов. Кто из тестировщиков обнаружил больше всех багов? Кто из программистов пофиксил больше всех? У кого меньше всех доля инвалидов в списке найденых и описаных дефектов? На ком "висит" больше всего "блокеров"? Подобных линеек можно придумать немало, и чаще всего подобная статистика бесполезна - как всякое сравнение теплого с мягким.
В самом деле, в проекте обычно участвует довольно много людей; все они обладают разным опытом, все они выполняют разные задачи, а список багов - только один из параметров, отражающих состояние этих задач. Для какой-то задачи 10 найденых багов - вполне ожидаемое среднее, для другой - уже слишком много. А для третьей, возможно, 10 багов - отличный результат, готовились к куда худшему.
Количество багов найденых тестировщиком также зависит не только от его личных навыков, но в первую голову от качества отданных в тестирование фич. У одного глаза разбегаются от количества багов, а другому досталась неплохо проработаная фича, и багов там намного меньше - но это ничего не говорит о самих багах.
Кроме того количество найденных дефектов, вообще говоря, ничего не говорит о том, сколько дефектов осталось необнаруженными. Кто знает, может описав сорок дефектов тестировщик не заметил одного самого критичного. И программист в угаре починки дефектов об этом одном незамеченном тоже не подумал. В итоге этот один оставшийся дефект может перечеркнуть усилия, потраченные на все остальные.
Так что не надо сравнивать людей друг с другом прикладывая их к столбикам из багов. С большой осторожностью можно сравнивать, как изменились результаты одного и того же работника по сравнению с предыдущим периодом. Впрочем, лучше не надо и этого.
Но ведь бывает так, что какой-то один программист действительно небрежен, и его код просто кишит дефектами. Или - тестировщик настолько невнимательно работает, что его описания дефектов зачастую бесполезны. Как отловить такие проблемы, если не анализировать распределение багов по людям? На самом деле - просто. Если человек действительно так уж выделяется на общем фоне, то скорее всего вы и так уже об этом знаете, без всякого анализа. А если не знаете - то весьма вероятно, что кто-то из участников постмортема (а чаще - сразу несколько) укажет на эту проблему.
Ок, людей не анализируем. Что же тогда можно извлечь?
Полезную статистику условно можно разделить на статическую и динамичекую. Статическая статистика - это почти те же линейки, что мы пытались прикладывать к людям, но обезличеные. На каких компонентах продукта у нас багов заметно больше, чем на других? Каков процент "инвалидов" в общем числе описаных дефектов? Да просто - что выделяется на общем фоне?
Конечно, в небольших командах подобная обезличеность может оказаться весьма условной: если компонент разрабатывал один человек, если в проекте один тестировщик, то, казалось бы, не все ли равно - имя человека или название команды фигурирует в статистике. На мой взгляд, не все равно. Имя человека провоцирует обвинять и атаковать этого человека, в то время как на самом деле проблема может быть не только и не столько в этом человеке.
Подробнее о том, какую информацию можно извлечь из собранной статической информации, какие вопросы стоит задать глядя на нее, я уже немного писал ранее. Вероятно, и даже наверняка, ту статью можно дополнять и развивать, но в качестве отправной точки, я надеюсь, она будет полезна.
Наконец, динамическая статистика. Что это за зверь такой? Это зверь очень простой. Речь о том, что баги не появляются одномоментно, и не распределены равномерно по проекту. И идея как раз в том, чтобы отслеживать изменения статистики багов во времени. Почему в середине третьей недели у нас такой пик новых багов? Почему на починку блокирующего дефекта уходит в среднем пять дней? Почему количество непроверифицированных дефектов растет весь проект, а уменьшаться начинает только за три дня до назначенной даты релиза? Почему в последнюю неделю процент "реопенов" увеличился в три раза? Как так вышло, что половина критических дефектов была найдена на предпоследней итерации проекта?
Именно динамическая статистика позволяет обнаружить неочевидные проблемы проекта. Нередко это проблемы организации процесса, или проблемы взаимодействия, или планирования, словом - не чисто технические проблемы, которые бывает трудно заметить техническим людям.
Напоследок хочу лишний раз повторить, что вся эта статистика - не более чем набор чисел, и только от людей зависит, как эти числа будут интерпретированы, и к чему приведет анализ такой статистики. Если вы видите что-то аномальное, то это не более чем показатель наличия проблемы - где-то, возможно совсем не там, где можно сперва подумать. В конце концов, может мы просто данные неправильно собрали.
Аномалии в статистике - это повод задать вопрос: "Почему так?" И постараться на него правильно ответить.
Комментариев нет:
Отправить комментарий