왜 계획을 만드는 데 실패합니까?

여기를 읽고

목적

잘못되는 요인을 이해하기 위해

통설

프로젝트의 거의 2/3은 비용 견적을 크게 초과합니다

제품 기능의 64 %는 거의 또는 전혀 사용되지 않습니다

평균 프로젝트는 약속 일정의 두 배 이상 걸린다

다섯 가지 문제

작업 완료를 기준으로 함

멀티 태스킹

기능 우선 순위 부족

불확실성 무시

견적 약정

작업 완료를 기준으로

기능 제공을 중시하지 않음

작업은 일찍 끝나지 않는다.

파킨슨의 법칙

“
작업의 양은 완성을 위해 주어진 시간을 모두 채울 때까지 팽창합니다. "

작업 일정은 상관성이 있음

독립적이지 않기 때문에 선행 지연은 후행 지연으로 이어진다

-> 피쳐 기준으로 한다(피쳐란 특징, 특질을 포함한 기능)

멀티태스킹

개인이 3개 이상을 평행하면 생산성이 크게 떨어진다
다중 작업 지연 시 문제 발생

멀티태스킹 및 스케줄링 문제

할당과 착수까지 열림이 있다

실시간 작업 분담이 불가능

개인 할당, 가동률에 초점을 맞춘다

공간(slack)이 없어진다

-> 그룹에 할당

피처 우선순위 부족

작업 완료를 목적으로 한 순서는 기능의 우선 순위와 다릅니다.

작업은 개발 측면의 관점, 기능은 고객 측면의 관점

작업 관점의 순서는 지연시 원래 필요한 피처를 깎습니다.

-> 피쳐로 순서를 지정하는 것으로 필요한 것으로부터 실현할 수 있다

불확실성 무시

프로젝트 초기와 불확실성은 최대

완료 전망에 폭을 갖게 한다

작은 반복 피드백을 반영

-> 계획 자체에서 계획 만들기로 시점이 옮겨진다

견적 약정

견적은 확률이지만 확약은 확률이 아닙니다.

견적이 확약되면 작업이 완료 될 확률은 100 %입니다.

확률이 100 %가되면 다양한 비즈니스 요소, 위험도 분석 및 검토 할 수 있다고 가정합니다

불확실성 콘의 개념에서도 초기에 완전한 분석 및 검토는 불가능

암묵적인 헌신으로 삼는 것은 확률을 낮추는 것일 뿐이다

기존 견적으로 인한 완성 확률은 0 %입니다.

->100%에 접근하는 행동 시점에서 견적과 계획 만들기를 하지 않으면 의미가 없다

책 정보

Mike Cohn (저자), 야스이 히로시 (번역), 카도야 신타로 (번역)
민첩한 견적과 계획 만들기 ~ 가치있는 소프트웨어를 키우는 개념과 기법
htps : // 아 mz 응. 및 / 30CRf 주

잡감

장두에 「적이 있으면 계획은 바뀐다」라는 속담이 기재되어 있다.
적의 상정수만 계획에도 바리에이션을 주는 것이 중요해
그 가정을 어떻게 할 수 있을지 중요하다.