워터폴 vs 애자일

초기 SW의 개발 방법은 계획 중심의 프로세스(SW 개발의 역사)

초기에 SW을 주로 개발했던 분야는 ‘군사’ 쪽의 대형 프로젝트이다.
즉, 계획 중심의 프로세스 로 SW 개발이 진행됐다.
이 계획 중심의 프로세스는 ‘건축(도시 계획)’에서의 방법을 본딴 것이다.
당시에는 이런 프로세스를 하는 것이 적합해보이는 프로젝트가 대부분이었다.

하지만, 지금은 달라졌다. 높아진 SW 개발의 불확실성
90년대를 지나면서 SW분야가 넓어지고 SW의 사용자(end user)들이 ‘일반 대중들’로 바뀌기 시작했다.
또한 비지니스 사이클이 짧아지면서 사람들의 욕구와 트렌드도 빨리 바뀌게 되었다.

 

 

일상적이고 익숙한 워터폴 모델(Waterfall Model)

우리가 가장 흔하게 쓰고 있고 어쩌면 당연하다고도 생각 될 만큼 익숙한 프로젝트 수행 방식이 ‘워터폴 모델’ 입니다.
요구분석 → 설계 → 디자인 → 코딩 → 개발 순으로 순차적으로 이어지는 흐름이 마치 폭포수처럼 아래로 이어져 보인다 하여 이름 붙여졌습니다.

  

[워터폴 모델 도식화, 출처. http://slidehunter.com/]

 

워터폴 모델은 오랜 기간 사용된 기법이니만큼 적용 사례가 많고, 단계별로 정형화된 접근방식을 사용하는 이유로 기술적인 위험 요소가 적다는 장점을 가지고 있습니다.
정해진 순서대로 각 파트의 업무가 분장되고 관리되기 때문에 프로세스 상의 마일스톤을 정하는 것이 비교적 쉬운 편이라는 것도 장점이 될 수 있겠습니다.

 

하지만 실제로 각 단의 경계를 명확히 구분하고, 앞선 파트의 업무가 완전히 끝난 후 다음 단계를 시작하는 것이 거의 불가능하다는 문제를 가지고 있습니다.
그리고 실제 프로젝트를 수행할 때 가장 빈번히 마주치게 되고, 해결하기도 굉장히 까다로운 문제가 있죠.
바로 ‘고객과의 커뮤니케이션’ 입니다.

 

워터폴 모델을 사용할 경우 디자인이 구현되어 시각적으로 확인하거나, 개발을 통해 실제로 웹 또는 앱이 구동되는 모습을 보기 전까지, 고객사는 자신들이 요구했던 사항들의 실체를 알기 어렵습니다.
물론 화면설계 문서나 요구사항 정의서만 보고 실제 구현될 서비스의 그림을 그릴 수 있는 고객도 있긴 하지만, 매번 그런 고객사를 만나기란 쉽지 않습니다.

 

그래서 실제 디자인 또는 개발된 화면을 시각적으로 확인하고 나서야 수정요청이 발생하기 시작합니다.
이럴 경우 고객사의 요청을 통제할 수 있는 방법은 음… 없습니다. 많지가 않습니다.

이미 많은 단계를 지나온 상태에서 다시 되돌아가 기획단계부터 수정되기 시작하면 일정과 비용 등 여러 항목에서 애로사항이 꽃피게 되는 것이지요.

이런 워터폴 모델의 단점을 보완하기 위해 여러가지 방법론들이 생겨나고 실제 사용되고 있는데요.
그 중 하나가 제가 이번에 수행했던 애자일 모델입니다.

 

고객과의 의사소통을 중시하는 애자일 모델(Agile Model)

애자일 모델은 정확히 말하면 어느 특정한 개발 방법론을 지칭하고 있지 않습니다.
‘Agile = 기민한, 날렵한’ 이란 뜻으로 좋은 것을 빠르게 취하고, 낭비 없게 만드는 다양한 방법론을 통칭해 일컫는 말입니다.

예전에는 애자일 개발 프로세스를 경량(Lightweight) 프로세스 라고 불렀다고도 합니다.
애자일 모델이 다른 방법론과 구별되는 가장 큰 차이점은 Less Document-Oriented, 즉 문서를 통한 개발이 아니라 Code-Oriented, 실질적인 코딩을 통한 방법론이라는 점입니다.

[ 애자일 모델 도식화, 출처. http://slidehunter.com/ ]

 

애자일 모델은 전체적인 플랜을 짜고 문서를 통해 주도해 나가던 과거의 방식(워터폴 모델)과 달리 앞을 예측하며 개발하지 않고, 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어 내며 필요할 때마다 요구사항을 더하고 수정하여 커다란 소프트웨어를 개발해 나가는 방식입니다.

이렇게 실질적인 프로토 타입이 계속해서 생산됨으로 고객이 개발과정에 참여할 수 있는 여지가 커지는 장점을 가지고 있습니다.
기능이 실제로 구동되는 모습을 확인하고, 수정요청을 하거나 다음 단계로 넘어가는 긴밀한 관계를 형성할 수 있는 것입니다.

 

 

애자일의 핵심 1. “협력”

SW 프로젝트가 망하는 경우는 기술 외적인 것도 크다. 따라서 특히 SW 개발의 불확실성이 높을 때는 “협력”을 잘 해야한다.

 

내부적 협력

내부적 협력: SW를 개발한 사람들 안에서의 협력을 말한다. 특히, 직무 역할을 넘어선 협력을 의미한다.

 

좋은 일은 곱하기!!

1) 혼자 얻은 좋은 통찰을 협력을 통해 다른 사람도 같이 얻을 수 있다.

2) 예상하지 못했던 기회를 잡을 수 있다.

예를 들어, 어떤 사람이 개발을 하다가 2배의 속도로 개발할 수 있다는 것을 발견했다. 협력이 약한 문화에서는 그 사람만 좋은 보상과 칭찬을 받게 되고, 그 사람 코드가 다른 사람들의 코드와 너무 이질적이어서 시스템에 문제가 발생할 수도 있다. 하지만 협력이 강한 문화에서는 그것을 다른 사람들과 공유하여 모두 같이 빠르게 개발할 수 있고 더 나은 발전점을 찾을 수 있다. 즉, 팀 전체의 개선이 일어난다.

 

안 좋은 일은 나누기!!

1) 문제가 되는 것을 찾기가 쉽다.

2) 예상하지 못했던 문제를 협력이 막을 수 있다.

예를 들어, 내가 생각지 못한 실수를 했는데 아무리 다시 봐도 모르겠거나 더 나은 방법이 생각나지 않을 때가 있다. 이때 나와 항상 같이 일하던 사람에게 물어봐도 나랑 비슷한 생각을 하고 있으므로 더 나은 대안을 제시하지 못하고 비슷한 얘기를 하게 된다. 즉, 서로 다른 사람들과 협력하는 것이 중요하다. 이를 통해 다른 사람이 쉽게 그 문제에 대해 찾을 수 있고 서로 같이 빠르게 해결할 수 있다.

 

 

애자일의 핵심 2. “피드백”

피드백은 학습의 가장 큰 전제조건이다. 내가 어떻게 했는가를 확인하면서 학습해야 한다.

 

또한, SW 개발의 불확실성이 높을수록 학습 이 중요해진다. 왜냐하면 모르는 것이 많기 때문에 더 빨리 배워나가야하기 때문이다.

 

일을 잘하는 사람은 feedback seeking 이 뛰어나다. 즉, 이런 사람들은 더 자주 더 많은 사람들에게 피드백을 구한다.

 

내부적 피드백

내부적 피드백: 내가 만든 것이 어떻게 됐는지 확인해보는 것

 

외부적 피드백

외부적 피드백: 내가 만든 것을 고객이나 다른 부서가 사용해보고 그것을 통해 또 다른 것을 배우는 것

 

 

애자일의 핵심 3. “단점도 존재한다.”

아래가 애자일 방법론의 단점들이다.

• 너무 개발자 중심의 방법론이다
• 애자일이라 쓰고 ‘무한수정’이라 읽는다
• 애자일과 통계의 시너지, 혹은 부작용
• 틀리지 않다, 다르다

 

애자일의 핵심 4. “애자일의 방법”

애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 

"애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것)

 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다.

 

즉, 애자일을 간단하게 정리하자면,

 

1. 개발자와 고객 사이의 지속적 커뮤니케이션을 통하여 변화하는 요구사항을 수용한다.

 

2. 고객이 결정한 사항을 가장 우선으로 시행하고, 개발자 개인의 가치보다 팀의 목표를 우선으로한다. 

 

3. 팀원들과 주기적인 미팅을 통해 프로젝트를 점검한다.

 

4. 주기적으로 제품 시현을 하고 고객으로 부터 피드백을 받는다.

 

5.  프로그램 품질 향상에 신경쓰며 간단한 내부 구조 형성을 통한 비용절감을 목표로한다. 

가 될 수 있다.

 

 

애자일의 핵심 5. “스크럼”

그래서 애자일 개발 프로세스로 불리는 개발 방법론 중 하나가 바로 스크럼이다. 

 

스크럼(scrum)은 원래  원래 럭비 경기에서 사용되던 용어입니다.

럭비에는 스크럼(scrum)과 라인 아웃(line out)이라는 두 가지 기본 대형이 있습니다. 

 

이 중 스크럼은 반칙으로 인해 경기가 중단됐을 때 쓰는 대형입니다. 

반칙이 행해진 장소에 되도록 가까운 곳에서, 양 팀의 7∼8명이 서로 밀집하여 팔을 꼭 끼고 하나의 집단을 형성해 상대팀을 앞으로 밀치는 대형을 말합니다.

 

이렇게 럭비 경기에서 쓰이던 용어가 소프트웨어 개발 프로세스에서 사용되는 것은 "팀이라는 단어가 주는 의미를 개발 팀에 적용하여 효율적인 성과를 얻기 위해서"라고 합니다.

 

 럭비 경기의 스크럼 대형

 

 

스크럼 프로세스도 '프로세스'이기 때문에 과정이 존재하는데 아래와 같다. 이해하고 넘어가면 면접에서 도움이 될 수 있다.

 

출처 - 네이버 지식백과

< 꼭 이해하고, 자기 것으로 만들어야, 설명을 할 수 있다! - 화이팅!>