[정처기 필기] 「1」 | 요구사항 확인 - (1.2) 스크럼 기법, XP 기법

[정처기 필기] 「1」 | 요구사항 확인 - (1.2) 스크럼 기법, XP 기법

> 「1」 소프트웨어 설계

- > 요구사항 확인, 화면 설계, 애플리케이션 설계, 인터페이스 설계

「2」 소프트웨어 개발

「3」 데이터베이스 구축

「4」  프로그래밍 언어 활용

「5」  정보시스템 구축 관리

 

1 소프트웨어 생명 주기

> 2 스크럼(Scrum) 기법

> 3 XP(eXtreme Programming) 기법

4 현행 시스템 파악

5 개발 기술 환경 파악

6 요구사항 정의

7 요구사항 분석

8 요구사항 분석 CASE와 HIPO

9 UML(Unified Modeling Language)

10 주요 UML 다이어그램

2. 스크럼(Scrum) 기법

스크럼의 개요

 

팀이 중심이 되어 개발의 효율성을 높이는 의미

 

- 팀원 스스로가 스크럼 팀을 구성, 개발 작업을 스스로 해결

- 제품 책임자, 스크럼 마스터, 개발 팀

 

제품 책임자(PO; Product Owner)

- 제품에 대한 이해도가 높고, 요구사항을 책임, 의사 결정함

- 백로그(Backlog) 를 작성, 우선순위 지정

- 주기적으로 우선순위 갱신

 

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

- 객관적인 시각에서 조언해주는 가이드 역할

- 일일 스크럼 회의 주관하여 진행 사항 점검, 장애 요소 처리

 

개발 팀(DT; Development Team)

- 제품 개발을 위해 참여하는 모든 사람

- 7 ~ 8명

 

스크럼 개발 프로세스 

 

→ (반복)
제품 백로그	스프린트 계획 회의	스프린트 수행				스프린트 검토 회의	스프린트 회고
		↑ ↑ ↑	일일 스크럼 회의		↓ ↓ ↓
		↑	←	←	↓

 

제품 백로그(Product Backlog)

- 요구사항(User Story)을 우선순위에 따라 나열한 목록

- 도출되는 요구사항으로 지속적으로 업데이트

- 요구사항을 기반으로 전체 일정 계획인 릴리즈 계획(Realease Plan)을 수립

 

스프린트 계획 회의(Sprint Planning Meeting)

- 수행할 작업을 대상으로 단기 일정 수립

- 처리할 요구사항을 태스크(Task)라는 작업 단위로 분할 후 스프린트 백로그(Sprint Backlog)를 작성

 

스프린트(Sprint)

- 실제 개발 작업을 진행, 2 ~ 4주의 기간

- 태스크를 대상으로 속도(Velocity) 추정 후 할당

- 할당할 때 개발자가 직접 선별하는 것이 좋음

- 할당된 태스크는  할 일(To Do), 진행 중(In Progress), 완료(Done)의 상태

 

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

- 모든 팀원이 매일 15분 정도 진행 상황 점검

- 남은 작업 시간은 소멸차트(Burn-down Chart)에 표시

- 스크럼 마스터는 장애 요소 해결

 

스프린트 검토 회의(Sprint Review)

- 사용자가 포함된 참석자 앞에서 테스팅 수행

- 한 주당 한 시간 내

- 제품 책임자는 피드백 정리 후 제품 백로그 업데이트

 

스프린트 회고(Sprint Retrospective)

- 주기를 되돌아보며, 개선사항 확인 후 기록

- 끝난 시점 또는 일정 주기로 수행

3. XP(eXtreme Programming) 기법

XP(eXtreme Programming)

 

요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정 반복 극대화 => 개발 생산성 향상, 실용성 강조

 

- 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여로 빠르게 개발

- 릴리즈의 기간을 짧게 반복하여 요구사항 반영에 가시성 높임

- 테스트마다 고객이 참여, 직접 확인

- 소규모 인원이 불확실하고 변경이 많은 요구를 접했을 때 적절

 

XP의 5가지 핵심 가치

의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)

 

XP 개발 프로세스

 

사용자 스토리 ↓	→ → → →	(테스트 시나리오) → → → →	→ → → →	→ →              ↓
↓  (요구사항)         ↓ ← ←  ↓↓	(새로운 사용자 스토리) ← ← ← ←	← ←   ← ← ↑↓	(버그) ← ← ← ←	↓   ↓ ← ←  ↓         ↑↓
릴리즈 계획 수립	(릴리즈 계획) → → → →	주기 (Iteration)	(최신 버전) → → → →	승인 검사	(고객 승인) → → → →	소규모 릴리즈
↓                     ↑ (불확신 추정) ↑ ↓                     ↑ ↓     (확신 추정) ↓                     ↑		↑ ↑              ← ←	← ← ← ← (다음 주기)	↓ ↓ ← ←
↓                     ↑ 스파이크

 

사용자 스토리(User Story)

- 요구사항을 시나리오로 표현

- 기능 단위로 구성, 필요한 경우 테스트 사항(Test Case) 기재

 

릴리즈 계획 수립(Release Planning)

- 릴리즈란 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품 제공 하는 것

- 부분 or 전체 개발 완료 시점에 대한 일정 수립

 

스파이크(Spike)

- 요구사항의 신뢰성을 높이고, 위험 감소를 위해 별도로 만드는 프로그램

- 처리할 문제만 작성

- 스파이크 솔루션은 기술에 문제가 발생한 경우 해결하기 위해 사용

 

이터레이션(Iteration)

- 릴리즈를 더 세분화 한 단위

- 1 ~ 3주의 기간

- 이 기간 중 새로운 스토리 작성될 수도 있으며, 진행 중인 or 다음 이터레이션에 포함

 

승인 검사(Acceptance Test, 인수 테스트)

- 하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행하는 테스트

- 고객이 직접 수행

- 오류 사항은 다음 이터레이션에 포함

- 이후 새로운 요구사항 작성되거나 우선순위 변경될 수도 있음

- 테스트 완료 후 다음 이터레이션 진행

 

소규모 릴리즈(Small Release)

- 소규모로 하게 되면, 고객의 반응을 기능 별로 확인할 수 있어서 요구사항에 유연하게 대처 가능

- 고객에 의한 최종 테스트 후, 최종 결과물을 고객에게 전달

- 완제품이 아닌 경우 다음 릴리즈 일정에 맞게 진행

 

>XP의 주요 실천 방법(Practice)<

 

실천 방법	내용
Pair Programming (짝 프로그래밍)	다른 사람과 함께 수행, 개발에 대한 책임을 공동으로 나눠 갖음
Collective Ownership (공동 코드 소유)	개발 코드에 대한 권한, 책임을 공동 소유
Test-Driven Development (테스트 주도 개발)	자동화된 테스팅 도구(도구, 프레임워크) 사용
Whole Team (전체 팀)	각자 자신의 역할이 있고, 그 역할에 대한 책임을 가짐
Cointinuous Intergration (계속적인 통합)	모듈 단위로 나눠서 개발된 코드들을 하나의 작업이 마무리 될 때마다 통합
Design Improvement (디자인 개선) or Refactoring (리팩토링)	기능의 변경 없이, 단순화, 유연성 강화를 통해 시스템 재구성
Small Releases (소규모 릴리즈)	릴리즈 기간을 짧게 반복, 요구사항 신속히 대응 가능

 

 

 

 

 

 

 

 

 

 

 

출처 | <시나공> 정보처리기사 필기 2024 기본서 (길벗알앤디)