Використання результатів безперервної збірки як частини показників перевірки ефективності? [зачинено]


11

Мій начальник планує використовувати показники з нашої безперервної збірки (будує та виконує тести на кожній комісії) як частину наших оглядів ефективності (у нашій метриці якості). Мені це здається дійсно поганою ідеєю, але я хотів би знати, чи вивчав це хтось чи бачив це раніше.

Думаю, що наші розробники не будуть виставляти стільки тестів, скільки вони в іншому випадку, побоюючись, що тести вийдуть з ладу. Я відчуваю, що він перетворює цінний інструмент для розробників на палицю, з якою бив розробників.

Очевидний протилежний аргумент полягає в тому, що він сприятиме більш уважним ставленням людей до їх вчинення, а отже, і до високої якості.

Я тут поза базою? Залиште осторонь питання про те, чи варто взагалі робити перевірку ефективності чи ні - на це відповіли в іншому місці.


8
Будь-яка система, яку можна грати, - це жахливий внесок для оцінки продуктивності.
Стів Джексон

У кожного є можливість не тестувати?
JeffO

1
@Steve, а "системи", які неможливо грати, дають вам крихітний вигляд більшої картини. Щоб справді точно відстежувати продуктивність, знадобиться робота з ногами.
maple_shaft

2
Зауважте, що деякі речі добре працюють на машинах розробників, але виходять з ладу на сервері збірки (випадкова залежність від зовнішньої банки, неправильний спосіб використання / та \ на скриньках Linux тощо). Основна причина сервера складання - це зловити ці речі, а не переслідувати нікого за те, що вони не перевіряли їх спочатку. Іншими словами, це погана ідея.

1
Далі: Після того, як ми почали це робити, я виявив, що найбільша проблема не мала нічого спільного з іншими інженерами та готовністю написати належні тести, а швидше з тим, що наші існуючі тести дійсно були нестабільними, тому кожен вчинок мав досить великий шанс прориву без вини особи, яка виконує вчинення. Цей фактор погіршив ентузіазм кожного щодо тестування набагато більше, ніж будь-який вплив перегляду ефективності.
Майкл Коне

Відповіді:


7

Огляди ефективності добре, але як щодо корисних показників, таких як:

  • Відсоток покриття одиничного тесту на функції
  • Можливість дотримання термінів
  • Чітка і стисла документація
  • Дотримуйтесь правильних правил кодування
  • Добре спілкується з іншими
  • Можливість перетворити вимоги та розповіді користувачів у завдання

Це все хороші способи вимірювання ефективності, але проблеми, які, як видається, мають управління у цьому, полягають у тому, що вони насправді потребують ... гммм .. ну, ви знаєте ... АКТУАЛЬНА РОБОТА з їх боку.

На жаль, у більшості керівників є таке ставлення: "До чорта цього я хочу судити своїх співробітників за показниками, які насправді не вимагають від мене не відставати від того, що вони роблять".


1
+1 за надання хороших виборів будь метрик є корисним.
Девід Руттка

3

Ігрові системи тут, на мою думку, цілком вірогідні, і ваш начальник повинен знайти способи запобігти тому, щоб це було реальністю. Інший ви, про який ви не згадували, - це коли розробники здійснюють багато разів, так що відбувається цей потік реєстрацій, коли кількість модифікацій порівняно низька, як якщо б є якась частина огляду, де використовується кількість збірок саме тут це стає новим інструментом, який можна легко використати. Я думаю про реєстрацію, де щось перейменовано або змінюється пробіл, це реєстрація і вважається певною формою продуктивності.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.