주로 문제를 파악하는 작업의 시간을 어떻게 추정 할 수 있습니까?

숙련 된 개발자가 패턴과 문제를 해결할 때 코드를 구현하는 데 걸리는 시간을 추정하는 것이 상대적으로 가능하지만, 최종 목표를 잘 이해하고있을 때 어떻게 예측할 수 있습니까? 구현은 95 % 이론 / 문제 해결이며 구현 량이 매우 적습니까?

저의 작업은 종종 잘 정의 된 목표를 달성하기위한 작업으로 구성되지만, 그 목표를 달성 할 수있는 방법을 찾아야하며, 해결책을 이해할 때까지 어떤 추가 장벽이 있는지 명확하지 않습니다. 보다 구체적으로, 나는 종종 코드 생성 또는 자동화 된 코드 조작 도구를 개발하고 있습니다. 솔루션이 완전히 해결되고 도구가 완성되면 실제 변경의 95 %를 매우 빠르게 수행합니다. 그러나 생성 또는 분석 도구가 예측할 수없는 최첨단 사례를 처리하기 위해 해결해야 할 추가 문제 수를 추정 할 방법이 없습니다.

계획을 세우기 위해 회사는 소요 시간에 대한 더 나은 아이디어를 원하지만 솔루션의 각 단계를 해결하는 동안 몇 가지 추가 문제가 발생하는지 알 수 없습니다. 더 나은 견적을 얻는 방법에 대해 잘 모르겠습니다.

너무 멀어지기 전에 Software Estimation : Demystifying the Black Art 는 추정을보고 생각하는 사람들에게 훌륭한 자료라고 할 수 있습니다. 아래의 이미지는 아이디어가 다음에 제시 될 경우 핵심이되는 해당 책의 이미지입니다.

앞서 언급했듯이 추정은 작업을 정확하게 예측하고 계획 할 수있는 중요한 부분입니다. 추정치가 없으면 비즈니스는 시간이 얼마나 걸리는지에 대해 눈을 멀게합니다. 비즈니스에 걸리는 시간에 대해 완전히 잘못된 생각을 갖는 것은 드문 일이 아닙니다. 쉬운 것으로 생각되는 것은 6-8 주가 걸리며 어려운 것은 금요일 오후의 해킹입니다.

첫 번째는 견적을 제공하는 것입니다. 견적 자체는 하나의 숫자가 아니며 약속입니다. "ABC는 얼마나 걸립니까"-> "약 5 일"은 약 5 일을 의미합니다. 그러나 올바른 추정치는 해당 범위 내에서 90 % 확신 할 수있는 범위입니다. "1 ~ 5 일이 걸릴 것이라고 90 % 확신합니다"라고 말하면 다음과 같이 말합니다. "1 일에서 10 일 사이가 걸리므로 5 일이 평균 일 것"이라고 생각하지 마십시오. 이는 추정치가 아니며 시간의 50 %가 잘못 될 수 있습니다.

글쎄, 시간의 50 % 이상 프로그래머는 작업 시간에 대한 악명 높은 과소 평가자입니다.

불확실성의 원뿔을 고려하십시오 :

^{_{에서 이미지 http://www.construx.com 에서 전체 기사 - http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/}}

해당 범위의 첫 번째 추정치는 16x임을 깨달으십시오. 이것은 "오후 2 주에서 2 주 사이에 걸리는 것 같습니다"라고 말하는 것과 비슷하지만 아직 모릅니다. 디자인을 조금 진행하면 범위가 4 배로 줄어 듭니다. 이것은 않습니다 하지 예, 추정치가 올라 갔다뿐만 아니라 추정의 범위는 갔다 - 그것은 일주일 걸릴 것을 의미, 당신이 대신 "이것 좀보고 후, 3 주 사이에 걸릴 것"말하는 것을 의미 내려가는.

각 추정치에 대해 추정치가 해당 범위 내에 있는지 90 % 확신해야합니다. 당신은 틀릴 수 있습니다-시간의 10 %가 그 범위를 벗어날 것입니다.

프로젝트 규모를 추정하는 방법 에는 여러 가지가 있습니다. 프록시를 사용하여 (작성하는 데 오랜 시간이 걸리는 1000 줄의 코드가 필요하다고 생각합니다) 함수 포인트 (LOC로 변환하는 데 사용)를 사용하여 여러 프로젝트에서 견적을 얻은 다음 과거 프로젝트와 비교 반복적으로 수정하면 ... 일부 프로젝트에서는 일부 작업, 다른 프로젝트에서는 일부 작업이 있습니다.

매우 내가 맨 위에 언급 한이 책의 중요한 장에서는 다루는 # 23 정치 추정 및 관리자와 경영진을 다루는.

추정의 핵심은 약간 작업 한 후에 정제하는 반복 프로세스입니다.

프로세스 초기에 너무 정확한 추정치를 제공하면 오류가 발생하기 쉽습니다. 확실하지 않은 경우 넓은 추정치를 제시 한 다음 일정 시간이 지나면 문제에 대해 더 많은 내성을 조사하고 어떻게 수행 할 것인지를 스케치하여 작성한 코드의 양을 확인하여 다른 추정치로 다시 돌아옵니다. 마지막 유사한 문제 및 추정에 영향을 줄 기타 요인.

추정에는 약간의 생각이 필요합니다. 커프 추정값을 포기하지 마십시오. 이것들은 종종 조금 생각할 때 걸리는 것과 비교하여 큰 오류가 있습니다.

에서 당신이 견적을 요청하는 경우 대응하는 방법?

견적 요청시 할 말

"다시 연락하겠습니다."

프로세스 속도를 늦추고이 섹션에서 설명하는 단계를 수행하는 데 시간을 투자하면 거의 항상 더 나은 결과를 얻을 수 있습니다. 커피 머신에서 주어진 견적은 (커피와 같은) 당신을 괴롭힐 것입니다.

소프트웨어 추정의 4 장에서 :

이것에서, 약간의 검토 후의 추정치는 커프 추정치보다 체계적으로 덜 거칠고 오류가 발생하기 쉽다는 점에 유의하십시오. 커프 추정값을 제거하지 마십시오. 앉아서 작업에 대해 생각하고 약간의 생각 후에 평가하십시오.

보스 : AJ, 개 3 마리, 토끼 2 마리, 투석기, 수녀가 있습니다. 우리는 개가 토끼를 먹지 않고 수녀를 익사시키지 않고 20 피트 벽을 넘어 반대편의 호수로 7 개 (예, 투석기도)를 모두 얻는 방법을 찾아야합니다. 솔루션을 만드는 데 얼마나 걸립니까?

문제를 해결하는 데 걸리는 시간을 추정하는 문제는 사람들마다 다른 시간이 걸린다는 것입니다. 비슷한 문제를 해결 한 이력이있는 경우 이전에 걸린 시간을 기준으로 추정 할 수 있습니다. 그렇지 않으면 추정하지 않고 추측하는 것입니다.

또한이 문제에는 수용 가능한 해결책이 없을 수도 있습니다. 또는 솔루션에 전체 프로젝트를 중단시킬 수있는 추가 권한 부여가 필요할 수 있습니다. 또는 솔루션이 문제의 전체적인 본질을 변경하여 솔루션이 완전히 불필요하게 될 수 있습니다.

이야기의 교훈은, 합리적인 추정을하기에 충분한 정보가 없다면 , 그렇지 않다는 것 입니다. 아직. 자세한 정보를 얻으십시오. 더 연구하십시오. "2 일 후에 더 확실한 숫자로 다시 연락 드리겠습니다."라고 말하는 것이 좋습니다.

고객을위한 솔루션을 설계 할 때 솔루션의 모양과 프로젝트 소요 시간을 알 수있는 일반적인 설계가 완성 될 때까지 계약서에 서명하지 않습니다. 즉, 초기 비용을 지불하지 않은 초기 디자인 작업 (프로젝트를 거치지 않은 경우)을 수행 할 위험이 있지만 작업 수행에 대한 대금이 과소 청구되는 것보다 낫습니다. .

tylerl 과 MichaelT 의 답변 사이 에 다음과 같은 것을 시도해보십시오 .

• 3 또는 4 단계로 수행 할 작업을 분할합니다. 단계는 다음과 같아야합니다.
  1. 문제 분석
  2. 솔루션 프로토 타이핑
  3. 실제 솔루션
  4. 출력 평가 (테스트)
• 경험에 따라 1 단계 (분석) 또는 1 + 2 단계 (분석 + 프로토 타입)에 대해서만 견적을 제공하십시오. 그런 다음, 문제 1 단계와 2 단계가 완료 될 때 (또는 적어도 예상치에 대한 확신을 가질 수있을 정도로 충분히 진행된 경우) 3 + 4 단계에 대한 추정치를 제공하십시오.

배후의 이론적 근거는 주어진 코드베이스 (아마도 크기에 따라 다름)를 분석하기 위해 X 일이 필요하고 기본 도구 나 스크립트가 실행 중이거나 실패 할 가능성이 있다는 사실을 경험으로 알고 있다는 것입니다. 그런 다음 오류 수에 따라 실제 작업의 실제 난이도에 대한 정보가 제공됩니다.

이것은 경영진이 원하는 것이 아닐 수도 있지만, 실제로 귀하가 실제로 충족 할 것으로 예상되는 수치를 제시하는 것이 좋습니다.

이 질문은 주로 연구 유형의 작업에 관한 것이므로 소프트웨어 개발자에게 용감한 접근 방식을 요구 하는 것이 일반적입니다. 일반적인 지표는 소프트웨어 개발자가 예상 한 것보다 두 배나 오래 걸린다는 것입니다. 그러나 연구 (및 아키텍처 설계) 작업은 프로그래밍의 많은 부분이며 종종 생략되거나 최소화됩니다. 그들은 또한 종종 추정하기 어렵다.

내가 스스로에게 물어보아야 할 첫 번째 질문 은 이것이 해결할 수있는 문제입니까? 이것은 지성이나 뇌력 문제가 아니라 실제 현실 중 하나입니다. 실패가 예상되는 결과 인 Google 문 샷의 세계에 있지 않는 한 어려운 현실은 이것이 무엇이든간에 이것을 제공 할 것으로 예상됩니다 . 대략적인 경험 법칙은 솔루션의 90 %가 무엇인지 이미 알고있는 것 같습니다.

두 번째 질문 은 해결책에 대해 생각할 때 알아야 할 다른 것이 무엇입니까? 이것은 실제로 이중 확인하는 방법입니다. 수용 가능한 솔루션을 생각해 낼만큼 충분히 알고 있습니다. 솔루션이 필요한 것을 더 잘 정의하는 데 도움이 되는 일련의 사실 찾기 작업을 생성 할 수 있습니다. 각 작업은 일반적으로 정의 및 추정이 매우 쉽습니다.

세 번째 질문은 누가 이런 종류의 문제에 가장 적합한가? 이 작업을하는 사람은 자신의 스타일로 결과를 맛볼 것입니다. 작업을 시작할 때 천만 개의 질문이있는 프로그래머에게 이런 종류의 문제를 주었다가 사라지고 처음으로 무언가를 전달하는 (느리기는하지만) 프로그래머에게 빠른 구현을 제공하는 것보다 더 나은 선택 일 수 있습니다 그러나 문제가 발생하면 프로세스가 끝날 때만 발견됩니다.

그런 다음 실제 작업 은 가능한 솔루션, 구현 및 접근 방식에 대해 생각하고보고해야하는 고정 된 시간 척도를 갖는 것입니다.

그들이 다시보고하면, 솔루션이 아직 명확하게 정의되지 않았기 때문에 더 광범위한 솔루션을 얻거나, 솔루션 구현을 계속 진행하거나, 반영 할 수 있습니다.

무엇을해야하는지에 대한 명확한 생각은 말할 것도없고, 답이 전혀없는 것이 확실하지 않은 연구적인 질문으로, 나는 보통 x 번의 시간을 시작으로 제안합니다.

"이것이 가능한지 모르겠지만, 이틀을 연구하는 데 쓸 수있었습니다. 아마도 우리에게 해결책을주지 않을 것입니다.하지만 아마도 몇 가지를 배제 할 수있을 것입니다. 구체적인 다음 단계가 무엇인지, 그리고 어떤 종류의 시간 투자를 의미하는지에 대해 다른 단계를 밟아야하는지 여부를 결정할 수 있습니다. "

따라서 다른 방향으로 불확실성을 넣으십시오-견적은 매우 정확합니다 (이틀을 보낼 것입니다). 그때까지 달성 할 내용은 매우 불명확합니다.

기본적으로 타임 박싱.