소프트웨어 제공 시스템 측정하기

내려야 할 결정에서 시작하세요

한 팀이 AI가 소프트웨어 제공을 개선하는지 알고 싶어 합니다. 생성된 코드 줄 수를 세는 것은 다른 질문에 답합니다. 지표를 선택하기 전에 유용한 결과와 품질 조건을 정하세요.

가상의 내보내기 서비스에서 원하는 결과는 더 적은 총노력으로 수락된 변경을 안정적으로 제공하는 것입니다. 준비, 구현, 검토, 수정, 대기를 기록하세요. 실패하거나 포기한 변경도 포함하세요.

경계가 명확한 서비스 하나를 사용하세요. 실험용 웹사이트와 핵심 결제 서비스를 합치면 어느 쪽도 설명하지 못하는 숫자가 나올 수 있습니다. 기간이나 팀을 비교하기 전에 맥락을 설명하세요.

현재 정의를 사용하세요

DORA의 현재 소프트웨어 제공 모델에는 지표 다섯 가지가 있습니다. 지표의 범위는 소프트웨어 제공 성과이며, 모든 기능의 가치나 개인의 기여가 아닙니다. DORA 지표 정의.

대시보드는 다른 정의를 사용할 수 있습니다. 결과를 해석하기 전에 정의를 읽으세요. Taiga의 현재 배포 문서는 제공자의 배포 기록에서 산출하는 네 가지 지표를 설명합니다. 복구 지표는 이후의 성공한 배포를 사용합니다. 모든 프로덕션 사고의 완전한 기록은 아닙니다. Taiga 정의.

가상의 변경 순서를 살펴보세요

서비스가 한 달에 배포 열두 번을 수행한다고 가정해 보세요. 여덟 번은 계획된 변경을 제공하고 네 번은 이전 릴리스의 문제를 수정합니다. 총수는 열두 번이지만 구성이 중요합니다.

다음 달에는 배포 열 번을 수행합니다. 계획된 변경 아홉 번과 수정 한 번입니다. 배포 수가 줄어도 유용한 작업은 늘 수 있습니다. 이 수치는 해석의 예시이지 성과 기준이 아닙니다.

분포도 살펴보세요. 한 번의 긴 검토 대기는 평균 안에서 사라질 수 있습니다. 실패 한 건에서 얻은 복구 지표는 미래 신뢰성에 대한 약한 증거입니다. 관찰 수와 중요한 예외를 보고하세요.

흐름과 결과를 함께 살펴보세요

서비스 신호로 제공 방식의 변경이 사용자에게 영향을 주는지 확인하세요. 내보내기 실패가 더 잦아진다면 파이프라인이 빨라지는 것만으로 충분하지 않습니다. 적절한 SLO나 명확히 정의된 다른 결과 지표를 사용하세요. SLO 지침.

검토 노력과 재작업은 결과를 설명하는 데 도움이 됩니다. AI가 구현을 단축해도 큰 diff를 만들면 검토가 제약이 될 수 있습니다. 환경을 확보하는 데 며칠이 걸린다면 코딩이 빨라져도 전체 제공 시간에는 영향이 작을 수 있습니다.

관찰한 제약을 해결하는 개선책 하나를 선택하세요. 예를 들어 지원되는 테스트 환경을 제공하거나 변경 크기를 줄일 수 있습니다. 검사가 약해져서 속도가 빨라진 것처럼 보이는 상황을 탐지할 수 있도록 품질을 함께 확인하는 지표를 정하세요.

측정을 유용하게 유지하세요

PR 수나 생성 코드로 개인의 순위를 매기지 마세요. 이런 지표는 작업을 인위적으로 나누거나 어려운 유지보수를 피하거나 동료에게 검토 노력을 넘기는 행동을 보상할 수 있습니다.

전체 서비스를 책임지는 사람들과 결과를 검토하세요. 도구, 작업 구성, 팀, 환경에서 무엇이 바뀌었는지 기록하세요. 전후 비교는 한계가 있는 증거로 다루세요. 자동으로 인과관계가 입증되는 것은 아닙니다.

목적은 더 나은 다음 결정입니다. 검증된 개선으로 이어지는 작고 신뢰할 수 있는 측정이, 의미에 합의하지 않은 큰 대시보드보다 유용합니다.

변경 열 개로 연습하세요

아래의 별도 가상 데이터셋은 계획된 변경 열 개를 기록합니다. 모든 시각은 표시된 날짜의 UTC입니다. 수정 열이 비어 있으면 이 데이터셋에는 수정이 기록되지 않았다는 뜻입니다.

코드 준비부터 검토 시작까지의 시간과 수락부터 릴리스까지의 시간을 비교하세요. 관찰할 수 있는 가장 긴 대기를 찾으세요. 피할 수 있는 대기라고 단정하기 전에 원인을 조사하세요. 이 시각은 실제 작업 노력을 측정하거나 사고 시작 시점을 알려 주지 않습니다. 수정 릴리스만으로 실패한 배포의 복구 시간을 알 수는 없습니다.

가상 데이터셋 다운로드(CSV)