Waterfall model
이 전 소프트웨어 개발 방식은 ‘폭포수 모델(waterfall model)’이 대중적이었다.
이 모델은 분석, 설계, 구현, 테스트가 순차적으로 실행되는 모델이다. 이때, 앞의 단계가 끝나야 다음 단계를 진행할 수 있다. 즉, 요구사항이 모두 정의되고, 이를 바탕으로 설계가 완성되어야 구현을 할 수 있다는 것이다.
그렇다면 여기서 문제제기를 해보겠다.
개발팀에게 고객은 실제 일을 맡기는 클라이언트일 수도 있고, 프로젝트를 지시한 기획자일 수도 있다.
- 이런 고객들이 개발에 대해 잘 알고 있을 확률은 얼마나 될까?
- 고객들이 자신들이 원하는 요구사항을 제대로 전달할 확률은 얼마나 될까?
- 그 요구사항이 변하지 않을 확률은 얼마나 될까?
위 사항을 모두 100%로 만족하면 폭포수 모델을 이용하여 개발을 하여도 큰 문제를 못 느낄 것이다.
하지만 요즘 시대에는 요구사항이 다양하고, 모호성이 증가하고 있다. 또한, 트렌드가 빠르게 변화하고 있는 상황에서 폭포수 모델의 방식으로 개발을 진행하게 된다면 어떠한 문제점을 가지게 될까?
- 요구사항이 초기에 확정되어야 설계를 시작할 수 있다.
- 고객이 원하는 방향과 개발 방향이 달라도 테스트 단계가 되어서 고객이 실제 구동화면을 보아야 문제점을 확인할 수 있다.
- 급변하는 시장 트렌드에 맞게 요구사항이 변화한다면, 다시 요구사항 분석부터 시작 해야 한다.
- 분석, 설계 기간에 시간을 많이 쏟아 구현, 테스트 단계에 가서는 시간이 부족해져서, 야근을 하게 될 확률이 높다.
- 야근을 하여도 마감일자를 못 맞출 확률이 높아진다.
- 부족한 시간으로 제품의 퀄리티가 떨어진다.
이 모델은 지나치게 계획과 절차에 의존한다는 단점이 있다. 빈틈없는 계획과 엄격한 심사를 중시하면서 시간과 비용의 낭비가 증가한다. 또한, 하나의 오류를 해결하기 위해서는 분석, 계획 단계부터 다시금 해야한다는 점이 마감기한을 지키기 어렵게 만든다.
즉, 이 모델은 변화에 대응하기 어렵고 문제점을 빠르게 알아차릴 수 없다는 단점이 있다.
이러한 문제점들을 해결하고자 17명의 개발자들이 스노버드에 모여 작성된 것이 ‘애자일 소프트웨어 개발 선언’이다.
반박 시 여러분의 말이 맞습니다.