개발자 생산성 - 측정 방법

인간은 본질적으로 인지 구두쇠이며 최소한의 노력으로 가장 간단한 방법으로 복잡한 문제를 해결하는 경향이 있습니다. 이것이 바로 우리가 가능한 가장 간단한 방법을 사용하여 "개발자 생산성"을 측정해 온 방법입니다.

'개발자 생산성'이라는 말을 들으면 가장 먼저 무엇이 떠오르시나요?

나는 이것이 부정적인 것이라고 확신하며 리더들은 이 문제에 대해 이야기하면 팀이 세세하게 관리되고 있거나 신뢰가 부족하다고 생각하게 될 것이라고 종종 걱정하기 때문에 이것이 개발 팀에서는 거의 금기시된다는 데 의심의 여지가 없습니다. 두 가지 이유:

1. 개발자의 생산성이 엔지니어링 리더에 의해 남용되고 있습니다.

2. "개발자 생산성"은 공식이 아니며 우리는 불확실성 속에서 성공하지 않기 때문에 가장 쉬운 길을 택하거나 멀리하는 것을 선택합니다.

생각해 보십시오. 개발자 생산성을 측정하는 일률적인 방법이 있다면 여전히 미스터리일까요? 아니면 이 블로그를 읽을 것인가?

PS: 가장 생산적인 개발자를 측정하거나 개발자를 승진시키고 해고하는 데 도움이 되는 숫자를 얻으려는 의도로 이 블로그를 읽고 있다면 실망할 것이기 때문에 돌아서십시오.

그렇다면 개발자 생산성을 측정해 볼까요?

네, 맞습니다! ! 개발자 생산성은 엔지니어링 결과를 향상시키는 것뿐만 아니라 팀의 만족도와 복지를 보장하는 것이기도 합니다. 종종 생산성 지표는 개발 프로세스의 병목 현상과 팀의 작업 환경 및 문화 문제를 식별하는 데 도움이 됩니다.

가장 성공적인 농구 코치 중 한 명인 필 잭슨(Phil Jackson)은 다음과 같이 아름답게 말했습니다.

“팀의 힘은 각 멤버의 힘입니다. — 필· 잭슨

In 개발 팀의 맥락에서 모든 팀의 성공은 각 개발자가 최선을 다하고 팀의 성공에 지속적으로 기여하는 데 달려 있습니다.

자, 이제 개발자 생산성을 어떻게 측정해야 할까요?

개발자 생산성 측정의 성공 가능성을 극대화하기 위한 두 가지 기본 요소입니다.

1. 생산성을 단일 지표로 축소하지 마세요

개발자 생산성을 측정하는 것은 논리적이고 창의적인 작업에 관련된 사람을 측정하려고 하기 때문에 어렵습니다. 그리고 우리는 인지 구두쇠로서 생산성을 측정 기준으로 축소하려고 노력합니다. 분명히 말씀드리자면 이 모델은 실패할 것입니다.

대신, 여러 차원에서 생산성을 포착하고 SPACE 프레임워크(S-만족도 및 행복, P-성과, A-활동, C-커뮤니케이션 및 협업, E-효율성 및 프로세스)와 같은 것을 활용하여 개발자 팀이 측정하는 데 도움이 될 수 있습니다. 올바른 방법으로 개발자 생산성을 높이세요.

2. 팀과 소통하세요

매우 흔한 오해가 있습니다. 개발자 생산성은 관리자에게만 적합합니다. 이것은 진실과 더 이상 다를 수 없습니다. 연구에 따르면 개발자 생산성에 대한 개발자와 관리자의 인식에는 상당한 차이가 있는 것으로 나타났습니다. 대부분의 개발자는 더 높은 생산성을 더 높은 활동과 연관시키는 반면, 대부분의 관리자는 생산성을 성과 및 효율성과 연관시킵니다.

이러한 뚜렷한 인식 차이는 개발 팀이 생산성의 의미와 생산성 추적에 대한 진정한 의도가 무엇인지에 대해 소통할 때만 제거될 수 있습니다. 이는 이것이 중요한 이유와 이를 측정하는 방법을 명확히 하는 데 도움이 되며 대부분의 개발 팀이 가지고 있는 의구심을 제거합니다. 이것이 우리의 평가를 결정하는 숫자입니까? 아니면 경영진이 우리가 일을 완수할 수 있다고 믿지 않기 때문에 이 일을 하고 있는 걸까요?

할 일

1. SPACE 프레임워크를 사용하여 여러 차원에 걸쳐 개발자 생산성을 추적하세요.
2. 팀 전체에 의도를 전달하세요.
3. 생산성 지표를 사용하여 개선이 필요한 영역을 식별하고 병목 현상을 제거하세요.

하지 말아야 할 일

1. 생산성을 단일 지표로 줄이세요.
2. 생산성을 추적하기 위한 비밀 조치를 개발하세요.
3. 측정항목을 평가를 결정하는 유일한 측정항목으로 사용하세요.

개발자 생산성 지표

이제 공간적 측면에서 추적된 몇 가지 개발자 생산성 지표를 살펴보겠습니다.

개발자 생산성 지표:

만족도와 행복

만족도가 높은 팀은 생산성도 높은 팀입니다. 이는 건강한 팀과 업무 문화를 나타내는 가장 큰 지표 중 하나입니다. 그러나 만족은 추상적인 개념이므로 누군가가 "얼마나 만족하십니까?"라고 묻는다면 측정은 잊어버리세요. 나는 당신이 이 질문에 답하기 전에 몇 분 동안 만족이 당신에게 어떤 의미인지, 그리고 이를 어떻게 정량화할지 생각해 볼 것이라고 확신합니다. 우리는 이 측면을 수치적으로 포착하는 것이 매우 어렵다는 것을 알고 있습니다. 여기서 볼 수 있는 것은 개발자 만족도와 행복의 다양한 측면을 가장 잘 포착하려는 프록시 측정항목입니다.

• 작업 완료: 작업을 완료할 때마다 우리의 뇌는 도파민을 방출하여 작업이 완료된 후 즉시 만족감과 의욕을 느끼게 합니다. 따라서 약속한 작업에 비해 높은 작업 완료율은 약속된 작업을 적시에 완료하고 팀의 성공에 기여할 수 있어 개발자에게 큰 만족감을 느끼게 할 것입니다.
• 초과 근무: 초과 근무 ≠ 더 높은 생산성, 사실 그 반대입니다. 초과 근무는 개발자의 피로를 유발하는 가장 큰 원인 중 하나이며 개발자의 행복에 해를 끼칩니다. 주말이나 심야 등 추가 근무 시간을 추적하면 개발자가 현재 작업 환경에서 만족하고 성과를 내고 있는지 이해하는 데 도움이 될 수 있습니다.
  • 비즈니스는 성취를 위한 수단이 아니라 성취를 가로막는 장애물입니다
    - Alex Soojung-KPang
    
• Disengagement: 불만족과 탈진의 가장 일반적인 지표는 팀과 팀 활동에서 이탈하는 것입니다. 개발자 참여를 측정하는 한 가지 방법은 코드 검토와 같은 팀 활동에 대한 개발자의 일반적인 응답 시간의 변화, 상호 작용이나 팀 회의 참석 감소를 측정하는 것입니다.
• 개발자 설문조사: 최고의 생산성 지표를 결정할 때 가장 확실한 방법, 즉 개발자 만족도 설문조사를 실행하고 분석하여 팀에 질문을 던지고 팀의 정서를 이해하는 것인 경우가 많습니다. "만족하시나요?"와 같은 질문을 해보세요. (등급 1-5)"는 이를 이해하는 최악의 방법입니다. 그러나 다양한 방식과 차원에서 유사한 정보를 포착하는 데 도움이 될 수 있는 다른 질문이 있을 수 있습니다.
• 임기: 팀 전체의 만족도를 추적할 수 있는 좋은 방법입니다. 개발팀 구성원의 평균 재직 기간을 볼 수 있습니다. 개발자 동향의 특성을 고려할 때 적절한 재임 기간은 12개월에서 18개월 사이일 수 있습니다. 더 낮은 기간은 성과를 측정하는 가장 좋은 방법입니다. 개발자와 개발팀의 목표는 결과보다는 결과를 측정하는 것입니다. 이러한 지표는 개발자가 수행한 작업의 품질 측면을 파악하는 데 도움이 됩니다. 모든 개발자에게 이상적인 결과는 최소한의 개발 재작업을 보장하고 고객 만족도를 최대화하는 것입니다.

재작업: 개발자가 끌어오기 요청을 수정해야 하거나 버그 수정을 위해 QA에서 개발자에게 작업이 반환되는 경우가 많습니다. 이는 수행된 작업이 명확하게 표시됩니다. 작업 품질이 예상 표준에 미치지 못하는 경우가 반복적으로 발생합니다. 기능 개발 주기는 결국 연장됩니다. 수정이 전혀 필요하지 않으며 요구 사항 변경으로 인해 재작업이 발생하는 경우가 많습니다. 그러나 개발자가 동일한 팀 제약 사항에 직면하면 다른 사람보다 문제가 많이 발생합니다.

적시 배송: 모든 엔지니어링 및 비즈니스 리더가 관심을 갖는 결과 중 하나는 배송의 예측 가능성입니다. 다른 많은 비즈니스 결정이 고객에게 전달되는 경우가 많기 때문입니다. 엔지니어링 프로세스 전반에 걸쳐 예측 가능성을 가지려면 각 개발자가 이러한 품질을 흡수하는 것이 절대적으로 중요합니다. 이를 측정하는 한 가지 방법은 개발 스프린트/반복 중에 개발자가 수행하는 작업을 살펴보는 것입니다.

고객 만족도. : 이는 모든 조직에 가치를 제공하는 가장 중요한 결과라는 점에 동의하므로 개발팀에게도 동일해야 합니다. 고객 만족은 API 서비스의 가동 시간이 더 높거나 앱 스토어 댓글에 더 나은 결과를 의미할 수 있습니다. 응답 시간이 더 빠르거나 플랫폼 팀의 경우 다른 팀에서 사용하는 내부 라이브러리가 더 사용하기 쉽고 고객 만족에도 불구하고 보고된 버그가 최소화될 수 있습니다. 개발팀은 자신이 제작 중인 제품의 실제 사용자와 접촉하여 올바른 일에 집중할 수 있도록 돕습니다.

• Activity
• 활동 차원 자체는 추적하기 가장 쉬운 차원이기 때문에 개발자 생산성과 대체로 동일합니다. SDLC 프로세스의 다양한 영역에서 활동 지표를 추적하면 실제 개발자 병목 현상과 개선 영역을 식별하는 데 도움이 됩니다
• .
  • 해결된 작업: 이 단계의 활동은 개발자가 개발 작업에 얼마나 자주, 어느 정도 기여하는지 결정하는 데 도움이 됩니다. 개발 작업은 항상 프로젝트 관리 도구의 작업, 사용자 스토리 또는 하위 작업으로 계획되므로 해결된 전체 작업을 살펴보면 개발 주기의 이 부분에 개발자가 참여하는 것을 이해하는 데 도움이 될 수 있습니다.
  • 풀 요청 검토: 일반적으로 기술 책임자나 개발 팀의 관리자만이 변경/풀 요청을 검토할 책임이 있으며 이는 명백한 안티 패턴입니다. 각 개발자가 동료의 코드를 점점 더 많이 검토하도록 장려하면 검토 병목 현상을 제거하는 데 도움이 됩니다. 이 지표는 개발자가 팀의 검토 부하에 기여하고 있는지 확인하는 좋은 방법입니다.
  • 배포 빈도: 팀이 프로덕션 시스템에 변경 사항을 배포하는 횟수는 개발 프로세스의 속도 측면을 이해하는 데 도움이 될 수 있습니다. 이는 또한 DORA 지표 중 하나이며, 연구에 따르면 고객 만족도는 물론 조직의 수익성과도 높은 상관관계가 있어 개발 팀의 생산성 활동 차원을 추적하는 데 탁월한 척도가 됩니다.

  COMMUNICATION & COLLABORATION

  모든 개발팀에서 최종 제품(기능, 서비스, 애플리케이션 또는 개선 사항 등)은 항상 팀 노력의 결과입니다. 원활한 의사소통과 협업은 효율적인 개발팀을 구축하기 위한 기반입니다. 개발자 생산성을 측정할 때 이 차원을 포함하면 투명성과 정보 공유 문화를 촉진할 수 있습니다. 이를 포착하는 데 도움이 되는 몇 가지 생산성 지표는 다음과 같습니다.

  • PR 대기 시간 및 주기 시간: 개발 팀의 협업이 원활하다면 이는 개발 프로세스에서 가장 병목 현상이 될 가능성이 높기 때문에 검토 프로세스에 명확하게 반영될 수 있습니다. 기여자와 리뷰어 사이의 효과적인 의사소통이 중요하며, 그 반대의 경우도 마찬가지입니다. 개발자가 얼마나 협력하고 있는지 추적하는 데 도움이 되는 측정항목은 해당 개발자가 할당된 풀 요청 검토를 시작하는 데 걸리는 시간을 측정합니다. 다음으로, 끌어오기 요청의 평균 주기 시간을 측정하면 기여자의 의사소통 기술을 이해하는 데 도움이 될 수 있습니다.
  • 함께 일하는 구성원 수: 개발 팀에는 지식 사일로와 나머지 팀 구성원과는 상호 작용하지 않고 서로만 상호 작용하는 개발자 그룹이 있는 경우가 많습니다. 이는 또 다른 고전적인 반패턴입니다. 개발자가 다른 팀 구성원과 얼마나 잘 소통하고 소통하는지 측정하는 것은 이 차원을 측정하는 좋은 방법입니다.
  • 신규 구성원 온보딩 시간: 새로운 개발자가 팀에 합류할 때마다 초기 학습 곡선을 거치고, 비즈니스 환경을 이해하고, 기술 스택에 익숙해지고, 일반적으로 코드 연습에 대한 도움을 받습니다. 개발자가 합류한 후 처음으로 영향력 있는 변경을 수행하는 데 걸리는 시간은 개발 팀 커뮤니케이션을 위한 중요한 생산성 지표입니다. 좋은 문서화 관행을 갖춘 팀으로서, 새로운 개발자를 돕기 위해 기꺼이 노력하는 개발자는 새로운 개발자가 가능한 한 빨리 영향력 있는 변경을 수행할 수 있도록 할 것입니다. 노력해야 할 좋은 벤치마크는 처음 30일 이내에 새로운 개발자의 첫 번째 생산적인 결과입니다.

  효율성과 프로세스

  개발자들이 자주 이야기하는 '프로세스 진입' 차원입니다. 여기서 측정항목은 개발 주기에 얼마나 많은 중단이 발생하는지, 작업이 처음부터 끝까지 얼마나 원활하게 진행되는지 이해하는 데 도움이 됩니다. 빈번한 중단은 개발자 생산성에 영향을 미칠 뿐만 아니라 스트레스와 피로 수준을 높일 수도 있습니다.

  • 중단 없는 개발 시간: 개발자가 프로세스에 참여하고 개발 활동에 시간을 투자할 수 있도록 매일 충분한 중단 없는 시간을 갖는 것이 절대적으로 중요합니다. 가장 큰 장애물 중 하나는 팀 회의입니다. 더 긴 개발 시간을 장려하기 위해 팀에서는 회의가 없는 근무일을 채택하거나 팀 회의 일정을 잡을 수 있는 엄격한 시간표를 채택하는 경우가 많습니다. 중단 없이 개발 시간이 길어진다고 해서 반드시 개발자 생산성이 높아지는 것은 아닙니다. 그러나 개발자에게 중단 없는 시간이 충분하지 않으면 개발에 필요한 프로세스를 달성할 수 없다는 것은 확실합니다.
  • 커밋 리드 타임: 개발 주기가 더 많이 중단되고, 더 많은 핸드오프가 발생하고, 작업이 너무 자주 다시 열리면 개발 작업 효율성과 흐름이 좋지 않다는 지표입니다. 커밋 리드 타임은 변경 사항이 최종 사용자에게 영향을 미치는 데 걸리는 총 시간을 측정하므로 이를 정확하게 포착합니다. 상대적으로 높은 커밋 리드 타임(CLT)은 확실히 개발 팀의 효율성과 흐름이 감소한다는 것을 의미합니다. CLT는 DORA 지표 중 하나입니다. 이에 대한 자세한 내용은 여기에서 확인할 수 있습니다.
  • 평균 WIP(Work-In-Progress) 티켓: 컨텍스트 전환은 확실히 생산성을 저하시킵니다. 동시에 더 많은 일을 한다는 것은 항상 모든 일을 완료하는 데 더 많은 시간이 필요하다는 것을 의미하며 불필요한 정신적 피로를 초래할 수도 있습니다.
    • 두 가지 병렬 작업 — 컨텍스트 전환으로 인해 20% 손실.
    • 세 가지 병렬 작업 — 컨텍스트 전환으로 인해 40%가 손실되었습니다.
    • — 제럴드 M. 와인버그

WIP 티켓은 개발자가 동시에 진행 중인 작업 수를 완벽하게 기록합니다. 이 생산성 지표를 추적하고 이를 세 가지 작업 미만으로 유지하는 것은 개발 팀에게 좋은 시작 방법입니다.

Change Engagement

개발자 생산성을 높이는 지표를 살펴보면 변화를 주도하는 데 도움이 되는 조치는 개발 프로세스의 변화일 것입니다. 팀이 추진하는 변화에 대한 개발자 참여를 측정하면 팀의 프로세스를 수정하기 위해 각 개인이 쏟는 노력을 이해하는 데 도움이 됩니다. 각 프로세스 변경에는 프로세스가 얼마나 잘 준수되고 있는지를 포착하는 관련 측정항목이 있을 수 있으며, 이러한 측정항목을 추적하는 순위표는 어떤 개발자가 프로세스 변경 계획에 잘 기여하고 있는지 게임화하고 이해하는 데 도움이 될 수 있습니다.

여러분입니다!

개발자 생산성은 실제로 중요한 지표보다는 단일 지표 또는 추적하기 쉬운 지표로 오해되는 경우가 많습니다. 개발자 생산성을 추적하고 SPACE와 같은 프레임워크에서 영감을 얻어 개발자 생산성 향상을 위한 전체적인 접근 방식을 취하는 것이 절대적으로 중요합니다. 몇 가지 지표로 시작하는 것이 가장 좋지만, 최소한 3가지 차원에 따라 이러한 지표를 선택하는 것이 중요합니다. 우리는 차원의 전체 목록과 각 차원 내의 많은 지표에 대해 논의했습니다. 이제 귀하와 귀하의 팀은 가장 영향력 있는 올바른 차원과 올바른 지표를 파악해야 합니다.

위 내용은 개발자 생산성 - 측정 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!