소프트웨어 개발팀을 관리하는 것은 결코 쉬운 일이 아닙니다. 프로젝트가 결승선에 도달할 때까지 엔지니어링 프로젝트 관리자는 숨을 쉴 수 없습니다. 이것이 바로 소프트웨어 엔지니어링 관리자가 프로젝트와 팀의 성과를 향상할 수 있는 방법을 찾는 이유입니다. 그리고 이것이 바로 Kpi와 같은 것들이 신의 변장을 한 곳입니다.
KPI는 팀의 피트니스 트래커와 같습니다. 원활하게 진행되고 있는 부분과 조여야 할 부분을 파악하는 데 도움이 됩니다. 하지만 세상에는 수많은 KPI가 있는데 실제로 어떤 것에 관심을 두어야 할까요? 당신을 록스타 소프트웨어 팀 관리자로 보이게 해줄 상위 15개와 버리고 싶은 몇 가지를 분석해 보겠습니다.
KPI는 화면에 표시되는 숫자 그 이상입니다. 더 나은 의사결정을 위한 로드맵입니다. 올바른 측정항목을 추적하면 팀이 뛰어난 부분과 개선의 여지가 있는 부분을 파악할 수 있습니다. 이는 프로젝트 일정, 리소스 요구사항, 잠재적인 장애물을 예측하는 데 도움이 되는 수정구슬을 갖는 것과 같습니다.
당신이 경주 중이라고 상상해 보세요. 자동차가 트랙을 빠르게 돌아다니는 대신 팀이 단거리 경주에서 작업을 완료하기 위해 경주하고 있습니다.
문제는 출발선("할 일")에서 결승선("완료")까지 얼마나 빨리 도달할 수 있느냐는 것입니다.
여기서 Cycle Time이 필요합니다. 팀이 얼마나 빨리 작업을 완료하는지 알려주는 스톱워치입니다.
Cycle Time은 속도에 관한 것이지만 단순히 빨리 가기 위한 것만은 아닙니다.
효율성과 속도 저하가 발생하는 지점을 파악하는 것이 중요합니다. 평균적으로 성과가 높은 팀의 주기 시간은 작업당 약 1.8~3.4일입니다.
시간이 더 오래 걸리면 내부를 살펴보고 지연의 원인이 무엇인지 확인해야 할 때입니다. 프로세스 병목 현상, 과도한 멀티태스킹 또는 단순히 오래된 기술 부채일 수도 있습니다.
귀하의 팀이 모바일 앱의 새로운 기능을 개발 중이라고 가정해 보겠습니다. 월요일 아침에 작업이 백로그에서 "진행 중"으로 이동합니다. 개발팀은 코딩, 테스트 및 커밋 푸시를 시작하고 수요일 오후까지 작업이 완료되고 "완료"로 표시됩니다. 3일의 사이클 타임입니다.
이제 또 다른 작업에 문제가 발생했다고 가정해 보겠습니다. 코드 검토에 시간이 오래 걸리거나 작업을 방해하는 종속성이 있을 수 있습니다. 해당 작업이 7~10일 동안 지속된다면 이는 뭔가 문제가 있다는 신호입니다.
여기서 마법이 일어납니다. 주기 시간을 추적하면 패턴을 찾아낼 수 있습니다.
귀하의 팀이 일부 작업에서는 속도가 매우 빠르지만 다른 작업에서는 속도가 느려질 수도 있습니다. 이러한 통찰력을 통해 세부 사항을 자세히 살펴보고 프로세스를 간소화하는 방법을 알아낼 수 있습니다. 코드 검토 프로세스를 조정하거나 작업 우선순위를 다르게 지정하는 것만큼 간단할 수도 있습니다.
목표는? 사이클 시간을 줄이기 위해 팀은 전문가와 같은 작업을 지속적으로 수행합니다.
그런 일이 발생하면 단지 빠르게 움직이는 것이 아니라 현명하게 움직이는 것입니다.
코드에 있어서는 코드를 많이 작성하는 것이 아니라 작성한 내용이 실제로 작동하는지 확인하는 것입니다. 이것이 바로 코드 적용 범위가 중요한 역할을 하는 부분입니다.
코드 커버리지를 코드의 건강검진이라고 생각해보세요.
테스트 중인 코드베이스의 양을 알려주므로 교활한 버그가 문제가 되기 전에 잡아낼 수 있다는 것을 알 수 있습니다.
소프트웨어 개발 세계에서 코드 적용 범위에 대한 좋은 벤치마크는 약 70-80%입니다. 그렇게 치신다면 꽤 잘하신 겁니다.
하지만 여기서는 완벽함이 목표가 아니라는 점을 기억하세요. 100% 적용 범위는 해변의 모래알 한 알까지 잡으려는 것과 같습니다.
대신 코드의 중요한 부분을 다루는 데 집중하세요.
전자상거래 사이트를 위한 새로운 기능을 구축한다고 가정해 보겠습니다. 장바구니라고 가정해 보겠습니다.
장바구니에 품목을 추가하고, 총계를 계산하고, 결제를 처리하는 코드를 작성했습니다. 이제 고객이 사용을 시작하기 전에 이 모든 것이 작동하는지 확인하고 싶습니다.
각 부분에 대한 테스트를 작성합니다.
장바구니에 항목 추가 -- 항목이 올바르게 추가되었는지 테스트합니다.
총계 계산 -- 누군가 여러 항목을 추가할 때 계산이 올바른지 확인합니다.
결제 처리 -- 결제 게이트웨이를 테스트하여 거래가 원활하게 진행되는지 확인합니다.
테스트가 이러한 모든 시나리오를 다루고 오류 없이 실행된다면 견고한 코드 적용 범위를 확보한 것입니다. 하지만 결제 프로세스 테스트를 건너뛰면(복잡하거나 시간이 더 많이 소요될 수 있음) 코드의 중요한 부분을 테스트하지 않은 상태로 두는 것입니다. 이는 밤에 문을 잠그지 않은 채 두는 것과 같습니다.
코드 적용 범위를 주의 깊게 관찰하면 대부분의 코드가 테스트되고 있으므로 버그가 프로덕션에 몰래 들어올 가능성이 줄어듭니다. 문제를 조기에 발견하여 나중에 고객 불만으로 이어지지 않도록 하는 것이 중요합니다.
이렇게 생각해 보세요. 개발팀이 동일한 코드 덩어리를 계속해서 다시 작성하고 있습니다. 진보를 향해 달려가는 대신, 그들은 햄스터 쳇바퀴에 갇혀서 실제로 앞으로 나아가지 않고 원을 그리며 맴돌고 있습니다. 이는 코드 재작업이 진행 중인 것이며 뭔가 문제가 있다는 신호입니다.
이상적으로는 팀이 새로운 기능을 구축하는 데 더 많은 시간을 투자하고 이미 수행한 작업을 다시 수행하는 데 드는 시간을 줄여야 합니다. 코드 재작업이 너무 많으면 생산성이 저하될 수 있습니다.
실제로 연구에 따르면 잦은 재작업으로 인해 개발자 시간의 최대 40%가 소요될 수 있으며, 이 시간은 혁신에 더 잘 투자할 수 있습니다.
변경 실패율(CFR)을 개발팀의 '버그 측정기'로 생각하세요. 코드 변경으로 인해 문제가 발생하는 빈도를 측정합니다. 높은 CFR은 물이 새는 보트와 같습니다. 순조롭게 항해(멋진 새 기능 구축)하는 대신 지속적으로 물을 퍼내는 것(버그 수정)입니다.
이상적인 세상에서는 코드베이스에 대한 모든 변경 사항이 완벽하게 작동할 것입니다. 그러나 실제로는 상황이 깨집니다. Accelerate State of DevOps Report에 따르면 CFR의 업계 평균은 약 16~30%입니다. 즉, 10번의 변경 중 1~3번에서 문제가 발생할 수 있습니다. CFR이 그 이상으로 올라가면 코드가 생산되기 전에 더 많은 TLC가 필요하다는 신호입니다.
팀에서 새로운 기능을 출시하고 즉시 사용자가 충돌을 보고하기 시작한다고 가정해 보겠습니다. 데이터를 조사한 결과 최근 배포의 40%에서 문제가 발생했다는 사실을 알게 되었습니다. 아야! CFR이 높다는 것은 팀이 버그를 해결하는 데 더 많은 시간을 할애하고 혁신에 소요되는 시간을 줄인다는 것을 의미합니다.
목표는? 테스트 및 코드 검토를 개선하여 CFR을 낮추면 이미 출시된 항목을 수정하는 데 드는 시간을 줄이고 차세대 제품을 구축하는 데 더 많은 시간을 할애할 수 있습니다.
DDR(결함 감지 비율)은 버그 잡기 스코어카드와 같습니다. 즉, 코드가 출시되기 전에 발견한 버그 수와 출시 후 누락된 버그 수를 알려줍니다. DDR이 높을수록 테스트 게임이 더 좋아집니다. 하지만 더 많은 버그가 몰래 지나가고 프로덕션 환경에 나타나면 이제 테스트 도구를 강화해야 할 때입니다.
좋은 DDR은 일반적으로 릴리스 전에 발견된 버그의 85% 이상을 목표로 하는 테스트 프로세스가 견고하다는 것을 보여줍니다. DDR이 낮다면 여러 가지 위험 신호를 놓친 것과 같으나 나중에 사용자가 불평하기 시작할 때 알게 됩니다.
새 앱 업데이트를 출시한다고 가정해 보세요. 테스트 중에는 8개의 버그를 발견했지만 출시 후 사용자는 또 다른 5개의 버그를 보고했습니다. 이는 8/13, 즉 약 62%의 DDR을 제공합니다. 별로 좋지 않습니다. 이는 테스트에서 버그의 거의 40%를 놓쳤음을 의미합니다. 이는 출시 전 점검을 강화할 때가 되었다는 분명한 신호입니다.
DDR을 강화하려면 자동화된 테스트를 개선하고, 보다 철저한 코드 검토를 받거나, 대규모 출시 전에 더 많은 사용자 수용 테스트를 실행하는 것을 고려해 보세요. DDR이 향상될수록 사용자는 더욱 행복해지며 출시 후 "어-오"하는 순간도 줄어듭니다!
버그율은 성가신 버그가 코드에 나타나는 빈도를 측정합니다. 높은 버그율은 큰 위험 신호가 될 수 있으며, 이는 코드가 급히 문 밖으로 나가거나 아직 학습 중인 누군가에 의해 작성되었음을 알리는 신호일 수 있습니다. 업계 데이터에 따르면 숙련된 팀은 일반적으로 코드 1,000줄당 버그 10개 미만을 목표로 합니다.
귀하의 팀이 새로운 기능을 출시하고 몇 시간 내에 15개의 버그가 보고되었습니다. 이러한 현상이 정기적으로 발생한다면 코드 검토나 테스트에 더 많은 주의가 필요하거나 개발자가 이를 올바르게 수행하는 데 더 많은 시간이 필요할 수 있다는 신호입니다.
MTTR은 시스템 충돌 후 팀이 얼마나 빨리 다시 일어설 수 있는지에 관한 것입니다.
어수선한 상황에서 얼마나 빨리 회복할 수 있는지 보여주는 재해 복구 스톱워치입니다. 이상적으로는 낮은 MTTR을 원합니다. 몇 시간이 아닌 몇 분만 생각하세요.
오후 2시에 웹사이트가 다운되고 팀은 오후 2시 15분에 다시 온라인 상태가 됩니다. 이는 15분의 MTTR입니다. 팀이 복구하는 데 일반적으로 1시간이 걸린다면 사고 대응 계획을 구체화해야 할 때일 수 있습니다.
속도는 스프린트 중에 팀이 수행하는 작업의 양을 측정합니다. 이는 생산성 척도이지만 잊지 마십시오. 서로 다른 팀에 걸쳐 항상 동일한 것은 아닙니다. 중요한 것은 단지 숫자만 비교하는 것이 아니라 시간이 지남에 따라 속도가 어떻게 변하는지 추적하는 것입니다.
지난 스프린트에서 귀하의 팀은 50개의 스토리 포인트를 완료했습니다. 이번 스프린트에서는 55회를 마쳤습니다. 속도가 더 빠르다는 것은 팀이 잘 나가고 있다는 의미일 수도 있고, 더 쉬운 작업을 수행했다는 의미일 수도 있습니다. 여기서 일관성을 유지하세요.
누적 흐름은 작업 흐름에서 작업이 쌓이는 위치를 보여줍니다.
프로젝트의 트래픽 보고서라고 생각하세요. 작업이 한 단계에 너무 오랫동안 정체되면 병목 현상이 발생하게 됩니다.
"코드 검토"에 많은 작업이 남아 있는 반면 다른 작업은 원활하게 진행되는 것을 발견했습니다. 이는 계속 진행하려면 더 많은 검토자가 필요하거나 더 잘 정의된 기준이 필요하다는 의미일 수 있습니다.
배포 빈도는 팀이 코드를 프로덕션에 푸시하는 빈도를 추적합니다. 배포 빈도가 높을수록 일반적으로 팀이 민첩하고 적응력이 뛰어나다는 것을 의미합니다. 속도를 위해 품질을 희생하지 않도록 주의하세요.
팀에서는 일주일에 두 번 업데이트를 배포합니다. 업데이트가 탄탄하면 좋지만 배포할 때마다 버그가 발생한다면 다시 전화를 걸어 품질에 집중해야 할 때입니다.
대기열 시간은 '할 일' 더미에 갇혀 있는 경우와 같이 작업이 대기 상태에 있는 시간을 측정합니다. 대기 시간이 길면 너무 많은 작업을 처리하는 팀원이 너무 적어 프로세스가 비효율적이라는 신호일 수 있습니다.
QA 승인을 기다리는 작업이 며칠 동안 지속된다면 이는 QA 팀에 도움이 필요하거나 작업 진행 기준을 간소화해야 한다는 신호입니다.
범위 완료율은 팀에서 계획한 작업이 실제로 완료되는 정도를 나타냅니다. 팀이 정기적으로 작업을 완료하지 않은 채 남겨둔다면, 감당할 수 있는 것보다 더 많은 것을 물어뜯고 있다는 의미일 수 있습니다.
귀하의 팀은 이번 스프린트에서 20개의 작업을 완료할 계획이었지만 15개만 완료했습니다. 이와 같이 범위 완료율이 낮다는 것은 팀이 보다 현실적인 목표를 설정하거나 시간을 더 잘 관리해야 함을 의미할 수 있습니다.
추가된 범위는 스프린트가 시작된 후 새 작업이 얼마나 자주 추가되는지 추적합니다. 여기서 높은 비율은 계획이 잘못되었거나, 더 나쁘게는 범위가 확장된다는 신호일 수 있습니다. 즉, 일정이나 리소스를 조정하지 않고 프로젝트 목표가 계속 확장되는 경우입니다.
10개의 작업으로 스프린트를 시작했지만 결국에는 5개를 더 추가했습니다. 이는 범위가 50% 증가한 것이며, 이는 팀이 계획 중에 작업 범위를 충분히 철저하게 지정하지 않고 있음을 의미할 수 있습니다.
리드 타임은 작업이 생성된 시점부터 완료될 때까지의 총 시간을 측정합니다. 아이디어부터 실행까지의 전체 여정과 같습니다. 일반적으로 리드 타임이 짧을수록 팀의 효율성이 높아지는 반면 리드 타임이 길수록 프로세스의 지연이나 병목 현상이 발생할 수 있습니다.
기능 요청이 들어오고 컨셉부터 배포까지 2주가 걸립니다. 비슷한 작업에 일주일이 걸렸다면 이제는 무엇이 속도를 늦추는지 조사할 때입니다. 승인이 지연되거나 팀 간에 핸드오프가 너무 많이 발생했을 수도 있습니다.
또한 읽어 보세요: 변경 리드 타임: DORA 지표 및 소프트웨어 제공에 미치는 영향에 대한 심층 분석
이탈률은 코드가 작성된 직후에 코드가 다시 작성되거나 크게 변경되는 빈도를 추적합니다. 높은 이탈률은 초기 접근 방식이 올바르지 않았거나 요구 사항이 너무 많이 변화하고 있다는 신호일 수 있습니다.
팀에서 기능을 작성했는데 초기 구현이 요구 사항을 충족하지 못했기 때문에 일주일 이내에 기능의 절반을 다시 작성해야 합니다. 이런 일이 계속 발생한다면 계획에 더 많은 시간을 투자해야 하거나 처음부터 요구사항을 더 명확하게 해야 한다는 신호입니다.
어떤 KPI에 주목할 가치가 있는지 궁금하십니까? 팀의 성과와 진행 상황에 대한 전체 그림을 제공하는 항목에 집중하세요. 주의할 점:
코딩 효율성: '이봐, 내가 이걸 썼어!'에서 코드가 얼마나 빠르고 원활하게 흘러가나요? "와, 효과가 있다!"
협업 지표: 잘 연습된 밴드나 싱크로나이즈드 수영 팀처럼 팀이 얼마나 조화롭게 경기를 펼치고 있는지를 나타냅니다.
예측 가능성 측정항목: 프로젝트 결과를 얼마나 정확하게 예측하여 날씨 앱만큼 신뢰할 수 있지만 더 정확한 예측을 할 수 있는지.
신뢰성 지표: 코드가 얼마나 견고한지, 그리고 교활한 버그가 눈에 띄기 전에 테스트에서 얼마나 잘 잡아내는지.
이러한 KPI는 예상치 못한 일을 방지하고 프로젝트를 순조롭게 진행하는 데 도움이 됩니다. 성공 툴킷의 필수 요소라고 생각하세요. 보풀 없이 좋은 것만 있으면 됩니다!
결론은 다음과 같습니다. KPI는 단순한 숫자가 아니라 현명한 의사 결정을 위한 비밀 무기입니다. 전문가처럼 엔지니어링 생산성의 우여곡절을 탐색하는 데 도움이 됩니다. 그리고 미들웨어의 DORA 지표를 여기에 추가하면 무적의 팀이 됩니다. 미들웨어는 배포 빈도, 리드 타임, 변경 실패율, 평균 복구 시간과 같은 DORA 측정항목을 쉽게 추적하여 추측을 배제합니다.
KPI를 감시하고 항상 올바른 방향으로 나아갈 수 있도록 도와주는 개인 조수가 있는 것과 같습니다. 미들웨어를 사용하면 단순히 문제에 대응하는 것이 아니라 문제를 예측하고 소프트웨어 개발을 성공으로 이끌 수 있습니다. 오픈소스 저장소를 확인해 보세요!
미들웨어 본사
/
미들웨어
개발자의 잠재력을 발휘하는 오픈 소스 엔지니어링 관리
오픈소스 커뮤니티에 참여하세요
미들웨어는 엔지니어링 리더가 DORA 지표를 사용하여 팀의 효율성을 측정하고 분석할 수 있도록 설계된 오픈 소스 도구입니다. DORA 측정항목은 소프트웨어 제공 성과 및 운영 효율성에 대한 통찰력을 제공하는 4가지 주요 값 집합입니다.
다음과 같습니다.
목차
소프트웨어 개발 KPI(핵심 성과 지표)는 코드 품질, 배포 빈도, 리드 타임 등의 지표를 포함하여 개발 프로세스의 효율성과 효율성을 평가하는 데 사용되는 측정 가능한 값입니다. KPI는 특정 목표에 대한 진행 상황을 평가하고 전반적인 성과를 개선하는 데 도움이 됩니다.
DORA 지표를 포함한 KPI를 추적하려면 프로젝트 관리를 위한 Jira, 코드 통찰력을 위한 GitHub와 함께 포괄적인 성과 추적을 위한 미들웨어를 사용하세요.
위 내용은 5가지로 추적해야 할 상위 소프트웨어 개발 KPI의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
