가장 일반적인 애자일 메트릭을 사용한 경험
애자일 메트릭을 사용하여 팀의 생산성을 측정하는 것은 애자일 철학의 핵심 부분입니다. 팀 관리자와 모든 구성원은 작업의 결과를 확인하고 이 데이터를 사용하여 워크플로를 개선하고 효율성을 높여야 합니다.
최종 사용자와 클라이언트는 또한 제품의 결과를 평가하는 데 초점을 맞춘 민첩한 프로젝트 메트릭을 사용하여 이익을 얻을 수 있습니다. 메트릭을 사용하면 스크럼 마스터,개발자,디자이너 및 테스터가 응용 프로그램의 성능을 측정하고 현재 및 이전 작업이 제품을 개선하는지 추적 할 수 있습니다.
이 기사에서는 중요한 애자일 메트릭을 검토하고 이 애자일 메트릭 대시보드를 실제 프로젝트에 적용한 경험을 공유합니다. 그것은 밝혀,성공적으로 팀을 리드 하 고 결과 제공,당신은 뿐만 아니라 어떤 메트릭을 적용 해야 하지만 그것을 할 방법-우리가 어떻게 그것을 알아 냈 공유. 
일반적인 애자일 메트릭 유형
애자일 메트릭의 분류는 돌에 설정되어 있지 않습니다. 아직도,수년에 걸쳐,우리는 다양한 민첩한 프레임 워크에서 애자일 메트릭의 세 가지 주요 종류의 상승을 보았다.
- 칸반 메트릭-이 메트릭은 투자 시간(주기 시간)과 전달 된 결과(처리량)및 그 비율을 측정합니다.
- 스크럼 메트릭—계획 및 워크 플로우를 이해하고 주어진 기간에 수행 된 얼마나 많은 작업을 보여주는에 초점을 맞춘 메트릭;
- 린 메트릭—기능을 테스트 가능한 오류를 확인하고 부정적인 영향을 예측하여 기술 평가와 생산 효율성과 제품의 품질을 지속적으로 측정.
우리는 세 가지 유형의 메트릭을 모두 사용하여 소프트웨어 개발 프로세스 및 결과의 주요 측면을 평가합니다: 제품 품질,팀의 생산성 및 건강.
애자일 품질 메트릭
팀의 속도와 효율성을 측정하기 전에 일반적으로 올바른 방향으로 움직이고 있는지 알아야합니다. 작업 자체가 잘못된 방식으로 형성되는 경우 모든 개발 작업의 신속한 전달에 사용되는 것은 무엇입니까? 각 소프트웨어 개발 팀 및 관리자의 우선 순위는 모든 활동이 제품 개선과 관련이 있는지 확인하는 것입니다.이 작업은 품질을 측정하고 부정적인 경향을 감지하여 수행됩니다.
이스케이프 결함
각 애자일 프로젝트에는 스프린트 또는 작업주기가 있으며,그 끝에 특정 작업이 전달됩니다. 작업이 완료된 후,팀의 관리자는 설정-이 결과의 품질을 평가한다. 모든 변경,편집 및 수정되지 않은 버그는 개발자가 수정할 수 있었지만 수정하지 않은 문제 인 이스케이프 된 결함입니다.정확한 수와 특성을 기록하여 개발자의 눈을 벗어나는 실수를 알 수 있습니다.
탈출한 결함에 대한 보고서를 작성하고 유형 통계를 수집한 후에는 팀과 결과를 논의해야 합니다. 각 팀 구성원이 팀이 일반적으로 놓친 오류의 종류를 알고 있는지 확인하십시오. 당신은 개인적인 제안이 있는 경우에,일대일 팀원과 그(것)들을 토론하십시오.
실패한 배포
제품이 배포되었지만 릴리스되지 않았거나 사용자를 유치하지 못한 경우 이는 실패한 배포로 기록됩니다. 때로는 실패한 배포가 이해 관계자 중 한 사람의 결정에 발생하거나 비즈니스 모델이 신뢰할 수없는 것으로 판명됩니다. 문제의 원인이 무엇이든 실패한 모든 배포와 실패 이유를 기록해야 합니다.
새 배포를 릴리스하기 전에 팀은 항상 이전에 실패한 배포 목록을 살펴보고 이 배포가 동일한 프로세스를 거칠 수 없는지 검사할 수 있습니다. 이전 버전의 실패 이유를 분석하면 향후 문제를 피할 수 있습니다.
출시 순추기인 점수(순추기인 점수)
순추기인 점수는 사용자의 반응을 정량적(숫자,통계,평균 평점)및 질적 피드백(리뷰,직접 피드백,메시지,이메일,통화)으로 평가하는 메트릭입니다. 팀이 피드백을 수집하고 분석 한 후 각 팀 구성원은 사용자가 제품을 추천 할 가능성이 얼마나 높은지 평가하는 점수를 제안합니다(일반적으로 점수는 1 에서 10 까지 제한으로 설정됨).
애자일 프로젝트 관리 메트릭
이전의 실패와 성공에 대한 전체 역사를 가지고 있으면 현재의 모든 불완전한 프로젝트에 대해 취한 방향을 분석하고 이전 경험에 의존하여 관련 작업을 제공 할 수 있습니다. 당신이 개발 방향을 설정 한 후-제품의”무엇을 할”,”당신은 팀의 효율성을 평가해야-그것은”어떻게 우리가하고있는”요소입니다. 민첩한 프로젝트 메트릭을 사용하여 팀 구성원이 기대치를 충족하는지,작업을 이해하는지,마감일을 관리하는지,모든 프로세스가 조정되고 동기화되는지 알 수 있습니다.
리드 타임
리드 타임은 팀이 제품 백로그 항목이 스프린트 끝에 도달하는 데 걸린 양을 확인할 수 있는 메트릭입니다. 모든 개발 단계에서 제품,작업 별 작업을 추적하거나 아이디어 화에서 릴리스까지 전체 시간 비용을 평가하는 데 사용할 수 있습니다. 그것은 그들의 미래 작업을 계획하고 가격을 추정하는 동안 개발자가 사용할 수있는 장기 통계입니다.
각 프로젝트의 리드 타임을 기록하십시오. 그것은 전체 프로젝트를 포함 모두 더 큰 그림 통계를 유지하는 것이 가장 좋습니다,스프린트 메트릭을 조직 한-그래서 당신은 개별적으로 각 단계를 검사 할 수 있습니다.
주기 시간
리드 타임이 장기적인 팀 성과 지표 중 하나인 경우 주기 시간은 개별 작업에 중점을 둡니다. 이 메트릭은 한 주기가 하나의 작업에 의해 수행되는 단일 주기의 기간을 평가하고,프로젝트 당 주기 수를 계산하며,제품이 이미 베타 테스트 또는 릴리스된 경우 최종 사용자에 대해 수행된 결과를 측정합니다.
사이클 시간을 통해 팀은 하나의 작업에 너무 많은 시간이 걸리는지 또는 일부 팀 구성원이 자신의 목적을 달성하지 못하는지 즉시 확인할 수 있습니다. 이 단기 메트릭은 프로젝트 관리를 훨씬 쉽게 만들고 문제가 발생할 때 문제를 신속하게 파악하는 데 도움이됩니다.
스프린트 번다운
이 메트릭은 단기 및 장기 모두에 적용됩니다. 관리자는 현재 프로젝트에 대한 팀의 진행 상황을 추적하기 위해 실시간으로 스프린트 번 다운 스크럼 보고서를 만들 수 있습니다-이를 위해,그들은 스프린트의 총 수를 추정하고 가능성이 시간 비용을 예측해야합니다. 또한 장기적으로 사용할 수 있습니다-관리자는 이전 프로젝트에 대한 보고서를 분석 예상 시간대를 실패 단계를 파악하고,지연의 원인을 분석 할 수 있습니다.
가장 중요한 것은 스프린트 번다운을 통해 팀 워크플로의 역학을 추적할 수 있다는 것입니다. 몇몇 일원은 다른 사람이 계획사업의 끝으로 다 타는 그러나,일에게 첫번째 단계에 더 느린 가지고 간것을 간다. 스프린트 번다운을 통해 팀 리더는 이러한 경향을 감지하고 원인을 파악하며 작업 분배 및 시간 관리를 통해 구성원을 도울 수 있습니다.
소프트웨어 개발에서 애자일의 장점과 단점에 대해 자세히 알아보십시오!
에픽&릴리스 번다운
이 메트릭은 스프린트 번다운과 유사합니다. 관리자는 새로운 요구 사항을 추가하고 최종 사용자의 피드백을 기반으로 작업을 통합 할 수 있습니다. 그것은 또한 프로젝트의 릴리스 이후에 주어진 작업을 통합으로 그것은 스프린트 번 다운의 개선 된 버전입니다.
속도
이 메트릭은 특정 기간 동안 완료된 스토리 포인트의 수를 평가합니다. 당신의 역사를 바탕으로,당신은 미래의 스토리 포인트에 대한 시간 비용을 예견 할 수 있습니다. 특정 스프린트에서 팀의 속도 감소는 팀 구성원 간의 오해 또는 이전에 예상했던 것보다 어려운 작업을 지적 할 수 있습니다.
소프트웨어 개발에서 애자일의 장점과 단점에 대해 자세히 알아보십시오!
추가 애자일 메트릭
애자일 메트릭은 팀이 프로젝트를 더 잘 알고 제품 개발의 많은 중요한 측면을 추적하는 데 도움이됩니다. 또한 개발 및 팀의 복지에 대한 더 큰 그림을 볼 수있는 고위 경영진에 대한 민첩한 지표가 있습니다. 우리의 경험에 따르면,이러한 추가 메트릭은 작업의 모든 측면을 측정하는 데 도움이됩니다. 그러나 우리는 최종 제품에 대해 가장 잘 알려주고 완전히 완벽한 결과를 제공하는 데 도움이되는 핵심 특성을 정의했습니다.
누적 흐름
메트릭의 이름은 모든 프로젝트 흐름을 누적하고 단일 다이어그램으로 평가하는 목적을 명확하게 전달합니다. 이러한 그래프를 사용하면 더 자세한 애자일 보고서를 분석할 시간이 없는 프로젝트 이해 관계자에게 보낼 수 있습니다.
다이어그램은 일반적으로 다음 프로세스를 설명합니다:
- 백로그에 있는 작업:백로그 팀 구성원의 지정된 기간 동안 있는 작업 수;
- 승인된 작업: 완충 작업:승인을 기다리는 모든 작업이 완충 영역에 정의됨.
- 진행 중:현재 작업량을 평가해야 합니다.
코드 이탈
이 메트릭은 릴리스 이전의 코드 기반 변경 추세를 보여줍니다. 이탈 다이어그램은 한 번에 한 번 추가,제거 또는 변경된 코드의 양을 보여줍니다. 초기 스프린트에서,이 많은 스파이크하고 코드가 여전히 불안정하기 때문에,그래프에 빠진다,하지만 프로젝트가 진행됨에 따라,코드 이탈 그래프없이 급격한 기복으로,안정적이 될 것입니다.
릴리스 전에 이탈이 감소해야 합니다. 전반적으로 애자일 차트에 불규칙성이있을 때마다 그 이유를 조사하십시오.
관리도
관리도는 팀이 사이클 시간의 지속 시간에 대한 정보를 볼 수있는 차트입니다. 이상적인 결과는 차트에 선이 꾸준히 시간이 추락 할 것-그것은 팀의 속도의 증가를 의미-적은 시간은 단일 사이클 당 필요합니다. 또 다른 중요 한 측면은 일관성—주기 시간 작업의 종류에 관계 없이 유지 해야-그것은 올바른 작업 분배를 의미 합니다.
건강 메트릭
소프트웨어 개발 팀은 구성원 간의 의사 소통을 원활하게 유지하고 모든 사람이 만족하는지 확인하는 등 장기적인 우선 순위에 중점을 두어야 합니다. 애자일은 즉시주의해야 할 것을 알고 관리자로,다른 구성원의 이익에 적응할 수 있다는 것을 의미 유연한 방법론이다. 모든 팀 구성원이 워크플로에 만족하는지 확인하는 방법은 다음과 같습니다.
행복
팀에서 신뢰할 수 있고 비공식적 인 관계가 있다면 각 구성원과 열린 대화 상자에서 시작하는 것이 더 쉽습니다. 모든 사람에게 회사에서의 경험을 1 에서 5 로 평가하도록 요청하십시오. 당신은 지원 질문을 요청할 수 있습니다-자신의 작품의 최고와 최악의 측면은 무엇인가,무엇을 개선 할 수있다,무엇을 행복을 증가시킬 수 있을까? 팀에 친근한 의사 소통 습관이 없다면 익명 설문 조사를 사용하면보다 객관적인 결과를 얻을 수 있습니다.
팀 사기
팀 사기와 행복은 같은 것이 아닙니다. 행복은 편안함과 더 관련이 있지만 팀 사기는 생산성,자부심,자신의 전문적 자질에 대한 평가와 관련이 있습니다. 다시 말하지만,직원들에게 사기를 1 에서 5 로 평가하고 다음 질문을 할 수 있습니다;
- 회사에서 일하는 것이 당신의 능력을 향상시키는 데 도움이 되었습니까?
- 현재 작업 부하로 잠재력이 얼마나 많이 탐구됩니까?
- 당신은 당신의 일을 즐기십니까?
- 당신은 당신의 작업의 명확한 결과를 볼 수 있습니까?
- 당신은 새로운 프로젝트에 대한 열정?
여기서 목표는 팀의 발전 흐름이 올바른 방향으로 가고 있음을 이해하는 것입니다. 때때로 소프트웨어 개발 팀의 관리자는 회원의 이익을 무시하고 수익성이 있지만 지루한 작업을 수행합니다. 이 설문 조사는 직원들이 자신의 작업에 흥분하고 도전하는지 확인하는 데 도움이됩니다.
팀 구성원 회전율
팀 관리자가 팀 구성원을 자주 교체하는 경우 작업 환경이 비정상적일 수 있음을 의미합니다. 회전율의 어느 비율은 한동안 건강하다-침체를 의미하기 때문에,실제로,당신은 수년간 사람들의 어떤 추가든지 있고 싶지 않다. 그러나 여러 사람이 팀을 떠났거나 많은 사람들이 합류 한 몇 달 동안의 활동이 갑자기 급증하는 것을 조심해야합니다. 많은 새로운 참가자가 갑자기 추가 된 경우 프로젝트 관련 작업에 직접 진행하기 전에 온 보딩 프로세스에주의를 기울여야합니다.
최종 사용자를 위한 이점 측정
애자일 팀은 제품이 최종 사용자 및 비즈니스 소유자의 요구에 얼마나 잘 부합하는지 알아야 합니다. 이 작업은 코드 품질 및 최종 사용자에 대한 유용성 및 가능한 유지 관리 합병증을 결정하는 포괄적 인 코드 분석을 통해 수행됩니다.
정적 코드 분석
소프트웨어가 비활성 상태일 때 간단한 코드 분석 유형입니다. 오픈 소스 도구를 사용하여 코드를 자동으로 모니터링하면 보안 문제를 식별하고 기술 부채 및 버그를 감지하고 문제가있는 코드 조각을 가비지 수집기로 보낼 수 있습니다.
동적 코드 분석
동적 코드 분석을 위해서는 팀이 소프트웨어를 실행하여 최종 사용자가 받은 경험을 평가해야 합니다. 우리는 우리의 개발자와 테스터는 항상 사용자의 신발에 자신을 넣어 격려,가장 일반적인 시나리오를 탐구. 예를 들면,그들은 해결책에 그들의 동료 및 가족 구성원을 소개해서 좋다,의견을 요구한—계약에 의해 금지되지 않는 한. 가장 중요한 것은 다이내믹 코드 분석을 전적으로 책임지는 품질보증 전문가 팀이 있다는 것입니다.
최고의 애자일 메트릭 적용 방법
사용 가능한 다양한 애자일 메트릭 중에서 팀 및 프로젝트와 장기적으로 관련된 메트릭을 선택해야 합니다. 이러한 주요 특성을 추적하는 것은 습관이어야하지만 더 긴급한 작업에서 당신을 산만하게해서는 안됩니다. 애자일 메트릭을 워크플로에 원활하게 통합한 방법은 다음과 같습니다.
성능,예산 및 품질에 초점
모든 메트릭을 선택한 후 작업의 품질,부하,시간 비용 및 예산에 대한 명확한 그림을 가질 수 있는지 확인해야합니다. 첫째,민첩한 성능 평가를 위한 주기 시간 및 속도,코드 품질 평가를 위한 코드 분석,모든 개발 프로세스 및 비용을 추적하기 위한 누적 흐름 등 활성 프로젝트와 관련된 단기 메트릭을 설정합니다.
첫 번째 스프린트 중에 다음을 수행해야 합니다:
- 프로젝트의 스프린트 및 사이클 수 정의;
- 고객의 요구를 고려하여 전체 프로젝트의 시간 비용 추정;
- 최종 제품의 복잡성 수준을 이해하기 위한 경쟁 솔루션 평가;
- 프로젝트의 가장 흥미롭고 도전적이며 어려운 측면에 대한 기대에 대해 팀원들로부터 피드백을 수집하십시오.
이 방법으로 프로젝트를 완료하는 데 얼마나 많은 시간을 소비 할 것인지,유사한 솔루션을 기반으로 품질 표준을 설정하고,우리 팀이 작업을 수행하도록 동기를 부여했는지 여부(생산성에 큰 영향을 미침)를 알 수 있습니다.
메트릭 첫 번째 스프린트
이후,우리는 클라이언트와 모든 팀 구성원으로부터 피드백을 얻는 데 중점을 둡니다. 첫 번째 스프린트 후,우리는 워크 플로우에 관련된 모든 당사자가 프로세스를 이해하고 편안한 느낌을 알고 싶어요. 또한,우리는 코드 품질 평가에 강조-우리는 심지어 우리의 다음 스프린트의 각각의 일환으로 코드 분석 및 기술 부채 평가를 계획. 첫 번째 코드 줄이 작성되자마자 품질을 유지하는 것이 우리의 우선 순위입니다.
속도는
속도 다음으로 오는 것은 우리 프로젝트에서 가장 중요한 메트릭 중 하나이지만 핵심 메트릭은 아닙니다. 우리는 초기 단계에서 속도 번호에 우리의 판단을 내놓고 자제. 신속하게 첫 번째 단계를 통해 얻기의 전략은 일이 기다리고 재해입니다—팀은 계획을 건너 뛸 수 있습니다,또는 클라이언트에게 몇 가지 중요한 질문을 잊지. 우리는 제품의 첫 번째 단계를 서두르지 않고 고객과 팀 구성원이 자신의 페이스를 찾도록합니다.
우리 팀의 속도를 높이는 것은 우리가 실행 시점에있을 때 우리의 우선 순위 중 하나가됩니다. 즉시 모든 기능과 디자인이 배치 될 때,우리는 시간 비용을 최소화하고 가능한 한 빨리 모든 작업을 완료하기 위해 노력하고 있습니다.
개별 메트릭
사용 된 각 메트릭은 전체 팀과 개별 구성원 모두에게 제공되어야합니다. 개발자,테스터,디자이너는 팀 전체가 아닌 작업 속도와 결과를 볼 수 있어야합니다. 이를 실현하기 위해 우리는 지라 및 허브스태프와 같은 생산성 도구와 시간 추적기를 사용합니다. 모든 일반 보고서는 개별 사람과 동기화됩니다—회원은 자신의 시간이 만드는 전반적인 생산 시간의 비율을 볼 수 있습니다.
자주 묻는 질문
애자일의 핵심 성과 지표는 비즈니스 목표를 달성하는 팀의 효율성을 보여주는 측정 가능한 가치입니다. 최종 제품,전환율,피드백 품질에 의해 끌렸다 얼마나 많은 사용자-높은 수준의 케이피스는 많은 요인에 따라 장기 결과에 초점을 맞 춥니 다. 낮은 수준의 투자수준은 프로젝트에 소요된 시간(보통 시간 단위로 계산됨),프로젝트 예산(작업당 투자)등 여러 연결 요소의 영향을 받지 않는 단기적인 가치입니다.
애자일은 지속적인 개선을 기반으로 한 개발 방법론입니다—소프트웨어 개발은 데이터를 분석하고 이에 적응합니다. 이 팀은 민첩한 성능 및 작업 품질을 분석하고 다음 스프린트에서 변경 사항을 즉시 구현합니다.
스프린트 메트릭이란 무엇입니까?
스프린트 메트릭은 소프트웨어 개발 팀의 결과물을 평가하여 각 스프린트가 끝날 때까지 최종 고객에게 얼마나 많은 가치가 전달되었는지 확인하는 메트릭입니다. 이 값은 새로운 기능,디자인 개선 또는 버그 삭제로 측정 할 수 있습니다.
스프린트 메트릭의 다음 목표는 솔루션이 시장에 얼마나 빨리 전달되었는지,고객의 피드백 및 전환 수준 등 비즈니스 측면에서 팀의 효율성을 측정하는 것입니다. 마지막으로 메트릭은 개발자가 자신의 프로젝트와 팀이 일반적으로 취하는 방향에 대한 만족도를 보여 주어야합니다.
애자일 프로젝트에 메트릭이 중요한 이유는 무엇입니까?
애자일 방법론의 요점은 개발자가 각 스프린트 후 프로세스에서 항상 수정할 수 있다는 것입니다. 가시적 데이터,통계 및 그래프를 갖는 것은 개발자가 다음 스프린트에 대한 변경 사항을 이해할 수 있도록하고,최종 제품의 품질을 평가할 수 있습니다-그렇지 않으면,기술 및 조직 세부 사항에 잡힐 쉬울 것이다.
애자일의 스프린트란?
스프린트는 팀이 특정 수의 작업을 완료하도록 설정된 시작 및 완료 날짜와 함께 명확하게 정의 된 기간입니다. 스프린트는 스크럼,애자일 및 개발 운영의 기초이며,팀은 작업 부하를 관리 가능한 작은 청크로 나누고 각 스프린트의 결과를 추적합니다. 이러한 각 기간은 사전 계획,위험 평가,책임 할당 및 스프린트 후 분석이 포함 된 미니 프로젝트처럼 처리됩니다.
각 프로젝트는 일련의 스프린트로 구성됩니다. 각 스프린트가 평가되므로 문제를 조기에 발견하고 다음 스프린트에서 쉽게 제거할 수 있으므로 워크플로가 지속적으로 최적화됩니다.
소프트웨어 개발을 위한 메트릭은 무엇입니까?
소프트웨어 개발 메트릭은 소프트웨어 개발 프로젝트의 품질,성능 및 팀의 건강을 측정 할 수있는 정량적 가치입니다. 그들은 프로젝트를 따라 이동 하 고 조직 및 계획을 개선 하기 위해 팀의 미래 작업에 사용할 수 있습니다 개발 프로세스를 개선 하는 데 도움이.
소프트웨어 개발 지표에는 6 가지 주요 유형이 있습니다.:
- 공식 코드 메트릭-코드 줄 수(위치),명령 경로 길이 등을 결정하여 수행 된 작업의 양을 계산하는 객관적인 질적 값입니다.
- 개발자 효율성 메트릭-팀은 할당 코드,활성 일 및 작업에 소요 된 시간을 계산할 수 있습니다.
- 민첩한 프로세스 메트릭-프로젝트가 스프린트로 나뉘어지면 팀은 프로젝트의 더 작은 부분의 효율성을 측정 할 수 있습니다–리드 타임(여러 스프린트를 포함 할 수있는 특정 개발 단계에 소요 된 시간),사이클 타임(일반적으로 한 번의 스프린트가 단일 사이클에 해당)및 속도(특정 시간 프레임에서 수행 된 작업 수).
- 운영 메트릭-이 메트릭은 소프트웨어 실행 특성을 확인하고 회사 직원이 제 3 자의 도움없이 도구를 유지 관리하는 데 얼마나 효과적인지 결정합니다. 정상적인 상황에서 소프트웨어가 어떻게 실행되는지,그리고 부하 처리에 있어서 사내 팀이 얼마나 장비를 갖추고 있는지 확인하십시오.
- 테스트 메트릭-이 메트릭은 코드 커버리지(테스트 된 코드 수,버그 수 및 기술 부채 비율)를 평가합니다.
- 고객 만족도-팀은 순 프로모터 점수,고객 만족도 점수 및 고객 노력 점수를 측정하여 제품에 대한 최종 사용자의 반응에 대한 통찰력을 얻습니다. 이러한 메트릭은 사용자가 제품을 추천할지 여부와 결과에 만족하는지 여부를 각각 평가합니다.
애자일 메트릭은 소프트웨어 네트워크의 일부이며 가이드에서 알 수 있듯이 다른 범주로 구성 될 수 있습니다.
소프트웨어 개발 라이프사이클은 일반적인 기술이 개념화,실행 및 최종화 과정에서 겪는 일련의 단계이다. 평균 자간전증은 다음 단계로 구성됩니다:
- 새로운 프로젝트 기능,디자인,타겟 고객 등에 대한 요구 사항을 정의합니다.
- 시스템 설계 및 일반 사용자 경로 개요
- 소프트웨어 개발,즉 코드 작성,하드웨어 준비 및 기능 생성;
- 테스트 소프트웨어 성능,기능,보안,인터페이스 등
- 코드를 업데이트하고,특정 조각을 교체 또는 편집하고,버그를 제거하여 시스템을 유지 관리합니다.
각 단계는 다음과 같은 특성에 의해 측정 될 수있다.
- 요구 사항:팀은 프로젝트에 대한 모든 요구 사항을 수집하고 시간과 비용 측면에서 각각의 구현을 평가해야합니다;
- 결함:작업의 효율성을 측정하기 위해 개발자와 테스터는 개발 중에 발생하는 문제의 정확한 수를 인식해야 합니다.작업 당 벌어 들인 돈은 모든 팀 구성원이 생산적인지 아닌지를 평가할 수있게합니다.
가이드에 설명 된 모든 메트릭은 소프트웨어 개발 라이프 사이클의 여러 단계에서 사용할 수 있습니다. 이 프로젝트는 문제가 쌓일 수 있고 제품의 중요한 결함을 쉽게 놓칠 수 있기 때문에 릴리스에 가까운 모니터링이 가장 필요합니다.
애자일 메트릭의 처리량이란 무엇입니까?
스프린트당 완료된 스토리 수를 계산하는 메트릭입니다. 스크럼에서 유사한 메트릭을 스프린트 속도라고 합니다.
결론
애자일 메트릭은 소프트웨어 개발 프로젝트 전반에 걸쳐 정보에 입각 한 의사 결정을 내릴 수있는 견고한 기반을 설정합니다. 개발자는 이러한 통찰력을 사용하여 다음 스프린트에서 효율성을 높이고 제품의 품질을 지속적으로 향상시킬 수 있습니다. 그러나 개발 메트릭이 소프트웨어 개발 프로젝트에서 절대적인 우선 순위가되어서는 안된다는 점은 주목할 가치가 있습니다. 개발자는 무엇보다도 프로젝트 요구 사항 및 잠재 고객 선호도에 의존해야합니다.
젤빅스에서는 메트릭을 프로젝트에 적용하는 데 개인화된 접근 방식을 사용합니다. 먼저,우리는 클라이언트와 프로젝트의 뮤직 비디오를 논의,타겟 고객을 연구,경쟁력있는 솔루션을 분석,오직 다음 프로젝트에 가장 적합한 메트릭을 선택. 대신,우리는 프로젝트의 요구를 가장 반영 하는 것 들을 선택 합니다.