소식

May 22, 2023

소프트웨어 개발자가 DORA 측정항목을 선호하는 이유

Dylan Etkin, InfoWorld | 기술자들이 분석하는 신기술 수년 동안 소프트웨어 엔지니어링 팀은 진정으로 도움이 되는 엄격한 지표를 통해 효율성을 측정하는 방법을 추구해 왔습니다.

Dylan Etkin, InfoWorld |

기술자들이 분석하는 신흥 기술

수년 동안 소프트웨어 엔지니어링 팀은 개발자가 감시당한다는 느낌을 받지 않으면서 실제로 개선에 도움이 되는 엄격한 측정 기준을 사용하여 효율성을 측정할 수 있는 방법을 추구해 왔습니다. 마침내 우리는 어딘가에 도착하고 있습니다.

모든 개발자는 역사적으로 업계에서 알려진 작성된 코드 줄이나 병합된 풀 요청 수와 같은 모호한 측정 항목을 기준으로 측정되는 어려움이나 잠재적인 어려움을 알고 있습니다. 그리고 엔지니어링 관리자라면 누구나 그러한 조치가 팀에 반발과 불신을 심어줄 수 있다는 것을 알고 있습니다.

그러나 이사회, 엔지니어링 리더, 개발자 모두가 프로세스가 제대로 작동하는지, 팀이 효율적인지, 어떻게 더 나은 결과를 얻을 수 있는지 알고 싶어할 때 수행 중인 작업을 측정할 수 있는 방법이 필요합니다.

이를 달성하기 위해 여러 가지 측정항목, 프레임워크 및 모범 사례가 등장했습니다. 필연적으로 어떤 사람들은 다른 사람들보다 더 잘합니다. 성배는 개발자가 이미 매일 사용하고 있는 도구와 시스템을 사용하여 작업을 측정하는 것입니다. DORA 지표는 이를 수행할 수 있으며 부분적으로 이것이 업계 표준이 되고 있는 이유이기도 합니다.

이에 대해 더 자세히 알아보겠습니다. 먼저 다른 유형의 측정항목을 이해해 보겠습니다.

Busyness 지표는 개발자가 얼마나 많은 흐름 시간을 가지고 있는지 측정하는 것으로 생각할 수 있습니다. 하루에 두세 번 흐름이 중단되면 작업을 완료하는 것이 거의 불가능하다는 것을 알 수 있습니다.

개발자의 시간을 보호하기 위해 HR 시스템 및 일정에 연결되는 전체 범주의 엔지니어링 효율성 도구가 개발되었습니다. 그들은 개발자가 따라야 할 컨텍스트 전환, 회의, 시간이 많이 걸리는 프로세스가 너무 많은지 평가하려고 합니다.

궁극적으로 이러한 측정항목은 코딩의 인간적인 측면을 살펴봄으로써 번아웃을 방지하려고 노력하며 이는 확실히 중요하지만 이러한 측정항목은 그다지 실행 가능하지 않습니다.

개발자가 너무 많은 회의에 참석하고 있다는 것을 알고 있다면 필요한 회의가 열리면서도 흐름도 더 효율적인 환경을 어떻게 구성합니까? 바쁜 정도 지표에는 안내할 수 있는 일련의 잠재적인 개선 사항이 포함되어 있지 않습니다.

DORA(DevOps Research Assessment)의 창립자 중 한 명인 Nicole Forsgren은 개발자 생산성을 이해하는 것을 목표로 하는 이 프레임워크를 개발했습니다. 그러나 SPACE 프레임워크는 엄격한 측정 기준보다는 개발자의 정신 상태와 신체적 웰빙에 중점을 두고 있습니다. 이는 개발자의 전반적인 작업 즐거움과 팀의 엔지니어링 성과에 중요한 요소입니다.

SPACE 프레임워크는 개발자 생산성의 5가지 차원을 측정합니다.

Busyness 지표와 마찬가지로 SPACE 프레임워크는 유효한 정보를 캡처하지만 조치를 취하기는 어렵습니다. 수행 중인 작업에서 측정하기 어려운 모범 사례라고 생각하세요. 간결함과 목표 지향적인 결과가 부족합니다.

이는 게임하기 쉽고 실제 개발자의 노력(예: 작성된 코드 줄, 병합된 끌어오기 요청 수, 코딩에 소요된 시간)을 포착하지 못하는 엄격한 측정값입니다. 이러한 조치는 최소한의 지침으로 작업을 수행한 개발자가 리더였던 펀치 카드 프로그래밍 시대에 나왔습니다.

그러나 개발자는 실제로 중요한 것을 측정하지 않는다는 것을 알고 있습니다. 애플리케이션에서 가장 중요한 다섯 줄의 코드를 작성할 수 있는데, 이 코드는 너무 복잡해서 그것이 올바른 다섯 줄의 코드인지 확인하는 데 2주가 걸릴 것입니다. 아니면 그다지 유용하지 않은 500만 줄의 코드를 작성할 수도 있습니다. 병합된 풀 요청 수를 측정하는 것과 동일합니다. 이를 통해 전체 배치 크기에 대해 어느 정도 알 수 있지만 팀 개선에 도움이 되는 통찰력이 있거나 유용하지는 않습니다.

이러한 조치를 기준으로 개발자를 판단하면 개발자는 귀하가 자신이나 작업을 이해하지 못한다는 것을 알게 될 것입니다. 게다가 이러한 것들을 개별적인 규모로 측정하는 것은 해롭습니다. 개발자들은 염탐당하고 판단받는다고 느낄 것이며, 발뒤꿈치를 파헤칠 것입니다.