엔지니어링 생산성을 측정하는 것은 복잡한 프로세스입니다. 개발자가 시간을 어떻게 소비하는지 전체적으로 파악하기는 어렵습니다. 생산성을 측정하는 일반적인 방법은 DORA 또는 SPACE와 같은 시스템 지표를 분석하는 것입니다. 이는 업계 표준과 비교하여 팀의 생산성을 이해하는 데 매우 유용한 측정항목이 될 수 있습니다. 각 측정항목을 자세히 살펴보면 팀 속도를 저하시키는 원인에 대한 통찰력을 얻을 수도 있습니다. 그러나 때로는 개발자가 하루 종일 사용하는 "숨겨진 시간"이 생산성에 영향을 미치는 것으로 인식되지 않는 경우도 있습니다. 그러나 이러한 사항을 합산하기 시작하면 그 숫자가 놀라울 수 있습니다. 예를 들어, 개발자가 변경으로 인해 실패했는지 여부를 파악하기 위해 불안정한 테스트를 디버깅하는 데 소요되는 시간을 생각해 보세요. 또는 메인라인 빌드 실패를 해결하려고 노력하는 개발자가 소비한 시간입니다. 이러한 관점을 제공하기 위해 우리는 엔지니어링 효율성을 평가할 수 있는 계산기를 만들었습니다. 이는 결코 엔지니어링 팀의 효율성에 대한 완전한 분석을 제공하지 않습니다. 이것이 제공하는 것은 일반적으로 더 일반적인 생산성 지표에서는 나타나지 않는 낭비되는 시간의 "숨겨진 주머니"를 엿볼 수 있다는 것입니다. 계산기는 개발자 워크플로의 빌드 및 테스트 실패로 인해 귀하와 귀하의 팀이 낭비하는 시간에 중점을 둡니다. 이를 DORA 지표와 비교하면 변경 리드 타임은 빌드 및 테스트 불안정성에 크게 영향을 받습니다. 이 계산기를 사용하여 그 영향을 평가할 수 있습니다. 작동 원리 귀하의 GitHub 활동과 GitHub 브랜치 사용 방법을 기반으로 데이터를 입력해 주시기 바랍니다. 아래의 실제 계산을 설명하기 위해 각각에 변수를 할당해 보겠습니다. M – 하루에 병합되는 PR X – 일주일 내 주요 라인 장애 T – 평균 CI 시간 F – 벗겨짐 계수 % 이러한 입력을 기반으로 엔지니어링 팀이 빌드 실패를 관리하고 불안정한 테스트를 처리하는 데 매주 얼마나 많은 시간을 낭비하는지 추정합니다. 결과를 하나씩 살펴보겠습니다. 문제를 해결하는 데 낭비되는 시간 이는 메인라인 빌드 실패가 감지되었을 때 빌드를 식별하고 분류하고 수정하고 다시 통과시키는 데 낭비되는 시간을 계산합니다. 일반적으로 대규모 팀에서는 누군가가 손상된 메인라인 빌드를 발견하고 보고합니다. 메인라인 빌드 실패에는 평균 1~3명의 개발자가 디버그하고 수정해야 한다고 가정합니다. 문제가 보고되고 수정 사항이 푸시되는 데 걸리는 시간을 평균 1시간으로 생각하면 문제를 추적하고 조사하고 해결하는 데 소요됩니다. (2*T + 1)시간이 즉, 일주일에 X개의 오류가 발생하면 매일 메인라인 빌드 오류를 해결하기 위해 개발자 시간에 (( 소비하게 됩니다. 2 devs * X/5 * (2*T + 1)) 시간을 병합 충돌을 해결하는 데 낭비되는 시간 롤백 및 병합 충돌로 인해 추가 문제가 발생할 수 있습니다. 깨진 빌드 시간 기간 동안 병합 충돌이 있는 PR이 약 2% 있고 매 시간마다 PR이 들어온다고 가정하면 이러한 충돌을 해결하는 데 낭비됩니다. ((2*T + 1) * X/5) M/8 ((2* T + 1) * X/5) * 0.02 * M/8은 손상된 빌드로 인한 주간 CI 실패 팀이 기능 브랜치를 기반으로 골든 브랜치를 사용하지 않는 경우 실패한 메인라인 브랜치 위에 기능 브랜치를 생성할 가능성이 높습니다. 언제든지 생성된 PR 수는 메인라인을 기반으로 하는 기능 분기의 평균 수와 유사하므로 이로 인해 매일 발생하는 CI 오류 수가 발생합니다. . (2*T + 1시간) * X/5 * M/8 CI를 해결하는 시간 빌드가 실패할 때마다 약 15분 동안 컨텍스트를 전환하면 이는 시간의 개발자 시간이 CI 실패로 인해 매일 낭비됩니다. (2*T + 1시간) * X/5 * M/8 * 0.25 불안정한 테스트를 다시 실행하는 데 시간이 소요되었습니다. 마찬가지로, 불안정한 테스트의 경우 테스트가 불안정한지 실제인지 조사하는 데 필요한 컨텍스트 전환 시간이 필요하며 테스트 자체를 다시 실행하는 데는 실행당 평균 15분이 걸립니다. 벗겨짐 요인에 따라 개발자는 매일 시간을 낭비하게 됩니다. (0.25 * M * F / 100) 효율성 향상 이들 중 대부분은 과 관련된 DORA 지표에 영향을 미치지만 엔지니어링 팀 워크플로의 비효율성을 측정하는 측면에서는 아직 수박 겉핥기 수준입니다. 빌드 및 테스트 실패의 영향으로 인해 릴리스가 지연되어 배포 시스템의 불안정한 테스트 지속성과 같은 기타 DORA 지표에 영향을 미치게 되어 실패율이 높아질 가능성이 높아집니다. . 변경 리드 타임 빈도, 서비스 복원 시간, DORA 지표에 대해 자세히 알아보세요 또는 단점에 대해 자세히 알아보십시오. 우리는 대규모 엔지니어링 팀의 숨겨진 과제 중 일부를 해결하기 위해 구축했습니다. 오늘날 많은 엔지니어링 조직에서는 Aviator MergeQueue를 사용하여 빌드를 중단하지 않고도 병합 워크플로를 확장할 수 있습니다. 이를 과 같은 불안정한 테스트 억제 시스템과 결합하면 팀은 매주 수백 시간의 엔지니어링 시간을 절약할 수 있습니다. Aviator를 TestDeck 게시되었습니다. 여기에도
