나는 추정치에 빠진다. 누군가가 시간이 얼마나 걸리는지 묻자 마자, 나는 마크에서 완전히 벗어날 것이기 때문에 추측조차하지 않습니다. 일반적으로 나는 너무 낙관적이며 아마도 내 추측에 큰 X 요소를 곱해야합니다 ...
더 나은 견적을 얻는 방법을 배우려면 어떻게해야합니까? 그것은 내 대학에서 가르치지 않으며, 우리는 모든 노동에 대한 마감일이 있지만 실제로 실제로 얼마나 오래 걸릴지 생각하지 않습니다. 어느 것이 좋을까. 모두를 위해 (특히 내).
답변:
나는 아직도 그것에 능숙하지 않지만, 나는 당신이 작업에 대한 추정 시간과 실제로 걸리는 시간을 추적하는 것이 큰 도움이 될 수 있음을 발견했습니다. 그렇게하면 일반적으로 얼마나 멀리 있는지 확실하게 알 수 있습니다. 시간 추적 기능이있는 문제 관리 소프트웨어 (제 경우에는 Jira) 나 스프레드 시트가 큰 도움이 될 수 있습니다.
나는 그것이 무엇보다 경험이라고 생각합니다.
시간 관리의 머피의 법칙 : 긴 뭔가 방법을 알아낼 것 , 그것이 얼마나 알아낼 걸릴 한다 가져 가서 배를.
그런 다음, 더 높은 다음 시간 단위로 이동하십시오. 따라서 하루 프로젝트에 2 주를 할당합니다.
함께 모아서 배울 수 있습니다 .
Planning Poker를 사용 합니다. 그것을 합의를 기반으로 추정하는 기법.
귀하의 추정은 추적하여 효과적으로 수행 한 것과 비교되어야합니다. 당신은 속도 를 얻을 것이다 .
당신이 무언가를 추정 할 때마다 정확한 추정치 를 얻기 위해 최근의 속도를 곱하십시오 .
Steve McConnell (MS Press)의 소프트웨어 견적은 좋은 평가입니다.
소프트웨어 견적의 주요 내용은 다음과 같이 요약됩니다.
과거 정보가 없으면 추정치가 쓸모가 없습니다.
이것이 왜 반복 프로젝트가 대형 단계별 폭포 프로젝트보다 훨씬 더 많은 성공을 거둔 이유라고 생각합니다. 그들은 그들이 생각해야 할 것의 블랙 박스 부두 이외의 정보가 거의없는 한 번에 1 년 동안 계획을 세우려고하지 않습니다. 매번 반복 할 때마다 재 추정 / 재 계획하고 있으며 추정치를 기반으로 마지막 반복이 있습니다.
명심해야 할 몇 가지 사항 :
Robert Martin의 The Clean Coder에 설명 된 PERT 스타일 추정 기법을 언급 한 사람이 아무도 없습니다 . 이 방법에서는 낙관적 ( O), 공칭 ( N) 및 비관적 ( P)의 3 가지 시나리오에 걸리는 시간을 추정합니다 . 그런 다음 예상 지속 시간 = (O+4N+P)/6과 표준 편차가 나타납니다 (P-O)/6.
이것은 꽤 잘 작동하는 것으로 보이며 경영진이 실제로 시간이 오래 걸리는 것에 관심을 가질 때 몇 번 사용했습니다.
다른 사람들이 언급했듯이, 나는 또한 과거 데이터를 조사하여 추정을했습니다 ( "이와 비슷한 일을하는 데 얼마나 걸렸습니까?").
그러나 내가 가장 좋아하는 방법은 시간 추정을 전혀하지 않고 포인트 추정 만하고 반복 속도를 얻는 것입니다. 팀이 작업의 크기를 정하고 완성하는 데있어 일관된 경우 (사용자 스토리) 각 작업에 소요되는 시간을 묻지 않아도되므로 많은 시간을 절약 할 수 있습니다.
시간 추정치가 너무 어려워서 효과적으로 측정하기에 충분한 양의 덩어리로 세분화하려면 많은 작업이 필요합니다. 심지어 변수가 너무 많아 질병, 휴가 또는주의 산만 등을 설명하는 것을 잊어 버렸습니다.
시간 단위로 견적을해야하는 경우 반복 내에서 작은 작업에 대해서만 평가하려고합니다. 반일 추정치 (4, 8, 12 시간)로 모든 것을 측정 할 수 있습니다. 그러나 나는 1 시간 이내에 아무것도 추정하지 않습니다.
가장 중요한 것은 프로세스를 정의하고 준수해야합니다. 프로세스의 각 단계가 끝나면 계획을 수정하십시오. 프로세스를 순서대로 수정할 수도 있습니다.
둘째, 어떤 종류의 디자인을하십시오. 디자인은 계획의 첫 단계이며, 그림이없는 집을 짓지 마십시오.
셋째, 시간 (노력)을 추적하십시오. 최소한 차별화해야합니다.
사용자와의 수락 테스트 (고정 결함 포함)
각 테스트 유형에 대한 결함 수정 노력을 측정하면 좋을 것이지만 복잡성을 추가하여 나중에 할 수 있습니다.
넷째, 추정을위한 주요 기본 항목을 식별하십시오. 예를 들면 다음과 같습니다.
다섯째, 기본 항목과 노력을 서로 연관시킵니다. 예를 들면 다음과 같습니다.
여섯째, 각 프로젝트의 성과와 추정치의 편차를 추적하십시오. 따라서 상관 계수를 미세 조정할 수 있습니다.
일곱째, 반복하고 개선하십시오. 첫 번째 프로젝트가 끝날 때 많은 통찰력을 얻을 수 있으며, 세 번째 프로젝트는 계획과 추정이 쉬워집니다.
http://en.wikipedia.org/wiki/Personal_Software_Process를 살펴보십시오 . 실제로 작동합니다.
추정 문제가 발생할 때마다 더 작은 조각으로 나누십시오. 그런 다음 조각과 비슷한 작업을 이미 수행했는지 확인하십시오. 가지고 있다면, 각 조각이 얼마나 오래 걸리는지 이미 알고 있어야합니다. 그렇지 않은 경우 다양한 종류의 작업에 소요되는 시간을 적극적으로 추적해야합니다. 이것은 향후 추정에 도움이 될 것입니다.
통합 및 테스트에 시간이 필요하기 때문에 필요한 총 시간은 개별 조각의 합계보다 더 큽니다.
비슷한 일을하지 않았다면 아마도 다른 사람들의 경험에 의존하고 그들로부터 견적을 얻을 수있을 것입니다. 그러나 액면가로 이것을 사용하지 마십시오. 경험처럼 당신을 가르치는 것은 없습니다.
대상을 촬영하는 것과 같습니다. 추정 시점의 이전 샷은 마크가 얼마나 벗어 났는지 알려주므로이를 수정할 수 있습니다.
위에서 언급 한 것처럼 최소한의 작업으로 나누는 과정을 수행하는 것이 가장 쉬운 것으로 나타났습니다. 그런 다음 함께 추가하고 50 %를 추가합니다. 이상적인 조건에서 대략적인 프로젝트 시간을 제공합니다. 작업이 실제로 다른 사람과 병행하여 진행되는 경우 더 오래 필요합니다. 다른 사람들을 기다려야한다면 생각보다 2 배 더 오래 걸릴 것으로 예상하십시오. 내용이나 피드백 또는 기타 정보를 기다리는 데 종종 가능한 것보다 훨씬 오래 걸립니다.
제가 근무하는 곳에서는 프로세스의 각 단계마다 최상의 사례 / 예상 사례 / 최악 사례 견적을 작성합니다. 이는 가이드로 유용하며 견적이 어떻게 진행되었는지 평가하는데도 유용합니다.
작업을 과소 평가하려는 프로그래머의 유혹에 맞서 싸울 수 있다는 점을 제외하고는이 기술은 그다지 중요하지 않지만 중요한 것은 무언가를 전달할 수있을 때 보수적 인 것입니다. 무언가를 만드는 데 7 주가 걸리고 8 주를 약속했다면, 조금 일찍 와서 좋아 보이거나 추가 테스트를 수행하여 신뢰성을 확보 할 수 있습니다. 6 주를 약속했다면 절대 잘못이 아니더라도 나빠 보일 수 있습니다. 의심스러운 경우 보수적으로 추측하십시오.
당신은 목록에 반복되는 특정 것들에 대해 어떤 승수를 가질 수 있는지를 알기 위해 추정치가 무엇인지, 다양한 작업이 실제 레코드가 무엇인지에 대한 트랙 레코드를 만들 수 있습니다. 이것은 시행 착오 운동이지만, 나에게는 잘 작동하는 것 같습니다. 패턴이 나타나기 전에 많은 시련에 대해 할 말이 있습니다. 이것은 아마도 "그냥해라!"로 요약 할 수있는 다른 많은 답변과 비슷할 것입니다. 실제로 우리 대부분이 기술을 개발 한 방식입니다. 추정 할 때 자신이 얼마나 잘못 될 수 있는지 보는 것이 큰 고통입니까? 예,하지만 추정치가 좋아지면 결국 모든 사람이 행복해질 수 있습니다.
여기에 책을 쓰지 않고 "파괴"추정 방법을 사용하는 방법에 대한 약간의 조언을 제공합니다.
과제를 더 작은 구성 요소 작업으로 분류하십시오. 가능한 한 각 작업을 추정하십시오.
계획 및 설계 작업 (현재 수행중인 작업 포함)을 추가하십시오.
아직없는 경우 "작업을 함께 가져 오기"를위한 작업을 추가하십시오. 이 작업은 처음에는 유용하지 않을 수 있습니다. 그러나이 "분할"추정 방법을 사용하면 "작업 사이에 빠짐"과 "작업을 함께 풀"하는 데 시간이 많이 걸립니다. 이것은 추정하기 까다로울 수 있습니다. 최고의 노력을.
테스트 및 문서화를위한 작업을 추가하십시오. 과제는 많은 테스트와 문서화를 요구하지 않을 수 있지만 적어도 그것에 대해 생각하는 데 약간의 시간을 소비해야합니다.
전체 견적을 얻으려면 작업 견적을 합산하십시오.
계속해서 총 추정치에 2 ††를 곱하십시오. 패딩 시간이 다음과 같이됩니다.
그리고 마지막으로, 아마도 완전히 잘못된 것으로 추정되는 것을 스스로 두려워하지 마십시오. 때로는 매우 부정확 할지라도 모든 것을 스케치하면 관련된 일을 더 잘 이해하는 데 도움이 될 수 있습니다.
†† 경험이 늘어남에 따라이 "퍼지 팩터"는 개인 스타일과 작업 환경에 맞게 조정할 수 있습니다.
나 자신을 위해 일할 때 작동하는 공식 :
할 일을 1-4 시간 단위로 세분화하십시오. 나는 보통 이것들로 정확하다는 것을 알았습니다.
'unknowns factor': 알 수없는 수의 2 배를 곱합니다. 즉, couchdb 응용 프로그램을 개발해야하지만 이제는 javascript 및 http에 대해 아무것도 알지 못합니다. 다중 요인으로 2 ^ 2를 추가하십시오.
context-switch-factor : 완벽한 환경에서 일할 경우 (연구 코너 등의 집에서) 1.5로, 또는 불완전한 환경에서 일할 경우 (사무실 / 붐비는 곳 등) 2.5
이 시간은 실제 소요 시간의 +/- 20 % 이내 인 것으로 나타났습니다 !!
자신의 편견을 배우십시오. 다음에 요인 2로 마지막 추정치가 너무 낮은 경우 초기 추정치를 두 배로 늘리십시오. (물론, Hofstadter의 법은 그것을 올바르게하기 어렵게 만듭니다 ...)
또한 이전 작업의 초기 릴리스 이후에 필요한 작업량을 기억하고이를 다음 추정치에 추가하는 것이 좋습니다. 예를 들어, 마지막 작업을 완료하는 데 2 개월이 걸렸지 만 실행 후 지원, 핫픽스 및 추가 변경으로 인해 한 달이 더 소요되므로 다음 번에는 비슷한 작업에 대해 3 개월이 소요됩니다.
오프너의 경우, Barry Boehm의 "Software Engineering Economics"및 Tom DeMarco의 "Controlling Software Projects"를 읽으십시오. 이 두 가지를 읽고 소화 한 후 Barry Boehm의 "COCOMO 2를 사용한 소프트웨어 비용 추정"을 읽으십시오.
다음에 말해야 할 것은 LOT이 확률과 통계 수업, 심지어 기본 요리 책을 수강하는 데 도움이 될 것입니다.
완벽한 견적은 없습니다. 일찍 올 확률은 늦고 올 확률은 늦습니다. Boehm의 원래의 상세한 COCOMO 모델은 실제 결과의 30 % 이내, 시간의 60 %보다 나은 것으로 예측했습니다. 그가 책을 쓰고 출판했을 때의 일반적인 것보다 훨씬 낫습니다.
당신이 최선의 추측을 할 때 (그리고 그 모든 추정치입니다), 당신은 그 확률을 포함합니다. 추정값을 가져 오면 늦게 올 확률이 높아집니다. 추정치를 늘리면 일찍 오거나 제 시간에 끝날 확률이 높아집니다. 잡아 당기거나 빼내는 정도는 확률이 어떻게 변하는 지 제어하며, 조기 또는 늦는 것에 대한 처벌에 반드시 의존해야합니다. (여기에 공포 이야기를 삽입하십시오-수년 동안 많은 이야기가있었습니다!)
DeMarco는이를 어느 정도 해결합니다. 그는 또한 "불가능 영역"이 있다고 지적한다. 어떤 종류의 영웅이 시도 되더라도 일정이 너무 빡빡하다.