애자일 개발 프로세스의 배경
90년대 후반까지 소프트웨어 공학과 개발 방법론은 다른 공학의 프로세스와 비슷하게 장기간에 걸쳐 많은 사람들을 투입하고 충분한 비용을 투입하여 진행되었다. 또 개발 프로세스들은 소프트웨어 프로젝트를 일련의 선형적 순서로 구성하는 waterfall model과 plan driven development 방식으로 진행되었다.
하지만 90년대 이후 소프트웨어 분야가 넓어지고 소프트웨어의 사용자들이 일반 대중으로 바뀌기 시작했다. 트랜드가 급격하게 변하기 시작한 것이다. 이에 따라 소프트웨어 개발은 유동적이고 개방적이며 요구사항의 변경에 따른 작업량을 예측하기 힘들어졌다. 전통적인의 방식은 일련의 차례와 정해진 계획을 기반으로 개발하기 때문에 계획대로 진행되지 않을 경우에는 부작용을 많이 겪을 뿐만 아니라 빠른 비지니스 사이클과 시장 상황을 따라가지 못하기 때문에(구현되기도 전에 취소될 정도였다) 소프트웨어 개발의 불확실성이 높아지게 됐다.
이에 대응하여, 경량 방법론 주의자들이 '규칙을 적게 만들고 가볍게 대응을 잘하는 방법'을 적용해서 새로운 개발 프로세스를 진행했다. 이 프로세스가 아주 잘 적용되면 겉으로 보기엔 미리 큰 계획을 만들어놓고 하는 것처럼 보이게 된다. 이후에는 이런 개발 방법론들이 소프트웨어 개발자 그룹이 애자일 소프트웨어 개발에 대한 선언문(The Manifesto for Agile Software Development)으로 작성되었다. 이 문서에서는 개발 프로세스의 새로운 접근방식과 애자일의 4가지 주요 특성을 설명하고 있다.
90년대 후반, 위기에 대한 기술적인 해결책으로는 객체지향 프로그래밍이 있다. 이 패러다임은 그 동안의 개발 문제를 적절하게 대처해 주었다. 이에 발맞춰 객체지향 프로그래밍 패러다임에 맞는 개발 프로세스가 필요했는데, 이때 수많은 애자일 개발 프로세스가 만들어졌다. 따라서 애자일 개발 프로세스의 상당수는 객체지향 기술을 기반으로 한다.
애자일 방법론이란?
애자일은 신속한 반복 작업을 통해 실제 작동 가능한 소프트웨어를 개발, 지속적으로 제공하기 위한 소프트웨어 개발 방식을 의미한다. 구체적으로 말하자면, 작동하는 소프트웨어의 작은 구성 요소를 빠르게 제공해서 고객의 만족도를 개선하는 방식을 의미한다. 이를 위해서 개발팀은 협력과 피드백을 저 자주, 일찍, 잘하는 것을 목표로 한다.
시간에 따라 변화하는 고객(즉, 소프트웨어 개발자) 요구 사항에 대응하는 민첩한(agile) 개발 방식
CI / CD와 관련해서 생각해본다면, 애자일은 CI / CD 라는 디지털 워크플로의 기반이다. 물론 초기에 애자일의 초점은 개발 팀의 작업 방식이었으나 DevOps는 하위 프로세스까지 영역을 확장했고 코드가 작성되고 릴리스될 때까지의 과정을 포함하게 되었다. 그러다보니 우리가 다음에 살펴볼 CI / CD 의 애자일한 특징들이 생겨난 것이다.
애자일 4가지 주요 특성 및 개발 방법
- 개인과 개인 간의 상호작용이 프로세스 및 툴보다 우선
- 작동하는 소프트웨어가 포괄적인 문서보다 우선
- 고객과의 협업이 계약 협상보다 우선
- 변화에 대응하는 것이 계획을 따르는 것보다 우선
- 개발자와 고객 사이의 지속적 커뮤니케이션을 통해 변화하는 요구사항을 수용한다.
- 고객이 결정한 사항을 가장 우선으로 시행, 개발자 개인의 가치보다 팀의 목표를 우선으로 한다.
- 팀원들과 주기적인 미팅을 통해 프로젝트를 점검한다.
- 주기적으로 제품 시현을 하고 고객으로부터 피드백을 받는다.
- 프로그램 품질 향상에 신경쓰며 간단한 내부 구조 형성을 통한 비용 절감을 목표로 한다.
스크럼
애자일 방법론을 적용한 가장 많이 사용되는 개발 프로세스이다. 원래 럭비 경기에서 사용되던 용어인데, 반칙으로 인해 경기가 중단됐을 때 쓰는 대형을 의미한다. 즉, 소프트웨어 측면에서 팀이라는 단어가 주는 의미를 적용시키고, 효율적인 성과를 얻기 위한 방식을 의미한다고 해석할 수 있다.
1. 제품 기능 목록 작성
개발할 제품에 대한 요구사항 목록을 작성한다. 우선순위가 매겨진, 사용자의 요구사항 목록이라고 할 수 있다. 개발 중에 수정이 가능하기는 하지만 일반적으로 한 주기가 끝날 때까지는 제품 기능 목록을 수정하지 않는 것이 원칙이다.
2. 스프린트 Backlog
스프린트란 각각의 목표에 도달하기 위해 필요한 작업 목록이다.
- 세부적으로 어떤 것을 구현해야 하는지
- 작업자는 누구인지
- 예상 작업 시간은 얼마나 걸릴지를 작성한다.
이를 통해서 개발이 어떻게 진행되고 있는지 상황 파악이 가능하다
3. 스프린트
스프린트란 이름이 붙여진 이유는 그 의미 때문이다. 스프린트의 단계부터 작은 단위의 개발 업무를 단기간 내에 전력질주해서 개발한다. 한 달 동안의 큰 계획을 3~5일 단위로 반복 주기를 정했다면, 이것이 스크럼에서 스프린트에 해당한다. 이 주기가 회의를 통해 결정되면 (보통 2~4주) 목표와 내용이 개발 도중에 바뀌지 않아야 하고, 팀원들 동의없이 바꿀 수 없어야 한다.
4. 일일 스크럼 회의
모든 팀원이 참석하여 매일, 짧게(15분) 진행 상황을 점검한다. 한 사람씩 어제 한 일, 오늘 할 일, 문제점 및 어려운 점을 이야기한다. 완료된 세부 작업 항목을 스프린트 현황판에서 업데이트시킨다.
5. 제품 완성 및 스프린트 검토 회의
모든 스프린트 주기가 끝나면 제품 기능 목록에서 작성한 제품들이 완성된다. 최종 제품이 나오면 고객들 앞에서 시연을 통한 스프린트 검토 회의를 진행한다. 이 때 고객의 요구사항에 얼마나 부합했는지, 개선점 및 피드백이 있는지 확인한다.
6. 스프린트 회고
스프린트에서 수행한 활동과 개발한 것을 되돌아보며 개선점이나 규칙 및 표준을 잘 준수했는지 검토한다. 팀의 단점보다는 강점과 장점을 찾아 더 극대화하는데 초점을 둔다.
스크럼의 장단점
장점
- 스프린트마다 생산되는 실행 가능한 제품을 통해 사용자와 의견을 나눌 수 있다
- 회의를 통해 팀원들간 신속한 협조와 조율이 가능하다
- 자신의 일정을 직접 발표함으로써 업무 집중 환경을 조성할 수 있다.
- 프로젝트 진행 현황을 통해 신속하게 목표와 결과 추정이 가능하며 변화 시도가 용이하다
단점
- 스프린트마다 테스트 제품을 만들어야 하기 때문에 추가 작업 시간이 필요하다.
- 15분 회의 시간을 지키기 어렵다. 그만큼 작업 시간이 또 줄어든다.
- 스크럼은 프로젝트 관리에 무게중심을 두기 때문에 프로세스 품질 평가에는 미약하다.
