애자일 방법론 - 스크럼(Scrum)

---

1. 폭포수 방법론

폭포수 방법론은 과제 초기의 수립한 계획과 요구사항을 그대로 따르는 방식이라 변경이 용이하지 않습니다.

 

 

2. 애자일 방법론

일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며 그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발 합니다. 요구 사항 변경을 수용할 수 있는 가변적 계획 수립과 신속한 소프트웨어 개발을 가능 하게 합니다. 상황이 바뀌는 경우 바로 피봇을 할수 있습니다.

 

 

3. 애자일 소프트웨어 방법론

애자일 소프트웨어 방법론의 예는 다음과 같습니다.

- 린 소프트웨어 개발

- 칸반

- 스크럼

 

 

4. 스크럼

스크럼 방식 또한 칸반 보드를 사용 합니다. 스크럼 방식은 칸반 요소 외에 '예측 항목(작업 시간 추정)'이 추가 됩니다. 스크럼은 소규모 팀을 위해 개발된 소프트웨어 개발 방법 입니다. 팀 구성원은 스프린트(sprints)라는 정해진 기간을 반복하며 다수의 작업을 수행 합니다. 스프린트 기간은 일반적으로 1주 ~ 1개월 사이 입니다. 보통 2주가 가장 일반적 입니다.

 

스프린트를 여러번 반복 수행하는 과정을 거치면서 팀의 작업 속도를 알 수 있습니다. 스프린트를 시작할 때 팀은 주어진 기간 내에 수행할 수 있는 작업 분량을 정합니다. 이후 스프린트를 여러번 반복하다 보면 '작업 시간 추정' 이 쉬어 집니다. '작업 시간 추정'을 통해서 스토리에 대한 구현 기간을 쉽게 예측 할수 있습니다. 결과적으로 주어진 스프린트 기간 동안 협의된 스토리를 모두 수행 할수 있는지 여부를 알수 있습니다.

 

팀은 주어진 기간 내에 수행할 수 있는 작업 분량을 정함 -> 스프린트를 여러번 반복 -> '작업 시간 추정' 

-> 주어진 스프린트 기간 동안 협의된 스토리를 모두 수행 할수 있는지 여부를 파악

 

 

5. 스크럼의 구성요소

- 에픽(epic)

- 스토리(story)

- 태스크(task)

 

 

 

5-1. 스크럼의 구성요소 - 에픽(epic)

에픽(epic) 이란, 여러 번의 스프린트를 거쳐 완료되는 정도의 작업량을 가진 업무를 의미 합니다. 에픽은 보통 상위 개념의 기능을 의미하며, 상세 내역을 제공 하지는 않습니다. 팀은 고객의 피드백을 보고 에픽을 완성하는 데 필요한 사항을 잘 파악할 수 있습니다. 에픽의 예로는 '앱 사용자들이 어플로 집의 시세를 조회하고 매매 한다.' 입니다. 에픽에는 개략적인 기능 설명만 있고, 상세한 설명이 빠져 있기 때문에 팀이 에픽에 대해서 좀더 자세히 알려면 여러개의 스토리가 생성 됩니다. 

 

 

5-2. 스크럼의 구성요소 - 스토리(story)

사용자 스토리(user story)는 비즈니스 가치를 제공하는 최소 단위의 요구 사항 입니다. 사용자 스토리는 보통 사용자의 입장에서 필요한 내용을 일상적인 언어로 기술 합니다. 기능을 기술 할 때는 사용자가 원하는 산출물을 몇 줄의 문장으로 간단하게 요약 합니다.  

 

 

5-3. 스크럼의 구성요소 - 태스크(task)

스토리에는 1개 또는 그 이상의 태스크가 있을수 있습니다. 태스크에는 스토리를 완성하기 위한 아주 구체적인 행동들을 기록 합니다. 태스크의 예는 '사용자가 내용을 입력할 수 있는 텍스트 박스를 구현 한다' 또는 '수정된 텍스트를 보관 하기 위한 저장 버튼을 추가 한다' 등 입니다. 태스크의 구성 요소는 아래와 같습니다.

- 디자인

- UX

- 분석

- 기술 연구 개발

- 코드 검토

- 테스트

- 문서화

 

 

6. 합격 기준

합격 기준을 정의하는 것도 중요 합니다. 스토리나 태스크를 구현한 결과가 무엇인지를 명확하게 정의 한다면, 테스터가 구현된 기능에 대한 '합격' 또는 '불합격' 여부를 쉽게 결정 할수 있습니다.

 

 

7. 스크럼 팀 구성

스크럼 개발 방식에는 보통 3가지 역할이 있습니다.

- 프로덕트 오너

- 스크럼 마스터

- 개발팀(테스터를 포함한)

 

 

7-1. 스크럼 팀 구성 - 프로덕트 오너

스크럼 팀에는 한 명의 프로덕트 오너(product owner)가 있습니다. 이해 관계자들 대부분은 해당 문제를 해결하는 솔루션에만 관심을 갖는 것과 반대로, 개발팀은 해당 솔루션을 구현하는 데 필요한 정보와 요구사항을 가능한 한 상세하게 받기를 원합니다. 프로덕트 오너의 역할은 아래와 같습니다.

 

1. 팀에게 필요한 비즈니스 가치를 제공할 책임이 있습니다.

2. 이해 관계자와 (개발)팀 간의 연결자 역할을 합니다.

3. 프로덕트 오너는 주로 비즈니스 측면의 문제 정의에 중점을 둡니다.

4. 사용자 스토리(구현해야 할 기능)를 정의하고 이를 백로그(할일 목록)에 추가 합니다.

5. 앱을 이해 관계자에게 시연하고, 앱의 주요 일정과 출시 시기를 결정 합니다.

6. 앱 개발 현황을 이해 관계자에게 보고하며, 자금 조달, 업무 범위 및 우선순위 결정에서 핵심 역할

 

 

7-2. 스크럼 팀 구성 - 팀(개발자, 테스터, 디자이너)

1. 팀은 스프린트에 집중 합니다.

2. 스프린트가 끝날 때마다 개선돼 동작하는 앱을 제공할 책임이 있습니다.

 

 

7-3. 스크럼 팀 구성 - 스크럼 마스터(Scrum Master)

1. 팀이 스프린트의 모든 기능을 제공하는지를 확인하고, 팀을 지도 합니다.

2. 팀과 이해관계자에게 스크럼 원리에 대해 교육 합니다.

3. 스프린트의 성공을 방해하는 내부나 외부의 장애물을 제거 합니다.

4. 백로그를 관리하고, 스토리가 명확한지 확인 합니다.

5. 팀이 스토리의 목표를 이해하고, 실제로 진행할 수 있도록 하는 것이 중요 합니다.

6. 데일리 스탠드업 미팅에서 팀원들에 장애물을 발견하고, 해결 합니다.

7. 팀이 '준비 단계'와 '완료 단계'를 정의 할수 있도록 돕는 것 입니다.

* 준비 단계 : 명확한 스토리가 있고, 실행 가능하여, 개발팀이 구현을 시작할수 있는 단계

* 완료 단계 : 새로운 기능을 출시할 수 있는 단계 (코드 리뷰, 유닛 테스트, UI 테스트, 문서 작성, 임시 배포, 공개 배포)

 

 

8. 데일리 스탠드업(stand-up)

팀은 스프린트 기간 동안 매일 스탠드업 미팅('데일리 스크럼' 이라고 부름)을 합니다. 이 미팅은 보통 15분의 제한 시간 동안 이루어 집니다. 매일 같은 시간에 미팅을 합니다. 미팅은 누구나 참여 할수 있지만, 발언권은 팀 구성원에게만 있습니다. 스탠드업 미팅에서 각 팀원들은 스프린트 진행과 관련되 3가지 질문에 대한 답을 해야 합니다.

 

- 어제 달성한 일은 무엇 인가요?

- 오늘 계획한 일은 무엇 인가요?

- 팀이나 내가 스프린트 목표를 달성하는 데 겪는 문제나 어려움은 무엇인가요?

 

회의 시간이 정해져 있기 때문에, 각 팀원들은 위 3가지 질문에마 초점을 맞추고, 세부적인 토론은 하지 않습니다. 이를 통해, '스크럼 마스터'는 회의 중에 언급된 모든 장애물을 파악 해야 합니다. 

 

 

9. 백로그 상세화 - 추정

스프린트가 시작되기 전에 스프린트 백로그를 정해야 합니다. 스토리마다 구현에 필요한 업무량을 추정해야 합니다. 일반적으로 추정은 시간이 아니라 '스토리 점수'로 표현 합니다. 예를 들어, '버튼의 텍스트 편집' 처럼 명확하고 구체적인 작업을 '1 스토리 점수' 라고 정의 합니다. 이것은 다른 스토리를 정의하는 기준이 됩니다. 이후 모든 스토리 점수 추정에 근거가 됩니다. 'planning poker' 라는 앱이나, 숫자가 쓰여있는 카드를 통해서, 팀원들은 각자 숫자가 쓰여진 카드를 골라 다른 팀원들에게 보여주므로써, '스토리 점수'를 매길수 있습니다. 만약, 팀원들간의 '스토리 점수'가 현저하게 차이가 난다면, 해당 개발이나 테스트가 왜 그렇게 시간이 오래 걸리는지에 대해 의논해야 합니다. 팀원 마다 알고 있는 지식이 다르기 때문이거나, 다른 시각으로 스토리를 해석하고 있기 때문 입니다. 만약, '스토리 점수'가 높다면, 작은 점수 여러개로 스토리를 분리해야 하는 신호 일수 있습니다.

 

 

10. 스프린트 진행

팀은 스토리 중에서 우선순위가 가장 높은 항목을 선택 합니다. 스프린트 중에 제한된 수의 스토리만을 구현 합니다. 스프린트의 작업량(스토리 수)를 결정 하기 위해서는 이전 스프린트에서의 작업량으로 평가하여 결정 합니다. 

 

 

11. 스프린트 리뷰, 회고, 계획

스프린트가 끝날 때마다 거쳐야 하는 2가지 과정이 있습니다. 

- 스프린트 리뷰 : 스프린트에서 완료한 모든 작업을 이해 관계자에게 시연 합니다.

- 스프린트 회고 : 스프린트에서 배운점, 개선점을 팀원들과 나눕니다. (개선점은 다음 스프린트에 포함)

- 다음 스프린트 계획 : 팀과 이해관계자가 모두 참여해, 다음 스프린트에 포함시킬 기능과 구현 방안을 결정 합니다.

 

 

12. 툴

스크럼을 지원하는 툴로는 아래와 같이 있습니다.

- 노션(Notion)

- 트렐로(Trello)

- 지라(Jira), 컨플루언스(Confluence)

 

 

더 자세한 스크럼은 https://www.scrum.org 를 참고해 주세요.

Home

 

 

이 글은 '린 모바일 앱 개발 - 이정표 옮김' 책을 참고 하였습니다.