[정보처리기사 필기] 소프트웨어 개발 모형 - 스크럼(Scrum), XP(eXtreme Programming)

스크럼(Scrum) 기법

1. 스크럼 개요

스크럼이란 럭비에서 반칙으로 경기가 중단된 경우 양 팀의 선수들이 럭비공을 가운데 두고 서로를 밀치기 위해 대치해 있는 상황을 말한다. 스크럼은 이렇게 팀이 중심이 되어 개발 효율을 높인다는 뜻을 내포한다.

• 스크럼은 팀원 스스로가 스크럼 팀을 구성해야하며, 개발작업에 필요한 모든것을 스스로 해결할 수 있어야한다. 
• 스크럼 팀은 제품 책임자, 스크럼 마스터, 개발팀 으로 구성된다.

제품 책임자(PO; Product Owner)

• 제품에 대한 이해가 높고, 요구사항을 책임 지며 의사 결정을 하는 사람. 주로 개발의뢰자나 사용자가 담당 
• 요구사항이 담긴 백로그 작성, 우선순위 지정 
• 팀원들은 백로그에 스토리를 추가 할 수는 있지만, 우선순위 지정 불가

백로그: 제품개발에 필요한 요구사항을 모아 우선순위를 부여해 놓은 목록

스토리: 백로그에 담겨질 요구 사항으로, 이는 이야기를 서술하는 형태로 작성되어야함 

 

스크럼 마스터(SM; Scrum Master)

• 스크럼 팀이 역할을 잘 수행할 수 있도록 객관적인 시선에서 조언해주는 역할
• 스크럼 회의를 주관하며  진행사항 점검, 장애요소 공론화 하여 처리

개발팀(DT; Development Team)

• 제품 책임자, 스크럼 마스터를 제외한 모든 팀원. 제품 개발을 위해 참여하는 모든 사람이 대상.
• 적정 인원은 7~8명

2. 스크럼 개발 프로세스

스크럼 개발 프로세스는 아래와 같다.

스크럼 개발 프로세스 예시[1]

 

스프린트 계획 회의

• 제품 백로그 중 이번 스크립트에서 수행할 작업을 대상으로 일정을 수립하는것
• 요구사항을 개발자들이 나워서 작업할 수 있도록 태스크(Task)라는 작업 단위로 분할한 후 개발자별로 수행할 작업 목록인 스프린트 백로그를 작성한다.

스프린트(Sprint)

• 실제 개발을 수행하는 과정. 보통 2~4주 소요
• 스프린트 백로그에 작성된 태스크를 대상으로 작업 시간을 추정 후 개발 담당자에게 할애
• 태스크 할당 시 개발자가 원하는 태스크를 직접 선별하여 할당하는것이 좋다
• 할당 된 태스크는 상태를 가진다. 할 일(To Do), 진행 중(In Progress), 완료(Done)

일일 스크럼 회의

• 모든 팀원이 15분정도의 짧은 회의시간 동안 진행 상황 점검
• 보통 서서 진행, 남은 작업시간은 소멸 차트(Burn-down Chart)에 표시한다
• 스크림 마스터는 발견된 장애 요소를 해결할 수 있도록 도와준다

소멸 차트(Burn-down Chart): 해당 스프린트에서 수행할 작업의 진행 상황을 확인할 수 있도록 남은 시간을 그래프로 표현한 것

 

스프린트 검토 회의

• 부분 또는 전체 완성 제품이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅
• 스프린트 한 주당 한시간 이내
• 제품 책임자(Product Owner)는 개선 사항에 대한 피드백 정리, 다음 스프린트에 반영할 수 있도록 제품 백로그 업데이트

스프린트 회고

• 스프린트 주기를 되돌아보며  잘 수행 했는지 회고 하고 기록
• 스프린트가 끝났을 때 혹은 일정 주기로도 수행

 

XP(eXtreme Programming) 기법

1. XP 개요

수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객참여와 개발 과정의 반복을 극대화 하여 생산성 향상

• 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발
• 릴리즈 시간을 짧게 반복. 고객의 요구사항 반영에 대한 가시성 향상
• 릴리즈 테스트마다 고객을 직접 참여시켜서 확인 시켜줌
• 소규모 인원이 효과적

릴리즈: 몇 개의 요구사항이 적용되어 부분 적으로 기능이 완성된 제품을 제공 하는것

 

XP의 5가지 핵심 가치:

1. 의사소통(Communication)
2. 단순성(Simplicity)
3. 용기(Courage)
4. 존중(Respect)
5. 피드백(Feedback)

2. XP 개발 프로세스

XP 개발 프로세스는 다음과 같다.

XP 개발 프로세스 예시[2]

사용자 스토리

• 고객의 요구사항을 간단한 시나리오로 표현한 것
• 내용은 기능 단위로 구성, 필요한 경우 테스트 사항(Test Case) 기재

릴리즈 계획 수립

• 몇 개의 스토리 적용되어 부분적으로 기능이 완료된 제품 선보임
• 부분 혹은 전체 개발 완료 시점에 대한 일정 수립

스파이크(Spike)

• 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램
• 처리할 문제 외에 다른 조건은 모두 무시하고 작성

이터레이션(Iteration)

• 하나의 릴리즈를 더 세분화한 단위를 말한다. 일반적으로 1~3주의 기간으로 책정
• 새로운 스토리가 작성될 수 있으며 작성된 스토리는 현재 또는 다음 이터레이션에 포함될 수 있다

승인 검사 

• 하나의 이터레이션 안에서 릴리즈 단위의 프로그램 작성이 완료되면 수행하는 테스트
• 사용자 스토리 작성시 함께 기재한 테스트 사항을 고객이 직접 테스트 
• 오류사항은 다음 이터레이션에 포함하며, 테스트가 완료되면 다음 이터레이션 진행
• 테스트 후 새로운 요구사항이 작성되거나 요구사항의 우선순위가 변경될 수 있다

소규모 릴리즈

• 더 작은 규모의 릴리즈를 수행하면 고객의 반응을 기능별로 확인 가능해서 조금더 유연한 대처 가능
• 릴리즈 기간동안 진행된 이터레이션이 모두 완료되면 고객의 테스트 후 릴리즈(최종 결과물)를 고객에게 제출한다
• 릴리즈가 최종 완제품이 아닐경우 다음 릴리즈 일정에 맞춰 개발 계속 진행

XP의 주요 실천 방법

실천 방법	내용
짝 프로그래밍(Pair Programming)	다른 사람과 함께 프로그래밍을 수행 하면서 개발에 대한 책임을 공동으로 나눠 가짐
공동 코드 소유(Collective Ownership)	개발 코드에 대한 권한과 책임을 공동으로 소유
테스트 주도 개발(Test-Driven Development)	코드 작성전 테스트 케이스 먼저 작성. 무엇을 해야할지 정확히 파악 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 구조(구조, 프레임워크) 사용
전체 팀(Whole Team)	개발에 참여하는 모든 구성원(고객 포함)들은 각자 역할에 대한 책임을 진다.
계속적인 통합(Continuous Integration)	모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합
디자인 개선(Design Improvement) 또는 리팩토링(Refactoring)	프로그램 기능 변경 없이 단순화, 유연성 강화등을 통해 시스템 재구성
소그모 릴리즈(Small Releases)	릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응

 

 

---

 

출처

[1] https://jinhojapan.tistory.com/72

[2] https://funyphp.com/archive/knowledge/158?sfl=mb_id%2C1&stx=webmaster&sst=wr_datetime&sod=desc&sop=and

 

자료 참고: 

시나공 정보처리기사 필기 2022

책 표지