[소프트웨어 공학] 애자일 개발 방법론 정리
- 이번 포스팅에서는 실무에서 다소 애매하게 적용될 수 있는 애자일 개발 방법론에 대해 자료를 찾아보고 공부한 내용을 정리하겠습니다.
(애자일 모델이란?)
2001 년 2 월 11일에 발표된 소프트웨어 개발 방법론의 하나입니다.
다만,
발표 7년 전인 1994 년의 DSDM(Dynamic Systems Development Method, 동적 시스템 개발 방법) 부터,
1995 년의 Scrum 이나,
1996 년 XP(Extreme Programming),
1997 년 RUP(Rational Unified Process),
1998 년 Crystal,
1999 년 FDD(Feature-Driven Development), ASD(Adaptive Sogrware Development)
와 같은 기존 개발 방법론을 2001 년 공표한 애자일 선언문을 중심으로 묶어서 애자일 개발 방법론이라고 부른 것입니다.
애자일은 기존의 규범적이고 무거운 방법론들과 차별을 두는 방향으로 등장한 것입니다.
예를들어 애자일 이전의 개발 방법론인 폭포수 모델은 절대 이전 단계로 돌아갈 수 없고, 프로토타입 모델은 시제품을 출시하기 전에는 고객으로부터 피드백을 받지 않죠.
애자일은 이러한 경직성이 소프트웨어 개발에 맞지 않다는 명목으로 나타난 것입니다.
(개인 경험 공유)
실제 애자일을 실천한다는 기업의 예시를 찾아보니 해석도 다양하고 부정적인 평가가 많았습니다.
체계가 없음을 애자일로 꾸미는 경우가 대표적인 불만사항으로 보이며,
이 경우에는 해석 권한을 가진 자의 주장에 힘을 실어주는 용도로 사용되기에 조직 전체의 반발을 일으킬 수 있을 것입니다.
고로 애자일 모델을 적용한다는 것은, 애자일을 적용한다고 말하는 것이 아니라,
XP 를 적용한다, Scrum 을 적용한다 와 같이 구체적인 틀이 존재하는 특정한 개발 방법론을 적용한다고 해야 제대로 적용될 것이라고 개인적으로는 생각합니다.
아래에는 각 세부 방법론을 정리하겠습니다.
(애자일 세부 방법론 종류)
- DSDM(Dynamic Systems Development Method, 동적 시스템 개발 방법)
소프트웨어 개발론이지만 IT 시스템 개발에 국한되지 않도록 Driving Strategy, Delivering More 이라는 이름으로 개정되어 공표된 개발론입니다.
미리 정의된 8가지 원칙을 준수하는 것을 목표로 하며,
1. 비즈니스 요구에 집중
2. 정시 프로젝트 완수
3. 협업 중시
4. 품질과 타협하지 않음
5. 확고한 기초를 기반으로 점진적으로 구축
6. 반복적으로 개발
7. 지속적이고 명확한 의사 소통
8. 통제력 유지
위와 같은 8 원칙이 있습니다.
해석해보자면,
업무 진행의 절대적 목표는 비즈니스 요구를 구축하는 것입니다.
정해진 스케쥴을 엄수하고, 그럼에도 품질을 떨어뜨려서는 안 된다는 각오로 진행하며,
계층화된 기술의 하부에서부터 순차적으로 탄탄히 기초를 완성해나가기 위해 점진적이고 반복적으로 개발하며,
조직적으로는 협업을 중시하며, 지속적이고 명확한 의사소통으로 조직 응집력과 통제력, 프로젝트 통제력을 잃지 않아야 합니다.
원칙을 실천하기 위한 방법으로는,
1. 사전에 계획된 정형화된 회의를 통해 요구사항을 명확화 하고 개발 일정 등을 구체화합니다.
2. 명확한 모델링을 근거하여 개발을 반복합니다.
3. 반드시 해야 할 것, 언젠간 해야 할 것, 하면 좋을 것, 이번에는 하지 않을 것... 이런 식으로 우선순위 설정
4. 2~4 주 단위의 단위 개발 설정 및 실행
위와 같습니다.
- Scrum
스크럼이란, 럭비 경기에서 양 팀 선수들이 하나의 집단을 형성하여 서로 협력을 통해 공을 빼앗는 대형을 말합니다.
XP 와 함께 애자일의 대표적 세부 방법론에 해당합니다.
이를 적용하려면 먼저 스크럼 팀을 구성해야 합니다.
스크럼 팀의 구성은,
1. 제품 책임자 : 목표 달성에 대한 책임을 지고 최종 의사결정을 하는 역할입니다.
이해관계자들의 의견을 종합하며, 요구사항을 백로그에 작성하고 우선순위를 조정하여 팀에 전달합니다.
2. 스크럼 마스터 : 개발 팀원들의 원활한 업무를 위한 가이드 역할을 담당합니다.
일일 스크럼 회의를 주관할 수 있으며, 개발 과정상 발생된 장애 요소를 공론화하여 해결 할 수 있도록 처리합니다.
스크럼 마스터의 역할은 팀원들이 상황에 유연하게 대응할 수 있게 조력하는 역할이며, 통제 권한은 없습니다.
3. 개발 팀 : 제품 책임자와 스크럼 마스터를 제외한 모든 팀원(개발자, 디자이너, 테스터 등 모든 역할)을 말합니다.
팀원은 수동적으로 스크럼 마스터를 따르는 것이 아니라 능동적으로 본인이 맡은 업무를 수행할 수 있어야 합니다.
위와 같습니다.
다은으론 용어를 정리하겠습니다.
1. 스프린트 : 2~4주 정도의 기간 내에서 하나의 task 를 개발하는 과정
2. 태스크 : 개발 요구사항을 개발자별로 나눈 것
3. 제품 백로그 : 우선 순위에 따라 개발에 필요한 사용자 스토리를 나열한 목록
4. 스프린트 백로그 : 해당 스프린트에서 개발해야 할 태스크를 나열한 목록
5. 사용자 스토리 : 사용자 요구사항을 단어의 나열이 아닌 이야기의 형태로 표현한 것
6. 릴리즈 계획 : 제품 백로그에 작성된 사용자 스토리를 기반으로 전체 개발 일정 수립
스크럼 진행 프로세스 종류에는,
1. 스프린트 계획 회의 : 스프린트 백로그를 작성하고 개발 일정을 수렵
2. 스프린트 진행 : 백로그에 기록된 태스크를 담당 개발자에게 할당하여 진행
3. 일일 스크럼 회의 : 매일 짧은 시간 진행되는 회의로, 소멸 차트를 이용하여 현재 진행 상황을 점검합니다.(할 일, 진행 중, 완료의 상태로 구분)
4. 스프린트 검토 회의 : 사용자와 함께 개발이 완료된 부분 또는 전체 제품을 테스트하고 피드백을 제품 백로그에 반영합니다.
5. 스프린트 회고 : 이번 스프린트 진행 자체에 대한 문제점 및 개선점을 도출하고 다음 스프린트에 반영합니다.
스크럼 모델의 개발 프로세스는 아래와 같습니다.
1차 스프린트로,
스프린트 계획 회의 -> 스프린트 진행 -> 일일 스프린트 회의 -> 스프린트 검토 회의(산출물 생성) -> 스프린트 회고
2차 스프린트로,
스프린트 계획 회의 -> 스프린트 진행 -> 일일 스프린트 회의 -> 스프린트 검토 회의(산출물 생성) -> 스프린트 회고
위와 같은 프로세스를 반복하며 산출물은 점점 완성이 되는 방식으로 진행하는 방법론입니다.
- XP(Extreme Programming)
고객 참여와 짧은 개발 과정의 반복을 극대화 하여 개발 생산성을 높이는 모델입니다.
최종 요구사항 구현에 필요한 세부 기술을 나누고, 세부 기술부터 개발 및 검증하여 조립하는 방식으로 이루어집니다.
특정 기술의 확인을 위해 다른 모든 조건을 무시하고 간단하게 개발하는 프로그램을 스파이크라고 부르고,
기능별로 고객의 피드백을 받을 수 있게 작은 단위로 배포하는 것을 소규모 릴리즈,
하나의 릴리즈를 1~3주의 개발 기간으로 세분화한 단위를 이터레이션이라 부릅니다.
XP 의 개발 프로세스는,
최초 요구사항을 수집 후 소규모 릴리즈 계획을 수립하고, 해당 릴리즈에 필요한 스파이크를 개발하여 검증이 완료되면 이터레이션으로 전달합니다.
이터레이션이 진행되는 동안에도 추가 요구사항이 생긴다면 언제든 릴리즈 계획 수립부터 스파이크 개발까지를 진행할 수 있고, 이번 이터레이션 기간이 만료되면 내부 승인 검사를 통해 개발 사항을 평가,
비승인시에는 다음 이터레이션을 다시 반복하고, 승인된다면 소규모 릴리즈를 통해 사용자에게 전달하여 피드백을 받아 적용하는 방식으로 진행됩니다.
XP 의 실천사항은 아래와 같습니다.
1. 팀원, 규칙, 목표 등을 명확하게 설정하여 계획 수립
2. 짧은 주기의 릴리즈로 고객 피드백 최대화
3. 개발 과정에서도 최종 목표 시스템의 구조 변환 가능
4. 가능한 가장 단순한 설계
5. 테스트 기반 개발 방식(TDD)
6. 기능을 유지하며 코드 개선 작업 수행
7. 2명의 개발자가 코딩, 리뷰 공동 수행
8. 모든 코드를 모든 개발자가 언제나 수정 가능하므로 주인의식 필요
9. 지속적 통합, 지속적 배포(CI/CD)
10. 오버타임 근무를 지양하여 설계, 계획 부분의 치밀함을 중시하고 팀원의 체력, 사기 유지
11. 고객 역시 피드백을 주는 팀원으로서 대응
12. 표준화된 관례에 따른 코딩으로 의사소통 및 유지보수 향상
- RUP(Rational Unified Process)
RUP 은 Rational 소프트웨어 사에서 상용으로 개발한 프로세스와 프로세스 프레임워크를 뜻합니다.
RUP 프레임워크를 사용하며, 그에 맞는 프로세스의 개발 방법으로 생각하면 되는데,
소프트웨어 개발 방법론으로서의 RUP 을 살펴보겠습니다.
RUP 의 실천사항은,
1. 발견된 위험 요소를 원동력으로 반복적으로 개발
2. 필수 사항을 관리
3. 컴포넌트 기반 구조로 개발
4. 소프트웨어를 시각화
5. 품질을 지속적으로 확인
6. 변화의 통제
위와 같으며,
RUP 의 프로세스는,
1. 개념 수립 : 프로젝트 범위와 목표를 정의하고 주요 요구사항 수집
2. 정교화 : 시스템 구조를 설계하고 주요 리스크를 분석 및 해결
3. 구현 : 실제 코딩 작업을 수행하여 시스템을 개발
4. 전환 : 시스템을 실제 운영 환경에 배포하고 사용자 훈련 및 지원
입니다.
- Crystal
크리스탈 방법론은,
인간 중심, 반복적/점진적 개발, 투명성, 지속적 개선이라는 다른 애자일 특징과 동일한 애자일 방법론으로,
프로젝트 크기, 팀 규모, 중요도에 따라 다른 방법론을 적용하는 프로젝트 맞춤형 방법론이라는 것이 특징적입니다.
크리스탈의 종류로는,
크리스탈 클리어, 크리스탈 옐로, 크리스탈 오렌지, 크리스탈 레드와 같이 눈에 보이는 색깔로 구분되며,
클리어에서 레드로 갈수록 보다 프로젝트 규모가 크고 중요도가 높은 프로젝트라는 뜻으로,
중요도가 높을수록 문서화와 프로세스가 보다 치밀하고 엄격해집니다.
요는, 애자일 기본 골격을 유지한채 프로젝트와 팀 규모에 따라 다른 방법론이 필요하다는 것입니다.
- FDD(Feature-Driven Development, 기능 중심 개발)
FDD 는 소프트웨어를 기능 단위로 나누어 개발하는 애자일 방법론입니다.
전체 시스템을 작은 기능 단위로 분리하고, 각 기능을 독립적으로 개발하여 이를 통합하는 방식으로 진행하며,
마치 컴포넌트 개발이나 XP 의 스파이크처럼 작은 단위의 개발을 통해 소프트웨어 개발 복잡도를 줄이고, 완성도 높은 소프트웨어를 제공하는 것을 목표로 합니다.
FDD 의 주요 특징으로는,
1. 전체 시스템을 작은 기능 단위로 나누어 기능 리스트 작성
2. 각 기능의 우선순위를 정해 개발 계획 수립
3. 각 기능을 반복적으로 개발하고 테스트
4. 기능 개발 완료시마다 지속적이고 정기적으로 배포
5. 기능 분리시 도메인 모델을 작성하여 설계 품질 높이기
위와 같습니다.
FDD 의 프로세스를 순서대로 나타내자면,
1. 프로젝트 개요 정리 : 프로젝트 큰 그림 정의 및 전체 시스템 설계(도메인 모델링)
2. 기능 목록 작성 : 시스템을 작은 기능 단위로 나누고 우선순위 정하기
3. 기능별 계획 수립 : 각 기능을 담당할 개발자를 정하고 2주 이내에 구현할 수 있도록 계획 수립.
각 기능은 평가를 위해 독립적으로 동작이 가능하도록 설계
4. 기능별 설계 및 개발 : 기능 하나에 대하여 설계 -> 개발 -> 코드리뷰 -> 테스트 를 수행.
이를 반복함으로써 점진적으로 전체 시스템이 완성됩니다.
5. 기능별 코드 검사 및 배포 : 구현한 기능에 대한 코드 리뷰 및 품질 검사 수행.
이상이 없다면 배포하고, 새로운 기능 개발로 넘어갑니다.
- ASD(Adaptive Sogrware Development, 적응형 소프트웨어 개발)
ASD 는 변화가 많은 프로젝트 환경에서 최대한 빠르게 적응하며 개발하기 위해 만들어진 방법론입니다.
이 방법론의 핵심은 계획보다 적응을 우선시 하는 것으로,
변화를 미리 예측하여 대비하는 것보다는 발생하는 변화에 빠르게 적응하는 것을 핵심으로 합니다.
정해진 계획 없이 빠르게 개발 -> 빠르게 피드백 반영 -> 빠르게 개선 을 반복하는 방식입니다.
ASD 의 3단계 프로세스는,
1. 추측 : 정확한 계획 없이 대략적인 목표(가설)를 설정하며, 세세한 계획보다는 방향성을 정하는 것입니다.
2. 협력 : 개발팀, 기획자, 고객이 긴밀하게 협력하는 팀워크를 강조하며, 각자 맡은 역할 수행만이 아닌 함께 해결하는 태도
3. 학습 : 실제 적용 후 사용자 피드백을 받고 개선(결과를 보고 무엇이 효과적이었고, 무엇을 바꿔야 하는지 학습)
위와 같습니다.
요구사항이 자주 바뀌고, 고객 피드백을 빠르게 반영해야 하는 환경에서,
개발팀이 협업을 자율적으로 수행하는 문화인 경우 ASD 가 적합합니다.