2018년 11월 27일
XP (eXtreme Programming)
I. SW 개발방법론의 Agility 강조, XP의 개요
가. XP (eXtreme Programming)의 정의
짧은 주기의 반복(Iteration)을 통해 요구 변화에 신속하게 대응하여 위험을 줄이고 고객 관점의 고품질 SW를 빠르게 전달하는 Agile 방법론의 기법
나. XP의 특징
개발자, 관리자, 고객 간 조화로 개발 생산성을 높이고자 하는 접근법
고객 요구사항 변경에 적극적, 긍정적으로 대처
다. XP의 등장배경
– RUP의 산출물 부담과 신속한 개발의 어려움
– Time to Market 실현과 Products의 적시 배포
– 프로세스 중심의 전통적 방법론으로는 변화의 유연한 수용에 한계
II. XP 프로젝트 개발 절차 및 절차 용어
가. XP 개발 절차
나. XP 개발 절차 용어
| 용어 | 설명 |
|---|---|
| 사용자 스토리 | 요구사항 수집, 의사소통 도구 기능단위 필요한 내용을 간단하게 기재 |
| 스파 이크 | 어려운 요구사항 혹은 잠재 솔루션을 고려한 간단한 프로그램 사용자 스토리의 신뢰성을 증대, 기술 문제의 위험 감소 목적 |
| 릴리즈 계획 | 전체 프로젝트에 대한 배포 계획 하나의 반복을 1 ~ 3주로 나누고 반복들을 균일하게 유지 |
| 승인 테스트 | 릴리즈 전 인수 테스트 고객이 수행 |
| 소규모 릴리즈 | 작은 배포는 XP 주기의 마지막 단계 소규모로 빈번하게 배포하면 고객에게 여러 이득을 조기 제공 |
– 요구사항을 바탕으로 일정 계획 수립하고 일정한 단위 소규모 배포 추구
III. XP 5가지 핵심가치와 12가지 실천사항
가. XP의 5가지 핵심가치(Core Value)
| 핵심가치 | 설명 |
|---|---|
| 용기 (Courage) | 고객의 요구사항 변화에 능동적인 대처 |
| 단순성 (Simplicity) | 부가적 기능, 사용되지 않는 구조와 알고리즘 배제 |
| 커뮤니케이션 (Communication) | 개발자, 관리자, 고객 간의 원활한 의사소통 |
| 피드백 (Feedback) | 지속적인 테스트와 반복적 결함 수정, 빠른 피드백 |
| 존중 (Respect) | 모든 프로젝트 관리자는 팀원의 기여를 존중 |
나. XP의 12가지 실천사항(Practice)
| 구분 | 내용 |
|---|---|
| 01. Planning game (= Planning process) | User story를 이용해서 next release의 범위를 빠르게 결정, 비즈니스 우선순위와 기술적 평가가 결합 |
| 02. Small/short releases | 필요한 기능들만 갖춘 간단한 시스템을 빠르게 프러덕션화 함, 아주 짧은(2주) 사이클로 자주 새로운 버전 배포 |
| 03. Metaphor | 공통의 name system(개발 및 커뮤니케이션 과정에서 공통된 개념을 공유 가능하게 함) |
| 04. Simple design 단순성 | 현재의 요구사항을 만족시키도록 가능한 한 단순하게 설계함 |
| 05. Testing | 개발자 먼저 단위 테스트, 고객은 기능 테스트를 작성하여 요구사항이 모두 반영되었는지를 확인 |
| 06. Refactoring | 프로그램의 기능을 바꾸지 안으면서, 중복제거, 커뮤니케이션 향상, 단순화, 유연성 추가 등을 위해 시스템 재구성 |
| 07.Pair programming | 하나의 컴퓨터에 두 사람이 앉아서 같이 프로그램 함 (Driver / partner) |
| 08. Collective ownership | 시스템에 있는 코드는 누구든지 언제라도 수정 가능함 |
| 09. CI(Continuous integration) | 하루에 몇 번이라도 시스템을 통합하여 빌드 할 수 있음 |
| 10. 40-hour week | 일주일에 40 시간 이상을 일하지 말도록 규칙으로 정하고 2주를 연속으로 오버 타임 하지 않도록 함 |
| 11. On-site customer | 개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀 타임으로 상주시킴 |
| 12. Coding standards | 팀원들 간 커뮤니케이션을 향상시키기 위해서는 코드가 표준화된 관례에 따라 작성되어야 함 |
V. 기존 개발 방법의 문제점 해결방안 및 고려사항
가. 기존 개발 방법의 문제점 해결을 위한 XP의 전략
| 구분 | 내용 |
|---|---|
| 관리측면 | 결정은 분산화, XP관리도구로 매트릭 이용, 코칭/트래킹/조정 |
| 계획측면 | 팀이 개발한 SW의 가치를 최대화, 임베디드 소프트웨어 가능한 적게 투자하고, 빠르게, 가장 가치 있는 기능 부여 |
| 설계측면 | 의사소통 통해 설계, 중복된 코드가 없을 것 → 단순하게 개발 가능한 클래스와 메소드 들은 적게 만들 것-> 변경에 유연 |
| 개발측면 | 지속적인 통합, 수정, 테스트, 배포 복잡한 코드 제거, Pair 프로그램으로 완벽한 코딩 |
| 테스트측면 | 각 테스트는 다른 부분과 관련이 없어야 함 → 테스트 자동화 테스트 프로그램 만드는 주체는 프로그래머 |
| 기타 | 계획세우기, 작은시스템릴리즈, 메타포등 12가지실천사항 병행 |
나. XP의 도입 시 고려사항
| 구분 | 고려사항 | 대응방안 |
|---|---|---|
| 재무관점 | 요구사항이 빈번히 변경 되어 예산 수립 어려움 | 개발기간 예측 및 관리로 정확도 향상 프로젝트관리기법 합리적 접목 |
| 고객관점 | 개발자 사용자간 공감대 형성 부족하면 생산성저하 | 요구사항 적극반영하고 SW를 자주 전달하여 신속 적용으로 고객 만족 |
| 내부관점 | 대규모 프로젝트 수행이 어려움 | 태스크 단위로 반복(Iteration)에 선택적 적용이 적합 |
| 학습 및 성장 | 산출물의 범위 변경 불가 능한 경우 적용 어려움 | 사용자나 개발자가 정확한 요구사항 도출 힘들때 적용, 잠재적가치 생성 |
| 개발자에게 기술요소에 대한 높은 숙련도 요구 | 구성원들의 이해와 공감 필요PM의 적극적인 방법론 실행의지 필요 |
About The Author
도리
One Comment
감사합니다! 덕분에 잘 개념정리 할 수 있었네요