👫 협업 잘하기/애자일(스크럼)

[애자일] 애자일 개발을 하고 있지만 공부해 본 적 없는 분들을 위해

Jinseong Hwang 2023. 7. 2. 00:50

 

안녕하세요. 황진성입니다.

 

오늘은 애자일 개발과 스크럼에 대해서 알아보겠습니다.

 

제가 현재 속해있는 팀은 애자일 개발 방식을 실천하고 있습니다. 운이 좋게도 애자일 코치님 계셔서 애자일 개발을 이끌어 주십니다. 처음 이 방식을 접했을 때는 "왜 이렇게까지 복잡하게 일하지?" 라는 생각이 들었지만, 따라갈수록 재밌고 효율적인 방법인 것 같아서 저 또한 매력에 빠졌습니다.

 

조금은 이론에 가까운 내용이라 지루할 수 있습니다. 하지만 지금 혹은 나중에 애자일 개발을 하는 팀에 조인했을 때, 당황하지 않고 소통에 어려움이 없으시길 바라며 이 글을 작성해봤습니다.

 

소프트웨어를 개발하는 목적

(이미 그럴 수도 있지만,) 당신을 회사에 소속된 소프트웨어 개발자라고 가정하겠습니다.

 

소프트웨어를 왜 개발하나요?

 

 회사 입장에서 생각해 봅시다. 회사는 당신을 고용했고, 1년에 수천만 원에서 수억 원이나 되는 돈을 지불합니다. 하지만 회사에는 소프트웨어 개발자가 당신만 있는 것이 아닙니다. 회사는 단 10명만 고용했다고 가정해도 1년에 꽤 큰돈을 지불하고 있습니다.

 

 회사는 무료 봉사 단체가 아닙니다. 왜 당신에게, 당신 팀에게 큰 돈을 지불하면서 소프트웨어를 개발하게 할까요?

너무나도 당연하겠지만, 정답은 "수익을 내기 위함"입니다.

 

 소프트웨어 개발은 만드는 행위가 목적이 되어선 안 되고 성과를 내기 위한 수단이 되어야 합니다. 성과는 곧 수익입니다. 따라서 당신 혹은 팀은 수시로 지금 만들고 있는 소프트웨어가 성과로 이어지는지 수시로 확인하며 개발해야 합니다.

 

 개발을 해보신 분은 알겠지만, 처음에 만들고 싶은 것을 멋지게 계획하고 상상했더라도 뒤늦게 추가하고 싶은 기능이 나오기 마련입니다. 어려운 기능을 오랜 시간 투자해서 만들었지만 쓸모 없어지거나, 원하던 모습과 다르게 나오는 경우도 있습니다. 성과를 좋게 만들기 위해서, 개발 중간에 좋은 아이디어가 떠올랐다면 수용하고 개선하는 것이 유리합니다.

 

 

애자일 소프트웨어 개발이란?

그러면 목적을 달성하고 성과를 극대화하기 위해 프로젝트를 어떻게 운영하는 것이 좋을까요? 아래 3가지 원칙은 지켜야 합니다.

  1. 목적을 달성하기 위해 모든 이해관계자가 긴밀하게 협조해야 한다.
  2. 한 번에 완벽한 것을 만들려고 하지 말고, 동작하는 기능 단위로 조금씩 개발하고 즉시 피드백을 받아야 한다.
  3. 사용자나 이해관계자의 피드백을 바탕으로 결과물과 계획을 지속적으로 보완해야 한다.

이렇게 개발하는 방식을 "애자일 소프트웨어 개발"이라고 합니다. 줄여서 애자일 개발이라고도 불립니다.

 

 애자일 개발이란 어느 특정한 개발 방법론을 칭하는 것이 아니라, 다양한 개발 기법 사이의 공통된 가치관과 행동 원칙에 이름을 붙인 것입니다. 가치관과 행동 원칙을 실현하기 위한 다양한 기법이 공존하게 됐는데, 많이 알려진 것으로는 스크럼, 익스트림 프로그래밍, 칸반 등이 있습니다.

 

 모든 애자일 개발 기법을 관통하는 공통된 생각은 "모든 것을 예측하고 대비할 수 없음을 인정한다"는 것입니다. 먼저 개발 기간과 투입할 인력을 정한 다음, 중요한 것부터 만드는 방식입니다. 즉, 중요도와 위험도가 높은 것부터 먼저 만들고, 그렇지 않은 것은 뒤에 만드는 방식으로 개발 성과를 극대화합니다.

 

 

스크럼이란?

스크럼은 애자일 개발 기법의 하나로 일하는 절차와 지켜야 할 규칙이 최소한으로 정의된 프레임워크입니다.

 

 말이 조금 어려운데, 일할 때 막 하는 거 이제 그만하고 뭔가 틀을 정하고, 틀에 맞춰서 일을 해보자는 것을 의미합니다. 앞으로 이 "스크럼"에 대해 자세히 알아가 보겠습니다.

 

스크럼에는 다음과 같은 특징이 있습니다.

  • 가치와 위험도, 필요성을 기준으로 요구 사항을 정렬한다.
  • 순서대로 구현하며 성과를 극대화한다.
  • 정해진 시간 안에 작업을 완료한다. (타임박스; timebox)
  • 현재 상태와 문제점을 명확하게 밝힌다. (투명성; transparency)
  • 개발할 제품과 진척에 이상은 없는지 수시로 확인한다. (점검; inspection)
  • 더 나은 방법으로 작업 방식을 개선한다. (보완; adaptation)

 

 스크럼은 아는 것보다 모르는 게 더 많은 복잡한 문제를 풀 때 유용합니다. 스크럼을 하나의 프레임워크라고 정의한 것도, 복잡한 문제를 절차와 규칙으로 해결하고자 하는 목적이 동일하기 때문입니다. 스크럼의 핵심 축은 "투명성", "점검", "보완"입니다. 진행 상황이 작업자, 이해관계자 간 투명하게 공개되어야 하고, 피드백을 수용하며 개선해야 합니다. 그 가치를 이해할 때 비로소 온전히 스크럼을 진행할 수 있다고 생각합니다.

 

 그렇다면 스크럼을 시작하기 위해 어떤 것들이 필요할까요? 스크럼을 시작하기 위해서는 3가지 역할(role), 5가지 활동(event), 3가지 산출물(artifact)이 필요합니다. 항목 별로 나열하자면 다음과 같습니다.

 

3가지 역할

  • 개발자
  • 프로덕트 오너
  • 스크럼 마스터

5가지 활동

  • 스프린트
  • 스프린트 계획
  • 데일리 스크럼
  • 스프린트 리뷰
  • 스프린트 회고

3가지 산출물

  • 프로덕트 백로그
  • 스프린트 백로그
  • 증가분

위 역할, 활동, 산출물에 대해서는 아래에서 자세히 알아봅시다.

 

 

각 항목들에 대해 알아봅시다

[안내]
각 항목을 그룹화해서 정리했습니다. 그룹화 하면서 이해 순서와는 무관하게 순서 배치가 됐습니다. 예를 들어, "역할 > 개발자"를 설명하다 보니 "산출물 > 프로덕트 백로그" 이야기가 나오는데, 그럴 경우에는 프로덕트 백로그 파트를 먼저 읽고 개발자를 읽으시는 것이 좋습니다.

역할

#1 개발자 | 동작하는 제품을 만드는 자

 

 프로덕트 백로그에 등록된 내용을 순서대로 하나씩 구현하는 일을 하는 사람을 개발자, Developer라고 합니다. 제품의 How를 담당하며, 잘 동작하는 것에 대한 책임을 가지고 있습니다.

 

 개발자 팀원은 3명에서 9명이 적당합니다. 3명보다 적을 경우에는 개인 역량을 지나치게 의존할 확률이 높고, 시너지를 발휘하기 힘듭니다. 9명보다 많을 경우에는 커뮤니케이션 비용이 늘어나면서 개발 효율이 떨어질 수 있습니다. 이럴 경우에는 상황에 맞게 작은 그룹으로 나눠서 전체적인 복잡도를 줄이는 것이 좋습니다.

 

 개발팀 내에서는 직무나 역량 수준에 따라 별도의 호칭을 사용하지 않아야 합니다. 개발팀 내 의사결정은 개발자 상호 간의 합의가 있어야 하고, 작업 방식에 있어서도 외부의 간섭을 받지 않아야 합니다. 그러기 위해서는 개발팀 내에서 원활한 의사 결정이 이뤄지기 위해 방해되는 요소는 없애야 하고, 스스로가 책임감을 가지고 개발을 완료할 수 있도록 해야 합니다. 스크럼 가이드에서는 이런 방식을 자기 관리화(self-managing)이라고 합니다.

 

 개발팀은 제품 개발에 필요한 모든 역량을 갖고 있어야 합니다. 요구사항 분석, 설계, 구현, 테스트, 배포, 문서화 등 모든 작업을 개발팀 내에서 진행해야 합니다. 이런 조직을 기능횡단팀(cross functional team)이라고 합니다. 현재 제가 속해있는 팀은 목적 조직이며, 개발자는 총 8명이고 iOS, Android, 백엔드로 포지션이 구분되어 있습니다. 인프라나 QA를 담당하는 기능 조직은 팀 외부에 존재하고 있으며 협업하고 있습니다.

 

#2 프로덕트 오너 | 제품의 명세를 책임지는 자

 

 프로덕트 백로그를 관리하는 사람을 프로덕트 오너라고 합니다. Product Owner를 줄여서 PO라고도 많이 부릅니다. PO는 제품을 책임지는 단 한 사람입니다. 제품의 What을 담당하는 사람이고, 제품의 가치를 극대화하는 것에 집중해야 합니다.

 

PO가 해야 하는 업무는 다음과 같습니다.

  • 거시적인 관점에서 계획을 세운다.
  • 제품의 비전을 명확히 하고 주변과 공유한다.
  • 제품을 만드는 데 소요되는 예산을 관리한다.
  • 프로덕트 백로그를 최신 상태로 업데이트한다.
  • 다른 사람이 프로덕트 백로그를 이해할 수 있도록 풀어서 설명한다.
  • 이해관계자와 프로덕트 백로그를 검토하고, 납기나 구현 순서를 상의한다.
  • 프로덕트 백로그의 각 항목이 완료되었는지 점검한다.

 

 프로덕트 백로그에 항목을 추가하고 보완하는 일은 개발자와 함께해도 무관합니다. 하지만 최종적인 결정 권한은 PO에게 있습니다. PO 외에는 프로덕트 백로그를 함부로 수정할 권한이 없습니다. PO에게 막강한 권한이 있는 만큼 결과에 대한 책임도 커집니다.

 

#3 스크럼 마스터 | 일이 되게 만드는 숨은 조력자

 

 프로덕트 오너와 개발자를 돕는 사람이 스크럼 마스터(scrum master), SM이라고도 불립니다. 스크럼 마스터는 스크럼의 규칙과 진행 방식, 산출물 등에 관해 팀원을 이해시키고, 스크럼이 효과적으로 운용되게 돕는 한편, 외부의 간섭이나 방해 요소로부터 팀원을 보호하는 역할을 합니다.

 

 프로덕트 오너는 사용자와 이해관계자에게 더 좋은 가치를 전달하기 위해 기능 추가와 개선을 목표로 일합니다. 개발자는 기능을 만들고 개선해서 사용자에게 완성도 높은 제품을 전달하는 것을 목표로 일합니다. 어떻게 보면 프로덕트 오너는 일을 더 많이 시키고 싶어 하고, 개발자는 완성도를 위해 일을 더 적게(적당히) 하고 싶어 합니다. 그 사이를 중재하고 협의하는 데 도움을 주는 사람이 스크럼 마스터입니다.

 

스크럼 마스터가 하는 일의 예시를 들면 다음과 같습니다.

  • 프로덕트 오너와 개발자에게 애자일 개발과 스크럼에 관해 알려준다.
  • 스프린트 플래닝이나 스프린트 회고에서 진행을 돕는다.
  • 프로덕트 오너와 개발자의 커뮤니케이션을 돕는다.
  • 프로덕트 오너와 개발자의 생산성이 높아지도록 변화를 꾀한다.
  • 프로덕트 백로그와 스프린트 백로그를 잘 쓰는 방법을 알려준다.
  • 프로덕트 백로그와 스프린트 백로그를 잘 관리하는 방법을 알려준다.

 

 

활동

#1 스프린트 | 작업 기간을 짧은 간격으로 나눈다

 

 스크럼을 할 때는 짧은 간격으로 기간을 나눠서 작업합니다. 이때 쪼개진 작업 기간 하나를 스프린트(sprint)라고 합니다. 개발팀은 이 기간 안에 할 일을 계획, 설계, 개발, 테스트를 거치면서 제품을 구현합니다. 스프린트 단위로 작업을 하면 리듬감이 생기면서 몰입하기 쉬워지고 전체적인 진척도 파악하기 용이해집니다.

 

 주의해야 할 점으로, 스프린트 마지막 날에는 할 일이 남았어도 스프린트를 종료하고 기간을 연장하지 않아야 한다는 것입니다. 길면 1달, 짧으면 1주 단위로 설정할 수 있는데 스프린트 기간은 PO의 판단 하에 결정됩니다. 만약 스프린트를 진행하다가 더 이상 필요 없다고 판단되면 PO에 의해 스프린트가 중단될 수도 있습니다.

 

스크럼의 활동 중 가장 큰 덩어리로, 다른 4가지 활동(계획, 데일리, 리뷰, 회고)을 포함합니다.

(또 다른 애자일 기법인 익스트림 프로그래밍에는 Iteration이라는 비슷한 개념이 있습니다.)

스프린트 간격의 좋은 예와 나쁜 예

 

#2 스프린트 계획(planning) | 스프린트에 할 일을 계획한다

 

 스프린트를 하기 전에 스프린트를 왜 하는지(why), 무엇을 할지(what), 어떻게 할지(how)를 생각하며 계획을 세워야 합니다. 이런 활동을 스프린트 플래닝이라고 합니다. 스프린트 플래닝에 필요한 시간은 스프린트가 1 달일 때 8시간 정도가 적절합니다. 현재 저희 팀은 스프린트 기간을 2주로 잡고 있는데, 이 경우에는 스프린트 플래닝에 4시간을 투자하는 것이 적절합니다.

 

> Why

 스프린트를 왜 하는지 생각해야 합니다. PO는 이번 스프린트 결과가 이해관계자에게 어떤 가치를 주는지, 얼마나 중요한지를 생각하고, 이번 스프린트를 반드시 해야 하는 합당한 이유를 찾습니다. 이것은 스프린트 목표(goal)가 됩니다. 예를 들어 이해관계자를 사용자로 한정했을 때, 사용자에게 어떤 가치를 전달할 수 있을지 고민해 보면 왜 그 작업을 해야 하는지 쉽게 이해할 수 있습니다.

 

> What

 스프린트에서 무엇을 할지 생각해야 합니다. PO는 스프린트 목표를 달성하기 위해 해야 할 일감을 프로덕트 백로그에서 골라야 합니다. 프로덕트 백로그는 우선순위에 맞게 정렬되어 있기 때문에 순서대로 집어오는 것이 일반적이나, 일감 별 크기나 개발자의 경험치에 따라 순서가 조금 변경될 수 있습니다. 예를 들어, 이번 스프린트 내에 개발팀에 휴가자가 있다면 고려해서 계획을 해야 합니다.

 일감을 하나 처리하는 데 몇 명의 사람과 시간이 얼마나 필요한지 견적을 내봐야 합니다. 개발자의 역량과 작업 시간을 고려해서 일감을 더 적게 만들 수도 있습니다. 이런 식으로 일감을 구체화하는 과정을 백로그 리파인먼트(backlog refinement) 혹은 백로그 정제라고 합니다. 백로그 정제를 언제 해야 하는지 따로 정해진 건 없습니다. 하지만 스프린트 직전에 하려고 하면 시간이 부족할 수 있으니 미리 하는 것이 좋습니다. 일반적으로 백로그 정제에는 스프린트 기간의 10%로 정하는 것이 일반적입니다. 예를 들어, 스프린트 기간이 2주라면 Work Day 기준으로 10일입니다. 10%면 1일 동안 백로그 정제에 시간일 투자할 수 있습니다. 하지만 백로그 정제에 너무 많은 시간을 투자하는 것 같다면 시간을 줄이는 게 더 좋을 것 같습니다.

 

> How

 스프린트 목표를 어떻게 달성할지 생각해야 합니다. 선택한 일감을 어떻게 작업할지 구체적인 방법을 고민하고, 필요하다면 일감을 추가하거나 더 상세하게 구체화해도 됩니다. 이렇게 프로덕트 백로그의 일감을 가져와 스프린트에서 할 일 목록을 만든 것을 스프린트 백로그(sprint backlog)라고 합니다. 스프린트 백로그는 개발팀의 작업 계획으로 스프린트 기간 중에 자유롭게 추가하고 삭제할 수 있습니다.

 

#3 데일리 스크럼 | 진행 상황을 매일 점검한다

 

 스프린트 플래닝이 끝나면 개발자는 스프린트 백로그에 등록된 작업을 시작합니다. 이때 진행 상황을 매일 점검해야 하는데 이런 활동을 데일리 스크럼(daily scrum)이라고 합니다.

 

데일리 스크럼의 특징은 다음과 같습니다.

  • 목표 달성에 문제가 없는지 진행 상황을 점검한다.
  • 문제를 해결하기보다 문제가 발생한 상황에 집중한다.
  • 매일 하되 15분의 타임박스를 지킨다. (시간을 연장하지 않는 것이 원칙이다)
  • 이야기가 길어지면 회의를 따로 잡는다.

 

참여자는 다음 질문에 답하면서 상황을 공유합니다. 아래 질문들에 답하다 보면 스프린트가 순항하고 있는지 파악할 수 있습니다.

  • 스프린트 목표를 달성하기 위해 어제 한 일은 무엇인가?
  • 스프린트 목표를 달성하기 위해 오늘 할 일은 무엇인가?
  • 스프린트 목표를 달성하는 데 방해가 되거나 도움이 필요한 일은 무엇인가?

 

#4 스프린트 리뷰 | 완성된 제품을 시연한다

 

 스프린트가 끝나면 PO가 주관하여 스프린트 결과를 점검합니다. 이 활동을 스프린트 리뷰(sprint review)라고 합니다. 리뷰 미팅에는 제품의 이해관계자인 스테이크홀더(stakeholder)가 초대됩니다. 스프린트 리뷰를 하는 목적은 스프린트 기간 동안 작업된 결과물을 점검하면서 그에 대한 피드백을 얻기 위함입니다.

 스프린트 리뷰는 스프린트 기간이 1 달일 때 4시간 정도가 적당합니다. 스프린트 기간이 2주라면 2시간이 적당할 것 같습니다.

 

스프린트 리뷰의 특징으로는 다음과 같습니다.

  • PO가 주관하고 이해관계자가 참석한다.
  • 개발자가 만든 결과물을 이해관계자에게 시연한다.
  • 피드백을 받고 프로덕트 백로그를 재점검한다.
  • 완성된 것과 완성되지 않은 것을 구분한다.
  • 전체 진행 상황과 남은 작업을 점검한다.

 

자칫 스프린트 리뷰를 증가분을 공유만 하는 자리로 오해할 수 있습니다. 하지만 스프린트 리뷰 때는 이해관계자가 직접 증가분에 대해 체험할 수 있게 만들어 적극적인 피드백을 이끌어 내도록 해야 합니다.

 

스프린트 리뷰에는 시연과 피드백을 받는 것 말고도 다음과 같은 일을 할 수 있습니다.

  • 제품과 비즈니스 환경에 대해 설명한다.
  • 스프린트 중에 완료하지 못한 것을 설명한다.
  • 스프린트 중에 직면했던 어려움과 해결 과정을 설명한다.
  • 프로덕트 백로그에 새로 추가할 게 있는지 논의한다.
  • 예상되는 잠재 위험에 대해 논의한다.
  • 현재 진척 상황을 감안하여 작업 완료 시점이나 릴리즈 날짜를 예측한다.

 

#5 스프린트 회고 | 했던 일을 돌아보고 더 좋게 보완한다

 

 스프린트 막바지에는 스프린트 회고(sprint retrospective)를 진행합니다. 스프린트 회고에서는 일하면서 어려움은 없었는지, 더 나은 성과를 내기 위해 개선할 점은 없었는지 되돌아보고, 다음에 시도할만한 개선 사항 몇 가지를 뽑아봅니다. 그중에서 적은 노력으로 큰 효과를 낼 수 있는 좋은 의견이 있다면 다음 스프린트에 반영해서 시도하게 됩니다.

 

스프린트 회고의 특징으로 다음과 같습니다.

  • 일하는 방식을 개선한다.
  • 사람, 관계, 프로세스, 툴의 관점에서 스프린트를 점검한다.
  • 버그를 고치기보다 버그를 유발하는 작업 방식에 집중한다.
  • 한 번에 너무 많은 것을 고치려 하지 않는다.
  • 잘 된 점과 안 된 점을 정리한다.
  • 다름 스프린트에서 실천할 실행 항목을 뽑는다.

 

 이렇게 일하는 방식을 수시로 점검하고 더 나은 방법으로 개선하는 과정은 애자일 개발의 중요한 특징입니다. 스크럼에서는 스프린트 단위로 점검하고 개선할 수 있도록 체계가 만들어져 있습니다. 회고는 스프린트 기간이 1달일 경우 3시간이 적당합니다. 2주라면 1시간 30분이 적당하겠습니다.

 

 

산출물

#1 프로덕트 백로그 | 요구 사항을 목록으로 정렬한다

 

 스크럼에서는 기능이나 요구 사항, 개선 사항과 같이 제품(product) 개발에 필요한 일감을 목록으로 정리합니다. 이것을 프로덕트 백로그라고 합니다. 일감의 순서는 그 작업(task)을 끝냈을 때 얻는 가치나 그 작업을 하지 않았을 때 얻는 위험도 등 다양한 기준으로 조정할 수 있습니다.

 

 프로덕트 백로그를 작성할 때는 사용자 스토리(user story) 형식으로 쓰는 것이 일반적입니다. 사용자 스토리란, 작업의 요구 사항을 사용자의 관점에서 "누가", "어떤 목적으로", "무엇을 하길 원한다"와 같은 형식으로 작성하는 것을 의미합니다.

 

 작업 계획을 세우기 위해서는 개략적인 작업량을 추정해야 합니다. 추정은 실제 소요되는 작업 시간이 아닌, 비교를 위한 참고치로 설정해야 합니다. 저희 팀에서는 스토리 포인트를 부여하고 있습니다. 스토리 포인트에 관한 내용은 여기에서 확인하실 수 있습니다.

 

프로덕트 백로그의 정의와 특징을 정리해 보자면 다음과 같습니다.

  • 구현하고 싶은 것을 목록으로 만든다.
  • 항목은 언제든지 추가, 삭제할 수 있다.
  • 우선순위에 맞춰 정렬한다. 상황에 따라 갱신할 수 있다.
  • 우선순위가 높은 항목부터 작업량을 추정한다.
  • 정기적으로 항목의 순서나 내용, 작업량을 보완한다.

 

#2 스프린트 백로그 | 스프린트 플래닝 결과를 보여준다

 

위에서 언급한 활동 > 스프린트 플래닝 과정에서 채워지는 백로그입니다. 스프린트 백로그의 특징으로는 다음과 같습니다.

  • 프로덕트 백로그에서 작업할 항목을 고른다.
  • 실행 가능하게 작업을 구체화한다.
  • 작업을 추가하거나 삭제할 수 있다.
  • 하루 안에 끝나는 크기로 분할한다.

 

 스프린트 백로그를 보고 주의할 점은, 개발팀이 목표 달성을 위해 최선을 다하더라도 계획된 내용이 반드시 완료된다고 보장할 수 없다는 점입니다. 계획을 무리하게 강제하다 보면 해야 할 작업량을 부풀리거나, 고의로 작업을 누락시킬 수 있습니다. 심지어 난도가 높거나 예상치 못한 문제에 직면하면 잦은 야근으로 개발자의 피로가 누적되기도 합니다. 이런 부작용은 결국 제품의 완성도에 영향을 주게 됩니다.

 

 스프린트 플래닝을 할 때 어떤 일감을 스프린트 백로그로 올릴지 결정합니다. 하지만 플래닝 시에 담당자를 배정하지 않습니다. 계획일 뿐이고 앞으로 일어날 모든 상황을 예측할 수 없기 때문입니다. 그래서 담당자 할당은 스프린트가 시작된 후 실제로 작업할 시점에 결정되고, 팀원 스스로가 자기 할 일을 가져가는 방식으로 배정하는 것이 좋습니다.

프로덕트 백로그의 일감을 스프린트 백로그로 가져온 예
프린트 백로그를 실제 작업 단위로 구체화한 예

 

#3 증가분 (increment) | 스프린트마다 동작하는 제품을 만든다

 

 스크럼에서는 스프린트 기간 동안 작업한 결과물을 실제로 동작시키면서 점검하는데, 이때의 결과물을 증가분, 인크리먼트라고 합니다. 증가분의 특징으로는 다음과 같습니다.

  • 개발자는 백로그를 작업한 결과로 동작하는 제품을 만든다.
  • 이전 스프린트의 결과물이 이번 스프린트의 결과물이 더해진다.
  • 결과물은 릴리즈 여부와 상관없이 동작하고 점검받을 수 있어야 한다.

 

 증가분은 이전 스프린트의 결과물에 이번 스프린트의 작업 결과를 더한 개발의 증가분을 의미합니다. 스프린트 백로그에 있는 일감이 대부분 완성이 됐을 것입니다. 하지만 완료된 작업 중에서도 어떤 작업이 증가분에 포함시킬 수 있는 작업인지 판단할 수 있어야 합니다. 이것을 완료 조건(definition of done)이라고 합니다. 개발팀은 이 조건을 만족해야 증가분에 포함시켜서 증명받고 점검받을 수 있기 때문에 완료 조건을 만족하도록 노력해야 합니다.

 

다음은 완료 조건의 예시입니다.

  • 위키 문서에 제품 명세서를 등록했다.
  • Repository에 코드를 push 했다.
  • 모든 publiuc 메서드의 테스트 코드가 구현되었다.
  • 모든 테스트가 성공했다.
  • 소스 코드를 빌드하고 시연할 수 있다.

 

 

 

 

이 글의 토대가 되는 스크럼 가이드(최신; 2020년 11월 개정)는 아래 링크를 클릭해서 읽을 수 있습니다.

 

References

저작자표시