스크럼(Scrum), XP(eXtreme Programming)

스크럼(Scrum) 기법

• 스크럼은 팀이 중심이 되어 개발의 효율성을 높이는 기법
• 팀원 스스로가 스크럼 팀을 구성하고 개발 작업에 관한 모든것을 스스로 해결할 수 있어야함

스크럼 팀

구성원	역할
제품 책임자 (PO, Product Owner)	- 요구사항이 담긴 백로그(Backlog)를 작성하는 주체 - 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사를 결정할 사람으로 선정
스크럼 마스터 (SM, Scrum Master)	스크럼 팀이 스크럼을 잘 수행할 수 있도록 가이드 역할을 수행함
개발팀 (DT, Development Team)	제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로 제품 개발을 수행함

스크럼 개발 프로세스

이미지 출처 :  https://brainhub.eu/blog/differences-lean-agile-scrum/

• 백로그 : 개발에 필요한 사항들을 토대로 스토리를 작성, 제품책임자가 백로그의 우선순위를 결정할 수 있따.
• 스프린트 계획회의 : 스크럼마스터가 주관하여 회의 진행, task를 정하여 개발자들에게 할당
• 소멸차트도 작성 : 소프트웨어 개발 진행 상황을 확인 가능
• 스프린트 검토 회의 : 제품책임자가 주관하고 매주 한다.
• 스프린트 회고 : 팀원들끼리 잘 지켜졌는지 등을 회고

🚀 정리

프로세스	내용
스프린트 계획 회의 (Sprint Planning Meeting)	제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 회의
스프린트(Sprint)	실제 개발 작업을 진행하는 과정으로, 보통 2 ~ 4주 정도의 기간 내에서 진행함
일일 스크럼 회의 (Daily Scrum Meeting)	- 모든 팀원이 매일 약속된 시간에 약 15분 동안 진행 상황을 점검하는 회의 - 남은 작업 시간은 소멸 차트(Burn-down Chart)에 표시 함
스프린트 검토 회의 (Sprint Review)	부분 또는 전체 완성 제품이 요구사항에 잘 부합하는지 테스팅하는 회의
스프린트 회고 (Sprint Retrospective)	정해놓은 규칙 준수 여부 및 개선할 점을 확인하고 기록하는 것

XP(eXtreme Programming) 기법

XP(eXtreme Programming) → 소규모 개발에 적합

• XP는 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
• 짧고 반복적인 개발주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 함
• 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성을 높임

XP의 5가지 핵심 가치

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

🚀 외우는 팁

• XP의 핵심 가치 → 피존의 용기는 단순

XP 개발 프로세스

프로세스	내용
릴리즈 계획 수립 (Release Planning)	- 부분 혹은 전체 개발완료 시점에 대한 일정을 수립하는 것 - 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 함
이터레이션 (Iteration, 주기)	실제 개발 작업을 진행하는 과정으로, 보통 1 ~ 3주 정도의 기간으로 진행됨
승인검사 (Acceptance Test, 인수테스트)	하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행하는 테스트
소규모 릴리즈 (Small Release)	요구사항에 유연하게 대응할 수 있도록 릴리즈의 규모를 축소한 것

계획 → 진행(이터레이션) → 검사 → 출시(릴리즈)

XP의 주요 실천 방법(Practice)

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