뭔가를 하는 데 실제로 시간이 얼마나 걸리나요?[닫은]

Question

내 말은 당신이 수행한 프로그래밍 프로젝트의 이름과 소요 시간을 말해주세요.사장님은 한번도 불평한 적이 없으나 때로는 일이 너무 오래 걸리는 것 같은 느낌이 들 때가 있습니다.하지만 이것도 내가 참을성이 없어서일 수도 있다.비교를 위해 경험을 알려주세요.

나는 또한 일이 원래 계획했던 것보다 항상 더 오래, 때로는 훨씬 더 오래 걸리는 것처럼 보인다는 것을 알아차렸습니다.왜 우리가 계획을 시작하지 않는지 모르겠지만 어쩌면 동기 부여 목적일 수도 있다고 생각합니다.

라이언

Answer 1

단순히 시간을 측정하고, 추정치를 기록하고, 벗어난 평균 비율을 결정하는 것이 가장 좋습니다.이를 감안할 때 일관성을 유지하는 한 작업을 완료할 것이라고 믿었던 시점을 기준으로 실제 시간을 적절하게 추정할 수 있습니다.단순히 평가가 얼마나 나쁜지 결정하는 것이 아니라 피할 수 없는 방해 요소(개인 및 상사/클라이언트 기반 모두)의 규칙성을 고려하는 것입니다.

이것은 조엘 스폴스키(Joel Spolsky)의 작품을 기반으로 합니다. 증거 기반 일정, 필수 읽기, 그는 작업을 작은 크기(최대 16시간) 작업으로 나누고 이를 추정하고 합산하여 최종 프로젝트 총계에 도달하는 것이 다른 중요한 측면이라고 설명합니다.

Answer 2

직감 기반 추정에는 경험이 있지만 합리적인 것을 얻으려면 관련된 작업을 자세히 설명해야 합니다.

사양이나 최소한 몇 가지 제약 조건이 있는 경우 작업 생성을 시작할 수 있습니다(사용자 디자인 페이지, 태그 디자인 페이지, 사용자 구현 페이지, 태그 구현 페이지, 태그 쿼리 작성 등).

이렇게 한 후에는 더해서 두 배로 늘리세요.다른 사람들과 협력해야 한다면 세 배로 늘리세요.

진행하면서 실제 시간을 자세히 기록하여 프로젝트가 완료되었을 때 얼마나 정확했는지 평가하고 추정 기술을 연마할 수 있습니다.

Answer 3

이전 포스터에 전적으로 동의합니다 ...팀의 업무량도 잊지 마세요.프로젝트에 3개월이 걸릴 것으로 예상했다고 해서 그 근처에서 완료된다는 의미는 아닙니다.

저는 소규모 팀(개발자 5명, 리드 1명)에서 일하고 있으며, 우리 중 다수는 한 번에 여러 프로젝트(일부는 크고 일부는 작음)를 진행합니다.프로젝트의 우선순위, 관리의 변덕, 다른 팀의 가용성(필요한 경우)에 따라 프로젝트 작업이 다른 팀들 사이에 분산됩니다.

예, 3개월 분량의 작업은 끝나버릴 수 있지만 6개월 동안 3개월 분량의 작업이 될 수도 있습니다.

Answer 4

저는 1~6개월 동안 혼자서 프로젝트를 수행했는데 항상 원래 예상 금액을 두 배 또는 네 배로 늘리는 경향이 있습니다.

Answer 5

두 프로그래밍 프로젝트를 비교하는 것은 사실상 불가능합니다. 요소가 너무 많아 해당 프로젝트의 측정항목이 다른 프로젝트에만 적용되지 않음을 의미합니다(예: 사용된 특정 기술, 개발자의 이전 경험, 변화하는 요구 사항).이전에 구축한 시스템과 거의 동일한 다른 시스템을 구축하지 않는 한, 귀하의 추정치는 정확할 가능성이 낮습니다.

주의할 점은 동일한 팀과 함께 기존 시스템의 다음 개정판을 구축할 때입니다.얻은 특정 경험은 다음 작업 배치를 예측하는 능력을 향상시킵니다.

추정 방법론에 대한 시도를 너무 많이 보았지만 아무 것도 효과가 없었습니다.그들은 사이비과학적 매력을 갖고 있을지 모르지만 실제로는 효과가 없습니다.

유일한 의미 있는 대답은 민첩한 옹호자들이 옹호하는 것처럼 상대적으로 짧은 반복입니다.짧은 시간 내에 수행할 수 있는 업무 범위를 선택하여 전달한 후 다음 라운드로 넘어갑니다.그런 다음 예산은 단기적으로 할당되며 이해관계자는 자신의 자금이 효과적으로 지출되고 있는지 평가할 수 있습니다.어디로든 이동하는 데 너무 오랜 시간이 걸리면 프로젝트를 버릴 수 있습니다.

Answer 6

호프스태터의 법칙:

'Hofstadter의 법칙을 고려하더라도 항상 예상보다 오래 걸립니다.'

나는 이것이 다음과 같은 이유 때문이라고 믿습니다:

• 일을 할 수 있는 시간을 채우기 위해 일이 확장됩니다.아무리 무자비하게 불필요한 기능을 잘라낸다고 해도 마감 기한이 더 촉박했다면 더 잔인했을 것입니다.
• 프로젝트 진행 중에 예상치 못한 문제가 발생합니다.

어쨌든, 일화를 비교하는 것은 정말 오해의 소지가 있습니다. 그 이유 중 하나는 사람들이 선택적인 기억을 가지고 있기 때문입니다.완전히 최적화된 퀵 정렬을 작성하는 데 2시간이 걸렸다고 말하면 아마도 일주일 전에 해당 작업이 있을 것이라는 사실을 알고 있었고 아이디어에 대해 생각하고 있었다는 사실을 잊어버린 것일 수도 있습니다.아마도 버그가 있다는 사실을 잊고 일주일 후에 고치는데 2시간을 더 소비한 것 같습니다.

나는 계속 진행되는 프로그래밍 이외의 모든 작업을 거의 확실히 생략합니다.회의, 건축 디자인, 내가 알고 있는 것에 막혀 있는 다른 사람들과의 상담, 관리자.따라서 "앉아 코딩"이라는 관점에서 그럴듯해 보이는 작업 속도를 생각하고 그것이 항상 유지될 것이라고 기대하는 것은 스스로에게 불공평합니다.이것이 "더 빨랐어야 했다"는 사실 이후 많은 감정의 원천이 됩니다.

Answer 7

저는 2주에서 1년 단위로 프로젝트를 진행합니다.일반적으로 내 추정치는 꽤 좋습니다. 사후.하지만 프로젝트 초기에는 내 추정치가 너무 크다고 생각되어 대개 당황합니다.

왜냐하면 나는 사람들이 잊어버리는 많은 것들을 고려하기 때문입니다.

• 버그 수정 시간
• 배포 시간
• 관리/회의/교류의 시간
• 요구사항 소유자가 마음을 바꿀 수 있도록 허용할 시간입니다.
• 등

비결은 증거 기반 스케줄링을 사용하는 것입니다(Joel on Software 참조).

문제는 약간의 추가 시간을 계획한다면 문제가 발생하지 않으면 코드 기반을 개선하는 데 사용할 것입니다.문제가 발생하더라도 여전히 예상 범위 내에 있습니다.

Answer 8

나는 Joel이 이에 대한 기사를 썼다고 믿습니다:당신이 할 수 있는 일은 팀의 각 개발자에게 자신의 작업을 자세히 설명하고(수행해야 할 모든 단계가 무엇인지) 각 단계에 필요한 시간을 추정하도록 요청하는 것입니다.나중에 프로젝트가 완료되면 실제 시간과 예상 시간을 비교하면 개발자별 편향을 얻을 수 있습니다.새 프로젝트가 시작되면 시간을 다시 평가하도록 요청하고 여기에 각 개발자의 편견을 곱하여 실제로 기대하는 값에 가까운 값을 얻습니다.

몇 가지 프로젝트를 수행한 후에는 매우 좋은 추정치를 얻을 수 있습니다.