Scrum vs. Waterfall: 프로젝트에 적합한 방법 선택 방법

프로젝트 관리, 특히 웹 개발의 경우 적절한 프로젝트 관리 방법론을 사용하는 것이 중요합니다. 팀의 프로세스를 지원하고 팀의 사용 사례와 팀에 가장 적합한 프로세스를 찾기 위해 방법론을 선택하여 구현하는 것은 모든 프로젝트 관리자와 조직이 직면하는 과제입니다.

이것이 중요한 이유는 선택한 방법론이 더 쉬운 프로세스를 의미할 수도, 그렇지 않을 수도 있기 때문입니다. 서로 다른 방법론은 개발 프로세스를 설계하고 관리하기 위해 서로 다른 프레임워크를 사용합니다.

하나 또는 다른 하나를 선택하는 것은 프로젝트의 유형이나 조직의 목표에 크게 좌우될 수 있지만, 두 가지 접근 방식 모두 소프트웨어 개발 프로세스에서 활발하게 사용되고 있습니다.

Scrum이란?

Scrum 방법론은 Agile 방법론의 부분집합이며 Agile을 구현하는 가장 인기 있는 프로세스 프레임워크입니다. 1993년 Jeff Sutherland가 럭비팀이 사용하는 Scrum 포메이션을 소프트웨어 개발에 적용하여 만들었습니다. Scrum이 기반을 두고 있는 세 가지 기둥은 다음과 같습니다.

• 투명성
• 검사
• 적응

이 접근 방식은 팀의 작업을 지원하는 일련의 회의, 도구 및 역할을 통해 완성된 제품을 효율적으로 제공하는 데 사용됩니다. Scrum은 프로젝트 완료까지 각 프로젝트에서 고정 길이의 반복을 통해 작동하며, 이를 스프린트라고 합니다. 보통 2주까지 지속되는 각 스프린트가 끝나면 프로젝트의 다음 단계를 논의하는 회의가 열립니다. Scrum은 구조를 제공하는 몇 가지 기본 요소를 따릅니다.

• 스프린트 계획: 스프린트를 시작하고 스프린트 기간 동안 제공할 내용을 정의하는 이벤트
• 일일 스탠드업: 팀이 현재 날짜의 작업을 계획하고 잠재적인 장애물이나 문제를 논의할 수 있는 짧은 일일 회의
• 스프린트 데모: 완료된 백로그 항목을 시연을 통해 검토
• 스프린트 회고: 다음 스프린트를 준비하면서 전체 워크플로우 개선 사항을 논의하는 스프린트 마지막에 열리는 정기 회의

Scrum 방법은 각 스프린트 중에 작업 보드, 차트 및 프로세스 비주얼과 같은 시각 자료를 사용하므로 사람들은 항상 진행 상황을 인식하고 피드백을 지속적으로 제공할 수 있습니다. 이 접근 방식은 팀원들이 개발 프로세스에서 특정 핵심 역할을 수행하기를 기대합니다.

• 스크럼 마스터 – 팀을 용이하게 하고 항상 최고의 관행과 도구가 사용되도록 하는 사람입니다. 스크럼 마스터는 상황을 추적하여 프로젝트를 앞으로 나아가게 하며 팀이 작업 수행 중에 발생할 수 있는 모든 문제를 해결하는 데 도움을 줍니다

• 제품 소유자 – 고객과 개발팀 사이의 연결 고리 역할을 하는 사람으로, 프로젝트 실행에 대한 기대를 명확하게 전달하는 책임이 있습니다

• 개발팀 – 완성된 제품을 만들고 테스트하며 완료될 때까지 각 릴리스를 실행하는 책임이 있는 사람들입니다

Scrum은 복잡하고 혁신적인 프로젝트에 훌륭하게 작동하는 방법으로, 프로젝트 관리에 초점을 맞춘 솔루션을 제공합니다.

Waterfall 방법론이란?

Waterfall 방법론은 Scrum과 마찬가지로 세 가지 주요 기둥을 기반으로 하는 시간 순서대로 작업하는 프로세스를 따릅니다.

• 고정 날짜
• 요구사항
• 결과

Waterfall은 일반적으로 더 보수적인 접근 방식이지만 2021년에도 여전히 널리 사용되고 있습니다. 팀은 더 독립적으로 작업하고 프로젝트 관리는 선형입니다. 요구사항은 프로젝트 시작 시 수집되고 해당 요구사항에 따라 프로젝트 계획이 수립됩니다. 프로젝트의 각 단계가 다음 단계로 이어지므로, 방법론의 이름은 논리적으로 이 'Waterfall' 움직임을 나타냅니다.

Waterfall 방법론은 5가지 주요 단계로 구성됩니다.

• 요구사항 – 다음 각 단계의 계획을 가능하게 하는 프로젝트 시작 전에 모든 고객 요구사항을 수집합니다
• 디자인 – 논리적 설계와 물리적 설계를 포함합니다: 솔루션을 구상하고 이를 명세로 변환합니다
• 구현 – 개발자가 모든 요구사항과 명세를 적용하여 코드를 작성합니다
• 검증 – 고객에게 제품/솔루션을 릴리스하여 검토하고 요구사항을 충족하는지 확인하도록 합니다
• 유지보수 – 고객이 완성된 제품을 정기적으로 사용하기 시작하여 버그 추적 또는 작동하지 않는 기능을 보고하므로 운영팀이 이를 수정할 수 있습니다

Waterfall을 사용하면 팀은 더 독립적으로 작업하며 지속적인 의사소통이나 정기적인 보고가 필요하지 않습니다. 팀은 기능별로 그룹화되며 각 팀이 자신의 부분을 완료하면 개발을 계속해야 하는 다음 팀으로 "인계"합니다.

프로젝트 관리

시작부터 완료까지 어떤 복잡도의 작업, 팀 및 프로젝트를 원활하게 관리합니다.

템플릿 사용 →

Scrum은 어떻게 작동합니까?

프레임워크로서 Scrum은 팀이 긴밀하게 협력하고 지속적으로 소통하는 단위로서 프로젝트를 실행하는 데 도움을 줍니다. Scrum에서 일하는 모든 사람은 자기 조직화를 장려하고 지속적으로 자신을 개선하도록 권장받지만, 동시에 연락을 유지하고 자신의 작업에 대한 잠재적 차단 요소를 전달합니다. Scrum의 구조는 정기적으로 발생해야 하는 몇 가지 변하지 않는 구성 요소, 이벤트, 의식 및 회의로 이루어져 있습니다. 다음은 Scrum에서 일반적으로 사용되는 인기 있는 단계 및 도구 중 일부입니다.

• 제품 백로그 – 제품 소유자와 개발팀 간의 정기 회의로, 현재 스프린트에서 완료해야 할 항목과 원하는 기능의 우선순위를 정합니다
• 백로그 세분화 – 또한 백로그 그루밍이라고 불리며, 각 스프린트 마지막에 제품 소유자와 개발팀 간의 회의로 백로그가 다음 스프린트에 준비되었는지 확인하고 관련 항목과 목표만 선택되었는지 확인합니다
• 스프린트 계획 – 각 스프린트 전 회의로, 제품 소유자가 실행할 상위 항목을 제시하고 팀은 이번 스프린트 동안 완료할 항목을 선택합니다
• 일일 Scrum 회의 – 이미 언급한 15분 일일 스탠드업 회의로 의존성, 목표 및 잠재적 문제를 논의합니다
• 스프린트 검토 – 각 스프린트 마지막 회의로 완료된 작업을 라이브 시연으로 제시합니다
• 스프린트 회고 – 다음 스프린트에서 어떤 변경사항이 필요한지, 무엇이 잘 진행되었는지, 그리고 무엇을 개선할 수 있는지를 성찰하는 회의입니다

의식이라고 불리는 이 회의들 외에도 Scrum 방법론은 작업을 진행하는 데 도움이 되는 여러 도구를 사용합니다. 예를 들어 Scrum 보드는 포스트잇 또는 색인 카드를 사용하여 스프린트 백로그를 시각화하는 데 사용됩니다. Scrum 보드에는 세 가지 주요 범주가 있습니다: 할 일, 진행 중, 완료이며 팀이 새 작업이 나타나면 스프린트 중에 업데이트됩니다.

사용되는 또 다른 도구는 사용자 스토리입니다 – 소프트웨어 기능을 고객 관점에서 설명하고 이를 충족하는 코드를 만드는 데 사용되는 짧은 스토리입니다. 번다운 차트(또 다른 도구)를 통해 미처리된 모든 작업을 명확하게 표시하므로 남은 항목이 스토리 포인트, 이상적 일수, 팀 일수 등으로 표현되어 모든 사람이 계획 방법과 차단 요소가 작업을 중단하는지 알 수 있습니다. Scrum에서 자주 접하게 될 또 다른 용어는 타임박싱으로, 팀이 특정 목표에 할당할 기간을 설정하고 기간이 끝날 때쯤 작업을 중단합니다.

Waterfall 방법론은 어떻게 작동합니까?

Waterfall 방법론은 일반적으로 처음부터 상황을 매우 명확하게 보여주는 프로젝트에 선택됩니다. 즉, 모든 요구사항이 처음부터 제공되고 끝까지 변경될 가능성이 거의 없습니다. Waterfall 모델에서는 비용, 기간 및 설계가 처음부터 설정됩니다.

다음은 Waterfall이 성공적으로 작동하는 도구와 기법입니다.

• Gantt 차트 – Waterfall에서 일할 때 프로젝트 관리자가 사용하는 도구로, 프로젝트의 소작업, 의존성 및 단계를 매핑할 수 있습니다. 각 작업의 기간을 Gantt에 설정할 수 있고 서로 의존하는 작업을 의존성으로 연결할 수 있습니다

• 문서 컬렉션 – 처음부터 Waterfall의 모든 요구사항 문서가 존재해야 하며, 인터뷰, 설문지, 화이트보드 및 기타 도구를 통해 이를 수집하는 전담팀이 있을 수도 있습니다

• 작업 템플릿 – 최종 제품을 완료하기 위해 많은 작업이 필요하므로 Waterfall 방법론에서 프로젝트 관리자는 이러한 각 작업을 분해 구조의 템플릿에 계획하려고 시도하여 팀이 각 단계를 파악할 수 있도록 도움을 줍니다

Scrum의 장점과 단점

Scrum은 소프트웨어 개발에서 선호되는 방법론으로 자주 인식되지만, 마케팅, 영업, 법률 및 관리와 같은 다른 분야에서도 채택됩니다. 그러나 모든 방법과 마찬가지로 프로젝트 관리자가 고려해야 할 특정 장점과 단점이 있습니다.

Scrum의 장점은 다음과 같습니다:

• 높은 투명성과 가시성 – 일일 스탠드업 회의 덕분에 누가 무엇을 하고 있는지에 대한 혼동은 대부분 제거되며 문제는 현장에서 파악됩니다.
• 모두를 위한 소유권과 책임감 – 개발팀은 각 스프린트에서 완료해야 할 작업을 집단적으로 결정할 수 있으며, 더욱 협력하고 소유권과 의존성은 항상 명확합니다
• 진행 중 방향 수정 – 각 스프린트 후 지속적인 피드백 덕분에 변경 사항을 수용하고 다음 스프린트를 위한 새로운 기능을 추가하거나 더 나은 것으로 변경하기가 더 쉬습니다
• 더 나은 비용 절감 – 모든 잠재적 문제와 차단 요소를 조기에 인식하면 비용을 절감하고 품질을 향상시키는 데 도움이 됩니다

Scrum의 단점과 관련하여 넘어갈 수 없는 몇 가지가 있습니다.

• 범위 크리프의 위험 – Scrum에서는 완료 날짜가 설정되지 않으므로 고객이 계속해서 추가 기능과 기능을 요청할 수 있습니다
• Scrum에 대한 숙련도 필요 – 팀이 Scrum이 어떻게 작동하는지 알아야 하며 방법론 내에서 잘 수용하고 기능해야 합니다. 팀원들은 좋은 기술 경험이 필요하고 프로젝트 기간 동안 Scrum의 모든 의식에 커밋해야 합니다
• Scrum Master가 너무 중요함 – 이 역할은 매우 까다로우며 팀의 비생산성의 위험을 유발할 수 있습니다. 제품 관리자와 달리 Scrum Master는 팀을 도와야 하고, 팀을 안내해야 하고, 팀을 지원해야 하고, 팀을 신뢰해야 하지만 팀에게 할 일을 지시하거나 작업을 제어해서는 안 됩니다
• 작업을 제대로 정의하지 못하면 지연이 발생할 수 있습니다 – 작업이 잘 정의되지 않으면 전체 Scrum 프로세스가 실패할 수 있고 각 스프린트 마지막에 많은 부정확성이 있을 수 있습니다

Waterfall의 장점과 단점

입증된 추적 기록에도 불구하고 Waterfall 방법론은 프로젝트 관리자가 정보에 입각한 선택을 할 수 있도록 이해해야 할 장점과 단점이 있습니다.

장점은 다음을 포함합니다:

• 처음부터의 명확성 – Waterfall의 요구사항이 시작할 때 주어지고 철저하고 최종적이어야 하므로 팀의 각 구성원은 언제까지 무엇을 해야 하는지 알고 시간을 효과적으로 계획할 수 있습니다.
• 비용의 정확한 추정 – 명확하게 정의된 요구사항을 통해 제품 또는 솔루션의 총 비용을 쉽게 추정할 수 있습니다

• 생산은 거의 지연되지 않습니다 – 다시 한번, 요구사항이 처음부터 제공되므로 새로운 기능이 나타나서 팀을 위한 더 많은 작업이 생기는 것은 매우 드물고 지연이 피해집니다

• 팀 멤버는 유연합니다 – 특정 역할의 사람들이 프로젝트 중에 오갈 수 있으며 그렇게 할 때 주요 중단을 일으키지 않습니다

• 마일스톤 중심 개발 – Waterfall은 날짜 중심 패러다임으로 데드라인과 마일스톤을 포용하는 방법 유형으로, 완료까지 각 단계에 대한 명확한 이해와 준비를 이끕니다

• 뛰어난 규율 – Waterfall에서는 프로젝트의 모든 측면을 관리하는 데 도움이 되는 조직과 구조를 갖추고 있습니다

Waterfall 방법론의 약점도 언급할 가치가 있습니다. 그 중 일부는 다음과 같습니다:

• 더 긴 배포 시간 – 이 방법은 시간 순서대로 선형 접근 방식을 사용하므로 최종 제품 배포에 더 오래 걸릴 수 있습니다
• 지연된 테스트 – Waterfall에서 테스트는 제품이 완전히 완료될 때까지 시작되지 않으므로 대부분의 버그 또는 설계 문제가 프로세스의 매우 후반에 발견됩니다
• 고객의 잠재적 실망 – 고객이 주기 마지막에 완성된 제품을 보므로 이로 인해 약간의 실망이나 추가 요청이 발생할 수 있고 통합하기 더 어려운 지점에서 새로운 기능에 대한 추가 요청이 발생할 수 있습니다

Scrum vs. Waterfall: 나란히 비교

Scrum과 Waterfall을 소프트웨어 개발 방법론으로 구분하는 주요 차이점을 지적해야 한다면 Scrum은 가치 기반이며 더 짧은 반복을 가지고 있고 Waterfall은 일정 기반이며 명확하게 추정된 비용과 계획을 가지고 있다는 것입니다. 다음은 두 가지 사이의 일부 기본 차이점을 나란히 비교한 것입니다.

• 개발 – Scrum에서는 반복적 개발을 가지고 있고 Waterfall에서는 순차적입니다

• 진행 – Scrum에서는 2주마다 가치 있는 기능의 배포로 진행 상황을 보고 Waterfall에서는 각 단계와 활동에 대한 보고서가 있습니다

• 품질 – Scrum에서는 품질이 표준과 함께 미리 구축되고 Waterfall에서는 제품 품질이 마지막의 광범위한 테스트로 정의됩니다

• 피드백 – Scrum은 팀에 대한 지속적인 피드백과 빠름을 중심으로 정리되고 Waterfall은 늦은 학습에 더 관대합니다

• 팀워크 – Scrum은 제품의 공통 지식과 공유 경험을 갖춘 기능 간 팀을 사용하고 Waterfall은 문서에 저장된 지식 및 훨씬 더 많은 자율성과 독립성으로 작동합니다

비즈니스를 위한 Waterfall 또는 Scrum 선택: Slingshot 살펴보기

Waterfall 및 Scrum 방법론을 더 자세히 살펴본 후 팀에 가장 적합한 방법이 무엇인지에 대한 질문에 답하는 것이 훨씬 쉬워야 합니다. 그러나 각 프로젝트 관리자의 일은 선택한 방법을 올바른 방식으로, 해당 구현을 위한 환경을 만드는 도구와 소프트웨어를 사용하여 구현하는 것입니다.

프로젝트 관리 도구 외에도 Slingshot은 다음을 통해 Waterfall과 Scrum의 구현을 모두 쉽게 할 수 있는 디지털 워크스페이스입니다:

• 한 곳에 파일 유지 – 정확하고 가장 최근에 업데이트된 문서가 필요한 것은 모든 팀의 일상 업무 현실입니다. Slingshot은 모든 클라우드 제공자를 통합하여 모든 파일 업로드 및/또는 링크를 허용하므로 각 팀 구성원은 작업 수준에서 가장 최근에 업데이트된 파일에 액세스할 수 있습니다

• 정의된 작업 – Slingshot은 작업을 정리하고 전체 프로젝트를 시작부터 완료까지 간략히 설명하도록 하며, 모든 파일 사용 가능, 채팅의 토론, 명확한 의존성, 차단 요소 및 소작업이 있습니다

• 모든 단계에서 데이터 분석 – Slingshot을 협력 앱 특성으로 보면, 본질적으로 프로젝트 관리 중추로 기능할 수 있고 팀에 필요한 모든 통찰력을 연결할 수 있습니다 – 작업 추적, 마감일, 유료 캠페인 결과, 프로젝트 진행 상황 및 컨텍스트의 토론

• 명확한 책임감과 마감일 – Slingshot의 전체 프로세스에 대한 기대치가 쉽게 관리되며, 명확한 마감일 개요 (Scrum을 사용하고 2주 스프린트가 있는 경우) 및 책임감 투명성이 있습니다

• 작업의 KanBan 보기 – KanBan은 Slingshot의 보기 유형 중 하나로 무엇이 언제까지 완료되어야 하는지와 각 작업이 진행 상황 측면에서 어느 위치에 있는지 (할 일, 진행 중, 검토 중, 차단됨, 완료됨)에 대한 가장 명확한 개요를 제공합니다

• 집계된 작업 보기 – Slingshot을 사용하면 필터를 만들고, 저장하고, 이를 사용하여 프로젝트에 연결된 모든 관련 하위 작업공간에서 작업을 나타내므로 개별 프로젝트뿐만 아니라 전체 팀을 실행할 수 있습니다

지금 Slingshot을 시도해 모든 상황에서 팀에 가장 적합한 것이 무엇인지 실험하고 배우세요.