Использование результатов непрерывной сборки как части показателей оценки производительности? [закрыто]

Мой начальник планирует использовать метрики из нашей непрерывной сборки (собирает и запускает тесты для каждого коммита) как часть наших обзоров производительности (в нашей метрике «качества»). Это кажется мне ДЕЙСТВИТЕЛЬНО плохой идеей, но я хотел бы знать, изучал ли кто-нибудь это или видел, пытался ли это раньше.

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

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

Я с базы здесь? Пожалуйста, оставьте в стороне вопрос о том, должны ли мы делать обзоры производительности вообще или нет - это было дано в другом месте.

Обзоры производительности хороши, но как насчет полезных показателей, таких как:

• Процент охвата модульным тестом функций
• Способность уложиться в сроки
• Четкая и краткая документация
• Следуйте надлежащим правилам кодирования
• Хорошо общается с другими
• Возможность превращать требования и истории пользователей в задачи

Это все хорошие способы измерения производительности, но проблемы, с которыми, похоже, сталкивается руководство, заключаются в том, что им действительно требуется ... ммм ... ну, вы знаете ... ФАКТИЧЕСКАЯ РАБОТА с их стороны.

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

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