В октябре я уже рассказывала о способах оценки тестирования, все страждущие и сочувствующие могут посмотреть запись здесь. А сегодня мне захотелось затронуть тему метрик проекта в целом, причём метрик не «длягалочных», а метрик «пользуприносящих» и «проектыулучшающих». Именно поэтому, вместо сухих формул и перечня метрик, я расскажу 3 истории из опыта о внедрении и использовании строго определённых метрик в строго определённых условиях — и о результатах, которые с их помощью удалось достичь.
Зачем что-либо измерять?
Есть проект. Ваш любимый, родной, которому вы желаете расти и процветать.
Но как вы оцените его процветание, если нет критериев этого самого процветания?
Как вы сможете оперативно среагировать на проблемы до того, как они стали неисправимыми, если не будете использовать «датчик грядущей Ж»?
Как вы поймёте, что именно следует улучшать, если вам неизвестен источник проблем?
Если вкратце, то метрики нужны, чтобы эффективно управлять проектом: диагностировать проблемы, локализовывать их, исправлять и проверять, правда ли выбранные вами способы решения проблемы помогают.
Я поделюсь разными типами метрик, каждые из которых проверены и принесли немалую пользу. Каждый раз, внедряя их, любой команде очень лень и некомфортно: приходится сохранять дополнительную информацию, что-то там мерять, разводить бюрократию. Но когда мы впервые получаем от какой-либо метрики пользу, на смену лени приходят дисциплина и глубокое понимание важности той или иной метрики.
А если не приходят, значит метрику можно смело выбросить 😉
История 1: Кто впустил его сюда??
В одной замечательной компании руководство жаловалось на «некачественный продукт», виной чему — тестирование. Моей задачей было проанализировать причины этого досадного недоразумения и каким-либо образом их решить, причём естественно вчера.
Задача #1 для меня стала очевидной: оценка % пропущенных ошибок: а правда ли, что тестировщики что-то пропускают? Для этого мы ввели в баг-трекере поле «сообщил клиент», пометили таким образом старые баги и посчитали. Процент составил чуть больше 5%, причём далеко не все из них были критическими.
Много это или мало? По моему опыту это достаточно хороший процент. Откуда тогда мнение, что тестировщики много пропускают?
Мы ввели ещё одно поле: «воспроизводится на релизной версии». Каждый раз, регистрируя новую ошибку с тестового стенда, тестировщики проверяли, есть ли она в последней пользовательской версии: возможно, пользователи просто не сообщают конкретные ошибки? Результат за первый месяц — около 40% ошибок, зарегистрированных в баг-трекер, воспроизводятся в релизной версии.
Получается, пропускаем мы действительно много, но пользователи не сообщают о конкретных ошибках, а вот мнение «ваш софт — отстой!» у них явно формируется. Таким образом мы сформировали метрики-датчики: что не так:
- % пропущенных в релизную версию ошибок
- % ошибок, сообщённых пользователем
Ставим цель (а иначе зачем что-то вообще мерять?)! Хотим не больше 10% ошибок, попавших в релизную версию. Но как это обеспечить? Непомерно расширять ресурсы? Увеличивать сроки?
Для ответа на этот вопрос нам нужно копать дальше, и искать новые метрики, которые дадут ответ на этот вопрос.
В данном случае, мы для всех пропущенных ошибок добавили ещё одно поле: «Причина пропуска». И на выбор указываем, почему не завели эту багу раньше:
- неизвестное требование (не знали или не поняли, что это было нужно)
- не учли тест (не додумались тестировать это ТАК)
- не протестировали (тест был, его проверили, но потом функционал сломался, а повторно эту область не проверяли)
По этому алгоритму я уже во многих компаниях исследовала причины пропусков, и результаты всегда разные. В рассматриваемом мной случае более 60% ошибок оказались пропущенными потому, что тестировщики не учли какой-либо тест, то есть даже не подумали, что это нужно тестировать. Конечно, нам нужно работать по всем фронтам, но начали мы с 60%, опираясь на закон Парето.
Брейншторминг «как решить эту загадку» привёл к различным решениям: еженедельное обсуждение пропущенных дефектов в группе тестирования, согласование тестов с аналитиками и разработчиками, прямое общение с пользователями для исследования их окружений и условий и т.д. Внедряя потихоньку эти новые процедуры, мы снизили всего за 2 месяца % пропущенных ошибок до 20%. НЕ расширяя команду, НЕ увеличивая сроки.
До 10% мы пока что не дошли, но в июле было 14% — мы уже совсем близки к цели, и судя по уверениям внедренцев, клиенты уже заметили изменения в качестве. Неплохо, да?
История 2: Откуда дровишки?
Эта история касается одного из моих собственных проектов. Мы разрабатываем некий ужасно нужный и полезный сервис, и сроки разработки не очень-то грели мою душу. Естественно, у меня на проекте всё ну очень хорошо с тестированием, но почему разработка еле плетётся?
Естественно, я начала с попыток измерить свои субъективные ощущения «медленно». Как это понять? С чем сравнить? KLOC в месяц? Фич в итерацию? Средние срывы сроков относительно плана? Естественно, первые 2 метрики ничего полезного не принесут, поэтому я стала смотреть % срывов сроков по фичам (итерации у нас не имеют фиксированного набора фич, поэтому серьёзно припоздниться не могут — что за 2 недели успели сделать и протестировать, то и выкладываем). Но фичи!
Оказалось, что по ним мы срываем сроки в среднем в 1,5-2 раза! Я не буду рассказывать, чего мне стоило добыть эту информацию из редмайна, но вот, она есть. И я хочу копать дальше, используя принцип «пяти «почему»». Почему так? Мы плохо планируем? Я слишком быстро хочу результат? Или низкая квалификация? На что уходит время?
Я стала анализировать: в среднем на 1 небольшую фичу приходится от 15 до 40 багов, а время на их фикс уходит больше, чем на разработку самой фичи. Почему? Много это или мало? Разработчики жалуются, что очень много просьб на изменение уже разработанного функционала — правда ли это или субъективная ошибочная оценка?
Копаем дальше. Я ввожу в бедный несчастный разбухший от дополнительных полей баг-трекер поле: «Причина появления ошибки». Не пропуска, как в Истории #1, а именно ПОЯВЛЕНИЯ. Это поле заполняет разработчик в момент коммита, когда он уже точно знает, что и как он исправлял. И варианты ответа следующие:
- Код (вот взяли и накосячили)
- Непонимание требований («ах я ж не понял, что именно это было нужно!»)
- Изменение требований (product owner посмотрел на результат и сказал «э не, на самом деле нужно по-другому, а не так, как я изначально просил»)
Ошибок в коде у нас оказалось около 30%. Изменений требований — меньше 5% (разработчики удивились, но признали — это ведь они указывают причину!). А почти 70% ошибок оказались вызваны непониманием требований. В нашем случае, когда багфикс занимает больше разработки, это ПОЛОВИНА ВРЕМЕНИ, ЗАТРАЧИВАЕМОГО НА РАЗРАБОТКУ ФИЧИ.
Что делать?
Вариантов решения проблемы мы нашли много, начиная от найма технического писателя, который будет вызнавать требования у product owner’а и документировать подробно всё то, что мы описываем в пару строк и заканчивая product owner’ом, переведённым в секретари, круглые сутки документирующим новые фичи. Ни один из этих вариантов нам не понравился, слишком они бюрократичны для команды из 4 разработчиков, сидящих в одном кабинете. Поэтому мы сделали следующее:
- Product owner вкратце, как и всегда, описывает новую фичу
- Разработчик, когда доходит до неё, тщательно обдумывает способ реализации, как это будет выглядеть, что с этой фичей ему вообще делать
- После этого разработчик и РО садятся вместе, и разработчик подробно рассказывает свои мысли на тему
светлого будущегоразрабатываемой фичи - Разработчик ни при каких условиях не начинает работу над новой фичей, не пройдя вышеописанный алгоритм действий и не согласовав своё видение с РО
- Тестировщик чаще всего участвует в этом процессе, заранее подсказывая сложные моменты, которые он будет тестировать
Теперь у нас есть около 3-7 таких ~часовых «болталок» в неделю, на которые отрывается 2-3 человека. Количество заводимых багов снизилось, из них ошибок кода стало больше 50% — поэтому нашей следующей задачей будет внедрение code review, т.к. теперь у нас новая «главная проблема».
Но от метрики-анализатора мы вернулись к метрике-датчику и поняли, что ни разу с весны не сорвали сроки по фиче больше чем на 50%, хотя до этого среднее значение срыва было от 50% до 100%, а иногда и больше.
И это только начало! 😉
История 3: Кто тормозит разработчиков?
Ещё одна история касается моего совсем недавнего опыта в сторонней компании. Настоящий-пренастоящий Agile, еженедельные итерации… И еженедельные срывы сроков!
Причина, заявленная руководством компании: «Разработчики допускают слишком много багов».
Я начала анализировать, как это происходит. Я просто участвовала в процессе и наблюдала со стороны, как это очень здорово описано в книге Имаи «Гемба Кайдзен». И вот что я увидела: Релизы по четвергам, пятница подготовительный к новой итерации день. Во вторник-среду появляется сборка на тестирование. В среду-четверг заводятся дефекты. В пятницу, вместо подготовки к новой итерации, разработчики экстренно исправляют баги и так каждую неделю.
Я попросила в таск-трекере, где дублируются фичи с доски, проставлять статусы по фиче: фича принята в разработку, фича отдана на тестирование, фича протестирована и отправлена на доработку, фича протестирована и принята в релиз.
И как вы думаете, какой средний срок между «фича отдана на тестирование» и «фича протестирована и отправлена на доработку»? 1,5 дня!
Причём иногда — с ЕДИНСТВЕННЫМ блокирующим дефектом.
Разработчики в этой компании жаловались на тормозных тестировщиков, но тестировщики и руководство были против разработчиков: «вы сами должны тестировать и не отдавать сырой продукт». Но ведь кесарю кесарево!
Итак, метрика есть, 1,5 дня недопустимо много, хотим сократить минимум втрое — это должно ускорить релизы на день. Как это сделать? Опять брейншторм, опять куча идей, 90% участников процесса настаивают что «разработчики должны тестировать сами».
Но в итоге мы решили попробовать по-другому: как только фича, по мнению разработчика, готова, тестировщик садится с ним за один компьютер, берёт блокнот с ручкой и начинает проверять, комментировать, выписывать замеченные косяки в блокнот, не тратя время на баг-трекинг. Больше половины багов разработчики в таком режиме исправляют на лету! Ведь фича только написана, всё ещё держится в голове!
Срок с 1,5 до 0,5 дней мы сократили очень быстро, но на практике мы достигли другого, более серьёзного изменения: % переведённых в статус «отправлено на доработку» фич снизился с почти 80 до почти 20! То есть в 4 раза! То есть 80% фич теперь сразу принимался после переведения в статус «тестирование», потому что незадолго до перевода в этот статус проходило тестирование «на лету», так сильно сокращающее и время регистрации ошибок, и стоимость их исправления.
Кстати, история 3 — единственная, где мы сразу достигли поставленную цель. Срывы итераций всё ещё бывают, но теперь это исключение, и почти каждый четверг команда разработки уходит домой вовремя, а в пятницу правда начинается подготовка к следующей итерации.
Бинго!
Выводы
Я очень не хотела рисовать сухие формулы, философствовать и теоретизировать. Я рассказала конкретные истории из свежего (2012!) опыта. Истории, в которых мы сокращали сроки и повышали качество, не меняя бюджет.
Вы всё ещё не готовы использовать метрики с пользой?
Тогда мы идём к вам! 🙂
