2015.01.16

IDG 블로그 | 개발자의 생산성을 측정할 수 없는 5가지 이유

Java Everywhere | Techworld
우리는 누가 개발팀의 스타인지, 믿을만한 사람인지, 컴퓨터와 씨름하는지 잘 알고 있다. 누가 위에서 깨지는지도 말이다. 그러나 개발자가 일을 제대로 하고 있는지, 또는 빠르게 업무를 해내고 있는지를 정확하게 측정하거나 팀의 생산성을 비교 측정할 수 있는 확실한 방법은 없다.

블로거 짐 버드는 전통적인 방식으로는 ‘절대 불가능한 일’이라며, 사실상 개발자의 생산성을 정확하게 측정하는 방법이 없다고 주장했다. 버드는 개발자의 생산성을 계량화하고, 증명하기가 어려운 이유에 대해 설명했다.

코드 라인 수
버드는 코드 라인 수로 생산성을 측정하는 것에는 오류가 있다고 말하는데, 훌륭한 개발자들은 더 적은 코드로 더 많은 작업을 하기 위해 시간과 노력을 들이기 때문이다. 라인 수가 길다고 해서 생산성과 연결해서 생각하는 것은 오류를 범하는 일이다.

수익성
또한, 버드는 최종 결과물의 가치(수익을 낼 수 있는가, 혹은 비용을 절감할 수 있는가?)로 생산성을 측정하는 것도 잘못된 방법이라고 말한다. 이 측정 방식은 개발팀의 입력 품질과는 상관없이, 제품이나 서비스의 성공을 결정할 수 있는 무수히 많은 비즈니스 요인을 고려하지 않는 것이다.

개발속도
속도는 개발자가 얼마나 많은 작업을 처리할 수 있는지를 측정하고, 자신의 업무 예상치를 조절해서 앞으로의 일을 계획하기 위한 용도로 사용된다. 팀의 개발 속도가 감소할 경우, 팀 또는 프로젝트나 시스템에 문제가 있다는 것을 암시해주기 때문에 프로세스를 향상할 수 있는 조치를 취할 수 있다. 그런데 많은 조직에서는 ‘빨리 처리하는 것이 생산적이다’며, 심지어 팀원 간의 생산성을 비교하는 데 활용하기도 한다.

사이클 시간
새로운 제품을 개발하고 배포하는 데 걸리는 시간을 측정하는 것은 팀의 생산성에 관한 개요를 제공한다. 이를 토대로 개발 주기를 지연하게 하는 병목 현상과 유휴 시간을 최적화하는 것이 가장 이상적이다. 그러나 이 방식은 근시안을 갖게 만들고 일을 날림으로 하도록 만들 큰수가 있는데, 속도가 바로 보상으로 직결되기 때문이다.

코드 품질
제품 출시 이후 버그를 고치는 것은 초기 테스트나 개발 과정에서 수정하는 것보다 더 큰 비용이 든다. 그러므로 제품 개발 과정에서 코드 품질을 측정하는 다양한 방법들을 활용하는 것이 좋다. 그러나 코드 품질이 개발자의 생산성과 직접적인 상관관계가 없다는 것이 문제다. editor@itworld.co.kr 


2015.01.16

IDG 블로그 | 개발자의 생산성을 측정할 수 없는 5가지 이유

Java Everywhere | Techworld
우리는 누가 개발팀의 스타인지, 믿을만한 사람인지, 컴퓨터와 씨름하는지 잘 알고 있다. 누가 위에서 깨지는지도 말이다. 그러나 개발자가 일을 제대로 하고 있는지, 또는 빠르게 업무를 해내고 있는지를 정확하게 측정하거나 팀의 생산성을 비교 측정할 수 있는 확실한 방법은 없다.

블로거 짐 버드는 전통적인 방식으로는 ‘절대 불가능한 일’이라며, 사실상 개발자의 생산성을 정확하게 측정하는 방법이 없다고 주장했다. 버드는 개발자의 생산성을 계량화하고, 증명하기가 어려운 이유에 대해 설명했다.

코드 라인 수
버드는 코드 라인 수로 생산성을 측정하는 것에는 오류가 있다고 말하는데, 훌륭한 개발자들은 더 적은 코드로 더 많은 작업을 하기 위해 시간과 노력을 들이기 때문이다. 라인 수가 길다고 해서 생산성과 연결해서 생각하는 것은 오류를 범하는 일이다.

수익성
또한, 버드는 최종 결과물의 가치(수익을 낼 수 있는가, 혹은 비용을 절감할 수 있는가?)로 생산성을 측정하는 것도 잘못된 방법이라고 말한다. 이 측정 방식은 개발팀의 입력 품질과는 상관없이, 제품이나 서비스의 성공을 결정할 수 있는 무수히 많은 비즈니스 요인을 고려하지 않는 것이다.

개발속도
속도는 개발자가 얼마나 많은 작업을 처리할 수 있는지를 측정하고, 자신의 업무 예상치를 조절해서 앞으로의 일을 계획하기 위한 용도로 사용된다. 팀의 개발 속도가 감소할 경우, 팀 또는 프로젝트나 시스템에 문제가 있다는 것을 암시해주기 때문에 프로세스를 향상할 수 있는 조치를 취할 수 있다. 그런데 많은 조직에서는 ‘빨리 처리하는 것이 생산적이다’며, 심지어 팀원 간의 생산성을 비교하는 데 활용하기도 한다.

사이클 시간
새로운 제품을 개발하고 배포하는 데 걸리는 시간을 측정하는 것은 팀의 생산성에 관한 개요를 제공한다. 이를 토대로 개발 주기를 지연하게 하는 병목 현상과 유휴 시간을 최적화하는 것이 가장 이상적이다. 그러나 이 방식은 근시안을 갖게 만들고 일을 날림으로 하도록 만들 큰수가 있는데, 속도가 바로 보상으로 직결되기 때문이다.

코드 품질
제품 출시 이후 버그를 고치는 것은 초기 테스트나 개발 과정에서 수정하는 것보다 더 큰 비용이 든다. 그러므로 제품 개발 과정에서 코드 품질을 측정하는 다양한 방법들을 활용하는 것이 좋다. 그러나 코드 품질이 개발자의 생산성과 직접적인 상관관계가 없다는 것이 문제다. editor@itworld.co.kr 


X