728x90
반응형
SMALL
에자일(Agile) 개발방법론의 종류에는 여러가지가 있지만 그중에서도 XP와 SCRUM이 제일 많이 통용된다
두 방법은 어떤 잛은 주기의 개발기간과 개발내용을 반복적으로 수행하는 측면에서는 동일하다.
XP (Extreme Programming) 의 등장배경과 정의
개발을 하기위해 사용자로부터 요구사항을 듣고 분석및 설계의 바탕이 되는 요구사항을 정의해야 하는데
실제 요구사항의 분석이 쉽지는 않다. 또한 사용자 입자에서도 자기가 원하는 요구사항을 명확하게
생각해내서 제시하는 것 또한 어려운 상황이다. 어리다 보니 불필요한 다량의 문서작업으로 인해 개발자의
의욕을 저하시키게 된다.
그래서 사용자의 요구사항을 한꺼번에 받는 방식이 아닌 반복형 모델의 개발주기를 극단적으로 짧게
함으로써 프로그래머가 설계,구현,시험 활동을 전체 SW개발기간에 걸쳐 조금씩 자주 실시하도록 하는
개발방법이 XP (Extreme Programming) 이다.
XP (Extreme Programming) 의 특징
① 짧은 개발주기 반복
② 프로토타입이 일찍 자주 만들어짐
③ 개발계획이 프로젝트 진행동안 계속 변화됨
XP (Extreme Programming) 의 4원칙
| 원칙 | 설명 | 12가지 기본원리 |
| 의사소통 (Communication) |
고객과 개발자와의 의사소통을 중요시 | User Story 카드 Pair Programming On site Customer |
| 단순성 (Simplicity) |
지금 해야할 일에 대해서 가장 효율적인 디자인이나 코딩을 하는 것이 좋다. | Simple Design Metaphore |
| 피드백 (Feedback) |
즉각적인 피드백을 통해 빠른 의사결정 그래서 XP는 항상 코드가 실행가능한 상태유지 |
On Site Customer Small Release Test Refactoring |
| 용기 (Courage) |
- XP는 개발자들이 자신감있게 변화를 수용 할 수 있도록 그 환경 을 만들어 준다 - Spike, Small Relase등으로 고객요구사항에 대응하는 용기 |
Small Release |
XP (Extreme Programming) 의 12가지 기본원리
| 기본원리 | 설명 |
| Planning Game | 개발계획 수립 - 고객과 다양한 스토리카드를 통한 개발계획 작성 |
| Small Release | 짧은 배포주기 - 매우 짧은 주기로 모듈 업데이트 |
| Metaphore | 문장형태로 시스템 아키텍쳐 기술 공통의 Naming System 개발 고객과 개발자간 의사소통 언어 |
| Pair Programming | 개발자 2명이 공동 작업을 한다. |
| Collective Ownership | 공동소유 - 시스템에 존재하는 코드는 언제 누구든지 수정 가능 |
| Continuous Integration | 지속적인 통합 - 작업이 끝날때마다 지속적으로 통합되고 동시에 테스트 된다 |
| Simple Design | 단순설계 - 현재의 비즈니스 가치에 집중 - 내일을 고려하는 디자인은 최대한 배제한다. - Refactoring 을 통해 개선 |
| Test | - 항상 단위 테스트를 작성한다. - TFD (Test First Development) : 테스트 수행 후 검증코드로 작성해 나감 - 실제 코드를 작성하기 전에 먼저 테스트를 작성해 봄으로써 자신이 무엇을 해야하는지 스스로 깨우칠 수 있다. |
| Refactoring | - 기능변화 없이 중복제거, 단순화, 유연성 추가 1.Method 정의 - 지나치게 긴 Method 를 분리 - 지나치게 긴 문장을 Method를 사용하여 단순화 2.위치이동 - Method난 변수 위치를 적절한 Class로 이동 3.캡슐화 - 멤버변수를 Get/Set 사용하여 캡슐화 4.조건문 단순화 - 긴 조건문을 분할하거나 method 화 하여 단순화 5.이름변경 - 이해하기 쉬운 이름으로 변경 6.Indentation - 가독성이 있는 Indent로 재포맷 |
| 주40시간 | 주40시간 |
| On-Site Customer | 고객상주 - 프로젝트팀에 고객이 상주하여 즉각적인 의사소통과 피드백 - 품질향상의 필수요소 |
| Coding Standard | 코드표준을 통한 효과적인 의사소통 - 자신의 코드에 개발자의 이름, 연락처 - 주석 |
SCRUM
| 정의 | 짧은 개발주기에 반복적, 점진적 방법으로 개발 | ||
| 역할 | Scrum Team | - 일정 우선순위에 대한 권한 가짐 - Product Backlog 에서 Sprint 기간만큼 가져와서 Spring Backlog로 삼는다. - 4~5명 개발자 |
|
| Product Owner (제품책임자/스폰서) |
- Product Backlog 관리 | ||
| Scrum Master | Owner와 Team간의 의사소통 | ||
| 프로세스 | 회의 | Sprint Planning Meeting | 스프린트가 시작할 때 열림다. 회의는 하루종일 모두 참석 |
| Daily Scrum Meeting | 15 분 동안 서서 | ||
| Spring Review Meeting (with 고객) |
- 한달간의 스프린트를 마쳤을 때 잠재적 으로 출시가능한 소프트웨어를 고객에 게 Review 받는다. - 가능한한 비공식적 |
||
| Sprint Retrospective Meeting (with 팀) |
Master와 팀원은 다음 단계에서 개선해야 할 사항 검토 | ||
| 즉흥적인 데모요청을 거부하고 기능구현항목의 동결을 보장받는 대신, 납기내에 Sprint 목표달성 |
|||
XP와 SCRUM 비교
| XP | SCRUM | |
| 형태 | - 엔지니어링 방법 초점 - 프로그램 실천법에 집중 - Framework는 미포함 (X) |
- 개발 프로세스를 위한 Framework - 관리및 조직적 실천법에 집중 - 특정 엔지니어링 방법 미포함 |
| 개발주기 | 1~2 주 | 4~6주 |
| 변경사항수용 | Refactoring을 통한 변경사항 수용 즉 요구사항 변경 발생 인정 |
Refactoring을 통한 변경사항 수용 즉 요구사항 변경 발생 인정 |
| 우선순위 결정 | Customer | Team |
| 공통점 | Agile 방법론으로 짧은 개발주기로 반복 개발 | |
728x90
반응형
LIST
'소프트웨어공학' 카테고리의 다른 글
| EVM (Earned Value Management) : 획득가치관리 (0) | 2019.10.08 |
|---|---|
| EVM 과 Burn Down Chart 비교 (0) | 2019.10.07 |
| 에자일 (Agile) 개발 방법론 (0) | 2019.10.05 |
| 기능점수 (Function Point) - 3탄 (0) | 2019.10.04 |
| 기능점수 (Function Point) - 2탄 (0) | 2019.10.03 |