긴밀한 일정과 일정 압력은 TCO 및 배달 시간에 어떤 영향을 줍니까?

소프트웨어 엔지니어링 관리자 인 친구의 아버지는 "오버런 예약의 가장 큰 원인은 예약 압력입니다."라고 강조했습니다.

연구는 어디에 있습니까? 일정량의 스케줄링 압력이 활력을 주거나, 내가 언급 한 관리자가 옳고 그름입니까, 아니면 "스케줄 압력이 높을수록 배달 시간이 길어지고 TCO가 더 커지는"문제입니까? 소프트웨어 엔지니어링이 압박을 가하지 않고 작동 할 수있는 곳 중 하나입니까? 그러나 실제로 실제 상황의 제약 조건으로 작업해야합니까?

소프트웨어 공학 문헌에 대한 모든 링크를 주시면 감사하겠습니다.

오버런 예약의 가장 큰 원인은 스케줄링 압력입니다.

동의하지 않습니다. 오버런 스케줄링의 가장 큰 원인은 현실을 반영하지 않고 지나치게 낙관적 인 스케줄입니다. 인간의 본성은 어떤 일정 압력이 절대적으로 필요하다는 것을 지시합니다. 일정의 일정 부담없이 발생하는 몇 가지 문제는 흥미로운 문제이며 "최고의 선은 충분합니다." 기술 담당자는 제품을 출시하기 위해 해결해야하는 문제보다는 관심있는 문제를 해결하는 것을 훨씬 선호합니다. 마감 시한 (일명 일정 압력)을 제거하면 제품이 손상 될 수있는 흥미로운 문제에 대처할 수 있습니다.

또 다른 문제는 제품이 "충분히 양호"해야한다는 것입니다. 완벽 할 필요는 없습니다. 엔지니어와 과학자들은 특별한 경우에는 유효하지 않은 단순화 된 가정을 봅니다. 그래픽 디자이너는 다른 사람에게는 보이지 않는 앨리어싱 문제를 봅니다. 프로그래머는 아키텍처에서 제품 동작에 영향을 미치지 않는 사마귀를 봅니다. "최고의 선은 충분히 좋은 것"입니다. 즉, 때때로 우리는 실제로 문제가 아닌 문제로 살아야합니다.

예약 압력이 부족하면 소유 비용이 매우 높은 제품이 만들어집니다. 오버런의 원인은 잘못된 일정입니다. 이것은 다양한 형태로 올 수 있습니다. 노력을 과소 평가하고, 의존성을 설명하지 못하고, 이미 늦은 프로젝트에 사람들을 추가합니다. 몇가지 말하자면.

시간, 품질, 리소스 및 기능 수가 모두 연결되었습니다. 세 가지 중 하나를 수정하고 마지막 프로세스를 예약 프로세스의 출력으로 가져올 수 있습니다.

질문이 공식화되는 방식은 시간이 변수이며 다른 세 가지 (품질, 리소스 및 기능 수)는 모두 고정되어 있음을 의미합니다. 질문은 시간 ^* 을 고정 하고 품질을 띄워서 원근을 약간 변경하면 도움이 될 수 있습니다 .

이제 당신의 질문은 "타이밍 제약이 품질에 부정적인 영향을 미칩니 까?" :이 질문에 대한 대답은 일제히 "예"입니다 연구 확인한다 사람들이 수학 관련 문제에 압력을 악화 할 것을 ^** 친구의 아버지가 바로 그래서, 그들은 광범위하기 전에 연습을하지 않았 음을 (즉, 시도 오십 배 이상).

^** 여기에는 프로그래밍이 수학을하는 것과 유사하다는 암시적인 가정이 있습니다. 나는이 가정이 공정하다고 생각합니다.

예약 압력이 높을수록 배송 시간이 길고 TCO가 더 큽니까?

기술 관리자와 논의하지 않고 관리자가 수행 한 일정은 그 경향이 있습니다. 사실에 근거하지 않은 스케줄링 또는 추정은 실패하기 쉽다 는 것은 매우 명백한 사실입니다 .

또한 증거 기반 예약 을 피하는 관리자 는 다음 프로젝트 실패로 나아가고 있습니다. 이 주제에 대한 많은 연구가 있으며 메트릭 기반 예약 이 올바른 방법입니다.

오른쪽에서 왼쪽으로 예약합니다.

경영진은 항상 자신이 유명한 현실 왜곡 영역을 가진 Steve Jobs라고 생각합니다. 제품 개발 담당자가 교육을받을 때까지 기술 전문가가 아닌 관리자는 초기 프랑스 영화 "Le voyage dans la lune"( "A Trip to the Moon") 이 로켓 과학을위한 것만 큼 ​​정교한 일정에 대한 견해를 가질 수 있습니다 .

문제는 잠시 동안있었습니다. Fred Brooks는 Mythical Man-Month 에서 장없는 평가에 대해 이야기 합니다. Barry Boehm은 경영진 에 대한 이론 -W 접근 방식 에 대한 제안에서 이에 대해 이야기합니다 . 더 최근에, Steve McConnell ( Code Complete의 저자 )은 "비인기 일정을 지키는 방법" 에서 원칙적인 협상 문제의 개념에 초점을 맞 춥니 다 .

애자일은 프로젝트의 범위를 눈에 잘 띄는 곳으로 옮깁니다. 애자일 선언문은 "계약 협상을 통해 고객 협력"을 요구한다. 그것은 또한 책임이있는 사람들에게 힘을 실어주기를 바랍니다. 계획 게임은 요구 사항이나 새로운 발견의 변화에 의해 오버런왔다 그들은 오래 전에 만든 약속 개발자를 강요 비 기술적 인 이해 관계자를 피할 수 있습니다.

귀사에서 민첩성을 거부하는 경우 획득 한 가치를 기준으로 일정을 재조정하기위한 추정치 보정과 관련된 훌륭한 방법이 있습니다 . 나는 가치 창출이 예측과 관련된 실제 문제 중 일부에서 큰 역할을한다고 생각하지는 않지만 프로젝트 속도에 대한 망상을 풀고 우리가 가지고있는 추정치에 대한 추측을 어떻게 든 사실이라고 할 수 있습니다.

코딩을 빨리 시작할수록 시간이 더 걸린다는 말이 있습니다. 일정 압력은 방법론 변경을 강제하는 효과가 있습니다. 때로는 폭포에서 "지옥 같은 코드"까지입니다. 이는 근로자가 최선을 다하지 못하고 동료와 미래의 관리자가 최선을 다하지 않고 최악의 상태를 볼 때 사기를 언급하지 않고 품질에 부정적인 영향을 줄 수 있습니다. 이와 같은 환경에서 어느 정도의 혼란은 소스 제어, 일일 빌드 및 테스트 (또는 지속적인 통합 및 단위 테스트), 코드 검토, 숙련되고 숙련 된 팀을 사용하여 늦게 직원을 추가하려는 유혹에 견딜 수 있습니다. 프로젝트 및 이전 대기 시간.

다른 경우에는 방법론 변경이 폭포에서 반복 증분으로 변경 될 수 있습니다. 저의 경험은 경영진이 애자일을 수용하는 데 느리다는 것입니다. 그러나 얼마 후 애자일을 지원하는 새로운 경영진이있었습니다. 시간 복싱은 예산 책정과 비슷할 수 있으며 제한된 자원을 최대한 활용하는 것에 대해 생각하게 할 수 있습니다. 스크럼 에는 두 개의 시간 상자가 있습니다. 하나는 팀 구성원 간의 피드백을 위해 매일, 다른 하나는 번 다운 목록을 통해 스프린트로 매월입니다.

크리에이티브 커먼즈 라이센스 -http://en.wikipedia.org/wiki/File:Scrum_process.svg 참조

소프트웨어 엔지니어링 문헌이 필요하지 않습니다. 저학년의 개념적 확률과 통계 만 있으면됩니다.

견적은 바로 견적입니다. 정확하지 않으며 보장되지 않습니다. 추정치에 따라, 당신은 그것을 초과하거나 코에 부딪 칠 가능성과 약간 초과 할 가능성이 있습니다.

확률 101 : p (언더런 또는 정확히 맞음) + p (오버런) = 100 %

추정을 기반으로 한 일정은 동일한 특성을 갖습니다.

불확실성을 완전히 제거 할 수는 없습니다. 항상 오버런 가능성이 있습니다. 이란이 사무실 건물을 뚫을 확률은 작지만 여전히 남아 있습니다. 최선을 다하는 것은 모든 것을 바라보고 가능한 한 불확실성을 줄이는 것입니다. 그렇게하면 운이 좋으면 불확실성이 작고 각 측면에서 50 %의 확률로 일정을 갖게됩니다.

이제 생각해보십시오. 일정을 가져 오면 일정을 초과하거나 일정에 정확히 도달 할 확률이 줄어 듭니다. 총계는 여전히 100 %이어야합니다. 그 가능성은 어디입니까? 답은 오버런 확률입니다.

General Dynamics / Fort Worth Division은 이것을 어려운 방법으로 배웠습니다. 그들은 F-16C / D 개발에 대한 초기 추정을 수행하고이를 먹이 사슬에 보냈습니다. 누군가가 1 년을 임의로 잘라서 공군에 보냈다. 직접적인 결과로, GD / FW는 비행 시험에 1 년 늦었고 공군은 행복하지 않았다. ( "1 년 늦음"은 수정 된 일정에 따른 것입니다. 즉, 원래 일정은 목표에 적합하다는 의미입니다.)

집중력을 유지하는 데 도움이되므로 프로젝트에 어느 정도의 압박이 가해 졌다고 생각합니다.

그러나 압력이 현실적이지 않거나 경영진과 기술 담당자 간의 의사 소통이 제대로 작동하지 않으면 압력을 예약하면 품질이 떨어지거나 배달이 늦어 질 위험이 있습니다.

숙련 된 개발자는 완벽한 솔루션이 아니라 충분한 솔루션을 생산할 것으로 예상됩니다 . 따라서 그러한 개발자가 제시 한 추정치는 특정 프로젝트에 충분한 것이 무엇인지에 대한 이해를 이미 반영합니다.

선의 정의에 영향을 미치는 많은 요소가 있습니다.

예를 들어 프로젝트가 몇 개월 지속됩니까? 프로젝트가 1 년 동안 지속되는 경우 프로젝트를 시작할 때 특히 어려운 모듈의 프로토 타입을 신속하게 작성할 수 있으며, 더 일상적인 다른 모듈의 개발에 대한 부수적 인 활동으로 테스트하고 디버깅하는 데 몇 개월이 있습니다. (이 모듈 이 충분히 좋을 때까지 몇 개월에 걸쳐 모듈을 익히 게 할 수 있으므로 처음부터 바로 시작할 필요가 없습니다.)이 전략은 매우 효과적이지만 당신을 신뢰하는 관리자가 필요합니다. 몇 달 동안 프로젝트를 열어 두십시오. 또 다른 (신뢰할 수없는) 관리자는 가능한 빨리 빨리 그 모듈을 끝내도록 강요 할 수 있습니다.

다른 예 : 프로젝트는 릴리스가 하나만있는 제품을위한 것입니다. 그런 다음 신속하게 처리하고 광범위한 테스트를 통해 제품이 예상대로 작동하는지 확인할 수 있습니다 (빠르고 더러움이 충분합니다 ). 반면에, 제품에 2 ~ 3 개의 릴리스가있는 경우 이후 릴리스에 대한 코드의 광범위한 재 작성을 피하기 위해 제품 설계에 시간을 더 투자하는 것이 좋습니다. (이 경우 세 릴리스의 총 개발 시간이 더 길기 때문에 빠르고 더티가 충분하지 않습니다 .)

결론적으로, 경영진과 기술 담당자 간의 잘못된 의사 소통과 현재 진행중인 프로젝트에 대해 충분히 좋은 점에 대한 일반적인 이해가 부족하면 과도한 예약 압력이 발생하여 품질이 나 빠지고 배달이 늦어 질 수 있다고 생각합니다.

처음에는 제대로 할 시간이 없지만 나중에 고칠 시간은 항상 충분합니다.