---

프로젝트를 이해하기도 전에 전체 프로젝트를 계획해야 했나요? 놀라실 수도 있습니다!

Scrum이 없을 때 저희 팀은 고객의 요구를 충족하지 못하는 완전히 잘못된 소프트웨어와 하드웨어 제품을 만들어 제공했습니다.

직장 생활 중에는 외부 업체들이 소프트웨어 제품이나 서비스를 어떻게 만들어야 하는지 강요한 때도 있었습니다.

역량 성숙도 모델(CMM), ISO 9001:2008 및 그 밖의 파생 방식들은 저희 회사가 올바른 소프트웨어를 올바르게 만들도록 돕고자 했습니다.

그 방식들이 얼마나 성공적이었는지는 이 책의 주제가 아닙니다. 이 책은 거의 사라진 절차를 비판하기보다 Scrum 프로세스와 Scrum 프레임워크의 장점에 집중하고자 합니다.

다만 Scrum 소프트웨어 엔지니어링 프레임워크 이전의 프로세스 개선 프레임워크는 단계적인 접근을 권장했다는 점을 덧붙여야겠습니다. 이들이 권한 단계적 소프트웨어 엔지니어링 접근을 저희는 다음과 같이 불렀습니다. 폭포수 소프트웨어 엔지니어링 모델.

폭포수 모델에서는 각 소프트웨어 프로젝트가 요구사항 분석으로 시작하며 고객이 필요로 하고 원하는 바를 이해하고자 했습니다.

이후 요구사항을 설계하고 구현하고 테스트(검증)하고 소프트웨어 운영 환경에서 유지보수했습니다. 마침내 소프트웨어 엔지니어링 생애주기의 끝에 도달했습니다.

하지만 현실은 그렇게 진행되지 않았습니다!

폭포수 방법론과 Scrum 프레임워크 비교

전통적 폭포수 모델의 단계

폭포수 소프트웨어 엔지니어링 모델의 특정 단계에서 예상치 못한 지연이 발생하면 이후 단계에 악영향이 미치는 것은 피할 수 없었습니다.

연구에 따르면 조사한 실패 소프트웨어 프로젝트의 80% 이상에서 폭포수 방법론 사용이 주요 실패 요인 중 하나였습니다. 그 이유는 무엇일까요?

왼쪽 그림처럼 폭포수 방법론에서는 프로젝트의 각 단계가 엄격한 순서로 연결됩니다. 다음 단계를 시작하려면 이전 단계를 완료해야 합니다. 되돌아가는 일은 대부분 고통스럽고 비용과 시간이 많이 들며 팀을 좌절시킵니다.

프로젝트 일정은 시작할 때 계획합니다. 출시 가능한 제품은 프로젝트 일정의 맨 끝에서만 제공합니다. 한 단계가 지연되면 다른 모든 단계도 지연됩니다.

이를 피하려고 폭포수 방법론의 프로젝트 관리자는 보통 모든 가능성을 미리 예상하려 합니다. 즉 프로젝트의 아주 초기 단계에서 모든 요구사항을 최대한 세밀하고 완전하게 정의하려 합니다. 그러나 초기 단계의 요구사항 정의는 흔히 복잡하므로 프로젝트 전반에 많은 요구사항이 바뀌거나 바뀌어야 합니다.

연구에 따르면 더 크고 복잡한 프로젝트에서는 최초 요구사항의 약 60%가 진행 중 바뀝니다. 나머지는 정의한 대로 구현되지만 일부는 고객에게 실제로 필요하지 않습니다. 따라서 이러한 구현은 고객에게 더 높은 부가가치를 주는 기능에 쓸 수 있었던 시간과 비용을 소모합니다.

프로젝트를 여러 단계로 나누면 관리자는 각 단계를 따로 추정해야 합니다. 문제는 이 단계 대부분이 실제로 분리되어 있지 않다는 것입니다. 함께 병렬로 작동합니다.

예를 들어 합리적인 사람이라면 테스트 단계가 시작하기 전에 개발 단계가 끝났다고 생각할 수 없습니다. 그러나 안타깝게도 폭포수 방법론은 정확히 그렇게 작동했습니다.

소프트웨어 개발의 폭포수 방법론은 작고 단순한 프로젝트 구현에 사용할 수 있습니다. 하지만 더 크고 복잡한 프로젝트에서는 무모하다고 할 만큼 위험한 접근입니다. Scrum 소프트웨어 개발 및 제공 프레임워크보다 비용이 더 드는 경우가 많고 언제나 덜 효율적입니다.

이것이 Scrum 프레임워크 이전의 삶이었습니다. Scrum 역량을 갖춘 전문가의 안내 없이 여러 팀 사이로 소프트웨어를 이리저리 보내며 저희 업무는 관료적이고 복잡하며 비생산적으로 바뀌었습니다.

. 결국 제품만 피해를 본 것이 아니라 직원의 사기와 조직 사명에 대한 헌신도 완전히 무너졌습니다.