특정 프로그래밍 언어, 도구 및 기술에 대한 실용적인 기술과 지식이 소프트웨어 개발자로서 정규직을 얻는 데 핵심이지만 여러 면에서 이 직업에서 성공의 전제로 볼 수 있는 또 다른 중요한 지표가 있습니다. 생산력. 생산성 측정은 오늘날의 비즈니스 환경에서 모든 소프트웨어 개발 팀에게 성능 메트릭이 본질적으로 중요하기 때문에 모든 전문 소프트웨어 개발자가 이해하고 고려해야 하는 것입니다.
개발자로서의 생산성이 중요한 이유는 무엇입니까?
애자일 개발, DevOps 및 단축된 소프트웨어 릴리스 주기의 시대에 개발자가 가능한 한 빨리 새 버전의 제품을 출시해야 할 때 기업은 여러 가지 생산성 지표를 사용하여 개별 프로그래머와 팀 전체의 성과를 평가합니다. 개발자의 관점에서 보면 성능 측정은 프로그래밍 기술의 진행 상황을 추적하는 데 도움이 되는 여러 가지 중요한 목적을 제공할 수 있으며 이를 통해 일관된 직업적 성장을 달성할 수 있습니다. 생산성이 높은 코더는 입이 떡 벌어지는 급여 제안을 받고 가장 흥미로운 프로젝트에 착수하는 사람들입니다. 그러나 당신이 그다지 높은 성취를 이룬 사람이 아니고 소프트웨어 개발 분야의 어떤 직업을 원하고 그 분야에서 합리적으로 성공하기를 원한다고 해도, 성과 지표에 대한 최소한의 기본적인 이해와 직장에서 입력의 생산성을 측정하는 데 어떻게 사용되는지는 여전히 알고 있어야 합니다. 이것이 오늘 우리가 이야기할 내용입니다.
소프트웨어 개발 생산성 측정 지표
소프트웨어 개발 생산성 지표란 무엇입니까?
소프트웨어 개발 메트릭은 개발자의 성능, 작업 품질 및 생산성을 추적하기 위해 정량적 측정을 적용할 수 있는 프로그래밍 작업 영역입니다. 모든 생산성 지표는 개발 프로세스에서 가져온 데이터를 기반으로 하며 이를 사용하여 생산성을 측정합니다. 소프트웨어 개발과 관련된 거의 모든 것이 쉽고 간단하기 때문에 프로그래밍 생산성 측정도 상당히 일관성이 없고 업계 전반에 걸쳐 파편화되어 있다고 말할 수 있습니다. 또는 간단히 말해서 다양한 팀과 회사가 완전히 다른 성과 지표를 사용하고 여러 각도에서 이 문제에 접근할 수 있습니다. 따라서 소프트웨어 개발 팀에서 사용할 수 있는 모든 메트릭을 일일이 학습할 필요가 없습니다.
어떤 유형의 소프트웨어 개발 생산성 지표가 있습니까?
당연히 다양한 수준과 각도에서 측정 성능에 접근하는 다양한 생산성 지표가 있습니다. 다음은 이러한 생산성 메트릭의 가장 일반적인 유형입니다.
공식적인 크기 중심 메트릭.
이러한 메트릭은 코드 라인(LOC), 코드 명령 길이, 코드 복잡성 등과 같은 프로그래머의 작업 결과 크기를 측정하는 데 중점을 둡니다. 이러한 메트릭은 오늘날의 소프트웨어 개발 산업에서 점점 구식으로 간주됩니다.
시간 및 기능 중심의 생산성 지표.
활성 날짜, 일정 기간 동안 배송된 기능 범위, 코드 변동률, 할당된 작업 수 등과 같이 폭포수 소프트웨어 개발에 사용되는 기존의 생산성 메트릭이 있습니다.
애자일 개발 프로세스 지표.
스프린트 번다운 보고서, 속도, 리드 타임, 주기 시간 등과 같은 애자일 개발 프로세스 메트릭은 아마도 오늘날 소프트웨어 개발 팀에서 가장 일반적으로 사용되는 메트릭일 것입니다. Agile 메트릭에 대해서는 이 기사 뒷부분에서 자세히 설명합니다.
운영 분석 지표.
이 메트릭 세트는 현재 프로덕션 환경에서 소프트웨어 성능을 측정하는 데 중점을 둡니다. MTBF(Mean Time Between Failures), MTTR(Mean Time to Recovery) 및 애플리케이션 크래시 비율이 여기에서 가장 많이 사용되는 지표입니다.
측정항목을 테스트합니다.
소프트웨어 테스팅에는 자동화된 테스트의 비율, 코드 적용 범위 등과 같은 시스템 테스팅의 품질을 측정하기 위한 자체 메트릭 세트가 있습니다.
고객 만족도 지표.
마지막으로 모든 소프트웨어의 궁극적인 지표는 최종 고객 경험이며 CES(Customer Effort Score), CSAT(Customer Satisfaction Score), NPS(Net Promoter Score)와 같은 전체적인 지표도 있습니다. 다른 사람.
애자일 소프트웨어 개발 지표
보시다시피 소프트웨어 생산성 메트릭의 모든 복잡한 내용에서 길을 잃기 쉽습니다. 그러나 일반 소프트웨어 개발자가 잘 알고 있어야 하는 유일한 것은 소프트웨어 개발 수명 주기의 여러 부분에서 팀 생산성 측정의 표준으로 오늘날 소프트웨어 개발 팀에서 일반적으로 사용하는 Agile 메트릭입니다. 주요하고 가장 일반적으로 사용되는 Agile 메트릭을 나열해 보겠습니다.
1. 스프린트 번다운.
Sprint Burndown 보고서는 애자일 스크럼 개발 팀의 주요 지표 중 하나입니다. Agile에서 개발 프로세스는 시간 제한이 있는 스프린트를 통해 구성되므로 스프린트 번다운은 스프린트 중에 작업 완료를 추적하는 방법으로 사용됩니다. 시간 또는 스토리 포인트가 측정 단위로 사용됩니다. 목표는 일관된 진행을 달성하고 초기 계획에 따라 작업을 제공하는 것입니다. Sprint Burndown은 팀이 작업 속도를 측정하고 필요할 때 조정할 수 있도록 도와줍니다.
2. 팀 속도.
속도는 시간 또는 스토리 포인트를 측정 단위로 기반으로 하는 또 다른 주요 지표입니다. 스프린트 동안 팀이 완료하는 평균 작업량을 측정하고 전체 프로젝트에서 추정 및 계획에 사용됩니다. 추적 속도는 팀이 일관된 성능을 제공하는지 확인하는 데 중요합니다.
3. 스토리 포인트.
개별 개발 팀원의 수준에서 프로그래머가 각 릴리스 동안 전달하는 스토리의 크기는 이 코더의 생산성을 나타내는 지표이기 때문에 스토리 포인트는 귀중한 메트릭입니다.
4. 사이클 제어 차트.
작업 또는 다른 백로그 항목에 대한 작업이 시작된 순간부터 완료될 때까지의 총 시간을 측정합니다. 보다 예측 가능한 결과를 제공하는 주기 시간을 추적하고 제어할 수 있습니다.
5. 제공되는 처리량 및 가치.
프로젝트 관리자는 개발자에게 할당된 작업을 분석하고 가치를 할당합니다. 그런 다음 이 메트릭을 사용하여 팀의 처리량, 즉 수행된 부가가치 작업의 양을 측정합니다.
6. 코드 변동.
코드 변동은 팀 전체의 생산성을 측정하고 개별 프로그래머의 성과를 추적하는 데 사용되므로 언급할 가치가 있는 또 다른 메트릭입니다. 코드 변동은 개발자가 이전에 추가한 코드 줄을 얼마나 자주 제거하거나 변경하는지, 이전에 작성된 코드 중 몇 퍼센트가 변경되거나 버려지는지를 측정합니다.
전문가 의견
마지막으로, 몇 가지 관점을 추가하기 위해 경험 많은 소프트웨어 개발 업계 전문가가 문제에 대해 몇 가지 인용합니다. “나는 당신이 어떤 종류의 표준이나 심지어 다른 회사의 다른 팀의 성과와도 당신의 메트릭을 "비교"하려고 하지 않기를 바랍니다. 내가 일한 모든 곳에서 스토리 포인트, 속도, 시간당 견적, 작업 등의 정의에 고유한 변형이 있어 한 회사의 한 팀의 성과를 다른 회사의 다른 팀의 성과와 직접 비교하는 것이 거의 불가능했습니다. 전 기술 제품 관리자이자 애자일 코치인 Cliff Gilley는 다음과 같이 말했습니다 .. “저는 팀 성과를 이끌어가는 데 있어서 측정 기준에 대해 조금은 조심스럽습니다. 하나 또는 두 개의 변수에만 주의를 기울이면 (의도적으로든 아니든) 메트릭 게임에 빠지기 매우 쉬워지고 메트릭을 개선하는 것뿐인데 자신이 개선되고 있다고 속이기 쉽습니다. 예를 들어 속도를 기반으로 하는 메트릭은 팀이 더 작은 스토리로 이동하여 "개선"될 수 있습니다(스토리당 작업 감소 - 더 많은 스토리 완료 - 속도 증가). 스토리가 비즈니스 가치의 작은 증분을 제공하는 유용한 사용자 스토리라면 좋은 일이 될 수 있습니다. 스토리 자체가 실제 가치를 제공하지 않는 더 작아지고 더 "기술적인" 작업이 되면 좋지 않을 수 있습니다.”라고 또 다른 업계 전문가인 Adrian Howard는 말했습니다 .. “풀 기반 시스템에서 작업할 때 처리량과 주기 시간을 중요하게 생각합니다. 첫 번째는 우리 팀의 역량에 대한 일반적인 정보를 제공하며 시간이 지남에 따라 매우 강력한 예측 척도가 될 수 있습니다. 두 번째는 파이프라인 효율성의 일반적인 척도로 유용합니다. 주기 시간이 길면 파이프라인을 살펴보기 시작할 때입니다. 완화/이용을 위해 작업할 수 있는 제약이 있기 때문입니다. 그러나 메트릭은 도구일 뿐입니다. 그것들에서 길을 잃지 말고 확실히 특정 메트릭을 향한 계획을 시작하지 마십시오. 팀으로 무엇을 만들고 있는지, 어떻게 자연스럽게 일하는지 생각한 다음 사람들을 중심으로 시스템을 구축하십시오. 메트릭은 시스템이 모든 사람의 작업을 어떻게 지원하는지 확인하는 데 도움이 됩니다. 그렇지 않으면.” 비디오 게임 개발 프로듀서인 Dave Cerra가 결론을 내렸습니다 .
