예상 프로젝트 완료 날짜를 늘리십니까?

예상 프로젝트 완료 날짜를 늘리십니까?

---

그렇다면 왜? 얼마예요?

나는 지나치게 낙관적이기 때문에 약간 부 풀리는 경향이 있습니다.

---

Hofstadter의 법칙 : 모든 컴퓨팅 프로젝트는 Hofstadter의 법칙을 고려하더라도 예상보다 두 배 더 오래 걸립니다.

---

내재 된 낙관주의를 보상하기 위해 과거의 경험을 바탕으로 추정치를 부 풀리면 부풀려지지 않습니다. 정확한 견적을 제공하려고합니다. 그러나 당신이 항상 보풀 시간을 갖도록 부풀린다면 그것은 그렇게 좋지 않습니다.

---

네, 저는 항상 초기 추정치에 2를 곱하는 법을 배웠습니다. 이것이 FogBUGZ의 Evidence-Based Scheduling 도구가 정말 유용한 이유 입니다.

---

프로그래머에게 대략적인 기능에 대한 시간을 추정하도록 요청하는 조직은 근본적으로 망가졌습니다.

해제 단계 :

1. 기술 프로그램 관리자를 고용하십시오. 개발자는 필요한 경우 이러한 사람들로 두 배가 될 수 있습니다.
2. 기능 요청, 변경 요청 또는 버그가 들어 오면 즉시 데이터베이스에 넣습니다. (내 조직은 Trac을 사용하지만 완전히 좋지 않습니다.)
3. PM이 이러한 요청을 각각 1 주일 이내의 단계로 나누도록하십시오.
4. 매주 회의에서 PM은 그 주에 원하는 티켓을 결정합니다 (마케팅 등의 의견을 통해 가능). 그들은 이러한 티켓을 개발자에게 할당합니다.
5. 개발자는 할당 된 티켓을 가능한 한 많이 완료합니다. 그리고 / 또는 그들은 1 주일보다 긴 작업에 대해 PM과 논쟁합니다. 티켓은 필요에 따라 조정, 분할, 재 할당 등을합니다.
6. 코드는 매주 작성되고 확인됩니다. QA는 항상 할 일이 있습니다. 우선 순위가 가장 높은 변경이 먼저 수행됩니다. 마케팅은 어떤 일이 언제 일어날 지 정확히 알고 있습니다. 그리고 궁극적으로 :
7. 귀사는 소프트웨어 프로젝트의 20 % 성공률 중 오른쪽에 있습니다.

로켓 과학이 아닙니다. 핵심은 3 단계입니다. 마케팅이 복잡해 보이는 것을 원하면 PM (개발자 의견 포함)이 1 주일도 채 걸리지 않는 첫 번째 단계가 무엇인지 파악합니다. PM이 기술적이지 않으면 모든 것이 손실됩니다.

이 접근 방식의 단점 :

1. 마케팅에서 "[X]를 얻는 데 얼마나 걸립니까?"라고 물으면 견적을 얻지 못합니다. 그러나 우리 모두는 그들이 이전에 얻은 추정치가 순수한 허구라는 것을 알고 있습니다. 적어도 지금은 매주 [X]가 작업 중이라는 증거를 볼 수 있습니다.
2. 개발자로서 우리는 매주 작업 할 옵션이 적습니다. 이것은 틀림없이 사실입니다. 하지만 두 가지 요점 : 첫째, 좋은 팀은 할당 할 티켓에 대한 결정에 개발자를 참여시킵니다. 둘째, IMO, 이것은 실제로 내 삶을 더 좋게 만듭니다.

내가 준 2 개월 추정치가 절망적으로 부적절하지만 이미 공식 마케팅 문헌에 나와 있기 때문에 변경할 수 없다는 것을 1 개월 마크에서 깨닫는 것만 큼 낙담 한 것은 없습니다. 나는 내 견적을 변경하거나, 나쁜 리뷰를 받거나, 보너스를 놓쳐서 상위업자들을 화나게하거나, 미지급 초과 근무를 많이한다. 많은 초과 근무가 나쁜 개발자의 표식이 아니라 "열정적 인"개발자의 표식이 아니라는 것을 깨달았습니다. 이것은 독성 문화의 산물입니다.

그리고 네, 많은 것들이 XP, "agile", SCRUM 등으로 (다양하게) 다루어 지지만, 그렇게 복잡하지는 않습니다. 책이나 컨설턴트가 필요하지 않습니다. 기업의 의지 만 있으면됩니다.

---

스코티 규칙 :

• 최선의 추측을하십시오
• 가장 가까운 정수로 반올림
• 그 4 배의 두 배 (Adam에게 감사합니다!)
• 다음으로 높은 측정 단위로 증가

예:

• 3.5 시간이 걸릴 거라고 생각합니다
• 4 시간으로 반올림
• 4 배로 16 시간으로
• 최대 16 일로 변경

따다! 당신은 8 일도 안되는 시간에 일을 마치면 기적의 일꾼입니다.

---

3 ~ 6 주 후에 답변 할 수 있습니다.

---

일반적으로 예,하지만 두 가지 전략이 있습니다.

1. 항상 단일 숫자가 아닌 범위 (예 : 1d-2d)로 추정치를 제공하십시오. 숫자의 차이는 프로젝트 관리자에게 자신감에 대해 알려주고 더 나은 계획을 세울 수 있도록합니다.
2. 같이 사용 무언가 의 Fogbugz '증거 기반 스케줄링 , 또는 개인 스프레드 시트, 실제로 걸린 시간에 역사의 견적을 비교. 그것은 항상 두 배로 늘리는 것보다 더 나은 아이디어를 줄 것입니다. 특히 두 배로 충분하지 않을 수 있기 때문입니다!

---

"부풀리기"라고하는 것이 아니라 "원격으로 현실적으로 만들기"라고합니다.

---

적절하다고 생각하는 모든 추정치를 취하십시오. 그런 다음 두 배로.

---

당신 (엔지니어)이 이상적인 시간 (스크럼 용어)에 실제로 추정하는 것을 잊지 마십시오.

경영진은 실시간으로 작업합니다.

차이점은 이상적인 시간은 중단없는 시간이라는 것입니다 (각 중단 후 30 분 워밍업). 이상적인 시간에는 회의 시간, 점심 시간 또는 일반적인 잡담 시간 등이 포함되지 않습니다.

이 모든 것을 고려하면 이상적인 시간은 실제 시간이되는 경향이 있습니다.

예 : 예상 시간 40 시간 (이상적) 경영진은이를 1 주 실시간으로 가정합니다.

40 시간을 실시간으로 변환하는 경우 :

• 하루에 한 회의 모임 가정 (1 시간 소요)
• 하루에 한 번의 점심 휴식 (1 시간)
• 더하기 20 %의 전담 채팅 화장실 휴식 시간 커피 등

이제 하루 8 시간이 5 시간 근무 시간입니다 (8-회의-점심-워밍업).
80 % 효율성 = 하루에 이상적인 시간 4 시간.

이 40 시간 이상은 완료하는 데 실시간으로 80 시간이 걸립니다.

---

Kirk : Scott 씨, 수리 견적에 항상 4 배를 곱해 보셨습니까?

Scotty : 물론입니다. 기적의 일꾼으로서의 평판을 어떻게 유지할 수 있습니까?

---

경험상 좋은 법칙은 걸리는 시간을 추정하고 다음 문제를 해결하는 데 1/2의 시간을 다시 추가하는 것입니다.

1. 요구 사항이 변경됩니다
2. 빠른 수정을 위해 다른 프로젝트로 이동합니다.
3. 다음 데스크의 새 직원은 도움이 필요합니다.
4. 더 나은 작업 방법을 찾았 기 때문에 프로젝트의 일부를 리팩토링하는 데 필요한 시간

---

<sneaky>
프로젝트의 예상치를 부풀리기보다는 각 작업을 개별적으로 부 풀리십시오. 상사가 이런 식으로 당신의 추정치에 이의를 제기하는 것은 더 어렵습니다.
</ sneaky>

그러나 진지하게 EBS를 사용함으로써 사람들은 일반적으로 큰 작업보다 작은 작업을 훨씬 더 잘 추정한다는 것을 알았습니다. 프로젝트를 4 개월로 추정하면 완료되기까지 7 개월이 될 수 있습니다. 아니면 그렇지 않을 수도 있습니다. 반면에 작업 예상 시간이 35 분이면 일반적으로 거의 옳습니다.

FogBugz의 EBS 시스템은 추정 내역의 그래프를 보여 주며, 내 경험 (다른 사람의 그래프도 볼 때)에서 사람들은 실제로 짧은 작업을 훨씬 더 잘 추정합니다. 그래서 내 제안은 프로젝트의 부두 곱셈을 총계로 전환하는 것에서 전환하여 예측하는 데 훨씬 더 나은 매우 작은 작업으로 미리 분할 시작하는 것입니다.

그런 다음 전체에 3.14를 곱하십시오.

---

원하는 세부 사항에 따라 많은 것이 달라 지지만, 추가 '버퍼'시간은 위험 평가를 기반으로해야합니다. 작업 수준에서 다음과 같은 다양한 버퍼 시간을 설정해야합니다. 고위험 : 50 % ~ 100 % 중간 위험 : 25 % ~ 50 % 낮은 위험 : 10 % ~ 25 % (모두 이전 프로젝트 경험에 따라 다름).

위험 영역은 다음과 같습니다.

• 요구 사항 범위 추정 (# 1 위험 영역은 설계 및 요구 사항 수준에서 구성 요소가 누락 됨)
• 사용되는 기술에 대한 지식
• 자원에 대한 지식 / 자신감
• 귀하의 프로젝트에 영향을 미치는 다른 프로젝트, 자원 변경 등과 같은 외부 요인

따라서 구성 요소 A를 포함하는 주어진 작업 (또는 작업 그룹)의 경우 초기 예상은 5 일이며 요구 사항 범위에 따라 높은 위험으로 간주됩니다. 50 %에서 100 % 사이를 추가 할 수 있습니다.

---

6 주.

Industry standard: every request will take six weeks. Some will be longer, some will be shorter, everything averages out in the end.

Also, if you wait long enough, it no longer becomes an issue. I can't tell you how many times I've gone through that firedrill only to have the project/feature cut.

---

I wouldn't say I inflate them, so much as I try to set more realistic expectations based on past experience.

---

You can calculate project durations in two ways - one is to work out all the tasks involved and figure out how long each will take, factor in delays, meetings, problems etc. This figure always looks woefully short, which is why people always say things like 'double it'. After some experience in delivering projects you'll be able to tell very quickly, just by looking briefly at a spec how long it will take, and, invariably, it will be double the figure arrived at by the first method...

---

It's a better idea to add specific buffer time for things like debugging and testing than to just inflate the total time. Also, by taking the time up front to really plan out the pieces of the work, you'll make the estimation itself much easier (and probably the coding, too).

If anything, make a point of recording all of your estimates and comparing them to actual completion time, to get a sense of how much you tend to underestimate and under what conditions. This way you can more accurately "inflate".

---

I wouldn't say I inflate them but I do like to use a template for all possible tasks that could be involved in the project.

You find that not all tasks in your list are applicable to all projects, but having a list means that I don't let any tasks slip through the cracks with me forgetting to allow some time for them.

As you find new tasks are necessary, add them to your list.

This way you'll have a realistic estimate.

I tend to be optimistic in what's achievable and so I tend to estimate on the low side. But I know that about my self so I tend to add on an extra 15-20%.

I also keep track of my actuals versus my estimates. And make sure the time involved does not include other interruptions, see the accepted answer for my SO question on how to get back in the flow.

HTH

cheers

---

I wouldn't call additional estimated time on a project "inflated" unless you actually do complete your projects well before your original estimation. If you make a habit of always completing the project well before your original estimated time, then project leaders will get wise and expect it earlier.

---

What are your estimates based on?

If they're based on nothing but a vague intuition of how much code it would require and how long it would take to write that code, then you better pad them a LOT to account for subtasks you didn't think of, communication and synchronization overhead, and unexpected problems. Of course, that kind o estimate is nearly worthless anyway.

OTOH, if your estimates are based on concrete knowledge of how long it took last time to do a task of that scope with the given technology and number of developers, then inflation should not be necessary, since the inflationary factors above should already be included in the past experiences. Of course there will be probably new factors whose influence on the current project you can't foresee - such risks justify a certain amount of additional padding.

---

This is part of the reason why Agile teams estimate tasks in story points (an arbitrary and relative measurement unit), then as the project progresses track the team's velocity (story points completed per day). With this data you can then theoretically compute your completion date with accuracy.

---

I take my worst case scenario, double it, and it's still not enough.

---

Under-promise, over-deliver.

---

Oh yes, the general rule from long hard experience is give the project your best estimate for time, double it, and that's about how long it will actually take!

---

We have to, because our idiot manager always reduces them without any justification whatever. Of course, as soon as he realizes we do this, we're stuck in an arms race...

I fully expect to be the first person to submit a two-year estimate to change the wording of a dialog.

sigh.

---

As a lot said, it's a delicate balance between experience and risk.

1. Always start by breaking down the project in manageable pieces, in fact, in pieces you can easily imagine yourself starting and finishing in the same day

2. When you don't know how to do something (like when it's the first time) the risk goes up

3. When your risk goes up, that's where you start with your best guess, then double it to cover some of the unexpected, but remember, you are doing that on a small piece of the project, not the whole project itself

4. The risk goes up also when there's a factor you don't control, like the quality of an input or that library that seems it can do everything you want but that you never tested

5. Of course, when you gain experience on a specific task (like connecting your models to the database), the risk goes down

6. Sum everything up to get your subtotal...

7. Then, on the whole project, always add about another 20-30% (that number will change depending on your company) for all the answers/documents/okays you will be waiting for, meetings we are always forgetting, the changes of idea during the project and so on... that's what we call the human/political factor

8. And again add another 30-40% that accounts for tests and corrections that goes out of the tests you usually do yourself... such as when you'll first show it to your boss or to the customer

Of course, if you look at all this, it ends up that you can simplify it with the magical "double it" formulae but the difference is that you'll be able to know what you can squeeze in a tight deadline, what you can commit to, what are the dangerous tasks, how to build your schedule with the important milestones and so on.

I'm pretty sure that if you note the time spent on each pure "coding" task and compare it to your estimations in relation to its riskiness, you won't be so far off. The thing is, it's not easy to think of all the small pieces ahead and be realistic (versus optimistic) on what you can do without any hurdle.

---

I say when I can get it done. I make sure that change requests are followed-up with a new estimation and not the "Yes, I can do that." without mentioning it will take more time. The person requesting the change will not assume it will take longer.

---

I always double my estimates, for the following reasons:

1) Buffer for Murphy's Law. Something's always gonna go wrong somewhere that you can't account for.

2) Underestimation. Programmers always think things are easy to do. "Oh yeah, it'll take just a few days."

3) Bargaining space. Upper Management always thinks that schedules can be shortened. "Just make the developers work harder!" This allows you to give them what they want. Of course, overuse of this (more than once) will train them to assume you're always overestimating.

Note: It's always best to put buffer at the end of the project schedule, and not for each task. And never tell developers that the buffer exists, otherwise Parkinson's Law (Work expands so as to fill the time available for its completion) will take effect instead. Sometimes I do tell Upper Management that the buffer exists, but obviously I don't give them reason #3 as justification. This, of course depends on how much your boss trusts you to be truthful.

---

My general estimation is guess * 2.5 + 1 week.

참고URL : https://stackoverflow.com/questions/537526/do-you-inflate-your-estimated-project-completion-dates