테커파트너스 TechTalk - Agile
1) 애자일 등장 배경 : 폭포수 모델
Agile이라는 소프트웨어 개발 방법론이 나오기 전 1960~1970년대에는
'폭포수 모델(Plan-driven)'이 주로 사용되었음
앞 단계가 끝나야만 다음 단계로 넘어갈 수 있어서
마치 폭포가 내려가는 모양과 비슷하다 여겨 이와 같은 이름이 붙음
- 폭포수 모델의 단계 : 요구사항 분석 > 설계 > 구현 > 검증 > 유지보수
- 폭포수 모델의 특징 : 각 단계가 철저히 분리. 모든 단계가 계획적, 순차적으로 이루어짐
- 폭포수 모델이 적합했던 이유 :
당시에는 SW를 군대나 정부 등에서 주로 사용 + HW와 연계된 개발이 주를 이룸
-> 개발 중간에 변경을 가하는 것이 치명적
1990년대부터 상황이 많이 바뀌기 시작
- 인터넷 발달
- 개인형 컴퓨터(PC) 확산
- SW를 일반 대중들도 사용
* 폭포수 모델의 [요구사항 분석 > 설계] 과정이 길다보니
구현에 들어가기도 전에 프로젝트가 취소가 될 정도로
비즈니스와 시장 상황이 빠르게 변화함
=> 빠른 변화에 적응하고 새로운 대안을 모색하다 나온 것이 '애자일' 기법
2) 애자일 정의 & 특징
애자일 : 프로젝트를 더 작은 반복 주기로 나누는 프로세스
[요구사항 분석 > 설계 > 구현 > 검증 > 유지보수] : 이 주기가 여러 번 반복
- 각 반복 주기의 결과물을 측정하여 지속적으로 일정을 평가하는데 사용
- 사용자의 평가 뿐만 아니라 팀 내에서 이루어지는 피드백과 회고를 모두 포함
- 각 주기마다 나오는 결과물을 'Increment(증분)'이라고 함
- 증분은 동작 가능한 소프트웨어의 형태로 나옴
- 각 주기마다 사람들이 실제로 SW를 사용해볼 수 있다는 의미
- 직접 사용해보고 '진짜로 원하는 게 맞는지 확인'해나가며 피드백을 줌
- 부정적인 피드백을 주더라도 다음 주기에서 해당 사항을 반영하면 되므로
변화를 잘 수용한다는 장이 있음
핵심 기능부터 개발이 됨 (비즈니스 가치 순서대로, 가장 중요한 것부터 구현)
(+) 사용자들이 빠르게 가치를 얻어냄
(+) 빠르게 시장출시 가능
(+) 핵심 기능이 가장 많이, 오래 검증됨 > 안정성 up
일정 관리
각 주기마다 얼만큼의 기능을 구현할지 범위를 조정함으로써 관리함
팀의 지속가능한 속도를 측정하고 일정 관리
< 애자일의 단점 >
1. 진행과정이 잘 보이지 않음
- 점진적 방식 (처음부터 모든 기능이 예상되는 것이 아니기 때문)
- 문서화 부족
- 비용 추산 어려움
- 일정 관리 어려움
2. 증분이 추가됨에 따라 시스템 구조의 품질이 저하될 수 있음
요구사항이 변경될 때마다 > 구조가 꼬이고 SW품질이 떨어지게 느껴질 수 있음
- DB 구조 변화
- 도메인 구조 변화
- 컴포넌트 변화
< 애자일의 단점 극복방법 >
1) 데일리 스크럼, 칸반 보드 -> 시각적, 직관적인 툴 이용해 진행과정 공유
2) 지속적인 리팩토링
* 리팩토링이란? 결과의 변경 없이 코드의 구조를 재조정함
리팩토링은 버그를 없애거나 새로운 기능을 추가하는 행위는 아님
주로 가독성을 높이고 유지보수를 편하게 하기 위해 사용되는 것
ex) 코드 중복 제거, 직관성 있는 네이밍
-> 이를 통해 단순성 유지 + 품질은 가능한 높게 유지
<Agile Mindset>
애자일을 '왜'하는지를 알고 있는 것이 중요
불확실한 상황 속에서 실패를 두려워하기 보다는,
빠른 실패를 여러 번 경험해보고 그로부터 얻은 피드백을 통해서 발전해나가는 것이 훨씬 중요
단순히 Agile이라는 방법론을 따르는 것을 넘어 Agile 마인드셋을 아예 장착하자!
* 자료 출처 : 우아한 테크, [10분 테코톡] 낙낙의 애자일