주변에서 Waterfall이 좋다 Agile이 좋다 등의 논쟁을 가끔 보게 됩니다.
하지만 Waterfall을 비교 대상으로 삼기에는 적당하지 못한 것 같습니다.
즉, 너무 극과 극의 비교입니다.
이미 Waterfall 방식은 너무 느리고 비용이 많이 들어서 대부분의 소프트웨어 프로제트에서는 사용하지 않습니다. 하지만 Waterfall 방식은 소프트웨어 개발의 기본 원리를 이해하는데 가장 중요한 모델이고 다른 모든 개발 모델들은 Waterfall에서 파생해 나온 것들이기 때문에 Waterfall 방식을 이해하는 것은 소프트웨어 개발 기본 원리를 이해하는 것처럼 중요합니다.
순수한 Waterfall 모델은 다음 단계로 진행하기 위해 전 단계가 완벽하게 끝나야 하고 모든 결과가 문서로 작성되어야 합니다. 폭포를 거슬러 올라가는 것이 원칙적으로 불가능하므로 Waterfall 모델에서는 이전 단계로 거슬러 가는 것이 불가능하거나 비용이 아주 많이 들게 됩니다.
현실에서는 이를 제대로 적용하기가 어려운 이유는 대부분의 소프트웨어 프로젝트는 요구사항을 초기에 완벽하게 파악하여 고정하는 것이 불가능하기 때문입니다. 더 많은 시간을 들여서 요구사항을 완벽하게 해도 시간이 흐르면서 주위 환경이 바뀌고 경쟁자들이 새로운 제품을 내놓는 등의 이슈로 인해서 이미 만들어 놓은 요구사항은 쓸모 없어 집니다. 그리고 너무 많은 문서를 요구하기 때문에 문서 작성과 관리에 너무 많은 시간을 쏟아 부어야 합니다. 그리고 프로젝트가 끝날 때까지 진행과정을 거의 볼 수가 없어서 사용자의 요구사항이 만족스러운지를 프로젝트가 끝날 때까지는 알 수가 없습니다. 이 또한 큰 리스크입니다.
만약에 Waterfall 모델을 따라서 개발하고 있다고 말할 수 있는 회사가 있다면 제대로 적용하고 있지 않거나 화성탐사선을 만드는 회사일 것입니다.
모든 종류의 프로젝트에 딱 적합한 방법이 있는 것은 아니니까 어느 한 라이프사이클 모델을 엄격하게 따를 필요는 없습니다. 원리만 알고 있고 경험이 있다면 응용이 가능하니까요.
엇... 그런데 한국에서 수행되는 대부분의 프로젝트들은
답글삭제폭포수모델에 따라 진행되고 있는 것 같습니다.
SI 업종 뿐만 아니라, 다른 곳에서 개발하는 사람들, 업무를 접하다 보면
다들 자연스럽게 폭포수 모델을 따르는 걸 보게 되죠.
기초기획 -> 상세기획 -> 디자인 -> 한참 지나서 개발팀에 넘어오고,
개발팀은 충분히 설계할 시간도 없고, 인프라웨어를 설치할 시간도 없고,
iteration을 경험할 틈도 없이... 스펙대로 기능들을 하나씩 만들어가고...
개발팀 스스로도 iteration의 필요성을 느끼고 실천해야 하지만,
개발팀이 곧 전체 팀은 아니기 때문에 다양한 역할을 가진 사람들이
우선 서로의 입장을 이해하고 논의하는 과정이 선행되어야 한다고 생각합니다.
사실 남의 핑계대자면 끝도 없는 것이지만,
에자일이라는 용어 혹은 개념을 좀 더 쉽게 풀어서 개발업무에서 벗어난 사람들에게
알리는 행동들도 필요하지 않을까 생각합니다.
제가 처음 IT에 발을 들여놓을 때와 달리
지금은 개발자들이 바로 프로젝트를 시작하는게 아니라
전문 기획자, 컨설팅팀, 디자이너 등 다양한 사람들이 프로젝트 계획 수립에
참여하고 있으니까요~ 개발팀에서 에자일 어쩌고 하면, 무슨 얘기야? 하죠. ^^;
써니님 안녕하세요.
답글삭제저는 Agile을 주장하는 것은 아니고, 프로젝트는 종류가 천차만별이거든요. 원자력발전소를 만든다면 Waterfall모델을 따를 수 있겠죠. 규모가 크고 작고, 기술이 어렵고, 쉽고, 일정 크리티컬하고, 비용이 중요하고 요구사항을 잘 모르겠고, 이러한 조건에 다 맞는 방법을 하나만 대라고 하면 할말이 없는 거죠. Agile은 프로젝트의 규모가 커지면 맞지 않죠. 스펙이 뻔한 유지보수 프로젝트에는 Waterfall로 진행하는 것이 더 빠를 수 있습니다. 그래도 Waterfall의 원리를 아는 것은 매우 중요한 것 같습니다.
"폭포수 vs 애자일"에 대한 논쟁은 적합하지 않지만, "계획기반 vs 경험기반"에 대한 논쟁은 충분히 가능하겠네요.
답글삭제애자일 방법론은 경험기반의 불확실성을 내포하고 있기 때문에 관리자는 통제와 조절이 가능할지에 대한 의문을 가지게 되는데요. 가장 풀어내기 어려운 숙제인것 같습니다.
사실, 계획기반 방법론자에게 폭포수모델을 사용한다고 단정지으면 그들은 애자일 방법론자에게 Code&Fix를 한다고 맞받아 칩니다. 상호간에 이해와 포용이 필요합니다.
YUZI님 안녕하세요.
답글삭제세상이 잘못된 방법론이란 없습니다. 자신의 상황에 맞게 적절히 적용해야 하는 것이고 그것이 어려운 것입니다. 얄팍한 지식을 가지고 자신이 하는 방식이 최고라고 하는 것은 경계해야할 자세입니다.
사실 본질적으로 "폭포수 vs 애자일"에 대한 논쟁이나 "계획기반 vs 경험기반" 논쟁이 과연 다를까요?
답글삭제이분법은 무언가 원리를 설명할 때 추상화와 대비를 위해 효과적일 뿐이죠.
계획 기반으로 한다고 경험에 기반하지 않나요? ^^
애자일을 적용한다고 워터폴을 피할 수는 없죠. 이는 Ray님 포스트에서도 설명하고 있습니다.
실제 현장에서 일하는 방식을 가지고 이분법 논의는 순진한 발상이 아닌 다음에야 말하는 이가 중요하게 생각하는 어떤 아이디어를 설명하고자 '대비와 추상화'를 활용했다고 이해할 수 있을 듯 합니다.
이미 Waterfall 방식은 너무 느리고 비용이 많이 들어서 대부분의 소프트웨어 프로제트에서는 사용하지 않습니다 정말인가요?
답글삭제