Полезные метрики для оценки проектов

    В октябре я уже рассказывала о способах оценки тестирования, все страждующие и сочувствующие могут посмотреть запись здесь. А сегодня мне захотелось затронуть тему метрик проекта в целом, причём метрик не «длягалочных», а метрик «пользуприносящих» и «проектыулучшающих». Именно поэтому, вместо сухих формул и перечня метрик, я расскажу 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!) опыта. Истории, в которых мы сокращали сроки и повышали качество, не меняя бюджет.

    Вы всё ещё не готовы использовать метрики с пользой?

    Тогда мы идём к вам! :)
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 34

      –1
      Отличный рассказ.
      Но если бы там были формулы, и немного философии — это только придало бы плюсов.
        0
        А каких формул не хватает? Что не понятно как посчитать?
          0
          Интеграл численный… ;)

          Нормально- смысл понятен и интересен.
        +2
        тестировщик садится с ним за один компьютер, берёт блокнот с ручкой и начинает проверять, комментировать
        Мне кажется, программист в этот момент еще и учится видеть потенциальные проблемы; учиться думать как тестировщик.
          0
          Да! Поэтому я ещё всегда стараюсь подключать тестировщиков и на этапе обсуждения фич между аналитиком и разработчиком. Тестировщик сразу говорит, что будет тестировать, разработчик заранее готовится к этому, и многие баги просто не допускает.
          +1
          Понятное дело, что всех ошибок не отловить, поэтому и выходят тестовые версии: альфы, беты.
          Но еще применяется хорошее решение, когда сама программа репортирует об ошибках разработчику.
          Последнее я применил в одном веб-проекте, где в базу система ложит что-то вроде лога ошибок с типом (ошибка, предупреждение, исключение) и всем стеком. В принципе, очень даже помогает.
            +1
            На самом деле статистика (если она действительно работающая, а не «длягалочная», как вы выразились :-) — это огромная помощь в оптимизации бизнеса.

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

              +3
              Вот!!! Тут с метриками есть такая хитрость: приходит руководство в один ужасный день и говорит «я буду вас мерять вот такими-то метриками, собирайте». И все собирают, но

              * не любят это делать, чувствуют давление
              * начинают читерить, стараться что-то приукрашивать

              Метрики никогда не должны исходить от руководства, их должна придумывать команда! И я стараюсь руководству вообще их поменьше показывать. Для них нужны 1-2 метрики про продажи и сроки разработки, но глубже лезть не следует, ответственной команде это только мешает, а безответственная начинает работать на метрики вместо результата.
                0
                Нам повезло с руководством, это оно их и внедряет :-)
              0
              Спасибо за статью! У меня на проекте проблемы по третьему примеру.
              Тестировщик считает багами нормально поведение (описанное в спеке), тестирует релизы с нуля, а не инкрементно, не перепроверяет старые баги на новых релизах.

              В итоге заказчик выдвинул — разработчики должны сами все тестировать. Релиз перед публикацией не тестируется.
                +1
                Значит вам не повезло с тестированием, найдите кого-то более адекватного, и включайте его в группу разработки, чтоб у них были общие цели, общее понимание работы над проектом.
                +3
                Мне кажется, в последнем случае неделя — недопустимо малый промежуток времени между итерациями. Мы тоже одно время так работали, и это приносило много стресса и команде, и энд-кастомеру. А как перешли на цикл в 2 недели — всё стало на свои места.

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

                Идея про мгновенный тестинг — гениальна, часто встречал девелоперов которые даже смок-тестить свой код не умеют, на всём полагаясь на 100% чисто на тестеров.
                  0
                  Идея про 2 недели очень упрощает жизнь, но увеличивает общие сроки разработки. У меня на моих проектах тоже 2 недели, но это потому что я разгильдяй и каждую неделю релизы просто не переживу :)

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

                  Кстати история про 1-недельные итерации единственная 100%-успешная из списка приведённых, всё оказалось не так сложно.

                  Мне очень нравится книга Имаи «Гемба Кайдзен», там он рассказывает о том что менеджер должен быть часто в Гемба (это завод или другое место, где производится продукция, в нашем случае пишется код) и внимательно наблюдать. Просто наблюдать. Я стараюсь часто это делать и в итоге вижу, где «узкие горлышки», с какими проблемами кто сталкивается. Со стороны заметить это проще, чем для непосредственных участников процесса, а вместе с ними потом можно обсудить, как эти проблемы решать.

                  Сократите срок итерации — и проблем сразу будет заметно значительно больше, они будут более яркими. Можно это даже иногда специально для контролируемого стресса делать, и для диагностики проблемных мест.
                  0
                  Отлично написано. Спасибо!
                    –1
                    Спасибо за статью. Мне тоже очень понравилась идея о мгновенном тестинге. Аж обидно, что сам не додумался. Как всегда, все гениальное — просто. Попробую это в нашей компании в самое ближайшее время. Тем более, что мы как раз переходим на ажайл и за каждой небольшой командой закрепили своего личного тестировщика QA инженера.
                      +1
                      Читал и не понял — ты говоришь о метриках как инструменте МОНИТОРИНГА хода проектов, или как инструменте ДИАГНОСТИКИ и радикального улучшения показателей на конкретном одном?

                      Во втором случае, если проблему и причину обнаружили и устранили, зачем продолжать собирать метрики, тратить на это ресурсы?
                        0
                        Тут есть и те и те метрики. «Мы пропускаем много багов», «Мы долго выпускаем релизы» и т.д. — это метрики мониторинга, и их надо собирать на регулярной основе.

                        «Причина пропуска бага», «причина появления бага» — это метрики диагностики, и они нужны только в тех случаях, когда метрики мониторинга показывают что что-то плохо.

                        А когда мы решили проблему, мониторить статус всё равно нужно, чтобы убеждаться, что проблема не воскрешается потихоньку, и чтобы заметить её на ранних этапах. Это касается метрик мониторинга, а диагностические — временные, до решения.
                        –1
                        Если честно, как-то ваши истории и метрики не убедили. Возможно всё упирается в тип компании и квалификацию сотрудников, но ощущение, что они какие-то однобокие и решаю одну проблему, потенциально создают другие.
                        Скажите, у вас есть более репрезентативные выборки с историями успеха метрик?
                          0
                          Действительно, мы диагностируем проблемы и какую-то одну проблему и решаем. А почему они потенциально создают другие? Можно примеры?

                          Про «более репрезентативные выборки» не поняла, как они должны выглядеть?
                            0
                            пример, ниже привели.
                            более репрезентативные — это значит, чтчо мы это сделали на 10 разных командах и везде результат одинаковый.
                            как найду время (возможно, в выходные, рапишу свои мысли по вашим решениям), у меня просто ощущение, что решив одну проблему вы добавили другую. Можно будет вместе подумать и обсудить это.
                              0
                              Схему про пропуски багов (История #2) я внедряла ну может не в 10, но больше чем в 5 проектов точно. Естественно результаты диагностики в разных командах были разные, решения тоже, но % пропущенных ошибок везде удавалось успешно сокращать.

                              По остальным метрикам опыт «одноразовый».

                              Но я про любые не гарантирую работоспособность в каких-либо условиях, метрики везде уникальные даны, я просто даю общий алгоритм «найди метрику — датчик проблемы», а потом «сделай метрику- диагност — источник проблемы». А что и когда это будут за метрики — зависит от конкретных условий!
                          +1
                          Я прочитал этот топик на одном дыхании! Хочется отметить что автор очень интересно и профессионально пишет! И вообще очень много для себя взял на заметку! Спасибо Вам огромное! Побольше бы таких статей. Пишите обязательно на эту тему еще! Мне очень понравилась статья! Проблема эффективного управления командой всегда остается актуальной.
                            0
                            Супер!
                              0
                              Пару лет используем решение из истории 3 — персональное тестирование «на лету», когда программист правит баги в режиме живого общения с тестировщиком.
                              Пока это один из самых эффективных способов тестирования.

                              Но есть проблемы, интересно, как их решили вы.
                              1. Необходимо соотношение тестировщиков\программистов один к одному. Дорого. Иначе — очереди и затея теряет смысл. И да, программисты имеют свойство доделывать задачи одновременно.
                              2. Сажать за один комп — работает на простенькой функциональности, неопытных программистах и очевидных багах. А если фича сложная, а программист опытный, то первые замечания появятся часа через три.
                                0
                                а можете рассказать как вам удалось решить эти проблемы?
                                p.s. Кстати, мне кажется у остальных историй, есть подобные проблемы тоже.
                                  0
                                  Первую решить пока не удалось, вторую — пока тестируется фича кодер чинит мелкие баги. По сути — не решили обе.
                                    0
                                    т.е. всё же свели к тому, что тестировщики сидят отдельно и тестируют код отдельно по указанию от программистов?
                                      0
                                      Да, для сложных задач.
                                      Разработчик отдает задачу тестировщику, параллельно запускает полное автотестирование — занимает примерно столько же времени. Сам в это время занят другим.
                                      Ну а мелкие задачи — тестируются вместе, в реалтайме, так сказать.
                                  0
                                  1. Ну я бы не сказала, что нужно такое соотношение. Конкретно в случае, описанном выше — 7 тестировщиков на 17 разработчиков, то есть отличия в 2 с лишним раза. А вот с одновременными доделками часто сталкиваемся, есть такая проблема. Пытались договориться о разбросе сроков, планировать каждую отдельную фичу с точностью до полдня — не сработало. Просто в случае одновременной готовности идём по порядку, кому-то приходится ждать. Я бы не сказала, что это прямо ПРОБЛЕМА, просто 1-2 фичи в неделю могут подвинуться на пару часов в тестировании.

                                  Решение — больше тестировщиков, но эти затраты *конкретно в нашем случае* не оправданы.

                                  2. Если нет очевидных дефектов, то тестирование на лету вообще не нужно! Минут 20-30 вместе покликали, убедились что в целом фича рабочая — и продолжаем тестировать на тестерском компьютере. Если баги и найдутся, то это уже не будут блокеры, из-за которых встанет вся итерация.

                                  Если у вас что-то не так — значит, у вас слишком большие фичи, которые не подходят ни для коротких итераций, ни для тестирования на лету.
                                    +1
                                    Вообще, приведённые мной истории — это упаси боже не предложение «делайте вот так». У меня сейчас есть проект с релизами раз в год и фичами, которые делаются целыми командами разработки по несколько недель. Тестирование на лету в этом проекте совсем не применимо, да и не нужно.

                                    Нет «хороших» решений, есть подходящие или не очень ПОД КОНКРЕТНЫЕ УСЛОВИЯ.
                                    0
                                    А как в описанных ситуациях Ваши решения повлияли на сроки выполнения? Увеличился ли срок выполнения фичи, всего проекта?
                                      0
                                      Об этом же в статье написано… Мы сократили сроки в 2-м и 3-м случае, и по разработке фичи, и по выпускам итераций. В 1-й же истории временные затраты врядли изменились.

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

                                      Т.е. истории №1 и №2 — про сокращение сроков без ущерба качеству, №3 — про повышение качества без замедления разработки.
                                        0
                                        Точнее:

                                        Т.е. истории №2 и №3 — про сокращение сроков без ущерба качеству, №1 — про повышение качества без замедления разработки.
                                          0
                                          Спасибо!

                                      Only users with full accounts can post comments. Log in, please.