여는 말
Agile 방법론은 그 이름을 워낙 많이 들어서 익숙한 느낌이지만, 정작 제대로 공부해 본 적은 없었다.
이론적인 것과 실제 개발에서의 체감은 또 다르겠지만, 이게 뭔지 설명 정도는 할 줄 알아야 할 것 같아 이번 기회에 정리하게 되었다.
Agile이란?
: SW 개발의 유연성과 효율성을 위한 방법론
Agile은 '기민한', '민첩한'이라는 뜻이다.
한 번에 모든 것을 완벽하게 설계하고 만드는 게 아니라, 짧은 주기로 계속 디벨롭 해 나가며 고객의 피드백을 반영하는 방식을 말한다.
Agile의 등장 이전에는 폭포수(Waterfall) 모델이라고 하는 정반대의 방법론이 있었다.
위에서 아래로 떨어지기만 하는 폭포수처럼,
요구사항 정의 → 설계 → 개발 → 테스트 → 배포 순으로 한 방향으로 흐르는 방식이다.
이 방식은 피드백을 반영하는 속도가 느리다는 단점이 있다.
현대의 소프트웨어 환경은 요구사항이 수시로 변하기 때문에, "계획은 언제든 바뀔 수 있다"는 점을 염두에 두고 Agile 방법론이 등장하게 되었다.
애자일 선언문(Agile Manifesto)에는 4가지 핵심 가치와 12가치 원칙을 소개하고 있다.
Agile 4가지 핵심 가치
1. 개인과 상호작용
: 애자일은 인간 중심의 업무 방식을 지향하기 때문에 팀원과의 소통 및 상호작용을 중요시한다.
2. 동작하는 소프트웨어
: 문서를 줄이고 실제로 돌아가는 결과물을 만들어내는 데 집중한다.
3. 고객 협력
: 고객과의 지속적인 피드백을 통해 새로운 요구사항을 유연하게 받아들인다.
4. 변화에 대응
: 변칙적인 상황에 대응하기 위해, 초기 설정보다 상황 변화에 따라 유연하게 대처하는 것을 더 중요시한다.
Agile 12가치 원칙
1. 고객 만족
2. 변화 수용
3. 소프트웨어 제공
4. 협업 강화
5. 동기 부여
6. 대면 대화
7. 소프트웨어 진척도
8. 지속 가능한 개발
9. 기술적 탁월성
10. 간결함
11. 자율적인 팀
12. 정기적 반성
Agile 프레임워크
Agile을 위한 대표적인 가이드라인은 다음과 같다.
1. 스크럼 (Scrum)
: 가장 대중적인 방식이다. 정해진 기간(Sprint) 내에 목표를 달성하는 데 집중한다.
2. 칸반 (Kanban)
: 업무의 흐름을 시각화하는 데 최적화된 방식이다. Jira처럼 '할 일 - 진행 중 - 완료' 상태를 한눈에 확인하는 데 목적이 있다.
3. XP (Extreme Programming)
: 개발 기술적 실천을 강조한다. TDD, Pair Programming, Code Review 등 소프트웨어의 품질을 높이는 방법론이 포함되어 있다.
4. 린 (Lean)
: 도요타의 TPS(Toyota Production System)를 SW 개발에 적용한 방법론이다. '낭비 제거'에 집중해서, 프로그램 개발 중에 발생할 수 있는 모든 낭비 요소를 제거하는 데 목적이 있다. 핵심 기능만 빠르게 개발해서 시장의 반응을 보고 다음 단계를 결정하는 방식이다.
스크럼 (Scrum)
SCRUM은 짧은 반복 주기(Sprint)와 정기적인 미팅(Daily Scrum)을 통해 적응력을 높이고, 팀 내 상황 파악을 단단히 할 수 있는 Agile의 대표적인 프레임워크다.
Scrum 프레임워크의 구성 요소는 다음과 같다.
1. Scrum Team
: 제품을 개발에 참여하는 전체 인원을 일컫는다.
-
Product Owner
: 제품의 소유자다. 고객의 요구사항과 피드백을 반영하여 Backlog를 업데이트한다. -
Scrum Master
: Scrum Team의 리더다. Scrum Team을 관리하며 Scrum을 효율적으로 수행할 수 있도록 주도적으로 진행한다. -
Scrum Development Team
: 실제 제품을 개발하는 개발자, 디자이너로 구성된다.
2. Scrum Event
: Scrum이 돌아가는 실제 과정이다.
-
Sprint
: Scrum의 기본 단위(보통 1~4주)로, 이 기간 내에 정해진 목표를 달성한다. -
Sprint Planning
: 이번 Sprint에 무엇을 어떻게 할지 결정하는 회의 -
Daily Scrum
: 매일 15분 정도 짧게 진행 상황을 공유하는 회의 -
Sprint Review
: Sprint가 끝나고 결과물을 시연하며 피드백을 받는 시간 -
Sprint Retrospective
: 팀의 업무 방식 자체를 돌아보고, 개선점을 찾아서 회고하는 시간
3. Scrum Artifact
-
Product Backlog
: 제품에 필요한 기능 목록과 요구사항/개선사항 등을 우선 순위에 따라 나열한 목록이다. Product Owner가 관리한다. -
Sprint Backlog
: Sprint 동안 개발 팀이 작업해야 하는 항목, 수정해야 할 버그 목록이다. Sprint 중에 변경될 수 있지만, 해당 Sprint 자체의 목표는 유지해야 한다. -
Increment
: Sprint의 '실제로 동작하는' 결과물이다.
맺음말
결국 '빠른 추진과 피드백 반영'이 핵심인 것 같다.
하지만 이론은 이론일 뿐, 실제로 팀을 운영하는 과정에서 Sprint의 목표를 달성하지 못 했을 때, 요구사항의 변경이 굉장히 많을 때 어떤 식으로 풀어나가야 하는지는 직접 겪어보면서 배워야 한다.
이번 프로젝트에서 PM을 따로 정하게 될지는 모르겠지만, 팀장 역할을 수행하면서 Agile하게 일정을 관리하는 연습을 해보고 싶다.
