실제로 90-90 규칙

코드의 처음 90 %는 개발 시간의 처음 90 %를 차지합니다. 코드의 나머지 10 %는 개발 시간의 다른 90 %를 차지합니다.

— 톰 카길, 벨 연구소

실제로 이것이 정확히 무엇을 의미합니까? 그 프로그래머들은 상당한 양의 일을하고 있고 그들 스스로 180 %를 제공하고 있습니까?

다음과 같이 상상해보십시오. 소프트웨어 작업을 시작할 때 비교적 짧은 시간에 많은 양의 코드를 작성할 수 있습니다. 이 새로운 코드는 엄청난 양의 새로운 기능을 추가 할 수 있습니다. 문제는 종종 그 기능이 "완료"와 거리가 멀고 버그, 작은 변화 (소규모 소규모) 등이있을 수 있다는 것입니다. 따라서 소프트웨어는 대부분의 사용 사례를 지원하기 때문에 소프트웨어가 거의 완료된 것처럼 보일 수 있습니다 (90 % 완료). 그러나 소프트웨어는 여전히 작동해야합니다. 이 규칙의 요점은 소프트웨어가 거의 완료된 것처럼 느껴지더라도 소프트웨어를 올바르게 작동하는 상태로 만드는 작업의 양이 "거의 완료"상태에 도달하는 것만 큼 크다는 것입니다. 버그 수정은 종종 시간이 걸리지 만 많은 코드를 생성하지 않기 때문입니다.

문제는 대부분의 개발자가 소프트웨어를 "거의 완료"상태로 만드는 것으로 추정한다는 것입니다. 소프트웨어가 실제로 수행하는 총 노력을 추정하는 것보다 비교적 간단하기 때문입니다.

슬프게도 오늘날에도 여전히 발생하는 일반적인 시나리오에 대한 참조입니다.

1. 팀은 모든 코드를 작성하는 데 필요한 작업량을 추정 (즉 추측)해야합니다.
2. 이 프로젝트는 "시간과 예산을 준수"하라는 수많은 내부 및 외부 압력으로 진행됩니다.
3. 따라서 프로젝트의 상당 부분에 대해 "목표 상"이보고됩니다. 이것은 좋은 진전을 이루기 위해 쉬운 작업을 먼저 선택함으로써 종종 복잡해집니다.
4. 그런 다음 어떤 단계에서 현실을 받아 들여야하는 중요한 시점에 도달합니다. 프로젝트가 제 시간에 완료되지 않고 릴리스 날짜가 뒤로 밀려납니다 (종종 여러 번).

"90 %"는 임의의 수치이지만, 요점을 잘 알 수 있습니다. 추정은 추측이며 잘못 될 가능성이 높으며 (종종 매우 잘못 될 수 있음) 인간의 본성은 우리가 거의 항상 추정치에 도달하도록 보장합니다.

다음과 같은 다른 버전 ( "90-90 규칙"이라고도 함)을 들었습니다.

기능의 90 %를 구현 한 후에도 다른 90 % 를 구현해야합니다. .

두 버전 모두 소프트웨어 제품 개발을위한 노력을 정확하게 예측하기가 어려우며 사람들이 자주 겪는 함정을 말합니다.

• 추정이 필요할 때 통계를 던지고 본질적으로 추측 ( "나는 80 % 끝났다")
• 작업량 감소 (일반적인 작업에 필요한 노력을 과소 평가) 할 때 작성 될 코드의 알고리즘 복잡성에 중점을 둡니다.
• 누락 된 단계 ( "눈에 보이지 않음")
• 기존 코드를 유지하고 변경하기위한 노력을 과소 평가
• 상용구 / "접착제"코드에 필요한 과소 평가 노력

이 규칙은 80-20 규칙을 보완합니다. 이제 80-20 규칙에 대한 여러 가지 해석이 있지만 가장 좋아하는 두 가지는 다음과 같습니다.

1. 최초의 80 % 제품 개발은 노력의 20 %를 차지합니다.
2. 오류의 80 %가 코드의 20 %에 있습니다.

실제로 이것은 다음을 의미합니다. 개발이 시작되어 첫 번째 지연이 발견 될 때까지 특정 시점까지 진행됩니다. 지연은 다양한 특성을 가질 수 있습니다.

• 품질 관리 불량, 버그 발생
• 고객이 따라야 할 추가 요구 사항 (이 이유도 여러 가지 일 수 있음)
• 처음부터 불명확 한 요구 사항으로 인해 이전 개발의 일부가 삭제됨 (회귀 버그가 발생할 수도 있음)
• 불확실한 범위, 인적 오류 또는 예기치 않은 상황으로 인한 초기 과소 평가. 이러한 예측할 수없는 상황은 병가, 사직, 하드웨어 고장 또는 극단적 인 경우 화산 분 화일 수 있습니다 (아이슬란드의 화산 분화로 인해 현장에서 비행 할 수 없어서 프로젝트를 지연시켜야했습니다).

결론은 목표에 도달하는 것이 실제로 도달하는 것보다 훨씬 쉽다는 것입니다.

나는 Wikipedia의 설명이 상당히 밝아지는 것을 발견했다 .

이로 인해 소프트웨어 개발 프로젝트의 악명 높은 일정을 상당히 과도하게 실행하는 데 최대 180 %가 추가됩니다 (소프트웨어 개발 노력 추정 참조). 그것은 프로그래밍 프로젝트의 쉽고 어려운 부분에 대한 시간의 대략적인 할당과 어려운 부분을 예측하지 못하는 것으로 많은 프로젝트의 지연 원인을 나타냅니다. 다시 말해, 프로젝트 작업에 예상되는 것보다 더 많은 시간과 코딩이 필요합니다.

실제로 이것이 정확히 무엇을 의미합니까? 프로그래머들은 상당한 양의 일을하고 있고, 그들 자신으로부터 180 %를주고 있습니까?

아니요, 프로그래머는 항상 단위 시간당 동일한 양의 작업을 수행합니다. 견적은 과소 평가 비용과 오버런에 관한 것입니다. 180 %는 프로젝트 비용이 발생하는 시간과 비용입니다.

그것은 "생각하는 데 2 ​​배가 걸릴 것"과 "너무 늦을 때까지 (마감일이 다가올 때까지) 잘 지내고 있다고 생각할 것"을 의미합니다.

이것이 실제로 의미하는 것은 사람들이 자신에게 거짓말한다는 것입니다.

프로그래머가 "우리는 90 % 끝났다"고 말하면 기능을 구축하려는 노력의 90 %가 소비되었음을 의미합니다.

프로젝트 관리자가 "우리가 90 % 완료했다면 완료해야합니다"라고 말하면 예산을 통해 90 % (아마도 50 % 완료)라는 의미입니다. 이것은 돈이없고 기대치가 높고 태도가 나쁜 고객입니다.

차이점은 Qa, 버그 수정, 복사 편집, 배포 등 프로젝트를 완료하는 데 코딩 기능보다 많은 노력이 필요하다는 것입니다.

이러한 것들은 프로젝트에서 관리되어야하며 프로젝트 관리자의 책임입니다. 이것은 종종 "프로젝트 완료"의 절반에 불과하다는 것을 깨닫기 위해 "90 % 기능 완료"에 도달 한 새로운 PM을 놀라게합니다.