소프트웨어의 가치를 어떻게 측정합니까?

애자일의 원칙 중 하나는 작동하는 소프트웨어를 측정해야한다는 것입니다.

작업 소프트웨어는 진행의 주요 척도입니다. 12 가지 애자일 원칙

문제는 스토리, 버그 뭉치 또는 결함 보고서의 양이 줄어드는 방식으로 소프트웨어를 측정 할 수 있지만 소프트웨어의 가치를 측정하는 방법에 붙어 있습니다.

Mike Cohn을 예로 사용하고 SalesForce.com이 전년도에 비해 고객에게 500 % 더 많은 가치를 제공하도록 돕는 경우 *-어떻게 그 증가를 측정합니까? 현재 위치를 어떻게 측정합니까?

그가 사용하는 다른 메트릭은 기능 수와 개발자 당 기능 수입니다. 백 로그가 양호하고 스토리가 '기능'으로 잘린 경우 해결할 수있는 것이지만, 이제는 애자일로 시작하기 때문에 지금 제공하는 가치를 해결하는 방법이 필요합니다. 그런 다음 6 개월 동안 유사한 측정 항목을 사용하여 결과가 증가했는지 확인합니다.

매출 증가로 고객의 소프트웨어 가치를 측정하거나 고객 만족도를 높이는 방법 (어떻게 측정하겠습니까?)에 대해 들었지만, 이러한 증가는 회사의 모든 것 (판매, 회계, 지원)에 의한 것일 수 있습니다. 부서에서하는 일에 직접

그렇다면 소프트웨어의 가치를 어떻게 측정하고 어떻게 시작 했습니까?

* 민첩한 성공-Mike Cohn

여기에 일반적인 가치를 정의하는 방법이 있습니다 (소프트웨어 개발 외부에서도)

값을 정의합니다 .

가치가 소프트웨어 덕분에 벌어 들인 돈의 금액이라면, 그 가치는 :

수익-개발 비용 = 가치

또는

운영 비용 절감-개발 비용 = 가치

뒤집을 수 있습니다. 귀사의 매출이 얼마인지 알고 있습니까? 이를 측정 할 수 있다면 민첩성 덕분에 이직률이 50 % 감소하여 제공 한 가치를 계산할 수 있습니다.

50 % 회전율 감소 = (회전율 / 2) = 가치

가치는 당신에게 중요한 무엇이든 할 수 있습니다. 가치 를 정의하는 사람.

값이 평가되는 이유 포인트 민첩있다. 가치는 우선 순위를 정하는 데 도움이되도록 스토리 포인트와 비교됩니다. (비즈니스) 가치 (임의)를 스토리 포인트 가치 (비용)와 비교해야하기 때문입니다.

대부분의 경우 소프트웨어의 가치는 "추가 수입"또는 "달성 된 비용 절감"을 계산하여 측정됩니다.

다른 경우에는 소프트웨어가 더 큰 시스템 (예 : 자동차를 제어하는 ​​소프트웨어)의 일부로 통합되어 있으면 더 어려워집니다. 지출을 측정하기 위해 지출을 측정하거나 (값 = 비용) 전체 시스템의 가치를 계산하고 (추가 된 수입 / 달성 된 비용 절감) 소프트웨어에 대한 일부를 할당합니다 (예 : 소프트웨어 비용에 비례) 총 비용)

간단히 말해서 그것을 갖는 것과 그렇지 않은 것 사이의 재정적 차이점을 해결해야합니다.

약간의 소프트웨어가 프로세스를 자동화하여 풀 타임으로 일하는 두 사람이 더 이상 해당 작업을 수행 할 필요가 없다는 것은 회사의 연간 급여 (및 관련 비용)를 절약하는 것입니다. 평균 판매원이 새 시스템을 사용하지 않는 판매원보다 평균 10 % 더 많이 판매하는 경우, 소프트웨어를 사용하는 모든 판매원의 총 판매액의 10 %가 혜택이됩니다.

수치는 거칠고 준비되어있을 수 있지만 대부분의 항목은 예상되는 것에 대한 유용한 인상을 줄 정도로 충분히 정량화 할 수 있습니다.

이것은 까다로운 질문입니다. 모든 기능이 동일하게 생성되는 것은 아니기 때문에 '기능 / 개발자'측정 항목이 마음에 들지 않습니다. 일부 기능은 "필수 기능"이며 고객을 경쟁 업체로부터 멀어지게합니다. 일부 기능은 명확하지 않으며 클라이언트의 0.1 %가 사용할 수 있으며 기능이 없어도 제대로 작동 할 수 있습니다.

소프트웨어의 판매 / 갱신의 급격한 유입과 새로운 릴리스 시점에 쉽게 상호 연관 될 수 있다면 매출 업틱이 좋습니다. 또한 어떻게 든 경쟁 제품에서 새 릴리스로의 사용자 전환을 추적 할 수있는 경우. 고객 만족도는 고객 또는 판매 수에 정규화 된 행복한 전화 수 (또는 화난 전화 부재)로 측정 할 수 있습니다. 이러한 사항을 부서와 직접 관련 시키려면 주요 변경 사항은 이러한 변경 시점과 릴리스중인 소프트웨어의 시점입니다.

작동하는 소프트웨어 가 측정입니다. 사용자의 의견을 공개적으로 듣고 개발 과정에 참여시킵니다. 필요할 때 필요한 기능을 정기적으로 제공하십시오. 사용자가 진행 상황을 느낄 수 있도록 작은 덩어리로 제공합니다 .

민첩한 개발이나 심지어 새로운 프로젝트를 시작하고 있다면 이해 관계자는 약간의 믿음을 가져야합니다. 이를 위해서는 제품 소유자가 민첩성이 다른 프로세스보다 나은 이유를 명확하게 설명해야합니다 (특정 상황에 있다고 생각합니다).

제품 소유자가 어떤 기능 (스토리)이 가장 상대적인 가치를 제공하는지 확실하지 않은 경우 이해 관계자와 함께 앉아서 파악해야합니다. 포커 계획은 좋은 도구입니다. 각 스토리에 Relative Business Value를 지정하면 우선 순위를 정하는 데 도움이되지만 "Agile Business Value"에 대해 Bean 카운터와 대화하지 않도록주의하십시오. ROI와 동일하지 않습니다!

"Feature X는 매출을 150 % 증가 시켰습니다." 하지만 더 자주는 아니지만 그것의 조합의 우리의 매출은 160 % 증가 그리고 우리는 '하드'와 '소프트'값 " 생각 평균 고객이 새로운 UI 기능을 사용하여 우리에게 11 % 더 높은 등급을 내 주면서 우리는 소프트웨어 변경으로 그 속성 수 ".

그건 정말 보기에 시도 그것을로 전체적으로 가능한 - 정확하게 이러한 것들을 측정하기 어렵다.