익숙하지 않은 기술로 작업 할 때 견적 제공?

내가 익숙하지 않은 프레임 워크 (및 잠재적으로 다른 프레임 워크의 비트)를 사용해야하는 프로젝트에 대한 견적을 제공하기 위해 최근에 새로운 문제가 발생했습니다. 내가 익숙한 것을 자유롭게 사용할 수있을 때 견적을 제공하는 것이 훨씬 쉽지만, 익숙하지 않은 영역에서 작업을 위해 견적을 요청했을 때 분석에 의한 마비가 시작된 것처럼 보입니다.

돌이켜 보면 내 해결책은 틀렸다. 나는 단지 일을 시작했다.

익숙하지 않은 언어 / 기술 / 프레임 워크로 작업해야 할 때 프로젝트와 작업을 어떻게 더 잘 평가할 수 있습니까?

민첩한 교과서의 표준 답변은 스파이크를 수행하는 것입니다. 스파이크는 미지의 것을 탐색하기위한 시간이 많이 걸리는 작업이므로, 결국에는 유용한 추정치를 제공하기에 충분한 정보를 얻거나 그 시점까지 얼마나 많은 시간이 필요한지 더 잘 알 수 있습니다. .

스파이크는 1 시간에서 며칠 이상 지속될 수 있습니다. 그것들은 타임 박스로되어 있기 때문에 어느 한 쪽 당사자와 관련된 위험이 없으며 지출은 엄격히 제한됩니다.

이상적으로는 급증하는 동안이 새로운 프레임 워크로 달성해야 할 몇 가지 간단한 사항을 식별하고이를 사용하여 매우 간단한 솔루션을 설정합니다. 당신이 따라갈 때, 당신은 배우고, 그것이 스파이크의 모든 것입니다.

이를 수행하는 고전적인 방법은 개선입니다. 첫 번째 계획 회의에서 당신은 말합니다;

"모르겠어-우리는 기본적으로 여기서 소프트웨어 연구를하고있다. 그러나 다음 회의에서 몇 달 안에 더 나은 추정을 할 것이다"

그런 다음 연구를 중단합니다. 다음 회의:

"2/4 분기에 걸리는 것으로 보인다. 우리는 수치를 더욱 구체화 할 수있는 프로토 타입을 만들 것이다".

다음 회의:

"이 프로토 타입은 우리가 생각한 것보다 구축하기가 더 쉬웠습니다. 한 달에 더하기 또는 빼기 2/4로 할 수있을 것 같습니다."

등등. 각 단계에서 비즈니스는 프로젝트를 통조림으로 만들거나 계속 진행할 수있는 옵션을 제공하여 완료 날짜를 예상대로 향상시킬 수 있습니다.

이것은 Steve McConnell의 위대한 저서 Rapid Development에 잘 설명 되어 있습니다. 확실히 내가 읽은 "민첩한"책들보다 훨씬 우수하다.

당신은 연구를 할 수 있고 여전히 잘못된 추정치를 내놓을 수 있습니다. JP Lewis의 소프트웨어 견적 에 대한 최대 한계 및 소프트웨어 견적 에 대한 수학적 수학적 한계를 참조하십시오 . 나는 당신이 객관적으로 정확한 추정을 할 수 없다는 것을 추정하거나 연구하려고 귀찮게해서는 안되며, 당신이 도달 한 견적과 함께 이것을 말해야합니다.