http://stackoverflow.com/questions/1161059/problems-of-measuring-programmer-productivity


Ok, the question is usually, how can one measure a programmer's productivity.

But I want to put a slight twist on the question. How does one measure one's own productivity when coding? Do you measure yourselves by problems solved, questions answered versus asked, or the dreaded "lines of code"?

흠 나랑 비슷한 질문이다


The right measure is the accuracy of delivery vs. prediction. If you say that you will deliver X features by Y date at Z cost, the variance of actual X, Y, Z is what measures your quality as a programmer.

Whenever you make a commitment to someone, write it down, then go back and look at how accurate your commitments and estimates are. Refine your process to make them as realistic as possible.

shareimprove this answer
13 
In other words, to shine as a programmer, I always tell the boss it will take three times as much time and money as it should, and use the extra time to figure out how to make the project come out precisely when and for how much I said? – David Thornley Dec 4 '09 at 21:04
5 
Surely that's a measure of estimation rather than productivity... We use something similar and I'm not entirely happy that it encourages development activity. – pb. May 25 '11 at 16:46
1 
Is @DavidThornley's point not valid, OP? Care to address it? – event_jr Jan 1 '13 at 1:38
2 
This is a good criterion for freelance programmer. You know how much he's going to charge you, and you get exactly what you need. However, if you are working inside a company this criterion will just make you overestimate everything. – Alexey Apr 5 '15 at 12:21 



  • "WTFs per minute" of code review (one looks at a part of the code and doesn't get what it does)
  • bug count (time spent redoing stuff that should be done)
  • LOC (bad one, though)
  • test coverage (and quality, if possible)
  • client satisfaction (that's what brings more money long term, right?)




트위터에서 여러 개발자들에게 생산성 측정 방식을 물었다고 함
매우 다양하다는 것을 알 수 있다.
Takeaways

Quantitative measuring is available and necessary!

While we can debate which metrics are key indicators of developer performance, it’s tough to stand behind the argument that they shouldn’t be measured at all.

In the first article referenced above the author, Eric Elliott, shares his #1 method of measurement — Interviewing peers about how helpful and knowledgable a developer is… Now, his way may not be my first choice, but I do like his methodology. More importantly, though, I appreciate that he has a clear strategic way of measuring performance.

That is key to it all — have a method of measurement!

In order to do so, it’s important to understand the stage of your company. If you’re very early-stage with a short runway, then speed and tech debt may be key metrics. If you’re further along, test coverage and quality might be 1 & 2. Point being, know where you are as an organization, set a plan, implement a strategy and MEASURE YOUR DEVELOPERS’ PERFORMANCE!

The tools and metrics are available and they can and should be tracked. Determine which are the most important for moving your startup forward and begin measuring.

이건 나도 동의해서 갓글갓역기 번역도 붙인다

정량 측정이 가능하며 필요합니다!

어떤 측정 지표가 개발자 성과의 주요 지표인지에 대해서는 논쟁 할 수 있지만, 전혀 측정하지 말아야한다는 주장을 뒷받침하기는 어렵습니다.

위의 첫 번째 기사에서 Eric Elliott은 자신의 # 1 측정 방법을 공유합니다. 개발자가 얼마나 도움이되고 지식이 있는지에 대해 동료에게 인터뷰합니다. 이제 그의 방식이 내 첫 번째 선택이 아닐지 모르지만 그의 방법론을 좋아합니다. 더욱 중요한 것은 성능에 대한 명확한 전략적 방법이 있다는 점입니다.

그것이 모두에게 핵심입니다. 측정 방법이 있습니다!

그렇게하기 위해서는 회사의 무대를 이해하는 것이 중요합니다. 짧은 활주로로 매우 초기 단계에 있다면 속도와 기술 부채가 주요 척도가 될 수 있습니다. 더 나아가, 테스트 커버리지와 품질은 1 & 2 일 수 있습니다. 요점은, 당신이 조직으로서 어디에 있는지 알고, 계획을 수립하고, 전략을 구현하고, 개발자의 성과를 측정하십시오!



결론은... 생산성 측정을 일단 해보라고 하고 있다. 안 하는 것보다는 낫다고.

다양한 측정방식이 있고 회사나 상황마다 적절한 방식을 써야한다고 한다.


깃 커밋 히스토리를 이용한 측정

진행사항(요구사항-요구테스트)문서 변화를 이용한 측정(깃 이용)

테스트 커버리지를 이용한 측정

품질이 균일하다는 가정하의 대략적인 LOC 측정


이 정도가 내가 개인적으로 할 수 있는 측정일까...