흔히 우리가 생각하는 Project 수행 방식은 "Waterfall Model🌊"입니다. Waterfall Model은 비지니스 요구사항 분석, 기술적 설계, 제품 디자인, 개발(Coding), 그리고 제품 배포로 이어지는 순차적인 흐름이 폭포수와 같아서 Model이름이 지어졌습니다. 오랜 시간동안 해당 모델은 사용되어 왔고 단계별로 정형화된 접근방식을 사용하는 이유로 기술적인 위험 요소가 적고 파트별로 업무가 분업이 확실히되고 관리된다는 장점이 있습니다.
하지만 이러한 모델은 개발자들의 업무 프로세스에 있어서 적합하지 않았습니다. 실제로 모든 업무 과정이 단계별로 명확히 구분되지 않았고 앞의 단계를 무조건 마무리 지어야 다음 단계로 간다는게 사실상 지켜지기 힘들어 문제가 발생했습니다. 또한 개발단계에 있어서 Client 요구사항이나 자체적인 조사를 통해서 수정해야 되는 일들이 발생을 하게 됩니다.
하지만 Waterfall Model에서 이미 많은 단계를 진행한 상태에서 다시 처음부터 기획을 건드리게 되는건 팀이나 회사에 있어서 많은 시간과 비용을 지불해야 하는 애로사항이 생기게 됩니다. 그렇기 때문에 현 개발상황에 더 적합한 애자일 방법론을 사용하게 되었습니다.
그렇다면 이러한 상황을 바꿀수 있는 애자일 방법론은 어떤 것일까요? 쉽게 이야기하자면 개발자들의 유연한 일하는(개발 프로세스) 방식이라고 생각하면 편합니다. 솔직히 애자일 방법론에 대해서 대학에서도 해당 부분에 대해 강의도 들어봤지만 정확히 이해하기가 아직 어렵습니다. 왜냐하면 다들 이해한 그래서 이번 블로그에서도 제가 이해한 애자일 방법론이란 무엇인지 기록하겠습니다.
Agile
Agile Software Development는 흔히 애자일 방법론(Agile)이라고 부르는 소프트웨어 개발 방법론 중에 하나로 개발과 함께 즉시 feedback을 통해 유동적으로 계획을 하고 개발을 하는 방법입니다. 당장 어떠한 일이 일어날지 예측하지 않은 상태로 개발을 해서, 일정한 주기(Sprint)를 가지고 끊임없는 검토나 피드백을 받아가면서 필요하면 요구사항을 더하고 수정하여 프로젝트를 완성시키는 과정을 거칩니다.
그렇기 때문에 앞서 이야기 했던 Waterfall Model은 한번의 프로세스 주기가 끝나면 프로젝트도 끝나게 되지만 애자일은 "계획-설계(디자인)-개발(Coding)-테스트-피드백" 이라는 하나의 프로세스가 계속해서 반복적으로 진행이 됩니다.
-
계획 및 분석: 이 단계는 Client나 사용자가 원하는 니즈를 파악하여 타당성을 조사하고 개발 기능과 제약조건을 정의하는 documentation과 해당 개발을 할 때 발생할 문제 영역과 사용자가 원하는 task를 이해합니다.
-
디자인: 개발의도에 맞는 모델 설계와 디자인을 추가 및 수정합니다.
-
개발: 디자인에서 만들어진 디자인과 설계를 토대로 프로그램을 작성(코딩) 및 테스트를 수행합니다.
-
테스트: 발생 가능한 오류를 미연에 방지하고 만약 발생할 시 이를 수정하는 단계입니다.
-
피드백: 테스트들을 끝마치고 나온 결과물을 가지고 기획의도와 부합했는지 확인하고 수정하는 단계입니다.
이러한 프로세스들을 걸치기 때문에 애자일의 특징으론 Client와 개발자들의 지속적인 소통을 요구하게 되고 이러한 소통들을 통해서 변화되는 요구사항들을 신속하게 프로그램에 적용하기가 편합니다. 개발자들은 개인의 사고를 통한 개발보다는 팀의 목적을 우선시해서 개발을 해야 하며 그리고 Client의 의견을 가장 우선시합니다. 마지막으로 계속되는 변화를 적용시키기 위해서는 팀원들과 주기적인 소통이나 회의를 가져야 하며 끊임없이 프로그램을 시행해보고 서로 피드백을 남겨야 합니다.
Scrum
스크럼(Scrum)은 애자일 방법론으로 인해 효율적이고 주기적인 회의와 소통을 가져야 하는 개발자들이 프로젝트 관리를 위한 상화, 점진적 개발방법론입니다. 스크럼은 Client의 요구사항을 충족시키는 데 초점을 맞추기 위해, 짧은 주기의 목표를 가지고 점진적으로 시스템 혹은 프로그램을 지속해서 개발하는 관리 프레임워크입니다.
스크럼은 특징은 개발중인 프로그램의 솔루션에 포함할 기능 혹은 개선점에 대해 우선 순위를 부여합니다. 보통 개발 주기 1~4주로 하는데 그 이유는 너무 짧을 경우에는 하나의 주기(Sprint)를 수행할 여유가 없고 너무 길게 잡을 경우에는 개발 자체가 느슨하게 되고 양도 늘어나게 되어서 결국에는 Waterfall Model의 단점을 가져오게 됩니다. 개발협업 툴(Trello, Slack, Notion)을 이용해서 한 사이클이 돌때마다 사이클 안에 적용할 기능이나 개선에 대한 목록을 작성 해야합니다. 매일 Daily Meeting을 통해서 팀원들 간에 진행상황이나 Blocker를 공유해서 팀원 모두가 각자 할일을 상기시킴과 동시에 프로세스 체크를 할 수 있습니다.
