소프트웨어 공학 - 애자일 프로세스 모델(scrum)

오늘은 애자일 프로세스 모델 (애자일 개발 방법론)에 대해 알아보겠다.

그중 scrum에 대해 자세히 알아볼 예정이다.

애자일 프로새스 모델

일단 애자일의 사전적 의미를 먼저 알아보도록 하자. 사전적 의미는 '날렵한', '민첩한'이란 뜻이다. 

 

그렇다면 이 애자일 프로세스 모델은 무엇일까? 이 모델은 고객의 요구에 '민첩'하게 대응하고 그때그때 주어지는 문제를 풀어나가는 방법론을 말한다.

 

등장 배경

폭포수 모델처럼 계획을 기반으로 하는 프로세스 중심의 전통적인 모델은 산출물 위주의 거대하고 무거운 방법론에 해당한다. 이러한 방법론들은 요구 사항의 변화에 유연하게 대처하기 어렵다는 큰 문제점이 있다. 따라서 가볍고 비교적 변화를 수용하기 쉬운 방법론이 필요하게 됐는데, 이것이 익스트림 프로그래밍( XP : eXtream Programming ), 스크럼( scrum ), 크리스털( crystal )과 같은 방법론들이다.

 

애자일은 가벼운 프로세스 방법론의 공통적인 특성을 정의하는 말인데, 2001년 1월에 각 방법론의 전문가들이 모인 애자일 연합 그룹에서 서로의 공통점을 찾아 '애자일 선언문'이라는 공동 선언서를 발표한다. 참고로 이때를 기점으로 애자일 프로세스가 주목을 받으며, 여러 회사에서 채택하기 시작했다.

 

그러면 이 애자일 선언문이 뭔지 궁금하니 내용을 살펴보자.

 

1) 애자일의 기본가치

1. 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통을 중시한다.
2. 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시한다.
3. 계약과 협상 중심이 아닌, 고객과의 협력을 중시한다.
4. 계획 중심이 아닌, 변화에 대한 민첩한 대응을 중시한다.

폭포수 모델과는 다르게 고객과의 협업, 빠른 시간 안에 고객이 작동해볼 수 있는 소프트웨어, 환경과 고객의 변화에 능동적으로 대처하는 것을 강조하고 있다. ( 폭포수 모델은 계획, 프로세스, 문서 등 산출물 같은 것에 중점을 둔다. )

 

2) 애자일의 원칙

 

애자일 선언문을 발표하면서 애자일 소프트웨어의 개발 원칙도 공개하였다.

그중 일부는 다음과 같다. 

• 최우선적인 목표는 고객을 만족시키기 위해 가치 있는 소프트웨어를 빨리, 지속적으로 제공하는 것이다.
• 개발 후반에 새로 추가되는 요구 사항도 기꺼이 받아들인다. 애자일 프로세스는 고객의 경쟁력을 위해 요구 사항의 변경을 받아들인다.
• 동작 가능한 소프트웨어를 짧으면 2주, 길면 2개월 간격으로 자주 고객에게 전달한다. 이때 간격은 짧을수록 좋다.
• 프로젝트가 진행되는 동안에 업무 담당자와 개발자는 매일 서로 의견을 주고받으며 함께 참여한다.
• 정보 전달을 위한 전화, 팩스, 인터넷 등 많은 매체 수단이 있으나 가장 효과적인 의사소통 방법은 역시 직접 만나 얼굴 보며 대화하는 것이다.
• 진척 사항의 척도를 나타내는 방법은 여러도구로 표현할 수 있으나, 가장 좋은 방법은 실행 가능한 소프트웨어를 보여주는 것이다.
• 자율적 사고와 자유로운 분위기의 프로젝트 팀에서 최고의 아키텍처, 요구 사항, 설계가 나온다.
• 프로젝트의 효율성을 향상시키기 위해 개발 팀 스스로 정기적인 미팅을 진행하여 자신들의 행동을 되돌아보고 조율 및 수정한다.

3) 애자일의 개발 방법

 

애자일 개발 방법은 반복적인 개발을 통한 잦은 출시를 목표로 한다. 실행 가능한 프로토타입을 만들어 사용자에게 확인받고, 좀 더 빠른 시간 안에 일부이지만 소프트웨어를 사용할 수 있게 하는 것을 중요하게 생각한다.

 

에자일 개발 방법론(scrum)

스크럼은 원래 럭비 경기에서 사용되던 용어이다. 럭비에는 스크럼과 라인 아웃이라는 두 가지 기본 대형이 있는데, 이 중 반칙으로 인해 경기가 중단됐을 때 쓰는 대형이 바로 스크럼이다. 스크럼은 반칙이 행해진 장소에 최대한 가까운 곳에서, 양 팀의 7~8명이 서로 밀집하여 팔을 꼭 끼고 하나의 집단을 형성해 상대 팀을 앞으로 밀치는 대형을 말한다.

 

이런 럭비 용어가 소프트웨어 개발 프로세스에서 사용되는 것은 팀이라는 단어가 주는 의미를 개발 팀에 적용하여 효율적인 성과를 얻기 위해서이다. 

 

스크럼 개발 프로세스는 소프트웨어 개발보다는 팀의 개선과 프로젝트 관리를 위한 애자일 방법론으로, 경험적 관리 기법 중 하나이다. 지금까지 배운 다른 소프트웨어 개발 방법들처럼 구체적인 프로세스를 명확하게 제시하지 않는다.

 

1) 스크럼 방식의 진행 과정

진행과정의 이미지화

스크럼 방식에서 알아야 할 용어와 스크럼 방식의 진행 절차를 살펴보자.

 

• 제품 기능 목록(product backlog) 작성

제품 기능 목록은 일반적인 개발 방법의 요구 사항에서 기능 목록과 같다고 보면 이해하 포인트기 편하다. 

사용자가 요구하는 제품의 기능 목록을 말하며, 제품에 관한 모든 요구 사항에 대해 우선순위가 정해져 있다.

이 우선순위는 고객 측 대표인 제품 책임자가 결정한다.

 

사용자와 계속 미팅하며 목록이 완성된다. 한 번 결정된 제품 기능 목록은 확정된 것이 아니고 개발 중이라도 수정이 가능하지만, 일반적으로 한 주기가 끝날 때까지는 제품 기능 목록을 수정하지 않는 편.

 

 

• 사용자 스토리(user story) 작성

사용자 스토리는 메모지 한 장에 쓰인 사용자 요구 사항이다. 구현할 기능이 사용자 관점에서 사용자 언어로 작성되어있다.

특징으로는 다음과 같다.

1. 제품 기능 목록에 정의된 사용자 관점에서의 기능
2. 구현할 기능이 사용자의 관점에서 사용자의 언어로 작성
3. 우선순위가 결정되어야 하고, 큰 것보다는 많은 것이 좋음
4. 다른 story에 종속되지 않고 독립적이어야 하며, 협상이 가능해야 함
5. user story의 업무량을 파악해 전체 개발 기간 산정이 필요함

• 스토리 포인트(story point) 산정

작성된 사용자 스토리는 스토리 보드에 나열되어 있다. 

사용자 스토리에서 보았듯이 각각의 사용자 스토리는 우선순위가 정해져야 하며, 하나의 사용자 스토리에 대한 업무량을 파악하여 수행하는데 걸리는 개발 기간도 산정해야 한다. 이때 상대적인 개발 시간을 스토리 포인트라고 한다.

 

이 스토리 포인트 산정은 개발자가 하며 중요도 판단은 업무 분석가가 하게 된다.

 

• 스프린트(sprint)

그냥 단어의 뜻은 '전력질주'이다. 이런 전력질주는 실제 달리기에서 마라톤 같은 장거리 달리기가 아닌 단거리 달리기에서 가능하다. 

이제 스프린트가 소프트웨어 개발에서 어떤 의미로 사용되는지 짐작이 가능할 것이다.

 

스프린트는 작업량으로 볼 때 그렇게 많지 않고, 개발 기간도 짧다. 결국 작은 단위의 개발 업무를 단기간 내에 전력 질주하여 개발한다는 뜻으로 보면 된다.

 

예를 들어 원고를 1년 동안 10일 또는 40일에 한 장씩 총 10장을 써서 완성하는 것을 계획으로 세웠다면, 10 ~ 40일 단위가 반복되어 원고가 완성될 것이다. 여기서 10 ~ 40일 단위가 반복 주기이며, 스크럼에서는 이것(10 ~ 40일 단위)을 스프린트라고 한다.

 

스크럼에서 반복 주기의 기간은 스프린트 계획 회의를 통해 결정하며, 보통은 2 ~ 4주 정도로 수행한다.

스프린트 주기가 결정되면, 개발 팀은 팀원의 역량에 맞게 스프린트에 배정된 작업을 중간에 멈추는 일 없이 전력 질주해서 끝내야 한다.

그렇기 때문에 결정된 스프린트 목표와 내용이 개발 도중 바뀌지 않아야 하며, 그 누구도 팀원들의 동의 없이 바꿀 수 없다는 원칙을 지켜야 한다.

또한 스크럼 마스터는 외부로부터 오는 개발 방해 요소를 차단해 줘야 한다.

 

이렇게 해서 하나의 스프린트에 대한 개발이 완료되면 사용자에게 시연해 보이고 사용자는 피드백을 제공해야 한다.

그런데 계획된 일정 안에 개발을 마치지 못할 수도 있다. 그렇다 해도 하나의 스프린트는 개발 완료 여부와 관계없이 정해진 일정이 지나면 끝난다.

 

추가로 제품의 완성도를 단순 기능 구현 정도로 할 것인지, 버그 하나 없이 완벽할 정도의 높은 수준으로 할 것인지는 회의를 통해서 결정한다.

 

• 스프린트 구현 목록 (sprint backlog)

스프린트 구현 목록은 각각의 스프린트 주기에서 개발할 작업 목록을 말한다. 작업 목록에는 세부적으로 어떤 것을 구현해야 하는지에 대한 세부 작업 항목과 작업자, 예상 작업 시간 등에 관한 정보를 작성한다

이와 같은 자료를 기반으로 개발이 어떻게 진행되고 있는지 진척 상황을 파악할 수 있다.

 

• 소멸 차트 (burndown chart)

소멸 차트는 처음 계획된 작업 소진 그래프를 그려놓고, 시간이 지남에 따라 실제로 얼마나 작업량이 줄어드는지 비교할 수 있도록 개발이 완료되기까지 남은 작업량을 보여준다.

이때 각 반복 구간별로 남은 작업량을 스토리 포인트로 나타낸다.

당연하게도 기울기가 높다면 빠르게 작업이 진행되고 있다는 것이고, 기울기가 완만하다면 느리게 작업되고 있다는 뜻이다.

 

• 스프린트 계획 회의

스프린트 계획은 각 스프린트에 대한 목표를 세우는 일과 제품 기능 목록에서 어떤 항목을 스프린트에서 진행할지 선택하는 것이다. 그리고 선택된 각 항목에 대해 개발자를 배정하고 세부적인 작업 단위로 계획을 수립하는 것이다.

 

이 스프린트 계획을 세우기 위한 계획 회의는 크게 두 가지로 나눌 수 있다.

 

- 전체적인 스프린트 계획 회의

제품 책임자를 통해 사용자가 원하는 것이 무엇인지를 파악하는 데 중점을 둔다.

 

이를 위해 스크럼 마스터는 제품 기능 목록을 검토하며 어떤 항목을 가장 높은 순위로 놓았는지에 관심을 갖고, 그 배경과 목표에 대해 팀원들과 토의하며 제품 책임자의 의도를 파악한다.

 

- 세부적인 스프린트 계획 회의

우선순위가 높은 항목에 대한 구체적인 작업 계획 수립한다. 그다음 제품 기능 목록에서 개발 항목을 결정하고, 스프린트 구현 목록을 작성한다. 또 팀원들은 정해진 작업을 수행하는 데 소요되는 시간을 추정한다.

 

• 일일 스크럼 회의 ( daily scrum meeting )

특징들을 짧게 요약하자면,

- 매일, 서서, 짧게 15분 정도 약속된 시간에 회의를 진행한다.

- 진행 상황만 점검하며, 스프린트 구현 목록을 잘 개발하고 있는지 확인한다.

- 모든 팀원이 참석해야 하며, 한 사람씩 어제 한 일을 얘기한다.

- 매일 완료된 세부 작업 항목을 완료 상태로 옮겨서 현황판을 업데이트한다.

- 그날의 남은 작업량을 소멸 차트에 표시한다.

 

• 스프린트 현황판 ( task board )

개발 팀의 개발 현황 ( 진척도, 남은 작업, 진행 속도 )을 나타낸다.

 

• 최종 제품

모든 스프린트 주기가 끝나면 제품 기능 목록에서 개발하려고 했던 제품이 완성된다.

 

• 스프린트 검토 회의 ( sprint review )

스프린트 검토 회의에서는 하나의 스프린트 반복 주기가 끝났을 때 생성되는 실행 가능한 제품에 대해 검토한다.

스프린트 목표를 달성했는지 작업 진행과 결과물을 확인하고, 전체 흐름을 확인하여 비즈니스 가치를 점검하는 데 중점을 둔다.

 

• 스프린트 회고 ( sprint retrospective )

그동안 스프린트에서 수행한 활동과 개발한 것을 되돌아보고, 개선점은 없는지, 팀이 정한 규칙이나 표준을 잘 준수했는지 등을 검토하는 것이다. 이때 팀의 단점을 찾는 것보다, 강점을 찾아 더 극대화하는 데 초점을 둔다. 또한 문제점에 대한 해결 방안을 찾는 회의가 아니므로 문제점을 확인하고 기록하는 정도로만 진행한다.

 

• 배포 목록 ( release backlog )

배포 목록은 제품 기능 목록의 항목 중에서 이번 배포 본에 포함하기로 결정한 항목을 말한다. 따라서 배포 목록을 작성하면 이번 배포 본의 개발 범위와 일정을 수립할 수 있다. 또 사용자에게 전달되는 배포 본의 기능 내역과 시기, 스프린트 주기, 배포 일정을 결정하게 된다.

 

스크럼 방식의 장단점

장점

1.  반복 주기마다 생산되는 실행 가능한 제품을 통해 사용자와 충분히 의견을 나눌 수 있음
2. 일일 회의를 함으로써 팀원들 간의 신속한 협조와 조율이 가능
3. 일일 회의 시 직접 자신의 일정을 발표함으로써 업무에 집중할 수 있는 환경 조성
4. 다른 개발 방법론들에 비해 단순하고 실천 지향적
5. 프로젝트의 진행 현황을 볼 수 있어, 신속하게 목표와 결과 추정이 가능
6. 프로젝트의 진행 현황을 볼 수 있어, 목표에 맞게 변화를 시도할 수 있음

단점

1. 추가 작업 시간 필요 : 반복 주기가 끝날 때마다 실행 가능하거나 테스트할 수 있는 제품을 만들어야 함. 이 작업이 많아지면 그만큼의 작업 시간이 더 필요
2. 일일 스크럼 회의를 15분 안에 마쳐야 함 : 스크럼 방식에서는 일일 스크럼 회의를 15분 정도로 정해놓았다. 그런데 때로는 회의가 길어져 작업 시작 시간이 늦어지고 그로 인해 작업하는 데 상당히 방해를 받을 수 있음
3. 투입 공수 불측정에 따른 효율성 평가 불가 : 투입 공수를 측정하지 않기 때문에 얼마나 효율적으로 수행되었는지 알기 어려움
4. 프로세스 품질 평가 불가 : 스프린트 수행 후 검토 회의를 하지만 프로세스 품질을 평가하지 않기 때문에 품질 관련 활동이 미약하고 따라서 품질의 정도를 알 수 없음 

이렇게 애자일 개발 방법론과 그중에서 scrum에 대해 알아 보았다.