애자일
애자일(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주)마다 이해관계자에게 일의 진척도를 보고함 |
