애자일 스크럼(Agile Scrum) 간단하게 이해하기

애자일 스크럼(Agile Scrum)이란

애자일(Agile)은 하나의 방법론으로서 짧은 주기의 개발단계를 거치며
지속적으로 하나의 소프트웨어를 개발해 나가는 방법입니다. 
스크럼은 이러한 팀이 애자일의 반복적인 개선에 집중할 수 있도록
가치, 역할, 지침의 틀을 제공하는 프레임 워크입니다.
스크럼은 특정 개발 언어나 방법에 얽매이지 않고
스프린트라는 작업 단위를 사용하며 어떤 프로젝트에도 사용이 가능한 프로세스 프레임워크입니다. 

Fig. 1. 출처: Jeff sutherland, The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework

 

요구사항 정의서와 문제 정의서

우리가 End-Users, Customer 그리고 stakeholders에게 외주를 받게 됩니다. 그럼 외주를 요청한 고객과 만나 미팅을 가지고 그 자리에서 고객이 요청하는 요구사항 정의서와 문제 정의서를 문서로 작성하게 됩니다. 

Fig. 2. 문제 정의서(예시)

Fig. 2 문제 정의서는 해결해야 할 문제나 개선해야 할 조건에 대한 간결한 설명입니다

 

Fig. 3. 요구사항 정의서(SRS)(예시)

Fig. 3 요구사항 정의서는 정해진 형식은 없지만, 요구ID, 구분, 요구사항명, 요청사항, 설명과 같은 카테고리는 넣어주는 것이 좋습니다. 100프로 완벽한 요구사항 정의서는 없습니다. 하지만 첫 단추를 잘못 끼우면 뒤에 작업으로 갈수록 잘못된 단추를 꾈 수 있기 때문에 그만큼 신중하게 작성해야 하는 것은 확실합니다

 

애자일 일의 단위

Epics > Features > Product Backlog Items > Tasks

Epics : 온라인 서점에서, 고객들은 쇼핑하고 책을 살 수 있다
Features: 고객으로서, 나는 나중에 제품을 사러 돌아올 수 있도록 위시리스트를 가질 수 있기를 원한다
PBI : 고객으로서, 나는 제품을 위시리스트에 저장할 수 있고, 이후에 다시 확인할 수 있다
Tasks : 제품 페이지 마다 "위시리스트에 저장"이라는 버튼을 만든다

Fig. 4. Feature > PBI > Tasks

모든 Epics은 추상화 수준을 통일해야합니다(Single Level of Abstraction Principles)

추상화 수준을 통일한다는 것은 Fig. 4를 보면 4가지로 구분된 단위를 볼 수 있는데, Epics는 Epics로

Features는 Features로 Tasks는 Tasks 구분지어 통일해야 한다는 것입니다

---

PBl(Product Backlog)란

Product Backlog는 제품에서 요구되는 functionality(기능)의 우선순위 목록입니다
무엇을 만들지와 어떤 순서로 만들지에 대한 정보를 제공해 줍니다
Epics, Features, and PBIs는 product owner에 의해서 작성됩니다

PBI는 다음을 포함하고 있습니다

• PBI ID
• 우선순위
• 스토리 포인트(임의의 스토리 포인트 1-150에서의 PBI 노력을 통해 프로젝트 작업을 추정할 수 있습니다)
• 제목
• 스토리
• 인수조건 (ex "작업물 공유가 편했으면 좋겠어요")
• PBl Grooming (백로그 그루밍은 제품 관리자, 제품 소유자 및 팀이 백로그 항목에 대해 논의, 검토 및 우선순위를 정하는 정기 세션입니다)

Fig. 5. 출처 : https://www.scrum-institute.org/The_Scrum_Product_Backlog.php

잘못된 작성

• 저는 고객으로서 홈페이지를 방문하여 웹사이트 정보를 볼 수 있기를 원합니다 (이유 : 홈페이지가 어떤 홈페이지를 말하는 건지 로그인 홈페이지인지 불분명하다)
• 관리자로서 주문 내용의 일부 또는 전부를 선택하고 페이지 우측 상단의 파란색 '픽업' 버튼을 클릭하여 주문을 취소하고 사용자(교사)에게 아이템을 전송하여 체크아웃을 완료해야 합니다. 관리자는 상단 왼쪽에 있는 드롭다운 메뉴를 사용하여 픽업 위치별로 주문을 필터링할 수도 있습니다. 관리자는 모든 픽업 레코드를 볼 수 있습니다. 요청 레코드는 픽업 후 목록에서 제거됩니다(이유 : 너무 길다)

 

인수 조건 (Acceptance Criteria )

• 고객이 원하는 제품 시나리오와 요구 사항을 모두 포함한 목록입니다.
• 솔루션이 아닌 고객의 의도를 나타냅니다
• 제품이 실제로 수행할 수 있는 내용으로 작성되어야 하며, 합리적인 정보를 포함해야 합니다
• 인수 조건은 제품이 달성해야 할 최소한의 기능 수준을 제공합니다

Fig. 6. Azure Board를 통한 인수 조건 작성 예시

---

 

참조

https://medium.com/dtevangelist/scrum-dfc6523a3604

[Agile] Scrum(스크럼) 이해하기

https://youngmikim.tistory.com/entry/Product-Backlog

[Essential Scrum] '프로덕트 백로그'(Product Backlog)란?

https://brunch.co.kr/@svillustrated/27#comment

24. 애자일 방법론으로 프로젝트 진행하기