#2 소프트웨어 설계 - 애자일과 스크럼

애자일(Agile) 개발 방법론

애자일 방법론

• 날렵한, 재빠른이란 사전적 의미
• 특정 방법론이 아닌 소프트웨어를 빠르고 낭비없이 제작하기 위해 고객과의 협업에 초점을 두고 소프트웨어 개발 중 설계 변경에 신속히 대응하여 요구사항 수용 가능

특징	짧은 릴리즈와 반복, 점증적 설계, 사용자 참여, 문서 최소화, 비공식적인 커뮤니케이션 변화
종류	익스트림 프로그래밍(XP, eXtremProgramming) 스크럼(SCRUM) 린(Lean) DSDM(Dynamic System Development Method) FDD(Featrue Driven Development) Crystal ASD(Adaptive Software Development, 적응형 소프트웨어 개발 방법론) DAD(Disciplined Agile Delivery, 학습 애자일 패보)

Agile 선언문

• 프로세스나 도구 < 개인과의 소통
• 완벽한 문서 < 실행되는 소프트웨어
• 계약 협상 < 고객과의 협업
• 계획을 따르는 것 < 변경에 대한 응답

XP(eXtremeProgramming)

XP

• 1999년 Kent Beck이 제안
• 개발 단계 중 요구사항이 시시각각 변동이 심한 경우 적합한 방법론
• 요구에 맞는 양질의 소프트 웨어를 신속하게 제공하는 것이 목표

XP 핵심가치

가치(Value)	설명
소통(Communication)	개발자,관리자, 고객 간의 원활한 소통을 지향
단순성(Simplicity)	부가적 기능 또는 미사용 구조와 알고리즘 배제
Feedback	지속적 테스트와 통합, 반복적 결함 수정 등 빠른 피드백
용기(Courage)	고객 요구사항 변화에 능동적 대응
존중(Respect)	개발 팀원 간 상호 존중

XP precess

용어	설명
User Story	일종의 요구사항으로 UML의 유즈케이스와 같은 목적으로 생성되나 형식이 없고 고객에 의해 작성됨
Spike	어려운 요구사항, 잠재적 솔루션을 고려하기 위해 작성하는 간단한 프로그램
Release Planning	몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것으로 부분/전체 개발 완료 시점에 대한 일정 수립
Iteration	하나의 릴리즈를 세분화한 단위이며 1~3주 단위로 진행됨 반복(Iteration) 진행 중 새로운 스토리가 추가될 때 진행 중 반복(Iteration)이나 다음 반북에 추가 가능
Acceptance Test	릴리즈 단위의 개발이 구현되었을 때 진행하는 테스트 사용자 스토리에 작성된 요구사항을 확인하여 고객이 직접 테스트 오류가 발생되면 다음 반복에 추가함. 테스트 후 고객의 요구사항이 변경되거나 추가되면 중요도에 따라 우선순위 변경 가능 완료 후 다음 반복을 진행
Small Release	릴리즈 단위를 기능별로 세분화하면 고객의 반응을 기능별로 확인 가능 최종 완제품일 때 고객게 의한 최종 테스트 진행 후 고객에 제공

XP의 12가지 실천사항(Practice)

구분	12 실천사항	설명
Fine Scale Feedback	Pair Programming	두 사람이 짝이 되어 한 사람은 코딩, 다른 사람은 검사를 수행하는 방식 코드에 대한 책임을 공유하고 비형식적인 검토 수행 가능 코드 개선을 위한 리팩토링을 장려하며, 생산성이 감소되지 않음
	Planning Game	게임처럼 선수와 규칙, 목표를 두고 기획
	Test Driven Development	실제 코드를 작성하기 전에 단위 테스트부터 작성 및 수행하며 이를 기반으로 코드 작성
	Whole Team	개발 효율을 위해 고객을 프로젝트 팀원에 포함
Continuous Process	Continuous Integration	상시 빌드 및 배포를 할 수 있는 상태로 유지
	Design Improvement	기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성 수행
	Small Releases	짧은 주기로 잦은 릴리즈를 함으로써 고객이 변경사항을 볼 수 있게 함
Shared Understanding	Coding Standards	소스 코드 작성 포맷과 규칙들을 표준화된 관례에 따라 작성
	Ceollective Code Ownership	시스템에 있는 소스 코드는 팀의 모든 프로그래머가 누구든지 언제라도 수정가능
	Simple Design	가능한 가장 간결한 디자인 상태 유지
	System Metaphor	최종적으로 개발되어야 할 시스템 구조를 기술
Programmer	Sustainable	일주일에 40시간 이상 작업 금지 2주 연속 오버타임 금지

효과적인 프로젝트 관리를 위한 3대 요소

• 사람(People) - 인적자원
• 문제(Problem) - 문제 인식
• 프로세스(Process) - 작업 계획

SCRUM

SCRUM 개요

SCRUM 개념과 특징

• 요구사항 변경에 신속하게 대처할 수 있는 소규모 중심의 소프트웨어 개발 방법론
• 기능 개선점에 우선 순위를 부여하고 개발 주기 동안 실제 동작 가능한 결과를 재공
• 커뮤니케이션을 위해 팀원 개방된 공간에서 개발하고, 매일 15분 정도 회의
• 팀원 스스로 팀을 구성(Self Organizing)
• 개발 작업에 관한 모든 것을 팀원 스스로 해결(Cross Functional)

SCRUM 기본 원리

• 기능 협업을 기준으로 배치된 팀은 스프린트 단위로 소프트웨어 개발
• 스프린트는 고정된 30일의 반복이며, 스프린트를 행하는 작업은 고정됨
• 요구사항, 아키텍처, 설계가 프로젝트 전반에 걸쳐 잘 드러나야 함
• 정해진 시간을 철저히 지켜야 하며, 완료된 모든 작업은 _제품 백로그(product backlog_에 기록됨
• 가장 기본적인 정보 교환 수단은 일일 스탠드 업 미팅 또는 일일 스크럼

SCRUM 팀의 역할

담당자	역할
제품 책임자(PM)	개발 목표에 이해도가 높은 개발 의뢰자, 사용자가 담당 제품 요구 사항을 파악하여 기능목록(Product Backlog)을 작성 제품 테스트 수행 및 요구사항 우선순위를 갱신 업무 관점에서 우선순위와 중요도를 표시하고 신규항목 추가 스프린트 계획 수립까지만 임무 수행 스프린트가 시작되면 팀 운영에 관여하지 않음
스크럼 마스터	업무를 배분만 하고 일은 강요하지 않으며 팀을 스스로 조직하고 관리하도록 지원 개발 과정 장애 요소를 찾아 제거 개발 과정에서 스크럼의 원칙과 가치를 지키도록 지원
스크럼팀	제품 책임자. 스크럼 마스터를 제외한 팀원(개발자, 디자이너, 제품 검사기 등 모든 팀원)이 해당되며 팀원은 5~9명 내외로 구성 기능을 작업단위로 분류하며 요구사항을 사용자 스토리로 도출, 구현함 일정, 속도를 추정한 뒤 PM에게 전달 스프린트 결과물을 제품 책임자에게 시연 매일 스크럼 회의(daily scrum meeting)에 참여하여 진행 상황을 점검

용어

용어	설명
소멸 차트(Burn Down Chart)	매일의 작업 리스트를 목록으로 만들어 놓고 소거
스프린트	사전적으로 전력질주라는 의미가 있음 작은 단위의 개발 업무를 단기간에 전력 질주하여 개발한다는 의미 반복 주기(2~4주)마다 이해관계자에게 일의 진척도를 보고함