이번 포스팅에서는 소프트웨어 개발방법론중 하나인 애자일 프로세스에 대해서 알아보겠습니다. Agile이란 "민첩한", "기민한", "재빠른" 사전적 의미가 있습니다. 많은 조직에서 이 애자일 방법론을 사용하고 있는데 변화에 빠르게 대응하기 위한 프로세스라고 생각하시면 될 꺼 같습니다. 하지만 꼭 개발 프로세스에만 적용해야 하는법은 없고 상황에 맞게 이 방법을 적용할 수 있을꺼 같습니다.
1. 전통적인 폭포수 모델형 개발 방법론
폭포수 모델을 포함한 전통적인 개발 방법론은 다음과 같은 큰 틀을 가지고 있습니다.
서비스 기획 -> 디자인 -> 개발 -> 테스트 -> 배포 -> 유지보수
예를 들어 프로젝트의 총 기간이 6개월이라고 가정한다면, 1개월은 서비스 기획, 1개월은 디자인 , 4개월 개발 및 테스트 배포 후 유저들의 반응을 보고 유지보수 하는 방법이라고 생각하시면 될꺼같습니다. 이런 방식으로 개발을 했을 때 단점은 진행한 프로젝트의 결과가 좋지 않았을 때 대응을 하는 비용이 크다는 것입니다.
스티브 맥코넬의 저서 "Rapid Development"에서 요구사항 상의 결함이 구현이나 유지보수 단계에서 발견되지 않고 남아있을 경우, 이를 수정하는 비용은 요구사항 기술 시에 수정하는 것에 비해 50배에서 200배까지 드는 것을 예측했다고 나와있습니다.
2. 애자일 방법론이란?
애자일 개발 방법론은 2001년에 발표한 애자일 선언에서부터 시작합니다.
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.
- 공정과 도구보다 개인과 상호작용을
- 포괄적인 문서보다 작동하는 소프트웨어를
- 계약 협상보다 고객과의 협력을
- 계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
이 선언문을 좀더 알기 쉽게 풀어서 말하면 이런 말입니다.
1. 우리는 팀이니까 커뮤니케이션 잘하고
2. 쓸데없이 문서 작성하는데 시간 들이지 말고, 실제로 동작하는 소프트웨어 만들고
3. 고객이 실제로 가치를 느끼는 프로덕트를 만들고,
4. 계획은 원래 변하는거니까, 이 변화에 대응할 수 있도록 유연한 작업 방식으로 일하자!
요약하면, 고객과 제품을 만들기 위해서 유연하게 움직이는 조직입니다. 애자일 선언 외에도 12개의 우너칙을 세워 놓고 그 원칙을 따르고자 합니다.
우리는 다음 원칙을 따른다.
-
우리의 최우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
-
비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
-
작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
-
비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
-
동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
-
개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
-
작동하는 소프트웨어가 진척의 주된 척도이다.
-
애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
-
기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
-
안 하는 일의 양을 최대화하는 기술이 필수적이다.
-
최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
-
팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
애자일 방법론과 관련되어 알아야할 용어가 몇가지 있습니다.
2.1 스프린트(sprint)
스프린트의 사전적 정의는 다음과 같습니다.
스프린트(sprint): 육상 경기·수영 경기·스피드 스케이트 등의 단거리 레이스. 또는, 단거리를 전력(全力)으로 행하는 질주(疾走)나 역영(力泳).
단거리 전력질주를 뜻하고, 이 개념을 프로젝트에 대입하여 Task를 너무 크게 잡지 않으며(단거리) 단기간에 전력 질주 하듯이 업무를 수행하는 것을 스프린트라고 생각하면됩니다. 저같은 경우에는 보통 2주 정도의 스프린트를 잡고 프로젝트를 진행하고 있습니다.
2.2 스크럼(Scrum)
이제는 스크럼에 대해서 알아보겠습니다. 스크럼의 사전적 정의는 다음과 같습니다.
럭비에서 반칙이 있을 때, 양편 선수가 밀집하여 서로 팔을 꼭 끼고 뭉치는 일. 그 사이로 굴려 넣은 공을 자기편 쪽으로 빼냄.
스크럼은 위의 사진과 같이 럭비에서 유래된 용어입니다. 팀원들이 어깨동무를 하고 상대편과 원을 이루고 중앙에 럭비공을 놓아서 경쟁하는 것을 말합니다. 스프린트 기간 동안 팀원들과 협업하여 소프트웨어를 개발하는 모습이 이 모습과 비슷해서 나온 용어 같습니다.
2.3 백로그(Backlog)
요구사항 리스트, 제품의 개발 대상 목록으로 이해하면 됩니다. 애자일에서는 요구사항을 User Story라고 부릅니다.
3. 애자일의 기본 요소
위의 그림은 스크럼의 전체 프로세스를 도식화한 그림입니다.
[Product Owner(PO)]
제품에 대한 책임자로 요구사항 즉 백로그(Backlog)를 작성하는 주체입니다. 팀이 개발할 소프트웨어에 대한 오너쉽을 가집니다. 또한 어떤 백로그부터 개발을 해야할지 우선순위를 정하는 유일한 사람입니다. 보통 이 역할은 소프트웨어 개발 영역에 있는 사람보다는 제품을 사용할 고객이 직접 하거나 비즈니스 요구사항을 정의 할 수 있는 사람이 합니다.
[Scrum Master(SM)]
스크럼 마스터는 팀의 스크럼이 잘 수행할 수 있도록 도와주는 역할을 합니다. 스크럼 마스터는 최대한 객관적인 시각에서 스크럼에 정해진 원칙들이 팀에 잘 적용될 수 있도록 도와주고, 문제가 생겼을 때 해결하는 역할을 합니다.팀 구성원의 분쟁이나, 일에 대한 우선 순위 선정, 일이 정말로 잘 끝났는지 내려진 정의를 보고 의사결정을 할 수 있게 가이드하는 역할을 합니다.
[Team Member]
위의 두 역할을 제외한 모든 팀원을 말합니다. 제품이 만들어지기 위해서 필요한 모든인력으로, 개발자, 디자이너, 테스터 등을 뜻합니다. 이렇게 구성된 스크럼팀의 크기는 일반적으로 2개의 피자를 한끼 식사에 먹을 수 있는 인원(Two-pizza team)인 7~8명을 넘지 않는 것이 좋습니다.
스크럼에는 이렇게 3가지 역할만 존재합니다. 우리가 흔히 알고 있는 프로젝트 매니저(PM)나 프로젝트 리더(PL)는 존재하지 않습니다. 프로젝트 매니저나 프로젝트 리더는 과제의 일정을 수립하고 예산에 대한 결정을 내리고 이슈나 리스크가 있으면 핸들링을 하는 '강압적인 존재'입니다. 팀원들의 의견을 듣지 않을 수 있고 팀원들의 의사를 반영하기 보다는 빨리 결정해서 Top-Down 방식으로 일을 수행하는 것을 편하게 생각하는 사람도 있습니다.
글이 길어져서 다음편에서 이어서 진행하도록하겠습니다.
REFERENCE
'개발방법론' 카테고리의 다른 글
| [Clean Code] 주석 작성 방법 (0) | 2020.04.14 |
|---|---|
| [Clean Code] 함수 작성 (0) | 2020.04.06 |
| [Clean Code] 깨끗한 코드란(클린코드)? (0) | 2020.04.02 |
| 객체지향프로그래밍(OOP) 설계 원칙 SOLID (0) | 2020.03.30 |
| 애자일(Agile) 프로세스란?(2/2) (0) | 2020.03.12 |
최근댓글