성능 검토 지표의 일부로 지속적인 빌드 결과를 사용하십니까? [닫은]

상사는 성능 검토 ( '품질'측정 기준)의 일부로 연속 빌드 (모든 커밋에서 테스트를 빌드 및 실행)의 메트릭을 사용할 계획입니다. 이것은 나에게 정말 나쁜 생각처럼 보이지만, 누군가 이것을 연구했거나 이전에 시도한 것을 보았는지 알고 싶습니다.

내 생각은 테스트가 실패 할 것이라는 두려움 때문에 개발자가 다른 테스트만큼 많은 테스트를 수행하지 않을 것이라고 생각합니다. 나는 그가 개발자를 이길 수있는 귀중한 개발자 도구를 스틱으로 바꾸고 있다고 생각합니다.

분명한 반론은 사람들이 커밋하기 전에 더 신중하게 행동하여 더 높은 품질로 이끌 수 있다는 것입니다.

내가 기지에서 떨어져 있습니까? 성능 검토를 수행해야하는지 아닌지에 대한 질문을 남겨 두십시오.

성능 검토는 훌륭하지만 다음과 같은 유용한 지표는 어떻습니까?

• 기능에 대한 단위 테스트 적용 비율
• 마감 시간을 충족시키는 능력
• 명확하고 간결한 문서
• 적절한 코딩 규칙을 따르십시오
• 다른 사람들과 잘 의사 소통
• 요구 사항 및 사용자 스토리를 작업으로 전환하는 기능

이 잘 ... 음, 어디 ... 그들이 실제로 필요로한다는 것이다 관리 다음으로 갖고있는 것 같다 것으로 성능을 측정하는 모든 좋은 가지 방법하지만 문제입니다 나중에 알고 ... 실제 작업 그들의 부분에 있습니다.

불행히도 대부분의 경영진은 "그런 일을하기 위해 직원들이 실제로하고있는 일을 따라갈 필요가없는 지표에 대해 직원들을 판단하고 싶다"는 태도를 가지고 있습니다.

제 생각에는 여기서 시스템을 게임하는 것이 가능할 것입니다. 그리고 당신의 상사는 그것이 현실이되는 것을 막을 방법을 찾아야합니다. 언급하지 않은 다른 경우는 개발자가 많은 시간을 투입하여 빌드 수가 사용되는 검토의 일부가있는 것처럼 수정 횟수가 상대적으로 적은 수의 체크인이 발생하는 경우입니다. 이 도구는 오히려 쉽게 오용 될 수있는 새로운 도구가됩니다. 이름이 바뀌거나 공백이 변경되는 체크인은 체크인이며 어떤 형태의 생산성은 pedantic view로 간주됩니다.