시간 추정에 누가 참여해야합니까?

IT 프로젝트에서 :

1. 시간 추정에 누가 참여 해야 합니까? 개발자, 팀장, 스크럼 마스터 등?
2. 누구의 투표 가 가장 중요합니까?

존재해야 할 기술과 관련된 사람들에 대해서는별로 중요하지 않습니다.

• 문제 영역에 대한 이해 – 요구 사항이 모호하거나 높을 때 특히 중요합니다. 비행기에서 티켓 클래스에 관한 작업을 추정하기 위해 여행을 한 적이없는 프로그래머로서 3 또는 4 (경제, 비즈니스, 첫 번째 등)가 있다고 가정하지만 여행에서 일했다면 알게 될 것입니다 수십이 있습니다. 이는 시간이 지남에 따라 개발자가 이러한 종류의 지식을 쌓을 수는 있지만 비즈니스 분석가 또는 전문가 사용자가 관련되어 있음을 의미 할 수 있습니다.

• 기술과 관련 작업에 대한 이해-일반적으로 팀에 대한 자신감이있는 최근 경험이있는 관리자이지만 종종 작업을 수행 할 수 있습니다. 이상적으로는 실제로 작업을 수행 할 사람을 예상대로 구매하는 방식으로 얻는 것이 이상적입니다.

• 추정 과정에 대한 이해 – 이것이 핵심입니다. 적절한 추정을 수행하는 방법, 올바른지 확인하는 방법, 적절한 수준의 우발 상황을 확인, 이중 계산 또는 너무 많은 패딩을 확인하는 방법에 대한 이해가 필요합니다. 일반적으로 PM, 개발 관리자 또는 선임 개발자가이를 제공하지만 일부 프로세스에서는 확실한 견적 템플릿이 필요한 지침을 제공 할 수 있습니다.

이러한 기술은 한 사람이 될 수도 있지만 때로는 세 명 이상이 필요할 수도 있지만 핵심은 특정 사람들이 아닌 해당 기술이 존재하는지 확인하는 것입니다.

즉, 일반적으로 두 사람 이상이 서로의 작업을 점검한다는 추가 보증을 원할 때 두 명 이상을 찾을 것입니다.

누구의 투표가 가장 많이 계산되는지에 관해서는 그렇게 작동하지 않습니다. 토론과 협상입니다. 관리자가 개발자가 추정치가 너무 높다고 생각하는 경우 개발자가 이유를 설명하고이를 정당화하기 위해 압력을 가하지 않는 이유를 설명해야하며 합의에 도달해야합니다. 당신이 그 합의에 도달 할 수없는 경우에 나는 경험으로부터 두 가지를 말할 것입니다 :

(a) 당신이 "원하는"숫자로 가지 말고 그냥 문제를 요구하고 있으며 원하는 것이 작업을 얼마나 빨리 수행 할 수 있는지에 중대한 영향을 미치지 않습니다.

(b) 개발자가 추정치를 과도하게 지배 한 곳을 보았던 거의 모든 경우에, 최종 숫자는 개발자가 자신을 지배 한 사람보다 개발자가 생각한 것에 더 가깝습니다. 위.

(즉, 민첩하게 XP에서 확실하게 XP에서는 규칙이 개발자가 추정값을 제어하고 최종 결정이라고합니다. 사용자가 추정값을 낮추려면 더 간단한 요구 사항을 변경해야합니다.)

이 질문에 대한 모든 답이 있는지 모르겠습니다. 내가 일하는 곳에서는 일반적으로 견적을 제공하는 기능 / 수정을 구현할 팀의 엔지니어가 두 명 있습니다. 따라서 두 엔지니어는 각각 "최소", "최대"및 "예상"추정치를 제공합니다. 우리는 일반적으로 두 추정치가 합리적으로 일관성이 있기를 기대할 수 있기 때문에, 그 수치가 크게 다르면 추가 논의가 필요할 수 있습니다 (아마도 한 엔지니어가 다른 엔지니어는 그렇지 않다는 가정을 했음).

우리의 상황에서는 아무도 "투표"로 간주되지 않습니다. 우리는 일반적으로 두 가지 추정치를 평균화합니다 (이미 동일한 구장에 있지 않은 경우 두 가지를 모두 거부하고 다시 논의를 시작하므로 평균을 취하는 것이 큰 도약이 아닙니다). 추정치는 결국 추정치 일 뿐이므로 정확할 필요는 없습니다 .

내 경험상, 추정은 그 일 자체를 수행 할 가능성이 높은 사람에 의해 수행되는 경향이 있습니다. SCRUM 팀은 교차 기능을 유지하기 위해 노력해야하지만 얼마 후 특정 유형의 작업은 대개 같은 사람들이 수행합니다.

가장 중요한 것은 모든 추정치에 대해 팀의 동의를 얻는 것입니다. 개발자가 추정치가 있다고 생각하면이를 충족시키기 위해 노력할 것입니다. 개발자가 자신이하지 않았고 입력이나 영향을받지 않았다고 추정 할 경우, 동일한 수준의 책임을 느끼지 않으며 초과 인출은 "더 오래 걸릴 것"이라고 설명합니다.

프로젝트에는 비즈니스 요구 사항과 마감일이 하향식으로 표시됩니다. 이것들은 첫 번째 반복에 대한 "주어진 평가"입니다.

이러한 요구 사항은 100 % 알려진 비용을 가진 가장 큰 작업으로 분할되어야합니다 (예 : "로깅 사용"= 2 시간 = " log4j / SLF4J 다운로드 및 플러그인").

추정은 이미 충분한 기술적 전문 지식을 보유한 가능한 최고 수준에서 수행해야합니다.

수정 된 평가는 "비즈니스 가시적 기능"= "이 시간"의 형태로 비즈니스 소유자에게 적절한 수준으로 도달 할 때까지 요구 사항을 삭제 / 변경하거나 마감일을 완화 할 수있을 때까지 다시 이동해야합니다. 그런 다음 물러서십시오. 최종 수렴까지. 실제로 사람들은이 단계를 무시하거나 단순화하는 경향이 있으며, 이로 인해 마감 기한 및 기회 누락과 관련된 위험이 발생할 수 있습니다.

시간 추정에 누구 또는 누구의 참여해야합니까? 개발자, 팀장, 스크럼 마스터 등?

나는 모두 시간 추정에 있기를 좋아하고 우리는 여기서 똑같이합니다.

누가 또는 누구의 투표를 가장 많이 계산해야합니까?

개발자이지만 여전히 팀 작업에 관한 모든 것

프로젝트 구현으로 충전 된 개발자들! 아무도 없습니다!

실제 작업을 수행하는 개발자와 개발 팀 리더는 실제로 얼마나 많은 시간이 걸리는지를 올바르게 추정 할 수있는 유일한 사람입니다. 실제 코드베이스에 익숙한 프로그래머 만이 개발 과정에서 발생할 수있는 잠재적 인 어려움과 함정을 이해할 수 있습니다. 다른 사람들은 모두 '관중'입니다.

또한 개발자가 정확한 견적을 제공 할 수있는 유일한 방법은 비즈니스 사람들이이를 신뢰하고 자신의 전문 지식에 의존하여 예상치가 비즈니스의 기대치를 충족하지 않는 경우 개발자가 불이익을받지 않을 것임을 알 수있는 것입니다.

경험의 법칙 : 개발에 대한 어려움과 해당 코드베이스에 친숙하지 않은 프로젝트 관리자 또는 비즈니스 직원의 추정치보다 3 배 이상 소요됩니다.

거의 20 년 동안 프리랜서 및 대기업의 직원으로 개발자로 일한 사람으로서, 나는 이것이 가장 확실하게 쓴 경험의 많은 이점을 가지고 있다고 말합니다.