100. Agile vs Waterfall - Comparison

강사: Waterfall인가요, Agile한가요?

어떤 것을 사용해야 합니까?
어떤 것이 가장 좋습니까?
이것이 요즘 프로젝트 관리 은하계의 백만 달러짜리 질문입니다.

두 접근법의 특징을 요약하는 것으로 이 점에 대한 분석을 시작하겠습니다.
Waterfall은 모든 프로젝트 성과물과 활동이 미리 정의된 순서를 갖는 순차적 접근 방식입니다.
이들 사이의 종속성은 처음부터 명확하며 프로젝트 산출물은 맨 마지막에 준비되어야 합니다.

반면 애자일은 반복적인 접근 방식으로 활동이 주기 또는 반복적으로 수행됩니다.
제품은 단계별로 생성되며 제품의 초기 버전이나 기능은 개발 초기에 사용할 준비가 되어 있습니다.
따라서 전체 프로젝트가 완료되기 전에 일부를 비즈니스 용으로 출시할 수 있습니다.
폭포(Waterfall)는 최적의 계획을 사전에 정의한 다음 효과적이고 효율적으로 따르도록 보장하는 것에 중점을 둡니다. 이른바 예측 계획입니다.

반면 애자일은 실행 활동으로 이동하기 위해 세부적인 계획이 필요하지 않습니다.
계획이 프로젝트 실행과 함께 발전하고 최종 목표에 도움이 되는 경우 계획을 업데이트하거나 변경할 수 있는 이른바 적응형 계획이 추진됩니다.
범위 및 요구 사항 유연성, 폭포 방법론은 계획을 수립하는 동안 범위 및 요구 사항을 엄격하게 정의하고 합의해야 하며, 실행 단계에서 변경되는 사항은 최소화해야 합니다.
이 학파는 변화의 비용과 범위와 관련된 모든 문제를 최소화하는 것의 중요성을 강조합니다.

애자일 철학은 여기서도 다른 위치에 있습니다. 프로젝트 팀이 제품에 대한 보다 현실적인 이해를 할 때 최소한 실행 중에만 요구 사항의 일부를 정의할 수 있을 것으로 예상됩니다.
그렇다면 프로젝트 구조는 변화에 유연하게 대응하고 쉽게 실행할 수 있어야 합니다.
마지막으로, 두 접근 방식이 추진하는 주요 목표의 차이를 관찰할 수 있습니다.
우리는 Agile에서 고객 중심성을 전달하는 것, 전통적인 폭포(Waterfall) 사례에서 시간과 예산 내에 프로젝트를 제공하는 것을 각각 목표로 하고 있습니다.

물론 이것은 그 중 어느 것도 범위, 시간, 비용을 과소평가한다는 것을 의미하는 것은 아니지만, 워터폴이 삼중 제약(Scope, Time, Cost)에서 균형을 추구하는 반면, Agile 원칙은 종종 고객 만족과 고객 요구에 맞는 제품 개발을 언급하는 것을 볼 수 있습니다.

흥미롭지만, 결국 어떤 것이 더 낫습니까?
글쎄, 우리는 그것이 잘못된 질문이라는 것을 인정할 필요가 있습니다.
정답은 특정 프로젝트에 따라 항상 다를 것입니다.
Waterfall과 Agile은 동일한 것을 제공하기 위한 다양한 접근 방식으로, 성공적인 프로젝트입니다.
그것들은 프로젝트 관리자의 도구 상자에 있는 서로 다른 도구이며 당면한 특정 사례에 따라 선택해야 합니다.

WATERFALL

• Sequential
• Predictive planning
• Scope & Requirements
  • fixed in advance
• Centered around the triple constraint and balancing it

AGILE

• iterative
• Adaptive planning
• Scope & requirements
  • flexible
• Customer centered

101. Agile vs Waterfall - Analysis

강사: 그러면 Waterfall 방법론을 통해 어떤 이니셔티브와 환경을 보다 적절하게 관리할 것인지, Agile을 통해 어떤 이니셔티브와 환경을 보다 적절하게 관리할 것인지 분석해 보겠습니다.

첫 번째 포인트는 불확실성(Uncertainty)입니다.
우리가 알고 있는 것처럼 프로젝트는 미래의 사건을 다루기 때문에 항상 어느 정도의 불확실성이 있을 것입니다.
그러나 이 정도는 큰 차이를 만들 수 있습니다.

이 원뿔(x축: Time,y축: Scenarios)로 표현된다고 상상해 보세요.
시간이 지날수록 더 많은 일이 일어날 수 있고, 더 많은 시나리오가 일어날 수 있습니다.
유일하게 확실한 것은 오늘 이 순간입니다.

어떤 경우에는 시나리오를 미리 잘 알고 예측할 수 있습니다.
이 경우 효과적인 계획을 수립할 수 있으며 Waterfall이 더 효율적인 해결책이 될 것입니다.

우리는 최선의 계획을 분석하고 확인하며 가능한 한 가장 많은 시간과 자원 효율적인 방법으로 계획을 추진합니다.

그러나 다른 경우에는 불확실성이 상당히 클 수 있습니다.
가능성은 셀 수 없이 많을 수 있으며, 아무리 계획을 세워도 이러한 불확실성을 드러내기 전에 일이 어떻게 진행될지 충분히 알 수 없을 것입니다.
애자일 원칙에 기반한 방법론은 이러한 상황에서 진정으로 유용합니다.

제품은 점진적으로 생성되고 테스트됩니다.
일은 단계적으로 진화합니다.
팀은 실행 중에 수집된 지식과 정보를 사용하여 실제 상황에 유연하게 적응합니다.
따라서 불확실성이 크다면 제품을 점진적으로 개발하고 테스트하여 변경하고 적응할 수 있는 여지를 남겨둘 것이므로 Agile 솔루션을 찾으십시오.

다음은 범위(Scope)입니다.
어떤 느낌이에요?

• 사전에 범위를 잘 정의되어야함
• 범위는 복잡하고 상위 수준에서만 정의될 수 있다.
• 실행하기 전에 범위를 자세히 정의할 수 있습니까?

후원자, 고객 및 기타 관련 이해 관계자가 처음에 세부 요구 사항을 정의할 수 있는 경우, Waterfall 방법론은 보다 효율적인 프레임워크를 제공합니다.
범위(Scope)를 잠그고 정의된 범위를 실현하는 데 필요한 시간과 리소스를 최적화합니다.
프로젝트 관리 3중 제약법.
이러한 경우에는 프로젝트 활동 간의 모든 종속성을 사전에 파악하여 실행 전에 범위를 완전히 합의할 수 있습니다.

일반적으로 공공 프로젝트나 건설 프로젝트는 엄격한 순서가 있기 때문에 대표적인 예입니다.
건축 공학 및 설계 계획은 잠겨 있어야 하며 건설 작업 중에 엄격한 기준이 적용됩니다.
건물의 건축 계획을 변경하고 중간에 2층을 추가하는 것은 상당히 어려울 것입니다.
물리적으로 이러한 변경을 할 수 있다고 하더라도 규제 요구 사항 및 법률로 인해 계획을 준수해야 하는 경우가 많습니다.
따라서 규제가 심한 비즈니스의 프로젝트도 워터폴과 같은 방법론에 치우칩니다.

반면에 프로젝트 범위의 활동을 선형적으로 명확하게 정렬할 수 없고 세부 요구 사항을 명확하게 설정할 수 없는 경우 Agile은 더 나은 솔루션을 제공할 것입니다.
프로젝트는 작업이 진화하고 불확실성이 드러남에 따라 요구 사항에 대한 변경 사항과 업데이트를 흡수하는 방식으로 구성됩니다.
시간이 지남에 따라 불확실성이 감소하고 더 많은 것이 알려지며 제품 특성, 기능 및 기능을 더 잘 정의할 수 있습니다.
프로젝트 팀은 가치 있는 새로운 작업을 추가하고 더 이상 관련이 없는 작업을 피할 수 있습니다.
이렇게 하면 최종 제품의 유용성이나 유용성을 극대화하고 고객과 사용자가 만족할 수 있습니다.

앞의 수업에서 언급했듯이 제품 개발과 같은 복잡한 작업이 수반되는 프로젝트, 특히 고전적인 소프트웨어 개발이 좋은 예입니다.
이러한 경우 제품은 특정 회사 또는 조직의 요구 사항 또는 시장에서 제품을 사용할지 여부에 따라 크게 맞춤화된 디자인 기능을 포함하기 때문에 고유한 경우가 많습니다.
수백만 명의 사용자가 사용할 소프트웨어 제품의 경우 요구 사항 정의 프로세스가 얼마나 복잡할 수 있는지 상상할 수 있습니다.
따라서 이해 관계자들이 처음부터 범위에 대해 합의할 수 있다면 Waterfall은 보다 효율적인 달성 방법을 제공할 수 있습니다.그렇지 않은 경우 Agile 구조의 유연성이 필요합니다.

스스로에게 물어볼 수 있는 또 다른 좋은 질문은 시간과 비용 제약이 얼마나 강한가 하는 것입니다.
시간과 비용, 지연 또는 추가 지출이 허용되는 프로젝트입니다. 최종 제품의 유용성이 가장 중요한 프로젝트입니다 고객 만족도입니다.

시간이나 비용 면에서 제약이 중요하다면 요구 사항을 정의하고 제한된 자원이 충분하도록 최선을 다해야 합니다.

이런 경우에는 Waterfall가 더 효율적일 겁니다 일반적으로 더 빠르니까요 팀원들이 좋은 추진력을 만들어 실행 단계에서 방해받지 않고 일할 수 있다면 말입니다. 리소스 관점에서도 종종 그럴 수 있습니다 순차적 구조는 좀 더 직관적이고 이해하기 쉽기 때문입니다 프로젝트 플랜, 필수 경로(Critical Path), 갠트 차트 같은 명확한 프로세스와 규칙으로 이해하기 쉽습니다. 또한 팀원들이 더 쉽게 폭포 프로젝트에 참여할 수 있습니다 프로젝트는 민첩한 환경에서 더 정교하게 진행되기 때문에 더 많은 자원과 조정시간이 소요됩니다. 예를 들어, 팀원들은 하나의 프로젝트에 전념해야 하고 클라이언트는 중대한 참여를 해야 하며 협력을 위한 시간과 노력을 더 투자해야 합니다.

Agile Systems와 소프트웨어 트레이닝 세션 스크럼 마스터 같은 전문적인 Agile Master도 참여해야 합니다. 하지만 이런 요소들이 고객의 욕구를 만족시킬 확률을 높입니다. 따라서 고객을 위해 더 나은 제품을 만들기 위해 시간과 비용 변동도 감수할 수 있다면 Agile 솔루션을 찾는 게 합리적일 겁니다. 요약하자면 폭포수는 프로젝트 자원을 더 효율적으로 활용할 수 있고 시간과 비용도 더 절약할 수 있습니다. Agile은 보다 구체적이고 복잡한 고객 문제를 해결하는 데 도움이 됩니다.

이 모든 세부 사항을 살펴본 후 다음 영상에서 어떤 결과와 결론이 나올지 브레인스토밍을 할 겁니다. 거기서 뵙겠습니다

정리
Waterfall - Manageable, Welldefined in advance, Maximize resource efficiency
Agile - Significant, Complex defined at a higher level, Maximize the product's utility

102. Agile vs Waterfall - Conclusion

강사: 분석한 결과, Agile 기반의 방법론은 불확실성이 높은 특정 프로젝트 사례에 맞게 맞춤화된 것으로 보입니다,
기술, 혁신, 다양한 기대, 경쟁 또는 기타 요인으로 인해, 사전에 포괄적이고 상세한 계획을 세우는 것은 그다지 효과적이지 않을 것입니다.
범위는 복잡하며 세부 요구 사항은 실행 중에 변경될 가능성이 높습니다.
가장 중요한 것은 이를 달성하기 위해 더 많은 시간과 자원을 투자하더라도 최종 제품이 특정 고객의 요구를 충족한다는 것입니다.

코스 전체에서 언급한 바와 같이 이러한 특성을 가진 이니셔티브의 좋은 예로는 소프트웨어 프로젝트, 제품 개발 프로젝트, 연구 개발, 혁신 프로젝트, 실험 사례, 콘텐츠 제작, 디자인 관련 프로젝트, 특정 클라이언트를 위한 강력한 커스터마이징 등이 있습니다.
교차 기능 팀은 재무 부서의 소프트웨어와 같은 하나 이상의 전문 분야를 함께 다루면서 협력해야 합니다.
우리는 애자일을 특수부대로 생각할 수 있으며, 이러한 독특한 노력을 가장 잘 관리하는 데 필요한 도구를 제공합니다.

반면에 폭포 방법론은 더 보편적인 것 같습니다.
순수 프로젝트 관리 관점에서도 범위, 시간, 비용뿐만 아니라 위험, 역할 및 책임, 품질, 커뮤니케이션, 변경 관리 및 조달 등 여러 측면을 고려하는 것이 중요하다는 점을 강조하고 있어 더욱 포괄적입니다.

또한 워터폴은 프로젝트 라이프사이클에 대한 명확한 기준을 설정하여 각 단계의 중요성을 강조하고 모범 사례를 제공합니다. 예를 들어, Agile과 같은 PMI 표준은 문서화 가능성이 적은 보다 가벼운 구조로 프로젝트를 수행하는 것을 목표로 합니다.

하지만 그들은 프로젝트 관리의 흑백과 완전히 반대입니까? 아니요.
그럼 어떻게든 함께 사용할 수 있나요? 예, 두 접근 방식 모두 프로젝트 관리를 더 잘, 더 효율적으로, 더 성공적으로 수행할 수 있도록 지원하는 것을 목표로 합니다.

프로젝트에 따라 두 가지 측면을 모두 차용할 수 있는 경우가 많습니다.
프로젝트 관리자 커뮤니티에서는 워터폴과 애자일의 두 가지 측면이 결합된 혼합 접근 방식에 대해 이야기하고 있습니다. 두 가지 모두의 이점을 파악하기 위해 실행의 일부를 스프린트 방식으로 제공하고, 다른 일부는 순차적이고 중단되지 않는 방식으로 진행하는 것이 어떨까요.

더 큰 프로젝트의 일환으로 새 시스템을 개발하는 것과 같은 스프린트에서 프로젝트 스트림을 수행한 다음, 이 새 시스템을 사용자에게 순차적으로 배포(예: 모든 사용자에게 데모)하고, 몇 세션 만에 사용자를 교육한 다음 비즈니스용으로 릴리스합니까? 또는 몇 가지 중요한 사항에 대해 계획과 방향을 변경할 수 있는 순차적인 프로젝트를 수행하거나, 고객이 Waterfall 프로젝트에 밀접하게 참여하도록 하고, Agile 등의 고객 중심성 원칙을 존중하도록 합니다. 또한 이 프로젝트는 프로젝트 관리자인 여러분에게 조언해 줄 것입니다.

이제 두 가지 철학에 대해 잘 알고 계시기 때문에 다음 프로젝트에 가장 적합한 철학을 사용할 수 있는 준비가 되었습니다.