추정 기술을 향상시키기위한 좋은 팀 구성 활동은 무엇입니까? [닫은]

9

팀원들 (모든 개발자)에게 전달할 프레젠테이션을 준비하고 있으며, 예측 기술 향상에 중점을 둔 짧은 팀 구성 활동을 포함하고 싶습니다. 누구든지 내가 사용할 수있는 팀 구성 활동에 대해 제안하거나 알고 있습니까?

estimation team-building

— 롭
소스

2

추정을 개선하는 것은 짧은 활동으로 수행 할 수있는 것이 아닙니다. 추정치와 실제 시간이 다른 이유를 확인하려면 추정치, 실제 시간 및 사후 부검을 추적하는 데 장기적인 노력이 필요합니다. 또한 시간이 지남에 따라 발전하는 기술입니다. 분석을 통해 실수를 추정하고 배우면 더 나아집니다.

— Thomas Owens

문제가 있으십니까? 견적이 얼마나 정확하고 시간을 내서 개선해야합니까?

— JeffO

@Thomas Owens, 나는 짧은 활동으로 할 수있는 것이 아니라는 것을 알고 있습니다. 좋은 평가 기술을 개발하는 것의 중요성에 대한 인식을 높이기 위해 노력하고 있습니다. 나는 내 질문에 더 구체적이어야했다.

— Rob

2

@ Jeff O, 문제 없음-이들은 신입 사원이며 일부는 경험이 적으며 일반적으로 견적 작업을 돕고 싶습니다.

— Rob

8

Joel On Software의 Evidence Based Scheduling을 확인하면 사람들이 더 정확하게 추정하는 방법을 알 수있는 매우 간단한 방법입니다.

추정 방법을 배우는 가장 좋은 방법은 좋은 요구 사항, 연습, 연습 및 연습을하는 것입니다. Evidence Based Scheduling과 같은 것을 가르치면 연습이 더 효과적 일 수 있지만 실제 연습을 대체 할 수있는 것은 없습니다.

— 몰 피스트
소스

나는 EBS를 좋아한다 (나는 열렬한 FogBugz 사용자이다). 그래도 예제로 사용하는 것에 대해서는 생각하지 않았습니다. 좋은 제안입니다. 나는 그것으로부터 영감을 얻을 것이다.

— Rob

6

Minecraft를 사용한 예제 문제를 제시하십시오.

고객에게는 20x20 블록의 갈색 스텝 피라미드가 필요합니다. 피라미드에는 폭이 10 블럭 이상인 해자가 필요합니다.

간단한 WBS와 예상치를 스케치하기 위해 3 분을주십시오.

2 분 안에 고객이 마음이 바뀌었고 지금은 30x30 피라미드가 필요하다고 말합니다. 남은 시간에 견적을 수정하도록하십시오.

시간이 끝나면 연필을 내려 놓으라고 말하고 이제 개발자가 프로젝트 작업을 시작하지만 해자를 가로 지르는 다리가 없기 때문에 고객이 혼란 스럽다고 말합니다.

그들에게 다리는 개발하는데 X 시간이 걸리고, 과소 평가 된 사람들은 일 어설 것을 요구합니다.

이것은 포인트를 집으로 몰아 올 것입니다.

— maple_shaft
소스

2

나는 이것을 좋아하지만 Minecraft에 익숙하지 않다면 어떻게 당신이 합리적인 견적을 내릴 수 있는지 잘 모르겠습니다. 갈색 계단 피라미드를 만드는 데 걸리는 시간을 어떻게 정량화 하시겠습니까?

— Rob

1

@Thomas Owens, maple_shaft 요점은 개발자에게 이러한 유형의 요구 사항을 발견하는 것의 중요성을 강조하는 것이라고 생각합니다. 컨설턴트로서, 나는 사용자가 요구 했어야했지만 엄청나게 분명하지 않은 것들의 많은 예를 개인적으로 보았습니다. 본인과 개발자는 모두 컨설턴트이며 현재 상황에는 우수한 요구 사항 엔지니어가 없습니다. 따라서 고객이 이러한 유형의 검색 질문을하여 견적을 개선하는 데 도움을주기 위해 노력하고 있습니다. .

— Rob

2

@ unforgiven3하지만 그것은 추정과 아무 관련이 없습니다. 요구 사항 엔지니어링 작업은 개발자에게 해당 될 수 있지만 알려진 요구 사항을 기반으로 추정치 만 사용할 수 있습니다. 요구 사항을 분석, 검증, 검증 및 검색하는 능력을 향상시키는 것은 작업 수행에 걸리는 시간을 예측하는 능력을 향상시키는 것과 별개입니다. 요구 사항 변경, 예상치 변경, 그러나 모르는 것과 예상해서는 안되는 것을 추정하는 것은 불가능합니다.

— Thomas Owens

1

@Thomas Owens, 나는 당신이 알지 못하는 것을 추정하는 것이 불가능하다는 것에 동의합니다. 정확히 어떤 것이 요점인지는 기능에 대한 요구 사항을 발견하고 그것에 대한 가정을 적절한 추정치를 만들기위한 전제 조건으로 검증해야한다는 데 동의합니다. 그러나 몇 가지 고려를 한 후에는 추정 능력을 향상시키는 것이 분리되어 있다는 데 동의합니다. 요구 사항을 발견하는 데 활동을 집중시키는 것이 추정 활동보다 더 유용 할 것입니다. 좋은 점-그들은 분명히 내가 향상시키기 위해 잘못된 기술에 집중하고 있다고 생각하게합니다.

— Rob

1

@ unforgiven3 좋은 엔지니어는 항상 두 가지를 개선하기 위해 노력해야합니다. 요구 사항 엔지니어링을 맡지 않은 위치에 있었지만 문제가있는 사양을 전달 받았습니다. 소프트웨어를 개발하는 모든 사람에게는 소프트웨어를보고 올바른 질문을 할 수있는 기술이 필수적이며,이를 연구해야합니다. 그러나 추정 할 때 질문이 있더라도 항상 추정치를 사양에 기반으로합니다. 오류가 더 큰 창을 그대로 두었습니다 (85 % 대신 75 %의 기회를 주거나 약간 큰 창을 제공함).

— Thomas Owens

1

나는 다음과 같은 점에 대한 미로 생성기 / 솔버를 제안합니다.

하는 것이 재미있다
모든 경우를 처음으로 생각할 수는 없습니다
생성 및 해결 요소는 매우 보완 적입니다.
여기에는 데이터를 저장하는 백엔드에서 데이터를로드하는 프런트 엔드가 포함됩니다.
파일 사양, 디스플레이, 생성, 해결, 최적화, 테스트 등 많은 포인트를 사람들에게 할당 할 수 있습니다.

— 위스 카스
소스

1

"이걸 쓰는 데 얼마나 걸립니까?" 경기. X 시간 안에 라스 베이거스로 운전할 수있는 방법에 대해 자랑하는 사람들의 그룹과 비슷합니다 (여기서 X는 보통 1 시간 안에 누군가가 할 수 있다고 주장 할 때까지 각 브라 가트와 함께 줄어 듭니다). 그래서 코더들에게 : 간단한 목표를 포기하고 각 개인의 의견과 그룹 또는 의견에 대한 합의가 있는지 확인하십시오. hello world를 작성하는 데 얼마나 걸립니까? "쓰기"는 무엇을 의미합니까? "실행"및 "테스트"도 의미합니까? 먼저 시뮬레이션 환경이 필요합니까? 어떤 플랫폼과 어떤 크로스 컴파일러에서 도구가 이미 설치되어 준비되어 있습니까? "Hello world"는 임베디드 플랫폼에서 "쓰기"하는 데 4 일이 걸릴 수 있습니다 (도구 설치, 플랫폼 준비,

팀이 목표를 달성하는 데 걸리는 시간을 결정한 후 실제로 소요되는 시간을 측정하거나 (아마 제안 된 목표가 아닌 실제 목표를 달성하기 위해) 비슷한 목표를 가진 이전 프로젝트를 리콜하십시오. 추정치를 실제와 비교하십시오. 추정치와 실제치 사이의 오차를 크게 과장하고 모든 사람의 결론을 발표하십시오.

— 조나단 클라인 IEEE
소스