더 큰 소프트웨어 프로젝트에 필요한 시간을 예측하기 어렵다고 설명하는 방법은 무엇입니까?

저는 주니어 개발자이며 더 큰 소프트웨어 프로젝트를 완료하는 데 걸리는 시간을 추정하기가 어렵습니다. 일반적으로 아키텍처를 구성하는 방법을 알고 있지만 수행해야 할 세부 사항과 해결해야 할 문제를 파악하기가 어렵습니다. 따라서 더 큰 프로젝트를 완료하는 데 걸리는 시간을 예측하기가 어렵습니다. 해결해야 할 문제와 해결하는 데 걸리는 시간을 모르기 때문입니다.

소프트웨어 개발자 가 아닌 사람에게 이것을 어떻게 설명 합니까?

당신은 그에게 그녀가 세계의 무인 구석에있는 먼 곳으로 접근하는데 얼마나 걸리는지 추정 할 수 있습니다. 극단적 인 예를 들어, 히말라야에서 알려진 사람이 거의없는 소수의 피크를 선택해 봅시다. 그녀는 여행을 시작하기 전에 끔찍한 준비와 연습이 필요하고 몇 개월에서 몇 년 동안 여행을 지연시킬 수있는 허가증과 좋은 지원 팀이 필요합니다 ... 언덕에 한 번 슬로프, 그녀는 피크 등을 향해 등반을 시작하기 위해 좋은 날씨를 기다리며기도해야 할 것입니다.

그리고 요점은 : 각 소프트웨어 프로젝트는 이전에 아무도 없었던 새로운 산을 오르는 것과 비슷하기 때문에 직접적인 경험을 가진 사람은 아무도 없습니다. 노련한 개발자는 다소 유사한 프로젝트 에 대한 경험을 수집했을지 모르지만 항상 새로운 요소와 놀라움이있을 것입니다. 그렇지 않으면 소프트웨어 프로젝트가 이전의 프로젝트 와 똑같 았다면 절대 아무 소용이 없습니다 .

그 사람에게 설명했습니까? 귀하는 전문 소프트웨어 엔지니어이므로 소프트웨어를 설계하는 사람은 소프트웨어 시스템의 설계 및 구현에 관한 지식과 피드백을 고려해야합니다.

불확실성의 콘은 아마 좋은 시작 지점입니다. 소프트웨어 프로젝트는 더 많은 세부 사항이 알려질 때까지 추정하기 어렵습니다. 또한 요구 사항을 변경하면 견적도 변경됩니다. 프로젝트가 시작될 때의 초기 추정치에는 많은 변동성이 있습니다.

다른 추정 기술에도 관심이있을 수 있습니다. 당신은 당신이 주니어 개발자 일 뿐이라고 언급했습니다. 일반적으로 경험이 많은 개발자는 더 많은 문제를 보았고 해결했으며 예상 시간과 실제 시간을 예상하여 추적했기 때문에 더 나은 추정 능력을 갖습니다. 광대역 델파이 또는 계획 포커 와 같은 추정 기술을 사용하여이를 활용할 수 있습니다 .

주니어 개발자는 지금 예상 시간과 실제 시간을 추적하십시오. Software Engineering Institute에서 개발 한 개인 소프트웨어 프로세스에 대한 정보가 필요할 수 있습니다. 핵심 PSP 서적은 소프트웨어 엔지니어링 분야 , PSP : 소프트웨어 엔지니어 를 위한 자체 개선 프로세스 및 개인 소프트웨어 프로세스 소개 입니다. 개인 소프트웨어 프로세스 소개에는 가장 유용한 주제가 포함되어 있다고 생각합니다. 나는 대부분의 개발자에게 일반적으로 과잉이라고 생각하지만, 개인 생산성을 향상시키고 경력에 지속적으로 사용하는 다양한 기술 (추정 포함)을 연마하기 위해 뽑아서 사용할 수있는 좋은 아이디어와 모범 사례가 있습니다.

더 많은 평가를 할 것이라면 Steve McConnell의 저서 중 두 가지를 강력히 추천합니다. 소프트웨어 견적 : 검은 예술의 비 현실화 (미술과 과학의 평가에 중점을 둡니다)와 빠른 개발 : 야생의 소프트웨어 스케줄 길들이기 (일반 소프트웨어) 엔지니어링 프로세스 및 프로젝트 관리 주제).

문헌을 참조하십시오. 연습 (실험)에 의해 입증 된대로 예상대로 작동하지 않는 복잡하고 종종 모순되는 많은 자료가 있습니다. 적어도 학자들은 책 더미에 흔들리고 있습니다.

필독 : http://en.wikipedia.org/wiki/The_Mythical_Man-Month

신화적인 Man-Month : 소프트웨어 공학에 관한 에세이 는 Fred Brooks의 소프트웨어 엔지니어링 및 프로젝트 관리에 관한 책입니다.이 주제의 핵심 주제는 "늦은 소프트웨어 프로젝트에 인력을 추가하면 나중에 만들어집니다"입니다. 이 아이디어는 Brooks의 법칙으로 알려져 있으며 두 번째 시스템 효과 및 프로토 타입 제작 옹호와 함께 제시됩니다.

Brooks의 관찰은 OS / 360의 개발을 관리하는 동안 IBM에서의 경험을 기반으로합니다. 그는 일정이 뒤처진 프로젝트에 더 많은 프로그래머를 추가했으며, 나중에 프로젝트를 더 지연 시켰다고 반 직관적으로 결론을 내릴 결정이었습니다. 그는 또한 ALGOL 컴파일러를 작성하는 하나의 프로젝트가 관련 작업자 수에 관계없이 6 개월이 소요될 것이라고 주장하는 실수를 범했습니다 (더 이상 필요함). 관리자가 프로젝트 개발에서 이러한 오류를 반복하는 경향으로 인해 Brooks는 "모든 사람이 인용하고 일부 사람들은 그것을 읽고 몇 사람은 그것을 읽음"으로 인해 그의 책을 "The Bible of Software Engineering"이라고 불렀습니다. 이 책은 소프트웨어 공학의 인간 요소에 대한 고전으로 널리 알려져 있습니다 ...

이 견적으로 그들이 무엇을할지 계획을 찾으십시오. 그들은 몇 개월 또는 몇 년이 걸리고 정확한 시간을 얻으려고 노력하고 있는지 알고 싶어합니다 (일반 엔지니어).

프로젝트에서 작업 할 수 있는지 확인한 다음 필요한 경우 더 나은 견적을 작성하십시오.

그들이 계속 추진한다면, 당신은 시간 프레임을 적용 할 수있는 한 많은 작업을 항목별로 분류해야 할 것입니다. 추정치에 영향을 줄 수있는 사항이 발견되면 바로 알려 주겠다고 알려주십시오. 사람들은 보통 놀라움을 피하려고 노력합니다.

소프트웨어를 평가할 수 있다고 주장하는 사람들을 만났지만 어떻게 소프트웨어를 사용하는지 모르겠습니다. 그들 중 누구도 그것을 어떻게 설명 할 수 없었습니다.

컨설턴트로서 고객은 종종 고정 입찰로 일하도록 요구합니다. 따라서 현실적인 입찰가를 준비 할 수 있도록 추정해야합니다. 한 번도 이것에 성공하지 못했습니다. 내가 저축하는만큼 자주 초과 입찰을 할 것이라고 생각하지만, 결코 그렇지 않습니다. 결과적으로 계약에서 많은 돈을 잃어 버리고 회사에서 정규 직원으로 일할 때보 다 훨씬 적은 돈을 벌게됩니다.

소프트웨어를 평가하는 방법을 알려줄 책을 여러 해 동안 찾고 있었지만 아직 찾지 못했습니다.

코더가 아닌 사람에게 이것을 설명하십시오. 업계의 어느 누구도 지속적으로 견적을 충족 할 수 없음을 지적 할 수 있습니다. 새로운 소프트웨어 제품이 사전에 발표 될 때는 항상 발표 된 날짜로부터 몇 개월 또는 몇 년 후에 배송됩니다.

Microsoft와 같은 대기업이 자체 제품을 생산하는 데 걸리는 시간을 추정하는 방법을 알 수 없다면 어떻게해야합니까?

시간당 또는 직장에서 임금을 받든 고객은 항상 이러한 견적을 제공 할 것을 기대합니다. 나는 그러한 추정이 어디에도 가르쳐지지 않을 때 그들이 어떻게 그것을 생산할 것으로 기대하는지, 그리고 나의 추정에 대한 합리적인 근거가 없다.

전체 프로젝트 시간의 추정은 일반적으로 프로그래머가 아닌 프로젝트 관리자가 수행합니다.

프로젝트 관리자가 필요한 전체 작업 목록을 가지고 있다는 사실에 근거하여 인수를 작성할 수 있습니다. 이 목록이 없으면 모든 추정이 '나쁜'추측입니다.

또한 시간은 이용 가능한 인원 수와 요구 사항의 범위와 같은 많은 요인에 따라 달라집니다. 아키텍처만으로는 충분하지 않습니다.

소프트웨어 엔지니어링은 아직 다른 엔지니어링 분야에 비해 초기 단계에 있으며, 예측 가능한 개발 기술이 등장하기에는 충분히 성숙하지 못했다는 점이 또 하나 있습니다.

소프트웨어 엔지니어링도 지속적인 흐름 상태에 있습니다. 기술이 성숙하다고 간주되기에 충분할 때까지 종종 일부 새로운 기술에 유리하게 포기됩니다. 이를 통해 누구나 신뢰할 수있는 견적을 생성 할 수있는 기술에 대한 충분한 경험을 얻지 못하게됩니다.

이것을 건설 견적과 대조하십시오. 입찰을 기반으로 계약을 체결 한 것이 아니라 문명이 시작된 이래 인류가 물건을 만들고 있기 때문에 이것은 매우 잘 이해되는 문제입니다.