프로젝트 기간을 추정 할 때 허용되는 오차 한계는 얼마입니까?

내가 일하는 회사는 최대 10 %의 오차 한계를 두는 것을 목표로하고 있으며, 분석가는 추정치가 10 % 이상 떨어지지 않기를 기대합니다.

나는 그것을 비교할 것이 없기 때문에 그것에 대해 어떻게 생각 해야할지 모르겠다.

우리가 다소 잘못 추정하고 있는지를 측정하는 좋은 기준은 무엇입니까? 어떻게 (%)에 훨씬 당신이 생각 할 괜찮 미스에?

당신과 당신의 동료들이 전에했던 것과 매우 비슷한 것을 추정하지 않는다면, +/- 10 %는 엄청나게 낙관적입니다. 경영진은 소프트웨어에 대한 경험이 많지 않거나 소프트웨어 추정에 대한 큰 한계를 모르고 있습니다. 이 논문에는 몇 가지 지원 자료 가 있으며, 많은 처벌 을 찾을 수 있습니다.

일반적인 소프트웨어 프로젝트 인 Rubik 's Cube보다 훨씬 간단한 시스템을 살펴 보겠습니다. 최대 20 개의 이동으로 모든 위치를 해결할 수 있습니다 . 그러나 추정하기 때문에 솔루션을 제공하기 전에 몇 분 동안 주어진 큐브 만 볼 수 있습니다. 당신은 좋은 견적을 줄 수 있습니까? 아니요, 때로는 프로세스를 추정하는 것이 프로세스를 수행하는 것보다 시간이 오래 걸립니다.

또 다른 간단한 시스템 : 피노키오. 나무 오토 마톤의 코 조각은 그가 거짓말을 할 때 자랍니다. 피노키오가 휴식을 취한 후 "코가 커지고있다"고하면 어떻게됩니까? 일부 시스템은 예측할 수 없으며 결정할 수 없습니다.

이 두 가지 문제는 대부분의 소프트웨어 시스템에 내장되어 있습니다. 이로 인해 +/- 10 %에 가까운 추정치는 절대 얻지 못할 것입니다.

저의 조언은 상당히 푹신한 견적을 내리고, 가능한 한 빨리 프로젝트를 완수하기 위해 노예처럼 일하고, 10 % 이하가 될 때까지 바쁘게 보이는 것입니다. 그 시점에서 놀라운 성공을 발표하십시오.

나는 프로젝트에 의존하기 때문에 어떤 종류의 "목표 오류 마진"에 대해 매우 주저 할 것이다. 어떤 종류의 사용자 지정이 필요한지, 어떤 종류의 비즈니스 프로세스 변경이 필요한지 확실히 모르는 새 CRM 시스템을 설치, 구성 및 사용자 지정하는 데 걸리는 시간을 추정하려는 경우 회사는 비슷한 대규모 프로젝트의 역사를 가지고 있지 않으므로 오류 마진은 상당히 커야합니다 (즉, 18 개월 +/- 50 %가 걸리고 9-27 개월이 걸릴 것이라고 추측 할 수 있습니다). 프로젝트가 진행됨에 따라 사양이 명확 해지고 비즈니스 프로세스에 대한 의사 결정이 내려지고 개발자의 편의가 높아집니다. 이러한 오류 마진이 더 엄격 해집니다. 101 번째 기본 전자 상거래 사이트를 구축하는 데 걸리는 시간을 예상하려는 경우 처음 100에서 좋은 역사를 얻었 으면 훨씬 정확한 추정치를 줄 수있을 것입니다. 그러나 대부분의 프로젝트는 중간 쯤에 떨어질 것입니다.

이제 범위가 아닌 단일 숫자를 인용하는 경우 추정을 수행하는 사람이 추정치가 얼마나 정확한지를 지정할 수 있도록 범위를 인용하는 것이 답입니다.

좋은 기준선 을 기반으로 한 것 실제 데이터 는 수집했다.

이를위한 첫 번째 단계는 모든 추정치를 기록 하는 것입니다 . 두 번째 단계는 실제 결과를 기록하는 것 입니다. 솔직하게 실제를 '자체 조정'하려는 유혹을받지 마십시오. 이 정보를 충분히 수집하면 추정치의 수준을 통계적으로 근거로하는 데이터가 있습니다. 누가 평가를했는지와 누가 작업했는지에 따라 크게 달라질 수 있습니다. 이 작업을 통해서만 다른 순수한 쓰레기 인 '오류 한계'를 합리적으로 기대할 수 있습니다.

거기서도 멈추지 않습니다. 추정치의 원인을 분석하면 향후 추정치의 정확성을 향상시키는 데 도움이 될 수 있습니다. 참고 : 여전히 추정치 이므로 추정치 입니다.

추정은 첫 번째 추정 후에도 끝나지 않습니다. 이것은 더 많은 지식을 습득함에 따라 프로젝트가 진행됨에 따라 조정될 수있는 것으로, 이에 따라 오류가 발생할 가능성이 줄어 듭니다. 의사 소통에 대한 열린 마음이 더 많을수록 이전의 놀라움에 대해 논의합니다. 사람들이 놀라지 않고 프로젝트 또는 고객의 기대에 더 많은 시간을 할애 할 수 있습니다.

둘째, 아마도 오류 마진을 처리하는 더 좋은 방법은 단순히 % 마진보다 ' 내부 신뢰 '입니다. 예상 날짜를 단일 날짜가 아닌 신뢰 구간을 기준으로 한 것보다.

PERT 는 통계적 추론에 기초한 추정을 처리하기위한 프레임 워크의 한 예입니다. 예를 들면 다음과 같습니다.

"내가 아는 바에 따르면 8 개월 동안 90 %의 신뢰 수준을 제공 할 수 있습니다. 10 개월 동안 95 % 신뢰, 2 년 동안 99 % 신뢰 등"

여기를 참고하십시오 : 그들이 당신을 원할수록 더 큰 견적이 될 것입니다. 복잡성 (일명 얼마나 정확한지에 따라)에 따라 80 %와 90 % 사이의 작은 차이 일 수 있습니다.

마지막으로-행운을 빌어 요;) 소프트웨어 평가에서 '최대 오류 마진'을 해결하여 '모든 추정치가 +/- 10 %가 될 것입니다'와 같은 것을 지정할 수 있다면 나머지 부분에 대해 박스 오피스 영화를 의뢰하십시오. 소프트웨어 산업에서 우리. Office Space와 The Matrix : D 사이의 십자가 같은 것을 생각하고 있습니다.

실제로 프로젝트의 크기와 복잡성에 따라 크게 달라집니다.

프로젝트 견적이 1 주일이면 10 %가 합리적입니다. +/- 1/2 일을 의미합니다.
1 개월이면 10 %가 흔들립니다-내 경험으로는 1 개월 안에 발견 할 내용을 예측하는 것은 불가능합니다.

한 달 이상-모든 베팅이 해제되었습니다 :).

이들은 개발자 당이므로 1 주일 == 1 개월 인 4 명의 개발자 팀의 경우입니다.

4 명의 개발자 팀의 경우 대부분 1 개월 안에 수행 할 수있는 기능 목록을 제공하는 것이 좋으며 해당 기능의 경우 10 % 이내입니다. 그런 다음 다음 달에 다시 추정하십시오.

나는 여기에 순진한 가정을했습니다.

1. 모든 개발자는 동시에 작업 할 수 있습니다.
2. 테스터를 고려하지 않았습니다-테스트 할 시간이 있어야합니다
3. 프론트 엔드, 백엔드, 디자이너 등 모든 개발자가 동일합니다.

당신은 그것들을 고려해야합니다. 그러나 이것은 일반적인 생각입니다.

많은 변수가 있습니다 :

1. 프로젝트는 얼마나 걸립니까?

2. 프로젝트는 어떻게 관리됩니까? 폭포? 기민한? 스크럼?

폭포라는 질문에서 가정합니다. 이 경우 마진 요청에 따라 일정 비율로 실패 할 것으로 예상됩니다.

대답이 애자일 방법론, 특히 스크럼과 같은 것이라면. 마진 백분율이 무엇인지는 중요하지 않습니다. 2 주 동안 50 %의 오차 한계 스프린트는 1 주일이며, 1 주일에는 스프린트는 2.5 일입니다. 두 가지 모두 최악의 시나리오입니다. 이는 스프린트마다 배송 날짜가 재 추정되기 때문에 시간이 지남에 따라 점점 더 정확 해지기 때문입니다.

Waterfall을 사용하면 50 %의 오차도 들리지 않지만 6 개월 인 12 개월 동안의 프로젝트에서 실제로 발견되지는 않습니다.

내가 백악기 / 제 3의 경계를 중심으로 소프트웨어 팀을 이끌던 시절에 우리는 실제로 추정치에서 +/- 10 %를 달성했습니다. 내 매우 기억에 남는 기억이 있다면 약 +/- 15 %였습니다. 그러나 이것은 우리가 이미 한 일 을 추정했기 때문 입니다. 우리가 설계 한 실시간 환경에서 A에서 바이트를 가져 와서 익숙한 언어를 사용하여 B로 옮긴 비교적 간단한 실시간 통신 펌웨어 , 사무실 몇 곳에서 사내에서 설계 한 하드웨어와 대화 할 수 있습니다. 말 그대로 몇 년 동안 위의 주제에 대한 약간의 변형이 있습니다.

일반 소프트웨어 프로젝트 추정 오류율의이 종류를 달성하기 위해 기대하는 것은 솔직히입니다 우스꽝 . 당신이 분명히 달성 한 것을 볼 때, 그것은 사람들이 과대 평가하고 패딩 (예산을 사용하기 위해 여분의 물건과 애완 동물 프로젝트를 수행)하거나 시간과 보충을 위해 저녁과 주말에 개처럼 과소 평가되고 일했기 때문입니다.

당신은 아마 300 %가 옳다고 들었습니까?

실제로 사용합니다. 내가 몇 년 동안 본 것에 완전히 기초합니다. 하루나 이틀 들었을 때, 실제로 해야 할 일주일 이상 입니다. 그리고 테스트되었습니다. 모든 환경에서. 설명서가 업데이트되었습니다. 사용성 테스트. 성능 테스트. 하중 테스트. 몇 시간은 정말 하루와 비슷합니다.

다음과 같은 이유로 우리가 추정하는 데 정말로 나쁘다고 생각합니다.

• 다른 사람들을 돕기
• 방해받는 중
• 새로운 사람들을 훈련
• 다른 것들이오고
• 아프거나 몸이 나쁘다
• 떠나는 사람들을 덮고
• 휴가 또는 휴가가 필요
• 다른 사람들에 의해 산만 해지기
• 다른 그룹에 의해 유지되고
• 현실보다 지나치게 낙관적이다
• 간헐적 인 테스트 실패에 대한 작업 시간을 할당하지 않음
• 테스트 시간을 쉽게 배제, 특히 자동 테스트 작성

따라서 최고 수준에서 300 % 이상의 견적이 필요한 비즈니스 사람들과 함께, 우리가하는 일은 합리적으로 좋은 견적을 목표로하지만 더 높은 수준의 일반적인 가격입니다. 버전 1이 1 개의 필드를 변경하기 위해 1 명의 사용자 그룹 만 의미하는 경우에도 "사용자 편집 기능이 있습니다".

그것이 올 때 "프로젝트 기간을 추정 할 때 어떤 일이 허용 오차 마진은?" 많은 애자일 환경에서 사용되는이 접근 방식은 알파 또는 베타 버전을 라이브로 구현 한 다음 반복하는 최소 기능으로 질문을 변경하는 데 도움이됩니다.