스크럼 vs. 워터폴: 프로젝트에 적합한 방법을 선택하는 방법

프로젝트 관리, 특히 웹 개발의 경우 적절한 프로젝트 관리 방법을 사용하는 것이 중요합니다. 팀의 프로세스에 도움이 되는 방법을 구현하는 동시에 사용 사례와 팀에 가장 적합한 프로세스를 찾는 것은 모든 프로젝트 관리자와 조직이 직면하는 문제입니다.

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

둘 중 하나를 선택하는 것은 프로젝트 유형이나 조직 목표에 따라 크게 달라질 수 있지만 현재 두 가지 접근 방식 모두 소프트웨어 개발 과정에서 적극적으로 사용되고 있습니다.

스크럼이란 무엇입니까?

스크럼 방법론은 Agile 방법론의 하위 집합이자 Agile을 구현하는 가장 널리 사용되는 프로세스 프레임워크입니다. 이는 럭비 팀이 소프트웨어 개발에 사용하는 스크럼 형식을 적용한 Jeff Sutherland에 의해 1993년에 만들어졌습니다. 스크럼의 세 가지 기둥은 다음과 같습니다.

• 투명도
• 점검
• 적응
•  

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

• 스프린트 계획: 스프린트를 시작하고 해당 기간 동안 전달할 내용을 정의하는 이벤트
• 일일 스탠드업: 팀이 당일 작업을 계획하고 잠재적인 장애물이나 문제를 논의할 수 있는 짧은 일일 회의입니다.
• Sprint Demo: 완료된 백로그 항목을 데모를 통해 검토
• 스프린트 회고: 봄이 끝날 때 다음 스프린트를 준비하는 동안 전반적인 작업 흐름 개선 사항을 논의하는 반복 회의입니다.
•  

스크럼 방법은 각 스프린트 동안 작업 보드, 차트, 프로세스 시각적 자료와 같은 시각적 도구를 사용하므로 사람들은 항상 진행 상황을 인식하고 피드백을 지속적으로 제공할 수 있습니다. 접근 방식은 다음과 같이 개발 프로세스에서 특정 핵심 역할을 맡는 팀 구성원에 따라 다릅니다.

• 스크럼 마스터– 팀을 촉진하고 항상 모범 사례와 도구가 사용되도록 하는 사람입니다. 스크럼 마스터는 사물을 추적하여 프로젝트를 진행시키고 팀이 작업 실행과 관련하여 발생할 수 있는 문제를 해결하도록 돕습니다.

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

• 개발 팀– 최종 제품을 만들고 테스트하며 완료될 때까지 각 릴리스를 실행하는 책임을 맡은 사람들

스크럼은 프로젝트 관리에 초점을 맞춘 솔루션을 제공하여 복잡하고 혁신적인 프로젝트에 매우 효과적인 방법입니다.

폭포수 방법론이란 무엇입니까?

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

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

폭포수는 일반적으로 더 보수적인 접근 방식이지만 2021년에도 여전히 많이 사용됩니다. 이 방식에서는 팀이 보다 독립적으로 작업하고 프로젝트 관리가 선형적입니다. 즉, 프로젝트 시작 시 요구 사항이 수집되고 해당 요구 사항에 따라 프로젝트 계획이 생성됩니다. 프로젝트의 각 단계가 다음 단계로 이어지기 때문에 방법론의 이름은 이러한 '폭포' 운동을 논리적으로 나타냅니다.

폭포수 방법론은 5가지 기본 단계로 구성됩니다.

• 요구 사항– 이는 다음 각 단계의 계획을 가능하게 하는 프로젝트 시작 전에 모든 고객 요구 사항을 수집하는 것입니다.
• 디자인 – 여기에는 논리적 디자인과 물리적 디자인이 포함됩니다. 솔루션을 브레인스토밍하고 이를 사양으로 전환합니다.
• 구현– 개발자가 모든 요구 사항과 사양을 취하고 이에 대한 코드를 작성하는 경우
• 검증– 고객이 검토하고 요구 사항을 충족하는지 확인할 수 있도록 제품/솔루션을 고객에게 공개합니다.
• 유지 관리– 고객은 완성된 제품을 정기적으로 사용하기 시작하고, 작동하지 않는 버그나 기능을 보고하고 추적하여 생산 팀이 이를 수정할 수 있도록 합니다.
•  

Waterfall을 사용하면 팀이 더욱 독립적으로 작업할 수 있으며 지속적으로 의사소통하거나 지속적으로 보고서를 제공할 필요가 없습니다. 팀은 기능별로 그룹화되어 있으며 각 팀이 자신의 역할을 마치면 개발을 계속해야 하는 다음 팀에 "인계"합니다.

프로젝트 관리

복잡한 작업, 팀, 프로젝트를 처음부터 끝까지 원활하게 관리하세요.

템플릿 사용 →

스크럼은 어떻게 작동하나요?

프레임워크로서 스크럼은 긴밀하고 지속적으로 소통하는 단위가 되어 팀이 함께 일하고 프로젝트를 실행하도록 돕습니다. 스크럼에서 일하는 모든 사람은 지속적으로 자기 조직화하고 자신을 개선하는 동시에 연락을 유지하고 작업에 방해가 될 수 있는 모든 사항에 대해 소통하도록 권장됩니다. 스크럼의 구조는 정기적으로 개최되어야 하는 몇 가지 변하지 않는 구성 요소, 이벤트, 행사 및 회의로 구성됩니다. 다음은 스크럼에서 일반적으로 사용되는 가장 인기 있는 단계와 도구 중 일부입니다.

• 제품 백로그– 현재 스프린트에서 완료해야 하는 항목과 원하는 기능의 우선순위를 정하기 위한 제품 소유자와 개발팀 간의 반복적인 회의입니다.
• 백로그 개선 (백로그 그루밍이라고도 함)은 백로그가 다음 스프린트에 준비되었는지 확인하고 관련 항목과 목표만 선택되었는지 확인하기 위해 각 스프린트가 끝날 때 제품 소유자와 개발 팀 간의 회의입니다.
• 스프린트 계획– 제품 소유자가 실행을 위한 상위 항목을 제시하고 팀이 이 스프린트 동안 완료할 항목을 선택하는 매년 봄 전의 회의입니다.
• 일일 스크럼 회의 -종속성, 목표 및 잠재적인 문제를 논의하기 위해 이미 언급한 15분간의 일일 스탠드업 회의입니다.
• 스프린트 검토– 각 스프린트가 끝날 때마다 실시간 시연과 함께 완료된 작업을 발표하는 회의입니다.
• 스프린트 회고– 다음 스프린트에서 어떻게, 어떤 변화가 이루어져야 하는지, 무엇이 잘 되었는지, 무엇이 개선될 수 있는지를 반영하는 회의

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

사용되는 또 다른 도구는 사용자 스토리 입니다. 즉, 고객 관점에서 소프트웨어 기능을 설명하고 이를 충족하는 코드를 생성하는 데 사용되는 짧은 스토리입니다. 모든 뛰어난 작업을 명확하게 표시하는 데 사용되는 또 다른 도구인 번다운 차트를 통해 나머지 항목을 스토리 포인트, 이상적인 날짜, 팀 날짜 등으로 표시하므로 모든 사람이 계획 방법과 작업 중단 여부를 알 수 있습니다. 스크럼에서 자주 접하게 되는 또 다른 용어는 타임박싱(Timeboxing)입니다. 이는 팀이 특정 목표에 할당하고 해당 기간이 거의 끝나갈 때 작업을 중지하는 정해진 기간입니다.

폭포수 방법론은 어떻게 작동하나요?

폭포수 방법론은 일반적으로 처음부터 상황이 어떻게 발생해야 하는지에 대한 매우 명확한 그림을 제공하는 프로젝트에 선택됩니다. 즉, 모든 요구 사항은 처음에 제공되며 끝까지 변경될 가능성이 거의 없습니다. 비용, 기간, 디자인은 Waterfall 모델에서 처음부터 설정됩니다.

Waterfall이 성공적으로 작동하는 데 사용되는 몇 가지 도구와 기술은 다음과 같습니다.

• 간트 차트– 프로젝트 관리자가 Waterfall에서 작업할 때 프로젝트의 하위 작업, 종속성 및 단계를 매핑하는 데 사용하는 도구입니다. 각 작업의 기간은 Gantt에서 설정할 수 있으며 서로 종속된 작업은 종속성과 연결할 수 있습니다.

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

• 작업용 템플릿– 최종 제품을 완성하려면 많은 작업이 필요하므로 Waterfall 방법론에서 프로젝트 관리자는 팀이 각 단계를 파악하는 데 도움이 되는 템플릿을 사용하여 분석 구조에서 각 작업을 계획하려고 시도합니다.

스크럼의 장점과 단점

스크럼은 소프트웨어 개발에서 선호되는 방법론으로 여겨지는 경우가 많지만 마케팅, 영업, 법률, 관리 등 다른 분야에서도 채택되는 경우가 많습니다. 그러나 모든 방법과 마찬가지로 프로젝트 관리자가 고려해야 할 특정한 장점과 단점이 있습니다.

스크럼의 장점은 다음과 같습니다.

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

스크럼의 단점에 관한 한, 건너뛸 수 없는 몇 가지 단점은 다음과 같습니다.

• 범위 확장의 위험– 스크럼을 사용하면 완료 날짜가 설정되지 않았기 때문에 고객은 계속해서 추가 기능을 요청할 수 있습니다.
• 스크럼에 대한 친숙함 필요– 팀은 스크럼이 방법론 내에서 어떻게 기능하고, 수용하고, 기능하는지 알아야 합니다. 팀원은 좋은 기술 경험이 있어야 하며 프로젝트 기간 동안 스크럼의 모든 행사에 전념해야 합니다.
• 스크럼 마스터는 너무 중요합니다. 이 역할은 매우 까다로우며 팀의 비생산성 위험을 초래할 수 있습니다. 제품 관리자와 달리 스크럼 마스터는 팀을 돕고, 팀을 안내하고, 차를 지원하고, 팀을 신뢰해야 합니다. 하지만 팀에게 무엇을 해야 할지 지시하거나 작업을 통제해서는 안 됩니다.
• 작업을 제대로 정의하지 않으면 지연이 발생할 수 있습니다. 작업이 제대로 정의되지 않으면 전체 스크럼 프로세스가 실패할 수 있으며 각 스프린트가 끝날 때 많은 부정확성이 발생할 수 있습니다.

폭포수 장점과 단점

입증된 실적에도 불구하고 Waterfall 방법론에는 프로젝트 관리자가 이해해야 할 장점과 단점이 있으므로 정보에 입각한 선택을 하게 됩니다.

장점은 다음과 같습니다:

• 처음부터의 명확성– Waterfall의 요구 사항은 처음에 제공되고 철저하고 최종적일 것으로 예상되므로 팀의 각 구성원은 시간을 효과적으로 계획하기 위해 무엇을 언제 수행해야 하는지 알고 있습니다.
• 정확한 비용 추정- 명확하게 정의된 요구 사항을 통해 제품 또는 솔루션의 총 비용을 쉽게 추정할 수 있습니다.

• 생산이 지연되는 경우는 거의 없습니다. 처음부터 요구 사항이 제공되기 때문에 새로운 기능이 등장하고 팀에 더 많은 작업이 발생하는 경우가 거의 없으며 지연이 방지됩니다.

• 팀 구성원은 유연합니다. 특정 역할을 맡은 사람들은 프로젝트 진행 중에 큰 혼란을 일으키지 않고 왔다 갔다 할 수 있습니다.

• 마일스톤 중심 개발– 워터폴(Waterfall)은 날짜 중심 패러다임으로 마감일과 마일스톤을 포괄하는 방식으로, 완료될 때까지 각 단계를 명확하게 이해하고 준비할 수 있도록 해줍니다.

• 탁월한 규율– Waterfall에는 프로젝트의 모든 측면을 관리하는 데 도움이 되는 조직과 구조가 있습니다.

Waterfall 방법론의 약점도 이를 적용하기 전에 언급할 가치가 있습니다. 그 중 일부는 다음과 같습니다:

• 배송 시간 연장– 연대순, 선형 접근 방식을 사용하기 때문에 이 방법을 사용하면 최종 제품을 배송하는 데 더 오랜 시간이 걸릴 수 있습니다.
• 지연된 테스트– Waterfall에서는 제품이 완전히 완료될 때까지 테스트가 시작되지 않으므로 대부분의 버그나 디자인 문제는 프로세스 후반에 발견됩니다.
• 고객의 실망 가능성– 고객은 주기가 끝날 때 완성된 제품을 보기 때문에 약간의 실망을 느끼거나 통합하기 어려운 시점에 변경 및 새 기능에 대한 추가 요청이 발생할 수 있습니다.

스크럼과 폭포수: 나란히 비교

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

• 개발– Scrum을 사용하면 반복적인 개발이 가능하고 Waterfall을 사용하면 순차적으로 개발됩니다.

• 진행– Scrum을 사용하면 2주마다 중요한 기능을 제공하여 진행 상황을 볼 수 있으며 Waterfall을 사용하면 각 단계와 활동에 대한 보고서가 있습니다.

• 품질– Scrum 품질은 표준을 통해 사전에 구축되고 Waterfall을 사용하면 최종적으로 광범위한 테스트를 통해 제품 품질이 정의됩니다.

• 피드백– 스크럼은 팀에 대한 지속적인 피드백을 중심으로 구성됩니다. 폭포수는 늦은 학습에 더 관대합니다.

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

귀하의 비즈니스를 위한 워터폴 또는 스크럼 선택: Slingshot 살펴보기

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

​프로젝트 관리 도구 외에도 Slingshot 다음을 통해 Waterfall과 Scrum을 모두 쉽게 구현할 수 있는 디지털 작업 공간입니다.

• 파일을 한 곳에 보관하는 것– 항상 최신으로 업데이트된 올바른 문서가 필요한 것은 모든 팀의 일상 업무에서 현실입니다. Slingshot 모든 클라우드 제공업체를 통합하여 모든 파일에 대한 업로드 및/또는 링크를 허용하므로 각 팀원은 작업 수준에서 가장 최근에 업데이트된 파일에 액세스할 수 있습니다.

• 정의된 작업–Slingshot 사용하면 작업을 구성하고 모든 파일 사용 가능, 채팅 토론, 명확한 종속성, 차단 및 하위 작업을 포함하여 처음부터 끝까지 전체 프로젝트 개요를 작성할 수 있습니다.

• 모든 단계에서 데이터 분석–Slingshot의 협업 앱 특성을 살펴보면 본질적으로 필요한 모든 것을 연결하는 프로젝트 관리 중앙 역할을 할 수 있습니다.통찰력팀을 위한 – 작업 추적, 기한,유료 캠페인 결과, 프로젝트 진행 상황 및 맥락에 따른 토론

• 명확한 책임 및 마감일– 전체 프로세스에 대한 기대치는 명확한 마감일 개요(스크럼을 사용하고 2주 스프린트가 있는 경우)와 책임에 대한 투명성을 통해 Slingshot에서 쉽게 관리됩니다.

• KanBan 작업 보기– KanBan은 예정된 작업과 시기, 진행 측면에서 각 작업의 위치(해야 할 일, 진행 중, 검토 중, 차단됨, 완료됨)에 대한 가장 명확한 개요를 제공하는 Slingshot의 보기 유형 중 하나입니다.

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

지금 Slingshot 사용해어떤 상황에서든 팀에 가장 적합한 것이 무엇인지 실험하고 알아보세요.