주어진 작업을 수행하는 데 걸리는 시간을 예측하는 것은 소프트웨어 개발에있어 가장 어려운 부분 중 하나 인 것으로 보입니다. 현재 진행중인 작업장에서는 반복 작업이 시작될 때 몇 시간 만에 작업을 추정하지만 일단 작업이 완료되면 향후 견적에서 우리를 보좌하기 위해 사용하지 않습니다.견적 과정을 어떻게 개선합니까?
과거 추정에서 수집 한 정보를 사용하여 향후 정보를 수정하는 방법은 무엇입니까?
지금까지 스케쥴링에 대해 가장 흥미로운 접근법 중 하나는 FogCreek FogBugz 6.0 릴리스의 일부인 Evidence Based Scheduling입니다. 시놉시스 및 몇 가지 예를 보려면 위의 Joel의 블로그 게시물을 참조하십시오.
견적이 나왔다면 무작위인지 (환경 파괴, 까다로운 버그 등) 또는 식별하지 못한 것이 있는지 확인하십시오.
에스티메이트가 너무 길면 오랫동안 걸릴 것이라고 생각했던 것이 무엇인지 확인하고 그렇지 않은 이유를 찾아 내십시오.
충분하게 수행하면 개발자가 추정에 도움이 될 것입니다.
예를 들어, 컨트롤러에 대한 테스트 작성이 오래 걸릴 것으로 생각하고 예상보다 짧은 시간이 소요된다고 생각하는 경우 비슷한 범위의 컨트롤러에 대해 다음에 예상 한 값을 유지하십시오 마음.
나는 우리가 합의에 도달 할 때까지 팀원과 반복적으로 예상합니다. 물론, 우리는 실수를하지만 우리는 "속도"요인을 명시 적으로 계산하지 않고 오히려 새로운 추정 토론에서 모은 경험을 사용합니다.
나는 예상 시간이 지금까지 당신을 얻을 것이라는 것을 알았다. 다른 업무, 예상치 못한 상황 또는 프로젝트 영향과의 간섭은 필연적으로 당신의 시간 틀을 변화시킬 것이며 만약 당신이 끊임없이 재 해석한다면 당신은 개발할 수있는 시간을 관리하는데 많은 시간을 낭비 할 것입니다.
여기에서 우리는 시간에 대한 솔루션 경험에 기초한 초기 추정을 제공합니다 (모델을 사용하지 않고 환경에서 충분히 잘 작동하는 것을 찾지 못했지만). KPI를 판단하지 않습니다. 우리는이 마감 기한이 타격을 입을 것이라고 확신하지도 않습니다. 우리의 개발 방식은 대개 반향이며, 우리 비즈니스 요구 사항을 잘 충족시키는 것으로 보입니다.
추정치가 꺼져있을 때 거의 항상 노골적인 원인이 있으며 이로 인해 교훈을 얻을 수 있습니다. 최근 메모리에서 :
사용자 인터페이스가 있다고 가정합니다. 존재하지 않는 .NET 기능 (새 행을 삽입하고 GridView에서 인라인으로 편집 할 수있는 기능). 학습 한 교훈은 추정을하기 전에 선택한 클래스의 기능을 확인하는 것입니다. 이 실수는 일주일에 걸립니다.
ftp 프로세스는 FtpWebRequest가 은행의 보안 FTP 서버와 통신 할 수 있다고 가정합니다. ftp 서버가 현재 디렉토리에 대한 백 슬래시 이외의 것을 반환하면이 클래스에 알려진 버그가 있다는 것을 알게되었습니다. 학습 한 교훈은 '버그'와 '문제'에 대해 클래스 이름으로 '튜토리얼'과 '예'뿐 아니라 '숨겨진'문제가 없는지 확인하는 것입니다. 이 실수는 3 일 걸립니다.
이러한 교훈은 프로젝트 평가 및 개발 "체크리스트"문서로 이동, 그래서 그들은
있는 GridViews 악한 다음 프로젝트를 위해 잊혀지지 않을 것입니다! – DaveDev