프로그래밍 작업을 추정하는 데 얼마나 걸립니까?

9

예를 들어, 프로젝트를 n 개의 개별 작업 제품 (예 : 클래스 또는 기능 또는 컴포넌트)으로 나누면 n * t가 추정에 적합한 시간이되는 시간 t가 있습니까?

estimation

— 마이클 베한
소스

9

그것은 간단합니다. 작업 부하를 살펴볼 시간을 계획하고 대략적인 예상 시간과 예상 시간은 얼마입니까?

— joshin4colours 16

추정치가 항상 잘못되기 때문에 투자 수익 제로 = 소비 시간 제로. 아, 보스를 제외하고는 가짜 추정값을 만들어야합니다. BogoEstimons라고하는 임의의 단위가없는 측정 단위에서 임의의 피보나치 수를 선택하는 민첩한 추정치는 실제 인간 시간 작업 단위의 추정보다 나은 것으로 보입니다.

— Warren P

작업 추정 시간을 예상하십시오. 견적 시작

— 사용자

13

해당 수준으로 세분화하기에 충분한 정보가있는 경우 각 정보에 1 분 이상을 소비해서는 안됩니다. 어쨌든 당신은 옳지 않을 것이지만, 1 시간 후와 마찬가지로 1 분 후에 옳을 것입니다.

반면에 사용자 스토리 에 대해 이야기 하고 있다면, 이해 관계자를 한 방에 데려 가서 견적을 내리기 전에 5 분 동안 질문하는 것이 좋습니다.

어쨌든, 견적을하는 데 많은 시간을 낭비하지 마십시오. 그들은 노력할만한 가치가있을만큼 유용하거나 정확하지 않습니다.

— pdr
소스

3

+1. 그러나 견적이 그다지 유용하지 않다는 것에 동의하지 않습니다. 그들은 더 나은 계획을 세우는 데 도움이되므로 생산성이 높아집니다.

— superM

4

@ superM : 나는 그들이 전혀 유용하지 않다고 말하지 않았습니다. 그들은 확실합니다. 나는 그들이 많은 시간을 소비 할 가치가 없다고 말했다. 작동하는 소프트웨어가 훨씬 유용하므로 많은 시간을 투자하십시오.

— pdr

@ superM : 추정치와 실제 값을 비교 한 적이 있습니까? 이것은 추측의 실제 가치 (정의에 의한 추정)에 대한 훌륭한 교훈을 알려줄 것입니다. 추정은 고전적인 파레토 (Pareto) 일입니다. 20 %의 시간 안에 상당히 좋은 추정치를 얻을 수 있습니다. 더 이상 시간을 낭비하면 5 % 만 향상됩니다.

— JensG

나에게있어 프로젝트에서 더 오래 일할수록 더 나은 견적을 얻는다. 너무 많은 요소와 내가 제어 할 수없는 요소가 있으며 이러한 [프로젝트 별] 요소를 아는 것은 경험과 함께 제공됩니다. 때로는 추정을 피할 수 없으며 때로는 부정확 한 견적으로 고통받는 사람들 사이에 있습니다.

— superM

2

내 경험상, 민첩한 접근 방식의 핵심 '예, 실제로 작동하는'조각 중 하나는 '작업이 하루보다 적게 걸립니다'지침입니다. 하루 이상 걸리는 물건을 추정한다면 꽤 멀어 질 것입니다.

일단 당신이 그것을 해체 할 수있게한다면, 당신은 충분히 했어요. 그게 무엇인지에 관계없이

— 텔라 스틴
소스

2

민첩한 스크럼 방법론에서 Planning Poker 는 전체 팀을 사용하여 스프린트에서 사용자 스토리에 필요한 노력을 신속하게 추정하는 효과적인 방법으로 간주됩니다 (이것이 당신이 말하는 내용이라고 가정). 그렇지 않으면 사용자 스토리의 일부인 단일 작업을 추정하는 데 몇 분 이상 걸리지 않습니다.

개발자 팀을 평가하려는 경우이 합의 기반 기술을 사용하는 것이 좋습니다.

포커를 계획한다는 것은 단일 세션 (1 ~ 2 시간 이내) 내 모든 단일 사용자 스토리에 대해 꽤 좋은 추정치를 얻을 수 있음을 의미합니다.

이것에 약간의 독서를하고 그것을 시도하십시오!

또한 일반적으로 사용자 스토리의 작업은 7.5 시간 (하루의 작업 일)을 초과해서는 안됩니다. 그렇다면 작업을 더 작은 작업으로 나눠야합니다.

— 키아 런 갤러거
소스

1

포커 계획은 실제 단위가 아닌 포인트를 추정합니다. 어떤 종류의 추정치가 실제와 비슷한 지; 야생 엉덩이 게세.

— Warren P

1

예를 들어 1 포인트 작업에 7.5 시간이 걸리는 경우 5 포인트 사용자 스토리에는 30 시간이 걸리고 10 포인트 사용자 스토리에는 60 시간이 걸린다는 것을 알 수 있습니다. 예를 들어, 가장 작은 작업 중 하나를 선택하고 예상 시간을 단일 사용자 스토리 포인트의 값으로 할당 할 수 있습니다. 그런 다음이 사용자 스토리를 더 큰 작업을 추정하기위한 기초로 사용할 수 있습니다. 다른 작업에 두 배의 시간이 걸린다고 생각되면 2 개의 사용자 스토리 포인트 (15 시간) 등을 할당합니다.

— Ciaran Gallagher

1

나는 그것이 당신이 필요로하는 것에 달려 있다고 생각합니다. 예를 들어, 프로젝트의 자원 할당이 프로젝트에 의존하는 경우 (이 경우와 같이) 신중하게 수행하는 것이 좋습니다. 다른 방법으로, 이런 종류의 필요성이없는 프로젝트를 수행하는 경우 너무 자세하게 설명하지 않을 수 있습니다. 너무 많은 시간을 소비하는 것은 좋은 생각이 아닙니다. 정확한 추정을하는 것은 매우 어려운 일입니다.

Wikipedia에는 불확실성 콘 ( Cone of Uncertainty) 과 불확실성 콘 (Cone of Uncertainty) 이라는 유명한 개념 이 있습니다. 읽어 볼 가치가 있습니다.

— 요크
소스

1

추정치에서 무엇을 얻습니까?

작업 내용에 따라 정확한 개별 견적은 관련이 있거나 (주말에 고객이 비용을 지불하거나 작업 / 스토리가 다른 사람에게 차단되고 정확한 ETA가 필요함) 또는 (백 로그에 200 개의 스토리가 있음) 이야기가 일주일 동안 바뀌면 아무도 죽지 않을 것이며, 많은 수의 평균을 계산하기 위해 추정 오류를 믿고 있습니다).

최소한의 시간 만 투자하면 귀하의 요구에 맞는 추정치를 얻을 수 있습니다. 공식이 없습니다.

개인적으로, 나는 1-2 분 이상이 당신이 아마 잘못된 것을 추정하고 있음을 의미한다고 생각합니다 (분할 또는 발견 계획).

— ptyx
소스

0

실제로 다른 이해 관계자가 상대 우선 순위를 지정하는 데 도움을주기 위해서는 추정이 필요합니다. 따라서 최소한 task1이 task2에 비해 대략 3 배의 노력이라고하는 광범위한 추정치 (시간의 관점에서 그 결과가 매우 정확하지 않더라도)는 유용합니다. 그러한 목표가 무엇인지 (특정 목표를 달성하기 위해) 이해하고 대략적인 추정치를하기 위해서는 많은 시간이 필요합니다.

상대적 우선 순위가 정해지면 일을하는 데 집중하고 견적을 조정하십시오. 다시 말해, 초기 추정치에는 시간을 거의 쓰지 않지만 시간이 지남에 따라 추정치를 세분화하여 프로젝트 계획이 완료 될 때 프로젝트 계획에 좋은 아이디어를 제공하십시오.

— 루시 쉬 노이
소스

0

좋은 추정은 가정이 아닌 사실에 근거한 것 입니다.

따라서 이미 유사한 프로젝트가 있고 이전 예상 시간을 캡처 한 경우 시작 하기에 좋은 평가 기준으로 서버가 될 수 있습니다 . 그러나 프로젝트 범위 에 따라 알 수 없는 아티팩트 가있을 수 있으므로 BA 또는 제품 소유자에게 최대한 빨리 설명하는 것이 좋습니다.

소프트웨어 프로젝트 추정이 본질적으로 정확하지 않다고 말하는 것도 사실 입니다. 그러나 다음과 같은 현실적인 추정 방법이 있습니다.

작업을 수행하는 사람들은 프로젝트 평가에 참여해야합니다
전문가의 참여 : 프로젝트 성공을 위해서는 전문가의 판단이 중요합니다
큰 조각을 범위로 추정
Delphi 기술 사용 : 소프트웨어 프로젝트 추정에 충돌이있을 경우 팀의 의견을 수렴하는 데 도움이되는 방법입니다.
비용을 명심하십시오
작업 수행에 사용할 수있는 할당 된 자원을 명심하십시오.

— 유수 보프
소스

나는 실제로 (시간의 50 % 이상) 실제 소요 시간의 10 % 내에서 정확한 것으로 판명 된 팀이나 개인을 본 적이 없다. 다른 곳의 다른 사람들은 내가 일한 어느 곳에서나 일어나고 있다고 상상하기 어려운 성공을 주장합니다.

— Warren P

"실제 소요 시간의 10 % 이내의 정확도"-실제로 결과가 매우 좋지 않습니다. 또한 프로젝트의 복잡성과 외부 의존성에 따라 증가하는 오차 한계를 고려하십시오.

— Yusubov

그것이 내가 말하는 것입니다. 추정은 짜증나.

— Warren P

네, "실제 소요 시간의 10 % 이내로 정확합니다"

— Yusubov