소프트웨어 개발 방법론 (애자일 / 스크럼 )

안녕하세요! 

오늘은 조금 생소한 단어들을 공부해보려고 해요 :)

혹시 애자일 / 스크럼..이런 단어들을 들어보신적 있으신가요?

저는 아직 소프트웨어 개발 현업에서 종사하고 있지는 않아서 

이런 단어들이 생소하답니다...XD

그래서 오늘 알아보려고 해요!!

먼저,

소프트웨어 개발이 무슨 뜻인지 알아야 하는데요, 어렵게 생각하지마세요!!

단어 그대로 생각해봅시다.

말그대로 '소프트웨어(software)를 개발한다'라는 뜻이에요!!

---

"소프트웨어 개발(software development)은 시장 목표나 사용자의 요구를 소프트웨어 제품으로 만드는 과정이다."

출처 - 위키백과

---

ㅎㅎ간단하죠?

그럼 이 소프트웨어를 개발하려면 어떻게 해야할까요?

그냥 마음맞는 개발자 몇명이서 모여서

만들자!!!하고 뚝딱해서 만드는 걸까요?

그렇게 만들면 좋은 소프트웨어가 쨘 하고 나오는 걸까요??

아니겠죠?

이 소프트웨어 개발에도 순서가 있답니다. 

---

소프트웨어 개발에 다음과 같은 단계들을 공유한다.:

•  시장 탐구
•  제안된 비즈니스 솔루션을 위한 요구 사항 수집
•  문제 분석
•  소프트웨어 기반 솔루션을 위한 계획 및 디자인 수립
•  소프트웨어 코딩
•  소프트웨어 테스트
•  개발
•  유지 및 버그 수정

출처 - 위키백과

---

이렇게 우리가 어떤 것을 만들지, 어떤식으로 개발할지 먼저 상의를 한 다음

 계획대로 만드는게 훨씬 좋겠죠? 

그런데!!

소프트웨어를 이때까지 사람들이 몇개나 만들어왔을까요? 

컴퓨터가 개발된 후라고 생각해도 엄청나게 많겠죠?

이때까지 사람들이 소프트웨어를 개발하면서

"야, 우리가 이렇게이렇게 계획 세워놓고 하니까 좋던데? 

너네도 우리가 한 것처럼 따라해봐!!"

"어 진짜 좋네!! 이 방법대로 소프트웨어를 만드는게 진짜 좋은거같아"

"이 소프트웨어 개발 모델을 ~~개발 모형(모델)이라고 칭하자"

.

.

.

소프트웨어마다 성향이 다르니 모두 똑같이 개발 모형을 잡을 수는 없겠죠?

때문에 정말 다양하고 많은 개발 모형들이 나왔답니다.

소프트웨어 공학을 배우신 분이라면, 이 개발모형에서 유명한 

폭포수 모델이나 나선형 모델... 많이 들어보셨을거에요.

이 소프트웨어 개발 모형(모델)중 하나가!!! 

오늘 다룰 애자일 개발 모형, 스크럼 개발 모형이랍니다. 

이름만 어렵지 그냥 소프트웨어 개발 모형 중 하나구나~라고 생각하시면 될 것 같아요.

자, 서론이 길었네요

이제 본격적으로 애자일 /  스크럼이 뭔지 알아보겠습니다.

1. 애자일 개발 모형(모델) 

먼저 이 애자일 개발모형을 알려면 폭포수 모델을 아는게 좋답니다.

폭포수 모델을 아시나요? 

출처 - 위키백과

한 번 떨어지면 거슬러 올라갈 수 없는 폭포수와 같이 

소프트웨어 개발도 각 단계를 확실히 매듭짓고,

 다음 단계로 넘어간다는 의미에서 붙여진 명칭이에요.

각 단계가 명확하여 관리가 쉬우나,

폭포수 모델을 따르기 위해서는

 완전히 순차적으로 한 단계, 한 단계를 진행해 나가야 해요.

 예를 들어, 가장 먼저 요구사항 기술을 진행하여 이를 확정하여야 하며, 

그런 이후에 설계를 진행할 수 있습니다. 

즉, 폭포수 모델은 전 단계가 수행되어 완료되기 전에는 

다음 단계로 진행할 수 없도록 제한하는 것이 가장 큰 특징입니다.

 

그러므로 요구 분석에 상당한 시간이 소요되며, 

일단 분석이 끝나면 수정이 어렵다는 단점을 지니게 돼요.

 또 개발 단계마다 피드백이 발생하므로 순차적인 흐름을 따라가기 어려우며, 

규모가 크고 복잡한 시스템에는 적합하지 않습니다.

이 폭포수 모델에 비판적인 견해를 가진 사람들이 많은데 그 이유는

주로 실제 실행에 있어 불가능한 모델이라는 점이 그 주요 논지입니다. 

의미있는 규모의 프로젝트에서는 

다음 단계에 대한 이해나 경험 없이,각 단계를 완벽히 마무리한 후 

다음 단계를 진행하는 것이 불가능하다는 것이죠. 

예를 들어 고객들은 동작하는 프로토타입을 보지 않고는 

정확히 자신들이 무엇을 원하는지를 요구사항으로 정하지 못할 수 있겠죠?

 

또 고객들은 정해진 요구사항을 빈번하게 수정해달라고 요구하는 경우도 많으며, 그럴 경우 설계자나 구현자가 이를 통제할 수 있는 방법은 많지 않습니다. 

만약 고객이 설계가 완료된 이후에 요구사항 변경을 요구했다면, 

설계는 새로운 요구사항을 위해 변경되어야 하고

그때까지 투입된 많은 노력은 무위로 돌아가게 됩니다.

또한 설계자들은 설계 시에 향후 구현 작업의 난이도를 예측하기 어렵습니다.

 즉, 구현 단계에 이르러서야 특정 부분의 설계를 구현하는 것이 불가능하거나 매우 어려움이 명백해지는 경우가 생기는거죠.

 그럴 경우, 기존 설계를 유지하여 어려운 구현을 진행하는 것보다 

재설계를 택하는 것이 향후 발생할 수 있는 

더 큰 문제 상황을 방지하는 데 나은 선택이 될 수 있습니다.

데이핏 파나스는

 "합리적인 설계 프로세스: 어떻게 그리고 왜 속이게 되는가 

(A Rational Design Process: How and Why to Fake It)" 

에서 아래와 같이 쓴 바 있습니다.

---

“[시스템의] 세부 사항 중 많은 부분은 

우리가 [시스템의] 구현을 진행할 때라야 비로소 우리 눈에 보이기 시작한다.

 그리고 그렇게 알게 된 것 중 일부는 우리의 기존 설계를 무효로 만들고, 

다시 전 단계로 돌아갈 수밖에 없게 만든다. ”

---

폭포수 모델의 배경이 되는 아이디어는

 "두 번 검토해보고, 한번 실행하라(measure twice; cut once)."

는 단순한 격언이지만, 그에 반대하는 이들은 신중히 검토하는 와중에도 

지속적으로 소프트웨어 요구사항이나 문제 자체의 양상이 변화하기 때문에, 

이 아이디어가 비현실적이라고 말하는거죠.

이 폭포수 모델을 보완하여 나온것이!!!!

바로 애자일 개발 프로세스(애자일 모델)입니다.

먼저 애자일? 애자일이 뭐지 하시는 분들이 있을 것 같아요 XD

(제가 그랬어요ㅎㅎ..)

Agile

- 날렵한, 민첩한

- (생각이) 재빠른, 기민한

이라는 뜻입니다. 

알아두고 다음으로 넘어가는게 좋을 것 같아서요 :)

계속 하겠습니다. 

애자일 모델과 위 폭포수 모델의 가장 큰 차이점은

 "less document-oriented"

즉 문서를 통한 개발 방법이 아니라, code-oriented.

실질적인 코딩을 통한 방법론이라는 점입니다.

애자일 개발 프로세스는  

계획을 통해서 주도해 나갔던 과거의 방법론(폭포수 모델)과는 다르게 

앞을 예측하며 개발을 하지 않고, 

일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며 

그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나가는 adaptive style 이라고 할 수 있습니다.

애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 

"애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것)

 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다.

애자일을 간단하게 정리하자면,

---

1. 개발자와 고객 사이의 지속적 커뮤니케이션을 통하여 변화하는 요구사항을 수용한다.

 

2. 고객이 결정한 사항을 가장 우선으로 시행하고, 개발자 개인의 가치보다 팀의 목표를 우선으로한다. 

 

3. 팀원들과 주기적인 미팅을 통해 프로젝트를 점검한다.

4. 주기적으로 제품 시현을 하고 고객으로 부터 피드백을 받는다.

5.  프로그램 품질 향상에 신경쓰며 간단한 내부 구조 형성을 통한 비용절감을 목표로한다. 

---

그래서 애자일 개발 프로세스로 불리는 개발 방법론 중 하나가!!!!

스크럼입니다. 

스크럼(scrum)은 원래 

원래 럭비 경기에서 사용되던 용어입니다.

럭비에는 스크럼(scrum)과 라인 아웃(line out)이라는 

두 가지 기본 대형이 있습니다. 

이 중 스크럼은 반칙으로 인해 경기가 중단됐을 때 쓰는 대형이에요. 

반칙이 행해진 장소에 되도록 가까운 곳에서, 양 팀의 7∼8명이 서로 밀집하여 팔을 꼭 끼고 하나의 집단을 형성해 상대 팀을 앞으로 밀치는 대형을 말합니다.

 

이렇게 럭비 경기에서 쓰이던 용어가 

소프트웨어 개발 프로세스에서 사용되는 것은 

"팀이라는 단어가 주는 의미를 개발 팀에 적용하여 

효율적인 성과를 얻기 위해서"라고 하네요.

 럭비 경기의 스크럼 대형

스크럼 프로세스도 '프로세스'이기 때문에 과정이 존재하겠죠?

출처 - 네이버 지식백과

위 그림이 스크럼 개발 프로세스를 나타냅니다.

하나하나 살펴볼까요? 

1. 제품 기능 목록 작성

개발할 제품에 대한 요구 사항 목록( 제품 기능 목록) 작성.

제품 기능 목록은 우선순위가 매겨진, 

사용자의 요구 사항 목록이라고 할 수 있어요.

이 제품기능 목록은 사용자와 계속 미팅하면서 목록이 완성되게 됩니다.

 한 번 결정된 제품 기능 목록은 확정된 것이 아니고 

개발 중이라도 수정이 가능하지만, 

일반적으로 한 주기가 끝날 때까지는 제품 기능 목록을 수정하지 않습니다.

2. Sprint Backlog

각각의 스프린트 목표에 도달하기 위해 필요한 작업목록

제품 기능 목록이 사용자가 원하는 

우선순위가 부여된 제품의 기능 목록이라면, 

스프린트 구현 목록은 각각의 스프린트 주기에서 

개발할 작업 목록을 말합니다. 

작업 목록에는 

1. 세부적으로 어떤 것을 구현해야 하는지에 대한 세부 작업 항목

2 .작업자

3. 예상 작업 시간 

등에 관한 정보를 작성합니다. 

이와같은 자료를 기반으로 

스프린트를 개발하는 데 걸리는 일정을 계산할 수 있고, 

필요한 자원도 확보하여

 최종적으로는 개발이 어떻게 진행되고 있는지 진척상황을 파악할 수 있습니다. 

스프린트 구현 목록을 스프린트 계획 회의에서 결정하며, 

이 작업 목록 하나하나가 개발이 완료되면 스프린트 주기는 완성됩니다. 

3. Sprint 

위에서 계속 스프린트, 스프린트라고 그래서 

"스프린트가 도대체 뭐야?"

라고 생각하셨을 것 같아요.

스프린트는 영어단어로,

Sprint

- (짧은 거리를) 전력질주하다.

- 전력질주 

라는 뜻을 가지고 있습니다.

 전력 질주가 마라톤 같은 장거리 달리기가 아닌 단거리 달리기에서 가능한 것처럼, 스프린트는 작업량으로 볼 때 그렇게 많지 않고, 개발 기간도 짧습니다. 

즉, 스크럼 모델에서의 스프린트 뜻은 

"반복적인 개발 주기"를 의미합니다. 

 

예를 들어서, 내가 한달동안 문제를 

3~5일에 5개씩 총 40개를 푸는 것으로 계획을 세웠다면, 

3~5일의 단위가 반복되면서 문제들을 풀어나가게 됩니다.

여기서 3~5일 단위가 반복 주기이고,

스크럼에서는 이것(3~5일 단위)을

스프린트라고 합니다. 

스크럼에서 반복 주기의 기간은 스프린트 계획 회의를 통해 결정하는데,

보통은 2~4주 정도로 수행합니다.

요구사항이 안정적이고, 

개발 팀이 애자일 방법에 대해 지식과 경험이 풍부하다면 

2주 정도의 짧은 기간을 스프린트 주기로합니다.

그러나 요구사항의 변화가 많고, 

개발팀의 역량이 낮다면 4주정도의 기간을 스프린트 주기로 합니다. 

스프린트 주기가 결정되면, 

개발 팀은 팀원의 역량에 맞게 

스프린트에 배정된 작업을 중간에 멈추는 일이 없이 

전력 질주해서 끝내야 합니다.

그러려면 

결정된 스프린트의 목표과 내용이 개발 도중에 바뀌지 않아야 하고, 

그 누구도 팀원들의 동이 없이 바꿀 수 없다는 원칙을 지켜야합니다.

즉, 스프린트를 간단하게 요약하자면,

작은 단위의 개발 업무를 단기간 내에 전력 질주하여 개발한다

는 뜻으로 보면 될 것 같습니다. 

이 스크럼 모델에는 특징이 하나 있는데요, 

위 그림에서 볼 수 있듯이

매일 일일 스크럼 회의를 진행합니다.

4. 일일 스크럼 회의 (Daily Scrum Meeting)

이 일일 스크럼 회의는 스프린트 기간에 하는 회의로, 여러 특징을 가지고 있는데요,

하나씩 살펴보겠습니다. 

---

• 매일 한다.

• 서서 한다.

• 약속된 시간에 한다.

• 짧게(15분 정도) 한다.

• 진행 상황만 점검한다.

• 스프린트 작업 목록을 잘 개발하고 있는지 확인한다.

• 모든 팀원이 참석한다.

• 한 사람씩 어제 한 일을 이야기한다.

• 한 사람씩 오늘 할 일을 이야기한다. 

• 한 사람씩 문제점 및 어려운 점 정도만 이야기한다. 

• 매일 완료된 세부 작업 항목을 완료 상태로 옮겨 스프린트 현황판을 업데이트한ㄷ.

• 개별 팀원에 대한 진척 상태를 확인힌다.

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

---

일일 스크럼 회의에는 이러한 특징이 있답니다. 

다음으로 넘어가죠.

5. 제품완성과 스프린트 검토회의 

모든 스프린트 주기가 끝나면 제품 기능 목록에서 개발하려고 했던 제품(finished work)이 완성되게 됩니다.

이 최종 제품이 나오게되면 스프린트 검토 회의(sprint review)란 것을 

하게 되는데요, 우리가 만든 최종 제품이 처음에 계획했던, 

즉 고객이 요구했던 사항에 얼마나 부합하는지 

참석자(고객포함)들 앞에서 시연합니다. 

그러고 나서 개선할 점 등에 관해 피드백을 받아요. 

6. 스프린트 회고(spring retrospective)

회고는 지나간 일을 돌이켜 생각해보는 것이죠? 

그러므로 스프린트 회고는 

그동안 스프린트에서 수행한 활동과 개발한 것을 되돌아 보고, 

개선점은 없는지, 팀이 정한 규칙이나 표준을 잘 준수했는지

 등을 검토하는 것이에요. 

이때 팀의 단점을 찾기보다는 강점을 찾아 더 극대화하는 데 주안점을 둡니다. 또한 문제점에 대한 해결 방안을 찾는 회의가 아니므로 

문제점을 확인하고 기록하는 정도로만 진행합니다. 

그리고 추정 속도와 실제속도를 비교해보고, 차이가 크면 

그 이유를 분석해보지만, 프로세스 품질은 측정하지 않습니다. 

자 이렇게 스크럼 프로세스를 다 보았어요 :)

그럼 이 스크럼 모델을 선택했을 때 

좋은점과 나쁜점이 있겠죠?

그것을 살펴보겠습니다.  

---

스크럼 방식의 장점

• 반복주기(스프린트)마다 생산되는 실행 가능한 제품을 통해 

  사용자와 충분히 의견을 나눌 수 있다.

• 일일회의를 함으로써 팀원들 간에 신속한 협조와 조율이 가능.

• 일일 회의 시 직접 자신의 일정을 발표함으로써 

  업무에 집중할 수 있는 환경이 조성된다.

• 다른 개발 방법론들에 비해 단순하고 실천지향적이다. 

  
  

• 스크럼 마스터는 개발 팀원들이 목표달성에 집중할 수 있도록 팀의 문제를 해결한다. 

  (스크럼 마스터는 팀원들에게 업무를 배분해주는 사람이라고 생각하시면 될 것 같아요. 또한 개발 과정에서 방해될 만한 요소를 찾아 제거해주기도 한답니다.)

• 프로젝트 진행 현황을 볼 수 있어, 신속하게 목표와 결과 추정이 가능.

• 프로젝트의 진행 현황을 볼 수 있어, 목표에 맞게 변화를 시도할 수 있다. 

  
  

스크럼 방식의 단점

• 추가작업 시간 필요 

  : 반복주기(스프린트)가 끝날 때 마다 실행가능하거나 테스트할 수 있는 제품을 만들어야한다. 이 작업이 많아지면, 그만큼 작업 시간이 더 필요하다. 

• 일일 스크럼 회의를 15분 안에 마쳐야함 

  : 스크럼 방식에서는 일일 스크럼 회의를 15분 정도로 한다고 위에서 그랬죠? 그러나 15분의 약속이 지켜질까요? 

  일일 스크럼 회의의 특성은 꼭 필요한 것만 매우 짧은 시간에 간략히 회의한다는 것이 이 일일 스크럼 회의의 목적이지만,때로는 회의가 길어져 작업 시작 시간이 늦어지고 이로 인해 작업하는데 상당히 방해를 받을 수 있을지도 모릅니다.

  (이 단점을 발견하고 드는 제 생각은 위에서 일일 스크럼 회의 15분으로 딱!!제한 하는 건지 몰랐네요.그냥 권장하는 건줄 알았는데..

  그리고 저는 4명이서 매일 일일 스크럼 회의를 진행하는데, 

  4명이서 한시간 하는데도 빠듯하답니다..15분은 너무 짧을 것 같아요ㅎㅎ..)

  
  

  
  

• 투입 공수 불측정에 따른 효율성 평가 불가 : 투입 공수를 측정하지 않기 때문에 얼마나 효율적으로 수행되었는지는 알기 어렵다.

  
  

• 프로세스 품질 평가 불가 : 스크럼은 프로젝트 관리에 무게중심을 많이 둔 방법입니다..따라서 스프린트 수행 후 검토회의를 하지만 프로세스 품질을 평가하지 않기 때문에 품질 관련 활동이 미약하고 따라서 품질의 정도를 알 수 없습니다. 

  
  

  ---

  
  

스크럼 모델을 이렇게 구구절절 길게 설명했는데요,

한마디로 설명드리자면!!!

스크럼 모델은

애자일 개발 방법론 중 하나로, 

회의를 통해 '스프린트'라는 개발 주기를 정한 뒤,

이 개발 주기마다 회의때 정했던 계획들을 구현합니다. 

그리고 이 하나의 개발주기(스프린트)가 끝날 때 마다 

스프린트 검토 회의를 통해 

생산되는 프로토타입을 통해 사용자들의 피드백을 받으며 

더 나은 결과물을 구현해낼 수 있습니다.

애자일과 스크럼이 어떤것인지 이제 잘 아시겠나요? 

저도 이 글을 쓰면서 정말 많은 공부가 되었답니다 :)

도움이 되었으면 좋겠어요 🙏