Неправильное использование метрик

Эта статья в некотором роде продолжает «вскрытие» некорректных подходов к тем или иным практикам в разработке ПО. Так, недавно написал статью «Риски и Agile/Scrum», где поделился мнениями коллег-слушателей по поводу управления рисками в проектах, использующих Agile/Scrum.

В этой же статье используется тот же подход. За последнее время несколько раз в разных городах проводил семинар «Какая польза от метрик?», который одновременно и знакомит слушателей с темой измерений в разработке ПО, и является презентацией тренинга на эту тему. По ходу семинара в одном из интерактивов я прошу слушателей припомнить случаи из жизни о неправильном использовании метрик, их интерпретации и принятия решений. Причем прошу сделать акцент на курьезности и явном непонимании сути измерений. И вот накопилось некоторое количество историй от слушателей, коим за это очень благодарен, некоторые истории я немного переделал, чтобы защитить действующих лиц от возможного узнавания, но смысл сохранен.

Итак, курьезные (надеюсь) истории о неправильном использовании метрик:

  • Начисление бонусных дней отпуска тестировщикам в зависимости от количества найденных дефектов. Вот так поощряется поверхностное тестирование и дубликаты. Зачем думать, разбираться в действительно серьезном глубинном дефекте, если можно за это же время наплодить 5-10 штук попроще?
  • Не о метриках, о планировании и заказчике, но все же. Для потенциального заказчика сделали оценку трудозатрат – 2 человеко-года. Причем заказчик на свою беду признался о доступном бюджете, который в несколько раз превышал оцененные трудозатраты. В итоге оценку направили «на доработку», чтобы она «соответствовала» бюджету заказчика. Вот уж действительно забота о заказчике!
  • История о важности размера (size) продукта, почему важно – большинство метрик опирается на понятие размера (см. материал «Оценки трудозатрат. Модели размера»). Так вот, между двумя людьми случился спор на ящик водки, ну а на что же еще может спорить наша душа :). Но проспоривший оказался парень не промах. Да, принес ящик водки. НО, победитель вместо привычных глазу «половинок» (0.5 л) обнаружил там «соточки» (0.1 л). И все по честному, размер не был указан, но размер-то имеет значение.
  • Инспекция кода была поручена не очень опытному инспектору, что уже странно. И так как по сути кода по причине неопытности он ничего существенного сказать не мог, то «фишкой» стала проверка количества комментариев в коде, причем какая-то добрая душа подсказала, что количество строк комментариев должно равняться количеству строк кода. Тут и началась бессмысленная гонка комментариев за растущим кодом. Говорят, весело было, только пользы мало.
  • При поддержке продукта работа заключалась в устранении дефектов, найденных конечными пользователями. Руководство решило ввести «мотиватор» — депремирование авторов дефектов за некачественную работу. Но не все так просто, люди приходили и уходили, и соответственно «достать» за авторство было тяжеловато. Причем «авторы» дефектов и те, кто их устранял могли быть совершенно разные люди. Поэтому руководство решило вопрос по простому – собрало статистику и «определило» авторство по тому, кто дефект устранял, а не кто его произвел. И произвело мотивационную работу.
  • Другой вариант «мотивации» — депремирование тестировщиков за пропущенные дефекты, т.е. те, которые нашел заказчик. Сама идея о мотивации за хорошую работу конечно правильная, но реализация, насколько мы поняли из обсуждения, была полностью некорректна. А именно, не было четкого соглашения о границе между качественной и некачественной работой, решение о депремировании было принято субъективно и скорее всего импульсивно, скорее всего не было соглашений и с заказчиком о критериях качества, тестирование в данном случае пришлось делать поспешно на релизе, который сдавался в пятницу вечером (ну а когда же еще!), плюс ко всему, в компании были проблемы со своевременной выплатой зарплаты.

 

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

Tags: , , , ,

Comments are closed.