Сообщений в теме: 23

[Ira]

Привет всем! И с прошедшими праздниками!
Возникла следующая проблема: что-бы разработчики более серьезно относились к допущенным ошибкам и к тестерам, руководство решило выводить допущенные баги, и так же ввести какую то оценку разработчику. Незнаю возможно ли это реализовать, так как тут играет роль не только количество ошибок но и их грубость, или количество итераций ( предположим 5 раз таже самая ошибка повторялась, хотя разработчик типа исправил ее)..и вообще на сколько сама задача сложна. Вообщем учитивая все это вывести "цифру" которая будет говорить о качестве разработчика.
Люди вообщем понимаю все очень не реалистично, но может есть этому какое то решение...или может даже готовые проги?
Заранее всех благодарю за ответы (надеюсь они будут).

[Green]

Привет Ира!

К сожалению, не возможно вывести какой-то усредненный показатель качества разработки, выполняемой программистом. Что бы такой показатель был справедливым и объективным, нужно учитывать и подсчитывать очень большое количество показателей, часть из которых вообще не возможно формализовать. К примеру, как измерить «давление» на проектную команду в виду возможности срыва сроков выпуска продукта? Ньютоны в этом случае точно не помогут.

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

Вот несколько примеров таких правил.
1. Код, помещенный в репозиторий, не должен портить сборку продукта. Если это правило нарушено и во время ночной автоматической сборки продукт не смог собраться, значит - правило нарушено. Есть реальный финансовые потери компании из-за ошибки программиста. На первый раз – предупреждение, во второй раз – «бьем рублем» (или долларом).
2. Рабочий день программиста должен начинаться с исправления найденных багов. Это необходимо для сокращения длительности жизни бага – прямая экономическая выгода компании.
3. Статус бага всегда должен быть актуален. Это позволяет исключить недопонимание между программистом и тестировщиком по вопросу объема работ. Опять же – экономия времени, а следовательно и средств.

Но из приведенного Вами примеров видно, что разработчик ставит статус бага «исправлен» в пятый раз после того, как он был открыт. Здесь уже другая проблема. Налицо конфликт между разработчиком и тестировщиком, который они не могут разрешить самостоятельно. По всей видимости, разработчик считает, что это фича, а тестировщик – баг. Вот они и "футболят" эту проблему друг другу. Это уже компетенция менеджера и никакой способ аттестации как одного, так и другого не позволит избежать такого рода конфликтов.

[Ira]

По всей видимости, разработчик считает, что это фича, а тестировщик – баг. Вот они и "футболят" эту проблему друг другу. Это уже компетенция менеджера и никакой способ аттестации как одного, так и другого не позволит избежать такого рода конфликтов.

В принципе проблема и не в этом, просто программист эксплуатирует тестера, он принял что это баг, поработал над этим пол часа, и поставил статус бага "fixed". А на самом деле баг не исправлен, посто программист не допроверяет свой код, и так к примеру 5 раз, тут и тестер кучу времени теряет и сам программист. Хотелось бы чтоб они серьезнее относились к багам.
А насчет "оценки" работы программиста, что если сделать так ( ну конечно могут быть и исключения, типа короткий срок и давление) но вообщем:
1. Подсчитать количество строк написанных програм. -ом для конкретной задачи (Есть проги).
2. Время потраченное ( У нас это в TaskTracker-e)
3. Время потраченное тестером, включая время потраченное на тестирование обнаруженных багов (Тоже есть в системе BugTracker)
4. Количество багов (BugTracker).
Основываясь на всем этом виявить коэффициент. Нормально?

[Green]

Конечно, нормально!

Только работать не будет!

Возьмем первую характеристику. Что считать хорошим результатом? Что лучше? Чем строк кода больше или меньше? Или как сравнить две разные задачи (если бы они были одинаковыми, то они использовали бы одно и тоже решение)?

Более того, человек легко подстраивается под обстоятельства. Как только будет распознан принцип «стать хорошим», так сразу же все начнут подстраиваться под него. Если скажите, чем строк кода меньше, тем лучше, то разработчики начнут урезать код даже за счет функциональности. Или другая крайность, начнут тратить время на поиск чужого кода, который может быть использован для своих задач.

Или представим другой вариант. Будем подсчитывать производительность тестировщика – количество багов на количество строк кода. Сравнивая показатель производительности одного тестировщика с показателем другого можно сделать вывод о том, кто из них работает лучше. Правильно?

Не правильно! У одного один проект, у другого – другой. Каждый из них имеет свою сложность. Значит нужно вычислять сложность проекта. А как ее подсчитать?

Но, допустим, мы смогли выработать методику определения сложности проекта. Тогда мы, пользуясь показателями сложности двух проектов, можем вычислить коэффициент относительной сложности проектов и использовать его как поправку при определении производительности тестировщиков. Все!

Нет не все! Как учесть, что каждый из проектов выполнялся под разным давлением. Для одного было достаточно времени, а для другого – нет. Его выполняли в авральном режиме. Но это уже может относиться к вопросам менеджмента каждого из проектов. А как учесть параметр, всязанные с менеджментом? И таких показателей - масса. Формализовать их невозможно.

Опять же, хочу привести пример с правилами движения. Как определить, какой из водителей лучше? Тот, который совершает меньше нарушений установленных правил. Другими словами, речь идет о процессе и о его соблюдении. Если у одного разработчика 2 грубых нарушения регламента, а у другого - 10, кто из них более ответственный?

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

[van]

Ирина, здравствуйте!

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

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

НО:
1. Это не Ваша задача, а задача HR. Поэтому посоветуйтесь, прежде всего с ними.

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

Понимаю, что с моих слов это звучит не очень убедительно :) Но советую почитать на эту тему Джоэла Спольски или ДеМарко и Листера "Человеческий фактор: успешные проекты и команды" - там более убедительно написано.

[I_G]

Всем участникам проекта, а особенно разработчикам, раз уж идет речь о них, необходимо объяснить, что производство багов - очень дорогое удовольствие. Можно много и долго дискутировать на эту тему, применять метрики и коэффициенты, но результат сведется к одному: существует прямая зависимость эффективности работы разработчика от количества багов, обнаруженных в его коде. Т.е. первый прямой показатель, меньше багов - лучше работает.
Ну а второй показатель, за который можно сразу наказывать - количество вернувшихся багов с ретестинга. Баг вернулся один раз - плохо, два раза - очень плохо, три раза - полное разгильдяйство.

[Ira]

Спасибо всем за ответы. Да, это страшнее чем я представляла...
Ну тогда как заставить разработчиков хотя бы раз проверять свой код, когда unit testing не проводится (ну если только на словах) - времени и ресурсов не хватает. Как сделать так чтоб они допускали меньше ошибок, и к этому относились бы серьезнее? За каждую ошибку из зарплаты удерживать? (это нервный смех)

[Green]

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

К сожалению, не все так просто. Не всегда большое количество багов в баг треккере у разработчика это плохо.

К примеру, у одного разработчика - опытный тестер, а у другого - нет. Или один рещает уникальную задачу, а второй - тривиальную (уже хорошо проработанную и описанную в литературе). Как следствие, у первого будут больше багов, чем у второго. Но это не отражает их реальную квалификацию.

Но могут существовать нормативы, соблюдение которых отражает ОТНОШЕНИЕ как разработчика, так и любого другого участника процесса. Это является характеристикой профессионального отношения к работе. И в этом случае справедливо:

Баг вернулся один раз - плохо, два раза - очень плохо, три раза - полное разгильдяйство.

[DrVal]

С одной стороны, если есть нормальный баг-трекинг, то достаточно просто получить статистику по движению багов.

Но я бы не стал оценивать качество разработчиков по количеству багов.

Они же не диктанты пишут. Даже за сочинение ставят 2 оценки - за содержание и за грамотность.

И все сильно завязано на политику, критерии и процессы в компании.
Человек может написать много безупречного кода, но при этом не решить задачу в отведенные сроки. Т.е. формально он отлично сработал, но результата нет. И чья в том вина?

[rlabs]

2. Рабочий день программиста должен начинаться с исправления найденных багов. Это необходимо для сокращения длительности жизни бага – прямая экономическая выгода компании.

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

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

Возможно, просто отсутствие внятного жизненного цикла для багов.

[DrVal]

Т.е. основной критерий оценки качества разработчика - минимизация работы для тестировщиков?

Думаю, что ваших заказчиков это меньше всего волнует. У них другие критерии - сроки, качество продукта (не вдаваясь в подробности), цена, сервис и т.п.

Спасибо всем за ответы. Да, это страшнее чем я представляла...
Ну тогда как заставить разработчиков хотя бы раз проверять свой код, когда unit testing не проводится (ну если только на словах) - времени и ресурсов не хватает. Как сделать так чтоб они допускали меньше ошибок, и к этому относились бы серьезнее? За каждую ошибку из зарплаты удерживать?  (это нервный смех)

[Ira]

Т.е. основной критерий оценки качества разработчика - минимизация работы для тестировщиков?

Думаю, что ваших заказчиков это меньше всего волнует. У них другие критерии - сроки, качество продукта (не вдаваясь в подробности), цена, сервис и т.п.

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

[rlabs]

Спасибо всем за ответы. Да, это страшнее чем я представляла...
Ну тогда как заставить разработчиков хотя бы раз проверять свой код, когда unit testing не проводится (ну если только на словах) - времени и ресурсов не хватает. Как сделать так чтоб они допускали меньше ошибок, и к этому относились бы серьезнее? За каждую ошибку из зарплаты удерживать?  (это нервный смех)

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

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

Вообще говоря, если разработчиков приходится заставлять и наказывать -- это говорит об отсуствии культуры разработки в компании. Там, где развита культура, разработчик не станет ждать, пока его накажут -- ему просто неприятно, и он сам стремится максимально эффективно решить проблемы. Короче, культура должна быть :-) Подробнее смотрим книжки по человеческому фактору.

Описанная же вами ситуация с "перебросом" багов между разработчиком и тестировщиком, помимо, возможно, низкой квалификации обоих, говорит, опять же, об особенностях внутренней политики компании. Могу предположить, что тестировщики и разработчики размещены в отдельных помещениях, редко пересекаются друг с другом, настроены друг против друга (об этом говорит желание "заставить" разработчиков) и предпочитают общаться по почте.
В реальной ситуации после второго "переброса" тестировщик поворачивается к разработчику лицом и выясняет, в чем дело. Да, можно, конечно, эскалировать проблему в менеджмент и выше, но в результате потери будут еще больше.


Вот как-то так, да.

[Ira]

Описанная же вами ситуация с "перебросом" багов между разработчиком и тестировщиком, помимо, возможно, низкой квалификации обоих, говорит, опять же, об особенностях внутренней политики компании. Могу предположить, что тестировщики и разработчики размещены в отдельных помещениях, редко пересекаются друг с другом, настроены друг против друга (об этом говорит желание "заставить" разработчиков) и предпочитают общаться по почте.
В реальной ситуации после второго "переброса" тестировщик поворачивается к разработчику лицом и выясняет, в чем дело. Да, можно, конечно, эскалировать проблему в менеджмент и выше, но в результате потери будут еще больше.

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

[Tiana]

Описанная же вами ситуация с "перебросом" багов между разработчиком и тестировщиком, помимо, возможно, низкой квалификации обоих, говорит, опять же, об особенностях внутренней политики компании. Могу предположить, что тестировщики и разработчики размещены в отдельных помещениях, редко пересекаются друг с другом, настроены друг против друга (об этом говорит желание "заставить" разработчиков) и предпочитают общаться по почте.
В реальной ситуации после второго "переброса" тестировщик поворачивается к разработчику лицом и выясняет, в чем дело. Да, можно, конечно, эскалировать проблему в менеджмент и выше, но в результате потери будут еще больше.

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

Из своего опыта могу сказать, что аналогичная проблема была решена путем проявления настойчивости в этом вопросе (можно сказать, маленькой хитрости). Путем обязательной перепроверки бага каждый раз, его переоткрытия (в случае, если баг не был исправлен), а также корректного обоснования, почему баг открыт снова. В такой ситуации каждый понимает, что проще исправить баг, чем откладывать его N-ое количество раз.

[DrVal]

мне кажется, что достаточно простую проблему (формализация отношений разработчик-тестировщик или недостаток ресурсов для тестирования) пытаются свести к гораздо более сложной (оценка качества работы разработчика)

[Green]

Описанная же вами ситуация с "перебросом" багов между разработчиком и тестировщиком, помимо, возможно, низкой квалификации обоих, говорит, опять же, об особенностях внутренней политики компании. Могу предположить, что тестировщики и разработчики размещены в отдельных помещениях, редко пересекаются друг с другом, настроены друг против друга (об этом говорит желание "заставить" разработчиков) и предпочитают общаться по почте.
В реальной ситуации после второго "переброса" тестировщик поворачивается к разработчику лицом и выясняет, в чем дело. Да, можно, конечно, эскалировать проблему в менеджмент и выше, но в результате потери будут еще больше.

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

Вот мы и добрались до самой сути.

Тестирование, так же как и разработка, должно вестись итеративным способом. Подготовлена очередная версия продукта - установлена в выделенное тестовое окружение - проведен smoke test - версия принята в тестирование, а уж затем проводим запланированные тесты.

В вашем случае, когда программисты и тестировщики используют разрабытываемую версию программы одновременно, получается закономерный "бег по кругу". Разработчики используют тестировщиков в качестве дебагера. Не удивительно, что сырая версия не работает.

[Ira]

Спасибо всем. У нас еще не внедрен до конца этот процесс: т.е. одтельный инвайрмент и все прочее. Надеюсь это решит проблему.

[ЛаМпочка]

Очень интересная беседа. Особенно спасибо (как в прочем обычно) Green
- весьма ценная информация.


Количество иттераций имхо еще не только показатель невнимательности разработчика, ведь и тестер может сделать невнятное (или заведомо неполное) описание. И кто виноват? Проводить служебное расследование по каждому пункту?

Интересно вот только , как должна выглядеть та самая процедура или инструкция, которая максимально эффективно позволила бы избегать подобные ситуации Регламент взаимодействия отделов??? Процедура фиксации ошибки? или Чернышевскийй "Что делать?"

[Green]

Очень интересная беседа. Особенно спасибо (как в прочем обычно) Green
- весьма ценная информация.


Количество итераций имхо еще не только показатель невнимательности разработчика, ведь и тестер может сделать невнятное (или заведомо неполное) описание. И кто виноват? Проводить служебное расследование по каждому пункту?

Интересно вот только , как должна выглядеть та самая процедура или инструкция, которая максимально эффективно позволила бы избегать подобные ситуации Регламент взаимодействия отделов??? Процедура фиксации ошибки? или Чернышевскийй "Что делать?"

Когда я писал об итерациях, то имел в виду проектные итерации (1-4 недели, у кого как). Закончилась итерация разработки - передаем билд в тестирование. С билдом идет отдельный документ (текстовый файл) - build notes, в котором кратко изложена информация о билде: какие фичи добавлены (ссылка на требование), какие фичи изменены (ссылка на запрос на изменения), какие баги пофикшены (перечень дефектов), какие баги еще не пофикшены (перечень дефектов), какие проблемы известны и их не стоит вносить в виде багов (перечень). Далее идет инструкция по установке билда (если это не автоинстоляция (через exe файл).

С каждым билдом файл обновляется (а не переписывается). Фактически, через несколько билдов это становится историей развития программы. Обычно такую процедуру относят к смежной дисциплине - конфигурационному менеджменту (известному так же, как релиз менеджмент, или как деплоймент менеджмент). При правильном подходе всю эту информацию можно получать автоматически, одновременно со сборкой билда. Но можно и вбивать ручками - работы не очень много, а пользы - вагон!


Если же обсуждать вопрос о том, каким образом избегать (или согласовывать в мирном порядке) неоднозначное понимание разработчиком и тестировщиком механизма реализации той или иной функциональности, то тут может быть только одно решение - диалог. Отличный подход реализован в FogBugz - у них по каждому дефекту, по фиче или по любому другому артефакту можно вести дискуссию в стиле Wiki прямо в теле записи. Если нужно, то к дискуссии может подключиться вся команда разработки и принять коллективное решение. Если же решение не принято, то менеджер принимает его сам. В итоге - решение принято и все довольны.