[🍎CS] 개발방법론

h-a-n-a·2023년 6월 8일

🍎CS

목록 보기

13/15

하나의 소프트웨어를 출시하고 유지/보수까지하는 과정은 보통 다음과 같다.

1. 기획(어떤 것을 만들지 정하는 단계)
1. 개발(기획한 것을 만드는 단계)
1. 테스트(개발이 기획대로 잘 되었는지 확인하는 단계)
1. 배포(개발된 제품/서비스를 사용자가 사용하는 단계)
1. 유지/보수(출시된 서비스를 변화시키는 단계)

그런데 다양한 여러 사람들이 만나 함께 일하다 보니 당연히 이러한 과정 속에서 여러 문제가 발생할 수밖에 없다. 그래서 그 과정에서 사용하는 가장 유명한 방식은 보통 agile방식과 waterfall 방식이라고 하는데, 한 번 알아보자~!

워터풀(waterfall) 방식

워터풀 방법론은 폭포수 방법론이라고도 불리며 각 작업이 폭포처럼 위에서 아래로 떨어지는 단계별 개발 방법론이다. 설계 -> 디자인 -> 개발 -> 테스트 -> 배포의 과정이 순차적으로 진행되며, 순차적인 진행과 명확한 요구 사항 분석이 요구된다.

장점

단계별로 업무를 분담하기 때문에 맡은바가 명확하다는 장점이 있다. 계획 단계의 문서화로 단계마다 소요되는 시간이나 현재 상황을 추적하고 병목을 파악하기도 쉽다.

*병목 현상: 전체 시스템의 성능이나 용량이 하나의 구성 요소로 인해 제한을 받는 현상

단점

그러나 속도가 느리고 유연하지 못하다는 단점이 있다. 아래에서는 위에서 물이 떨어질 때까지 마냥 기다리고 있어야 한다거나, 떨어진 요구사항대로 기능을 만들었지만 수 개월이 지난 시점에서는 시장 상황이 변해 더 이상 고객이 그 기능을 필요로 하지 않는 경우도 발생할 수 있다.

90년대 이후 이러한 워터풀 방식의 한계가 드러나기 시작했다. 인터넷 기술이 발달하고 개인 PC 보급이 늘어나면서 고객의 요구는 빠르게 변했지만 소프트웨어 개발은 이러한 요구사항에 민첩하게 대처하지 못한 것이다. 워터풀 방법론은 속도, 변화에 취약했고, 문제가 발생했을 때 전 단계로 되돌리기 어려웠기 때문이다. (변경사항이 생길 경우, 처음 계획 단계부터 다시 시작해야 함)

이러한 경직된 워터풀 방법론에 대한 대안으로 생겨난 것이 바로 애자일 방법론이다.

애자일(agile) 방식

애자일은 '기민한, 민첩한' 이라는 뜻으로 일정한 주기를 가지고 빠르게 제품을 출시하여 고객의 요구사항, 변화된 환경에 맞게 요구를 더하고 수정해나가는 탄력적인 방법론을 의미한다. 즉, 소비자로부터 일방적으로 모든 요구사항이 내려오면 개발을 시작하는 것이 아니라, 개발해나가면서 필요한 것들을 피드백을 바탕으로 주도적으로 개발하겠다는 뜻이다.

소비자로부터 요구사항을 전달받았다 해도, 그 시점으로부터 요구사항은 끊임없이 바뀌고 개발환경도 끊임없이 바뀌는 걸 생각하면, 당연한 변화방식이라고 할 수 있다.

애자일 흐름과정

기본적으로 스크럼 프로세스에 의해 진행된다.

스프린트: 작은 기능에 대한 [계획, 개발, 테스트, 기능완료] 에 대한 전체 주기
스프린트 계획 회의: 스프린트 목표와 백로그를 계획하는 회의
스프린트 백로그: 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록
스크럼: 개발 과정에 대한 모든 주기 (30일 정도)
일일 스크럼 회의: 날마다 진행되는 미팅(어제 회의, 오늘 할 일, 장애 현상 등을 공유)
스크럼 마스터: 프로젝트 관리자(코치)

위의 그림을 보면, 결국 애자일 이라는 건 일종의 스프린트를 바탕으로 한 피드백 기반 개발방식이라는 걸 알 수 있다. 작은 기능들을 개발하면서 피드백을 주고받고 그러면서 필요한 기능들을 더 개발하거나 삭제하고, 점진적으로 개선하는 방식이라는 것이다.

왜 공유할까?

앞서 워터풀과 다른 또하나의 큰 특징. 바로 피드백을 주고받으며 공유한다는 점이다. 앞선 워터풀에서는 공유를 하지 않으니 피드백도 당연히 못 받아 오래 걸리고, 이전 단계가 완료되기 전까지는 다음 단계로 갈 수 없었다. 정해진 기준이 있으니 변경에 취약하고 비효율적인 면이 많이 있었다.

⬆︎Jira

⬆︎Confluence