Your SlideShare is downloading. ×
Dark side of metrics
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Dark side of metrics

103
views

Published on

Про метрики. Не рассказывал нигде. По хорошему переделать надо бы

Про метрики. Не рассказывал нигде. По хорошему переделать надо бы

Published in: Leadership & Management

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
103
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • С тех пор, как человечество научилось считать, оно только этим и занимается. Считают прибыль, убытки, рост, вес, длину, ширину, высоту и т.д.
  • Т.к.
  • Несложные математические операции + набор весовых коэффициентов, которые высчитывались годами, позволяют прикинуть стоимость разработки софта. Для basicимеет мемто ранжирование проектов от маленького, до большого. Basic работает только с количественными характеристиками софта, т.е. KSLOC. Intermediate же принимает во внимание дополнительные показатели: характеристики продукта (сложность, размер бд, надежность и т.д.), свойства железа (память, производительность и т.д.), свойства кадрового обеспечения (способность анализировать, опыт в использовании стороннего софта, опыт использования языков программирования), свойства проекта ( использование средств разработки, применение различных методов разработки, необходимость плана разработки).Все имеет веса, ранжированные по принципу «ваще не важно» - «супермегаважно». Все это перемножают и вставляют в формулу для получения человеко-месяцев.Есть нюанс: основнымрулевым в формулах является количество KSLOC. Т.е. Надо изначально иметь представление о размере софта. В detailedэто учли и подкручивают на каждом этапе.
  • Объединили 10 в один, остальные задублицировалиКлассика. Баги не в багтрекере, а рядом, или почтойТакие ведь нельзя считать, т.к. они ничьи и статус у них не понятьСговор, следствие альтернативного багтрекераУжос. Тратит время на не свою работуДать премию за самое большое количество найденых багов
  • Если чуть-чуть исправить значение термина «тест» на «большая часть теста», ситуация сильно улучшитсяТы же знаешь, какие тесты провалились. Так не включай их в отчетА это вообще смертный грех!!!!!
  • Именно изменение, т.к. В сложной формуле сразу не поймешь, что на что влияет
  • Transcript

    • 1. Темная сторона метрик она действительно существует Роман Ивлиев
    • 2. О чем это я... • Метрики, что это и что с ними делать? • Метрики, есть примеры? • Темная сторона метрик, как это? • Серебряный топор есть?
    • 3. Метрики, что это?
    • 4. • Метрика - это мера, позволяющая получить численное значение некоторого свойства объекта
    • 5. Метрики, примеры
    • 6. Я – тестер=> метрики для тестеров • Найденные дефекты/ исправленные дефекты • Процент выполненных тестов /процент успешных тестов • Метрики для одной из комплексных моделей оценки (например, COCOMO)
    • 7. COCOMO – два слова • COnstructive COst MOdel (COCOMO) • Basic – помогает расчитывать затраты исходя из размеров программы • Intermediate - помогает расчитывать затраты исходя из размеров программы и некоторого набора «ценовых показателей» • Detailed – использует две предыдущих, но обсчитывает не целиком, а по этапам.
    • 8. Чем мерять? • Счетчик новых и закрытых баг-репортов • Процент выполненных тестов (удачных и неудачных) • Ацкий набор метрик (цикломатическая сложность, количество дефектов, размер программы), обсчитываемый ацкой формулой (как в COCOMO например)
    • 9. Темнеет...
    • 10. Счетчики, предположения • Все дефекты найдены и задокументированы • Есть цель починить все дефекты • Если все известные дефекты исправлены – продукт готов • Есть разумное объяснение для всех исправленых дефектов
    • 11. Проценты, предположения • Перед выполнением точно знаю, сколько тестов будет выполнено • Все четко понимают, что такое «тест» • Все четко понимают, что такое «выполненый» • Выходом теста является либо «Прошел», либо «Не прошел»
    • 12. Ацкий набор, предположения • Тот, кто считает, точно знает что делает
    • 13. Темная сторона метрик
    • 14. Счетчики, проблема Желание занизить один и завысить другой
    • 15. Счетчики, управление • Объединение дефектов в один • «Альтернативный» коллектор дефектов • Перевод дефектов в «Unassigned» • Добавление дефект, только после того, как он был исправлен • Самостоятельный поиск и исправление дефектов разработчиком. • А ещѐ можно ругать или хвалить
    • 16. Счетчики, следствие • Надо ли учитывать Unassigned? • Как заставить отказаться от альтернативы? • Как считать сложные дефекты? • И т.д.
    • 17. Проценты, проблема Желание занизить один и завысить другой 
    • 18. Проценты, управление • «Исправление» термина «тест» в сторону увеличения гибкости. • Прогон только «хороших» тестов • Исправление тестов по поведению софта.
    • 19. Проценты, следствие • Падает ли тест дважды, если он находит два дефекта? • Надо ли прогонять тест, который наверняка упадет? • Надо ли включать в отчет такой дефект? • Если функционал работает частично, все тесты отклонять, или только те, что реально упали?
    • 20. Ацкий набор, проблема Желание исправить результат
    • 21. Ацкий набор, управление Комплексное
    • 22. Ацкий набор, следствие • Тестеры не заносят дефекты в хранилку • Модель управляет. Даже без тестирования, она может сказать, что все готово. • Желание наказать, за «плохую» работу.
    • 23. Серебряный топор есть?
    • 24. НЕТ
    • 25. А что есть?
    • 26. Кэм Канер предложил вот что
    • 27. •Понять назначение измерения. Какое измерение для чего будет использоваться.
    • 28. •Понять цель измерения. Как широко будут использоваться измерения.
    • 29. •Найти объект измерения.
    • 30. •Определиться с масштабом измерения.
    • 31. •Найти описание естественного изменения объекта измерений, т.е. некоторый алгоритм, по которому изменяется объект измерения.
    • 32. •Найти инструмент для измерения свойств объекта. Например, счетчик новых дефектов (Не путать с тулами для работы с данными по измерениям).
    • 33. •Определиться с масштабом инструмента для измерений.
    • 34. •Познать как изменяются измерения, сделанные с использованием выбранного инструмента.
    • 35. •Познать каким образом объект измерения соотносится с инструментом.
    • 36. •Выяснить побочные эффекты, которые могут возникнуть при измерениях объекта выбранным инструментом.
    • 37. Спасибо за внимание! Я: Роман Ивлиев E-почта: Roman.ivliev@mail.ru ICQ UIN: 73034738 Skype: roman.ivliyev LJ: http://dumtest.livejournal.com